故障轉移群集是一組相互獨立的計算機，通過協同工作改善群集角色（以前也叫做群集的應用程式與服務）的可用性與擴充套件性。群集的伺服器（叫做節點）通過物理線纜及軟體連線在一起。如果一個或多個群集結點故障，其他節點可繼續提供服務（這一過程叫做故障轉移）。此外群集角色可通過主動監控以驗證節點是否正常工作。如果沒能正常工作，則會重啟動或轉移到其他節點。故障轉移群集還提供了群集共享卷（CSV）功能，能為群集角色提供一致的分散式名稱空間，供群集節點訪問所有節點的共享儲存。通過使用故障轉移群集功能，使用者感受到的服務中斷可以降到最低。故障轉移群集有多種典型實用場景：

1) 為應用程式，例如 Microsoft SQL Server 及 Hyper-V 虛擬機器提供高可用或持續可用的檔案共享儲存。

2) 執行在物理伺服器或 Hyper-V 伺服器中所執行虛擬機器內的高可用群集角色，例如群集DHCP伺服器。

Windows Server 2012 R2故障轉移群集特點：

1. 建立最多包含64個節點的群集，對管理員的環境進行擴充套件，而老版本只能包含16個節點。

2. 通過對基礎架構進行擴充套件，每個群集最多可執行8,000個虛擬機器，每個節點最多可執行1,024個虛擬機器。

3. 具有控制虛擬機器群集管理和其他群集角色的功能。

4. 相比Windows Server 2008 R2，增加了對於擴充套件檔案伺服器的支援。

5. 支援群集感知更新 (CAU)，群集感知更新 (CAU)是一個自動化的功能，允許更新自動應用於群集伺服器中的主機作業系統，並且更新過程中的可用性損失極小或為零

6. 在執行 Windows Server 2012 R2的群集中，管理員可以配置對同時執行Windows Server 2012 R2的群集虛擬機器上的服務進行監視。

從虛擬化的角度來看，故障轉移群集提供了具備高可用性的虛擬機器。如果物理宿主機故障，執行在該宿主機中的虛擬機器也會中斷。這會造成破壞性關閉，並導致虛擬機器停機。然而由於物理節點是群集的一部分，因此剩餘群集節點可通過協調將停機的虛擬機器重新恢復，通過群集中的其他節點再次將其快速啟動。這一過程是自動化的，無需 IT 管理員干預，因此可確保群集中執行的負載比獨立物理伺服器中執行的負載具備更高級別的可用性。

在 Windows Server 2008 R2 及老版本中，在群集中執行虛擬機器要求虛擬機器必須使用共享的儲存。這個場景中的共享儲存意味著 iSCSI 或光纖通道連線的 SAN。在 Windows Server 2012 及後續的 Windows Server 2012 R2 中，故障轉移群集可支援將虛擬機器放置在檔案共享中，使用 SMB 3.0 協議通過網路訪問。這樣管理員在部署基礎結構時可獲得更大程度的靈活性，並能簡化部署與管理體驗。

對於依然希望利用 SAN 儲存作為共享儲存解決方案的客戶，強烈建議將 SAN 的 LUN 直接呈現給群集的每個節點，並將這些 LUN 作為群集共享卷使用。

一、 群集共享卷：

Windows Server 2012 R2 故障轉移群集的群集共享卷（CSV）功能使得群集的多個節點可以同時讀寫訪問同一個 LUN（磁碟）中供應的 NTFS 卷。通過使用 CSV，群集角色可從一個節點快速故障轉移至其他節點，同時無需更改驅動器的所有權，也無需斷開並重新載入卷。CSV 還有助於簡化故障轉移群集中大量 LUN 的管理工作。對於群集中的每個節點，CSV 都呈現為一致的檔案名稱空間，例如 C:\ClusterStorage\Volume1。CSV 以 NTFS 為基礎提供了針對一般用途的群集檔案系統，並且並非只能用於指定的群集負載。（在 Windows Server 2008 R2 中，CSV 只支援 Hyper-V 負載）。CSV 的應用包括：

1) 群集的虛擬磁碟（VHD）檔案，將其用於群集的 Hyper-V 虛擬機器。

