失去網路連接時的 hyper-v 集群行為
設置：
- （相當新）具有 2 個節點的 Hyper-V R2 集群（在故障轉移配置中）。實際主機作業系統：Windows Server 2008。
- 大約 8 個虛擬機（混合：Windows Server 2008 和 Linux）
昨天我們停電了大約 15 分鐘。
我們的刀片安裝在 UPS 上，因此實際主機 (Windows Server 2008) 從未停機。我們的主開關（尚未）在 UPS 上，我們看到類似於以下的行為（從事件日誌中提取）。
- 集群中的節點失去了通信方式（因為外部交換機關閉）。
- 集群想要關閉一個（的
first）節點（啟動故障轉移？）。- 上一步會影響虛擬機 VHD 所在的集群儲存。
- 所有虛擬機都被殘酷地終止，並且在主機作業系統的故障轉移管理器中被發現處於故障狀態。Linux VM 的核心恐慌，看起來他們的磁碟被撕掉了。
整個設置對我們來說相當新，所以我們仍在學習這一點。
問題：
我們很快就會打開 UPS 開關，但想知道上述行為是否是預期的行為（似乎相當脆弱），或者在配置方面是否有明顯的改進來處理這種情況？
如果有必要，我可以上傳一個
evtx關於到底發生了什麼的文件。
該行為最可能的解釋與仲裁配置有關。看看http://technet.microsoft.com/en-us/library/cc731739.aspx。
基本上，當您的網路交換機出現故障時，兩個節點之間就會失去通信。那時，兩個節點都不知道另一個節點在做什麼。如果一個節點決定它將承擔所有集群資源（即虛擬機）的所有權並啟動它們，誰能說另一個節點不會做同樣的事情呢？您最終會遇到兩個節點都試圖完全擁有所有虛擬機的情況，並且您手上會遇到一些非常討厭的硬碟驅動器損壞。
Quorum 配置解決了這個問題，說明為了讓節點執行，它必須與大多數節點（並且可選地，磁碟或文件共享）保持聯繫。如果它不能做到這一點，它將停止作為集群成員執行。
要驗證是否是這種情況，請打開故障轉移群集管理器並檢查群集摘要頁面上的“仲裁配置”。如果它是Node Majority並且您有偶數個節點，那麼我所描述的幾乎可以肯定是發生了什麼。
解決方案是設置一個稱為 Disk Witness 的小磁碟（50 MB 綽綽有餘）並將其添加到集群的儲存中（但不是集群共享卷）。然後，將 Quorum Configuration 更改為Node and Disk Majority。使用此設置，如果您遇到與以前相同的故障，則在故障時擁有磁碟所有權的節點將繼續執行（並且實際上將承擔來自另一個節點的所有資源的所有權），而另一個節點會停下來。故障轉移到執行節點的虛擬機將經歷一次殘酷的重啟，但至少它們會盡快上線。
正如您所說，理想的情況是將您的開關也放在 UPS 上。那將完全防止失敗；但是，您還應該確保使用推薦的仲裁配置來滿足您擁有的節點數量。