如何加快 Hyper-V 2012 群集的自動故障轉移？
當我第一次設置 2 節點 Hyper-V 2012 集群時，故障轉移幾乎是即時的。我有一個分配了 8GB RAM 的 Sql Server 2012（在 Win2012 上）VM。我可以反彈它所在的節點，它會跳轉到另一個節點而不會斷開我的 Sql 連接。
然後我在集群中添加了第二個虛擬機（第一個虛擬機的複製），也是 8GB。現在故障轉移需要幾秒鐘，我的 Sql 連接會重置。它是必須移動的 RAM 量的一個因素嗎？受網路影響嗎？是仲裁磁碟的速度嗎？
就我而言，兩個節點都連接到同一個 DAS，並且 VM 文件位於 CSV 上。我希望磁碟不是一個因素，因為不需要移動任何東西。應該都是記憶體吧？那麼隨著 RAM 的增加，故障轉移性能會降低嗎？
回想起來，我想我應該知道的。答案分為兩部分，因為在我看來，有計劃的故障轉移和“真正的”/計劃外的故障轉移——計劃的故障轉移不算在內。
計劃的故障轉移
計劃中的故障轉移實際上只是集群系統耗盡節點，然後為您重新啟動它。因此，當您通過 RDP 或集群應用程序 GUI 中的“停止集群服務”直接重新啟動節點時，首先會發生虛擬機實時遷移關閉。因為您實際上只是在實時遷移虛擬機，所以所需時間取決於需要傳輸的內容和網路連接。如果您有 1Gb 網卡，則需要一段時間（~118MB/秒）。您的 VM 擁有的 RAM 越多，更快的 NIC 將為您提供更好的服務。
真正的故障轉移
計劃外/“真正的”故障轉移是在您拔下機器時。在這種情況下，集群系統會自動在另一個節點上啟動 VM。對外界的行為與重新啟動 VM 相同。對於虛擬機來說，這就像你“關閉它”然後重新啟動它一樣。因此，“真正的”故障轉移始終與您的虛擬機啟動所需的時間有關。
相切
從概念上講，這對我來說是一個失望，因為我覺得網路上的所有集群討論都表明集群系統隱藏了一個（“硬”）節點故障——它應該就像服務永遠不會下去了。我記得讀過的所有網頁都在軟體中測試了它們的集群故障轉移（計劃的故障轉移），這很可能傳播了這一事實。所以他們真正做的只是證明 Live Migration 像宣傳的那樣工作（從客戶的角度來看沒有停機時間）。
我的主要錯誤是誤解了故障轉移本身。除了在熱伺服器上發生自動故障轉移的熱/溫/冷備份伺服器的概念之外，還有熱/溫/冷故障轉移。如此處所述，熱故障轉移是即時的，熱故障轉移以秒為單位，冷故障轉移以分鐘為單位。我天真地認為所有自動故障都是“熱的”。我想我期待 RAM 有某種魔力，集群會在另一個節點上更新 VM 的 RAM 副本——就像使用 Sql Server 傳送事務日誌一樣。但這需要機器之間的通信通道至少與 RAM 一樣快，以保證它能夠正常工作。