2) 用橫向擴充套件檔案共享儲存應用程式資料，供橫向擴充套件檔案伺服器角色使用。這類應用程式數的例子包括 Hyper-V 虛擬機器檔案及 Microsoft SQL Server 資料。

1. 優化的 CSV 放置策略：

在故障轉移群集中，有一個節點被看做該 CSV 的所有者或“協調節點”。協調節點擁有關聯了邏輯單元號（LUN）的物理磁碟資源。所有針對檔案系統的 I/O 操作都需要通過協調節點進行。分散式的 CSV 所有權可改善磁碟效能，因為有助於對磁碟 I/O 進行負載平衡。

因為 CSV 所有權可以跨越所有群集節點進行平衡，節點所擁有的 CSV 數量將不再不對稱，因此如果一個節點故障，CSV 所有權的過渡將變得更高效。對於使用儲存空間的橫向擴充套件檔案伺服器群集，該功能非常重要，因為可確保儲存空間所有權的分散。

此外在 Windows Server 2012 R2 中，針對某些情況，例如 CSV 故障轉移、節點重新加入群集、為群集新增新節點、重啟動群集節點，或在關閉後重新啟動故障轉移群集，所有權可自動重新進行平衡。

2. 增強 CSV 的適應性：Windows Server 2012 R2 包含下列有關 CSV 適應性的改進：

1) 每個故障轉移群集節點多個伺服器服務例項。預設例項負責處理來自伺服器訊息塊（SMB）客戶端的傳入通訊並訪問檔案共享，輔助 CSV 例項處理節點間的 CSV 通訊。這種節點間通訊包括元資料訪問及 I/O 通訊重定向。

2) 伺服器服務的 CSV 健康度監控。

CSV 使用 SMB 作為群集節點間 I/O 轉發的傳輸方式，並用於實現元資料更新。如果伺服器服務變得不夠健康，就會影響 I/O 效能以及訪問儲存的能力。因為現在群集節點可以包含多個伺服器服務例項，因此如果預設例項遇到問題，CSV 將獲得更大程度的適應性。此外這一變化也改善了 CSV 節點間 SMB 通訊的擴充套件性。

如果伺服器服務變得不夠健康，可能會影響到 CSV 協調節點接受其他節點 I/O 請求的能力，以及執行元資料更新的操作。在 Windows Server 2012 R2 中，如果一個節點的伺服器服務變得不夠健康，CSV 所有權會自動轉移到其他節點，以保障適應性。

在 Windows Server 2012 中，每個節點的伺服器服務只有一個例項，同時伺服器服務也不受監控。

二、 Active Directory 分離的群集

在 Windows Server 2012 R2 中，可在不依賴 Active Directory 域服務（AD DS）作為網路名的情況下部署故障轉移群集。這種群集也叫 Active Directory 分離的群集。在使用這種方式部署群集時，群集網路名稱（也叫做管理訪問點）及客戶端訪問點所用的任何群集節點的網路名稱都需要在域名系統（DNS）中註冊。不過在 AD DS 中無需為這樣的群集建立計算機物件，包括群集本身的計算機物件（也叫做群集名稱物件，即 CNO），及在 AD DS 中為任何客戶端訪問點訪問群集角色時建立的物件（也叫做虛擬計算機物件，即 VCO）。（群集節點依然需要加入 Active Directory 域。）

通過這種部署方式，即可在原本不具備建立計算機物件所需許可權的 AD DS，或無需求助 Active Directory 管理員在 AD DS中更新計算機物件的情況下直接建立故障轉移群集。此外也無需為這樣的群集管理並維護群集計算機物件。例如，可以避免遇到 Active Directory 管理員無意中刪除群集計算機物件造成的問題，這種問題會對群集負載的可用性產生極大影響。

用於建立 Active Directory 分離群集的選項並未包含在 Windows Server 2012 中。在 Windows Server 2012 中，只能在 DNS 及 AD DS 中都存在群集網路名的情況下部署故障轉移群集。

Active Directory 分離的群集使用 Kerberos 對群集內通訊進行身份驗證。然而如果需要針對群集網路名進行身份驗證，此時群集將使用 NTLM 協議。

