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