Windows Server 2012 與 Windows Server 2012 R2 群集還能不依賴 AD DS 啟動，因此對於在群集中執行虛擬化域控制器的資料中心，可提供更高程度的靈活性。

三、 群集仲裁及動態見證

群集的仲裁是由投票元素的數量決定的，該機制確保了群集能夠正常啟動並持續執行。一般來說，群集中的每個節點都有一個仲裁投票，此外仲裁見證（在配置後）可以有額外的一張仲裁投票。在 Windows Server 2012 中，可以為每個群集配置一個仲裁見證。仲裁見證可以是指定的磁碟資源或檔案共享資源。每個元素可通過投出自己的一“票”確定群集是否可執行。群集能否正常工作的仲裁結果是由活躍群集關係中大多數投票元素決定的。

為改善群集以及群集中所託管角色的可用性，群集仲裁配置的設定一定要慎重。

群集仲裁配置將直接影響整個群集的高可用性，原因在於：

1) 有助於確保在活躍成員關係產生變化後，故障轉移群集依然能正常啟動並持續執行。成員關係的變化可能是由於節點計劃內或計劃外關機，或節點與群集儲存之間連線的中斷導致的。

2) 當節點的子集無法與節點的其他子集（分裂式群集）通訊時，群集仲裁配置有助於確保群集中只有一個子集可以持續執行。缺乏足夠仲裁投票的子集將停止作為群集繼續執行。具備大多數仲裁投票的子集可繼續承擔群集角色。這樣即可避免群集產生分割槽，並確保同一個應用程式不會同時由多個分割槽承載。

群集環境下，使用群集完整功能的執行還取決於下列因素：

1）群集結點間的網路連線。

2）承載群集資源的每個節點所放置的容量。

3）群集角色的優先順序設定。

1. 見證配置：

作為一項常規規則，在配置仲裁時，群集中的投票元素必須是奇數。因此如果群集包含偶數個投票節點，就必須配置磁碟見證或檔案共享見證。群集可承受額外一個節點的故障。此外新增見證投票使得群集能夠在半數節點同時故障或斷開的情況下繼續正常工作。

如果所有節點都能訪問磁碟，則通常建議使用磁碟見證；如果需要通過複製儲存實現多站點災難恢復，則建議使用檔案共享見證。只有儲存供應商支援從所有站點讀寫訪問複製儲存時，才可以對包含複製儲存的環境配置磁碟見證。

2. 節點投票的分配“

在 Windows Server 2012 中，作為一種高階仲裁配置選項，管理員可以選擇針對每個節點分配或取消仲裁投票。預設情況下，所有節點都可投票，無論投票如何分配，所有節點都能在群集中正常工作，獲得群集資料庫的更新，並可承載應用程式。

在某些災難恢復配置下，管理員可能希望取消某些節點的投票。例如在多站點群集中，可以取消備份站點內節點的投票權，讓這些節點不影響仲裁的計算結果。但只建議對跨站點手工故障轉移的環境使用這種方式。

要檢視節點配置的投票選項，可使用 Get-ClusterNode Windows PowerShell cmdlet 檢視群集節點的通用屬性 NodeWeight。如果值為“0”，意味著該節點無法參與仲裁投票；如果值為“1”則意味著該節點將參與仲裁投票，並且受到群集的管理。所有群集節點的投票分配情況可使用 Validate Cluster Quorum 驗證測試加以驗證。

3. 動態仲裁管理：

在 Windows Server 2012 中，作為一個高階仲裁配置選項，管理員可以選擇啟用群集的動態仲裁管理。在啟用該選項後，群集可根據每個節點的狀態動態管理節點的投票分配情況。離開活躍群集關係的節點投票會被自動取消，重新加入群集的節點可重新獲得投票。預設情況下動態仲裁管理已被啟用。注意 – 通過動態仲裁管理，群集仲裁的大多數將由任意時刻位於群集活躍成員關係內的節點決定。這一點與 Windows Server 2008 R2 的群集仲裁有很大不同，以前的仲裁大多數是固定的，取決於初始群集配置。通過動態仲裁管理，群集還可以通過最後一個殘存的群集節點正常執行。通過動態調整仲裁大多數需求，群集可持續承受節點的關機，直到剩下最後一個節點。

群集為節點分配的動態投票可通過使用 Get-ClusterNode Windows PowerShell cmdlet 檢視群集節點的通用屬性 DynamicWeight 加以驗證。如果值為“0”，意味著節點沒有仲裁投票；值為“1”意味著節點有仲裁投票。

4. 動態見證：

在 Windows Server 2012 R2 中，如果群集被配置為使用動態仲裁（預設設定），見證投票也將根據當前群集關係中投票節點的數量進行動態調整。如果有奇數個投票，仲裁見證將不參與投票；如果有偶數個投票，仲裁見證將參與投票。

正如在上圖中看到的，對於這個包含 64 的節點的群集，我們使用了“節點及磁碟大多數”仲裁配置，並且這也是預設的推薦設定，但這一共就有了 64 張投票 – 偶數個。我們需要奇數個投票，因此使用見證磁碟作為第 65 個投票。然而如果即將失去一個節點，最後又剩下 63 個執行中的節點：

在本例中，負載已經故障轉移到其他節點，已關機節點的投票被取消。這樣我們就剩下 63 個節點，每個節點都有一票，再加上見證磁碟也有一票。這樣總共就有 64 張投票 – 又是偶數個。上文已經提過，我們需要確保投票數量為奇數，而在 Windows Server 2012 R2 中，我們可以自動將見證磁碟的票數調整為 0。群集仲裁也會自動調整，這一次將變為“節點大多數”。

仲裁見證投票也能根據見證資源的健康程度動態進行調整。如果見證資源離線或故障，群集會將見證投票設定為“0”。

動態見證功能極大降低了由於見證資源故障導致群集停機的風險。群集可根據目前可用的節點投票數量決定是否使用見證投票。

這一改動也極大簡化了群集見證的配置。管理員不再需要決定是否配置仲裁見證，因為 Windows Server 2012 R2 的推薦配置始終包含仲裁見證。群集可以自動決定何時使用見證。

四、 關閉時清空虛擬機器

在 Windows Server 2012 中，如果關閉群集結點前沒有清空節點，虛擬機器會被切換至儲存狀態，隨後轉移到其他節點上恢復。這意味著虛擬機器的可用性將產生中斷。如果儲存虛擬機器狀態所需時間太長，則可將虛擬機器關閉，然後在其他節點上重啟動。不過在 Windows Server 2012 R2 中，群集可自動在關閉前將執行中的虛擬機器實時遷移到其他節點。

這一變化提供了一種更安全的機制，可確保伺服器關閉（或任何需要關閉群集服務的情況）不會造成虛擬機器的計劃外停機。這樣的設計可提高來賓作業系統內所執行應用程式的可用性。

微軟官方建議管理員在關閉群集節點前先將其置於維護模式，或將所有虛擬機器移動到其他節點。這是清空執行中群集角色最安全的方式。

要啟用或禁用該功能，需要配置 DrainOnShutdown 群集通用屬性。預設情況下該屬性已啟用（值為“1”）。

五、 虛擬機器網路健康度檢測

在 Windows Server 2012 中，如果發生虛擬機器層面的網路中斷，此時雖然該虛擬機器對使用者不可用，但實際上依然在計算機上正常執行。

在 Windows Server 2012 R2 中，虛擬機器的設定介面新增了一個保護網路選項。如果受保護的虛擬網路斷開，群集會將受影響的虛擬機器實時遷移到外部虛擬網路可用的其他宿主機。為此群集節點間須有多個網路路徑。

該設定位於網路介面卡的高階功能下。預設情況下此設定已被啟用。管理員可以針對每個虛擬機器的每個網路修改該設定，因此如果有低優先順序網路，例如用於測試或備份的網路，可以選擇在這樣的網路斷開後不對虛擬機器進行實時遷移。

如果沒有可連線到群集其他節點的可用網路，群集會將此節點從群整合員關係中刪除，轉移虛擬機器檔案的所有權，然後在其他節點上重啟動這些虛擬機器。

這一變化提高了虛擬機器遇到網路問題的可用性。如果進行實時遷移，由於實時遷移可維持虛擬機器的會話狀態，因此不會產生停機。

六、 增強的群集儀表板

在 Windows Server 2012 中，需要點選每個故障轉移群集的名稱才能檢視狀態資訊。在 Windows Server 2012 R2 中，故障轉移群集管理器新增的群集儀表板可供管理員快速檢視所有被管理故障轉移群集的健康度狀態。管理員可以看到故障轉移群集的名稱，並通過圖示瞭解群集的執行狀態，群集角色的數量與狀態，以及節點狀態和事件狀態。

如果要管理多個故障轉移群集，該儀表板可讓管理員更方便地快速檢視故障轉移群集的健康度。

七、 虛擬機器監控

在執行 Windows Server 2012 與 Windows Server 2012 R2 的群集中，管理員可監控同樣執行 Windows Server 2012 或 Windows Server 2012 R2 的群集虛擬機器內的服務。管理員可以監控虛擬機器內的任何 Windows 服務（例如 SQL 或 IIS），或虛擬機發生的任何 ETW 事件。當管理員監控的條件被觸發後，群集服務會在宿主機的錯誤日誌中加以記錄，並執行恢復操作。這些操作可能是重啟動服務，或在其他節點上重啟動或移動群集虛擬機器（取決於服務重啟動設定叢集及故障轉移設定）。

只能在列表中看到使用自己的程序所執行的服務，例如 SQL、Exchange，但 IIS 與 Print Spooler 服務不受此規則限制。不過可以通過使用 Windows PowerShell Add-ClusterVMMonitoredItem cmdlet 設定監控任何 NT 服務 – 該命令無任何限制：

Add-ClusterVMMonitoredItem –VirtualMachine BJ-VM-03 -Service spooler

當被監控的服務遇到非預期故障，後續的恢復操作將由該服務的恢復操作決定。這些恢復操作可在來賓系統內部使用 Service Control Manager 檢視並配置。在下圖所示的例子中，在服務首次和第二次故障後，Service Control Manager 將重啟動這些服務，如果再次故障，Service Control Manager 將不執行任何操作，並將恢復操作交由宿主機所執行的群集服務負責處理。

群集服務通過定期健康度檢查監控群集虛擬機器的狀態。當群集服務確定某個虛擬機器處於“關鍵”狀態，例如虛擬機器內部的應用程式或服務處於不健康狀態，群集服務將執行下列恢復操作：

1) 宿主機記錄 ID 1250 事件 – 隨後可通過集中化的監控解決方案加以監控，例如 System Center Operations Manager。

2) 故障轉移群集管理器內的虛擬機器狀態將顯示該虛擬機器處於“應用程式關鍵”狀態。

3) 針對“應用程式關鍵”狀態的虛擬機器執行恢復操作。首先在同一個節點上重啟動該虛擬機器。請注意 – 虛擬機器的重啟動是強制不允許取消的。如果第二次故障，虛擬機器將重啟動並故障轉移到群集的其他節點。請注意 – 故障轉移，或在同節點上重啟動，這個決定是可配置的，並可由虛擬機器的故障轉移屬性決定。

八、 故障轉移優先順序，相關性及反相關性

1. 優先順序

在 Windows Server 2012 及後續的 Windows Server 2012 R2 中，故障轉移提供的新功能使得管理員能夠定義群集中虛擬機器的啟動順序，這樣一旦遇到故障，有大量虛擬機器需要儘快重啟動，取決於選項設定，部分虛擬機器可被優先進行重啟動處理。

該功能可以幫助管理員確保如果故障轉移導致資源佔用率過高，最重要的虛擬機器始終可以優先獲得所需的全部資源，隨後才開始處理重要性次高的虛擬機器。

另外在節點故障後，如果高優先順序虛擬機器無法獲得所需的足夠記憶體和其他資源以完成啟動操作，群集服務會暫時讓低優先順序的虛擬機器離線。隨後釋放出來的資源可分配給高優先順序虛擬機器。在必要時，可搶佔啟動最低優先順序的虛擬機器，隨後繼續啟動高優先順序虛擬機器。搶佔啟動的虛擬機器會按照優先順序順序重啟動。

2. 相關性

在 Windows Server 2012 與 Windows Server 2012 R2 故障轉移群集中，管理員可以配置首選和可能所有者。

對於特定虛擬機器（從技術上說，可以是任何群集組），可對故障轉移時所用節點的順序進行配置。假設該虛擬機器通常在節點 A 上執行，管理員希望在可行的情況下儘量將其轉移到節點 C，那麼就可通過首選所有者選項定義最先轉移到的節點，隨後轉移到的節點，以及後續轉移到的節點。這是一種優先順序列表，群集將通過該列表確定虛擬機器的放置位置。因此管理員可以明確控制虛擬機器的位置。

另一方面，可能的所有者則是指，對於特定虛擬機器（從技術上說，可以是任何群集資源），可以配置虛擬機器在故障轉移時可能放置到的節點。預設情況下這是指所有節點，但如果不希望將任何虛擬機器故障轉移到某個特定節點，則可將其從可能的所有者列表中刪除，防止轉移到該節點。

3. 反相關性

可能的所有者是一種儘量確保相關虛擬機器相關虛擬機器分散在不同節點上的做法，每個虛擬機器都有相對獨立的可能的所有者，不過還有另一種方式實現這一點。

AntiAffinityClassNames 是另一個群集組屬性，Windows 故障轉移群集使用該屬性確定不應位於同一個節點的群集組。在使用群集的 Hyper-V 環境時，群機組與虛擬機器之間存在 1:1 的關係，因此可以使用 AntiAffinityClassNames 屬性為虛擬機器配置反相關性。

一旦配置完畢，故障轉移群集會盡可能試圖確保屬於同一個組的虛擬機器分散到群集不同節點上。與故障轉移優先順序與首選的和可能的所有者功能配合使用後，即可更細化地控制重要虛擬化負載的放置。

九、 群集感知更新

在老版本 Windows Server 中，伺服器更新工具（例如 WSUS）無法考慮一組伺服器可能是高可用群整合員這種情況。由於高可用群集的目的是為群集中託管的服務提供高可用性，因此絕不能同時對群集的所有節點安裝補丁。故障轉移群集的補丁安裝工作通常需要分批手工進行，或使用專門的指令碼/工具，同時需要管理員加以密切關注，在每月一次短暫的維護視窗內為所有節點成功安裝補丁。

群集感知更新（CAU）是 Windows Server 2012 R2 內建的一個重要功能，解決了這個問題。CAU 可供管理員對群集伺服器進行更新，而更新過程幾乎不會影響可用性，或者只產生最少量的影響。在進行更新的過程中，CAU 會用透明的方式將群集每個節點設定為節點維護模式，將“群集角色”臨時故障轉移到其他節點，為節點安裝更新和其他必要內容，需要時執行重啟動操作，讓節點退出維護模式，將最初的群集角色重新轉移到這個節點上，並對下一個節點執行更新。CAU 的工作與具體負載無關，非常適合 Hyper-V 及各種檔案伺服器負載。

尤其是從 Hyper-V 的角度來看，CAU 能與故障轉移群集功能配合使用，將執行中的虛擬機器遷移到不同物理節點，這樣即可確保虛擬機器中執行的重要應用程式和負載不會停機，同時宿主機設施也能安裝必要的更新，隨時保持最新狀態。

管理員觸發 CAU 掃描後，CAU 會配合節點本身令其針對更新源執行更新檢查工作，例如更新源可能是 Microsoft Update、Windows Update，或 WSUS。

CAU 可幫助企業促進 IT 程序的一致性。針對不同型別的故障轉移群集可建立更新執行配置檔案，並能通過檔案共享集中管理，以確保整個 IT 機構內所部署的 CAU 能用一致的方式應用更新，就算群集是由其他業務線或管理員負責管理的也不受影響。

更新的執行可安排計劃，每天、每週，或每月進行，這樣即可確保群集的更新與其他 IT 管理流程保持一致，而 CAU 提供了一種可擴充套件架構，能用可感知群集的方式對群集軟體清單進行更新。這樣開發商即可對並非通過 Windows Update 或 Microsoft Update 釋出的軟體更新，或並非來自微軟的更新安裝情況進行協調，例如非微軟裝置的驅動更新。

CAU 的自行更新模式促成了一種“一體式群集”裝置（一套執行 Windows Server 2012 與 Windows Server 2012 R2，通常安裝到一個機箱內的群集環境）自行更新操作。一般來說，這類裝置都部署在分支辦公室，缺乏管理群集的本地 IT 人員。自行更新模式能為這類環境提供巨大的價值。

CAU 有兩種模式：下文第一張圖所示的自行更新模式，以及第二張圖所示的遠端更新模式。

在自行更新模式中，需要在一個節點上執行 CAU 角色，並充當更新工作的協調者。更新協調者這個節點確保了整個群集都能順利安裝更新。CAU 角色也是可以感知群集的，因此 CAU 更新協調者角色可由多個節點承擔 – 但同一時間只能有一個節點是更新協調者。

另一方面，遠端更新模式使得執行 Windows Server 2012、Windows Server 2012 R2、Windows 8 或 Windows 8.1 的遠端計算機可以充當 CAU 更新協調者。這種方法最適合使用 CAU 對 Windows Server 2012/R2 伺服器核心作業系統安裝更新，並且需要實時看到更新進度的情況。

要部署故障轉移群集，並充分利用故障轉移群集的其他功能，需滿足下列條件：

1. 帶 Hyper-V 的 Windows Server 2012 R2 或 Hyper-V Server 2012 R2。

2. 對於群集共享卷，需要共享儲存，並通過 iSCSI 或光纖通道連線。

3. 對於虛擬機器監控，需要建立相應的防火牆例外，並提供所需的域配置。

4. 對於群集感知更新，需要 WSUS 基礎結構，或從一個群集節點連線到網際網路以訪問 Microsoft/Windows Update。

十、 來賓群集

在 Windows Server 2012 Hyper-V 中，微軟為虛擬機器本身的虛擬化工作提供了完整的支援，從群集到來賓作業系統全都包含在內。例如群集的 SQL AlwaysOn 配置，其本身就需要多個節點，所有節點都為虛擬機器，並且還需要訪問共享儲存。該配置看起來類似下圖所示：

在上述例子中有一個簡單的三節點 Hyper-V 物理群集，在該群集基礎上使用兩個虛擬機器建立了兩節點來賓群集，這些節點都能直接訪問共享儲存。使用共享儲存的來賓群集在微軟平臺中可充分利用多種不同儲存選項所提供的優勢。舉例來說，如果使用 SMB 儲存作為 Hyper-V 群集的主要儲存方式，則該 SMB 儲存還可通過網路供應給虛擬機器使用。通過這種方式，虛擬機器即可藉助虛擬網路介面卡訪問 iSCSI 儲存。然而這些場景都需要通過虛擬網路介面卡將底層儲存設施直接提供給虛擬機器，而非使用共享儲存上儲存的 VHD 或 VHDX 檔案。

Windows Server 2012 中首次引入了虛擬光纖通道。正如上文介紹的，通過該技術可將虛擬光線儲存直接供應給虛擬機器，並能通過訪問共享儲存直接構建來賓群集。

上文曾提過，來賓群集配置可得到微軟的完整支援，並可配合其他功能，例如實時遷移與動態記憶體等功能使用，這意味著客戶能夠將群集負載虛擬化，並且不會影響密度和敏捷度等重要特性。此外來賓群集能通過故障轉移優先順序、相關性，及反相關性等上文介紹的功能獲益，可確保來賓群集節點能以在相互之間，以及與底層物理宿主機之間最優化方式放置。

來賓群集的優勢是可提供額外的一層適應性。如果物理宿主機故障，只會導致來賓群集的一個節點子集遇到故障，來賓群集所提供的應用程式級別的適應性依然能夠快速恢復負載。

當物理節點故障了，之前在該節點執行的虛擬機器也停止執行，但物理 Hyper-V 群集可確保虛擬機器在其他節點所執行的來賓群集虛擬機器中快速重啟動。應用程式級別的適應性確保了從整體來看，應用程式或負載只會經歷一個短時間的停機。

然而挑戰之處在於，在這些配置中，底層儲存（FC、iSCSI、SMB）需要直接供應給虛擬機器。在私有或公共雲環境中，通常需要為使用者或租戶管理員隱藏底層設施細節。

PS：文章在寫作的同時參考有微軟TechNet。

轉載於:https://blog.51cto.com/ericxuting/1597930