叢集集合能夠將多個各自運作的容錯移轉叢集，透過「鬆散耦合」方式將資源彙整叢集，建構出一個採用「統一儲存命名空間」的超大型融合式容錯移轉叢集。為此，本文將對叢集集合做深入剖析，並實際操作示範。
在現代化IT基礎架構中，企業組織的資料中心架構，已經從過去單獨或多個各自運作的容錯移轉叢集，轉變成「軟體定義資料中心」（Software Defined Data Center，SDDC）的運作架構，如圖1所示。因此，在軟體定義資料中心（SDDC）的架構下，多個容錯移轉叢集之間，不僅能夠互相支援達到負載平衡，並且當災難發生時更能夠達到容錯移轉的目的。
圖1 在SDDC軟體定義資料中心架構下多個容錯移轉叢集運作架構示意圖。 （圖片來源：Microsoft Docs - Windows Server Software-Defined Datacenter）
新一代雲端作業系統Windows Server 2019，新增了「叢集集合」（Cluster Set）容錯移轉叢集特色功能。簡單來說，叢集集合能夠將多個各自運作的容錯移轉叢集，透過「鬆散耦合」（Loosely-Coupled）的方式將資源彙整，也就是將多個容錯移轉叢集把運算、儲存、網路等硬體資源融合在一起，建構出一個採用「統一儲存命名空間」（Unified Storage Namespace）的超大型融合式容錯移轉叢集。
那麼對於企業和組織來說使用叢集集合能夠帶來什麼好處？首先，對資料中心的維運人員來說，過去所有的管理經驗和工具都能持續使用無須變更，同時多個容錯移轉叢集雖然融合為一個超大型容錯移轉叢集，但是每個容錯移轉叢集仍然具備獨立性和彈性。
舉例來說，管理人員倘若有兩個不同儲存資源的S2D HCI超融合容錯移轉叢集，其中一個HCI叢集採用Hybrid（SSD+HDD）儲存資源，另一個HCI叢集採用All-Flash（NVMe+SSD）儲存資源，那麼企業便可以將正式營運環境或需要大量儲存資源的VM虛擬主機，運作在採用All-Flash儲存資源的HCI叢集上，而第二線營運服務或測試用途的VM虛擬主機，則運作在Hybrid儲存資源的HCI叢集即可。
此外，採用叢集集合也能增加容錯移轉叢集的可用性，例如，企業和組織建構一個具有8台節點主機的HCI叢集，資料保護則採用自動複寫三份的3-Way Mirror方式進行保護，但是當這個HCI叢集發生重大災難事件，導致3台節點主機發生故障無法服務，那麼仍然會導致VM虛擬主機無法運作並且遺失資料。
同樣的基礎架構運作環境，企業和組織分別建構兩個HCI叢集，並且每個HCI叢集具備4台節點主機，並且同樣採自動複寫三份的3-Way Mirror方式進行資料保護，當災難事件發生時，其中一個HCI叢集2台節點主機發生故障無法服務，另一個HCI叢集1台節點主機發生故障無法服務。此時，運作在兩個HCI叢集中的VM虛擬主機，仍然能夠持續正常運作並且不會發生任何資料遺失的情況。
剖析叢集集合運作架構
事實上，透過叢集集合的運作機制，能夠幫助企業和組織在自家地端資料中心內，輕鬆建構出類似Azure公有雲環境中，高可用性和叢集生命週期管理的「容錯網域」（Fault Domains）和「可用性集合」（Availability Sets）機制，如圖2所示。
圖2 Azure容錯網域和可用性集合機制運作架構示意圖。 （圖片來源：Microsoft Docs - Manage the availability of Windows VMs in Azure）
叢集集合運作架構和角色
在開始實戰演練叢集集合技術之前，必須先了解叢集集合的運作架構和角色，如圖3所示，以便稍後實作演練時能夠順利地建構叢集集合，並且在後續發生問題時能夠進行故障排除作業。
圖3 叢集集合運作架構示意圖。 （圖片來源：Microsoft Docs – Cluster Sets）
‧管理叢集：在叢集集合運作架構中，擔任「管理叢集」（Management Cluster）角色的容錯移轉叢集，將會負責指揮和承載整個叢集集合的高可用性管理的工作任務，並且採用「向外延展檔案伺服器」（Scale-Out File Server，SOFS）機制，提供對外服務和統一的「叢集集合命名空間」（Cluster Set Namespace）。在一般情況下，擔任管理叢集角色的容錯移轉叢集，並不會運作任何VM虛擬主機的工作負載，除非發生重大災難事件或特殊情況。
‧成員叢集：擔任「成員叢集」（Member Cluster）角色的容錯移轉叢集，通常會建構新一代的S2D超融合容錯移轉叢集，並且運作大量的VM虛擬主機或容器等工作負載，並且加入叢集集合運作架構中的「容錯網域」（Fault Domains）和「可用性集合」（Availability Sets）。
‧叢集集合命名空間轉介至SOFS：由管理叢集透過SOFS機制所建構的唯一叢集集合命名空間，而這個SOFS轉介採用的SMB共享機制，為新一代Windows Server 2019雲端作業系統中新增的「SimpleReferral」特色功能，讓SMB Client的存取作業能夠自動導向至適合的成員叢集。由於這個特殊的SOFS為輕量級的轉介機制，所以不會參與SMB I/O路徑，這也是一般情況下管理叢集不會運作VM虛擬主機和容器等工作負載的主要原因。
‧主要叢集集合：在叢集集合運作架構中多個成員叢集彼此之間，將會透過機制自動選舉出「主要叢集集合」（Cluster Set Master，CS-Master）角色，並採用新式的叢集集合WMI提供者機制，與成員叢集進行互相通訊，以便因應管理叢集或成員叢集發生災難事件時執行復原程序。
‧工作者叢集集合：每個成員叢集都會運作一個「工作者叢集集合」（Cluster Set Worker，CS-Worker）執行個體，並且與CS-Master角色互相通訊，以便將成員叢集的硬體資源和VM虛擬主機存放資訊提供給CS-Master角色，以利後續運作VM虛擬主機和容器等工作負載。
‧容錯網域：一般來說，企業組織的資料中心管理人員，會將同一組可能發生故障的成員叢集，指定為同一個「容錯網域」（Fault Domains），例如這些成員叢集內的成員主機，共用同一個機櫃中的PDU機櫃排插，或連接至同一台網路交換器。但是，不管成員主機是否同為一個容錯網域，都可以加入可用性集合內。
‧可用性集合：透過「可用性集合」（Availability Sets）機制，為叢集集合內運作的VM虛擬主機或容器等工作負載提供高可用性機制。在微軟官方的最佳建議作法中，倘若要保持VM虛擬主機或容器的高可用性，應該將VM虛擬主機和容器等工作負載，運作在可用性集合內「不同」的兩個容錯網域，好讓其中一個容錯網域發生災難事件時，仍然能夠保持服務的高可用性。
叢集集合的常見疑問
至此，雖然已經說明叢集集合的運作架構和角色，但管理人員可能仍然對叢集集合有其他疑問，例如叢集集合是否僅支援採用新式的S2D超融合容錯移轉叢集才能建構，倘若採用舊式共享儲存設備建構的Hyper-V容錯移轉叢集，是否也能加入叢集集合當中？以下條列出剛開始接觸叢集集合的管理人員最常見疑問的快問快答：
Q：叢集集合是否僅支援S2D超融合容錯移轉叢集？
A：當然不是！管理人員可以在叢集集合中，同時混用傳統共享式儲存設備的Hyper-V容錯移轉叢集，以及新式的S2D超融合容錯移轉叢集。
Q：可以透過SCVMM管理叢集集合嗎？
A：不行！目前僅支援採用PowerShell或WMI管理和組態設定叢集集合，而SCVMM管理工具尚未支援叢集集合。
Q：舊有的容錯移轉叢集能否加入叢集集合？
A：不行！由於叢集集合技術是新一代Windows Server 2019的新增功能，因此不支援舊有的Windows Server 2012 R2或2016的容錯移轉叢集直接加入至新式的叢集集合當中。但是，原來舊有的Windows Server 2012 R2或2016的容錯移轉叢集，可以先透過滾動升級至Windows Server 2019的方式，再加入至新式的叢集集合。
Q：在叢集集合架構中，能否僅擴充儲存空間或運算資源？
A：可以！資料中心的管理人員，可以隨著企業組織的工作負載需求，擴充成員叢集內的成員主機數量或硬體資源，或是新增成員叢集至容錯網域和可用性集合內，來達到擴充儲存或運算資源的目的。
Q：叢集集合是否支援VM虛擬主機跨不同處理器遷移？
A：不行！事實上，這並非是叢集集合的限制而是Hyper-V虛擬化平台的限制，倘若真的需要進行跨CPU處理器世代的遷移，目前僅支援採用「快速遷移」（Quick Migration）搭配處理器相容模式達成。因此，建議叢集集合內的成員叢集伺服器應該採用相同世代的CPU處理器，以便VM虛擬主機能夠在叢集集合內不同的成員叢集之間進行遷移。
Q：叢集集合是否支援IPv6網路環境？
A：可以！與傳統容錯移轉叢集一樣，都支援IPv4和IPv6網路環境。
Q：叢集集合對於Active Directory的要求是什麼？
A：所有成員叢集必須處於同一個Active Directory樹系當中。
Q：叢集集合支援多少台叢集節點？
A：在Windows Server 2019運作環境中，微軟已經建構並測試可支援至64台叢集節點。事實上，叢集集合可以支援更大的運作規模，就像Azure公有雲一樣，倘若企業和組織需要超大型運作規模時，可以向微軟請求專業技術支援。
Q：叢集集合內的S2D成員叢集是否能匯整成更大的儲存資源？
A：不行！目前的S2D技術仍僅支援在單一叢集中運作，尚未支援將多個成員叢集的S2D儲存資源進行匯整。
實戰叢集集合
在實作環境中總共建立三個容錯移轉叢集，分別是擔任管理叢集的「MGMT-Cluster」，以及兩個擔任成員叢集的「MBR-Cluster01」、「MBR-Cluster02」，如圖4所示，其中成員叢集採用S2D超融合建構，並且每個成員叢集中有兩台叢集節點主機。
圖4 實作叢集集合運作環境。
建立叢集集合
當叢集集合運作環境準備完成後，管理人員便可以執行New-ClusterSet指令建立叢集集合，在本文實作環境中，叢集集合的名稱為「CS-Master」，而屆時存取的叢集集合命名空間為「SOFS-ClusterSet」。
至於負責管理叢集工作任務的容錯移轉叢集名稱則是「MGMT-Cluster」，最後指定叢集集合名稱CS-Master使用的固定IP位址為「10.10.75.40」，如圖5所示。
圖5 建立叢集集合，並指定命名空間以及使用的固定IP位址。
當叢集集合順利建立完畢，切換至MGMT-Cluster管理叢集中，如圖6所示，將發現系統已經自動新增「Infrastructure File Server」、「Scaleout Master」這兩個角色。
圖6 管理叢集自動新增Infrastructure File Server和Scaleout Master角色。
加入成員叢集
叢集集合中的管理叢集已經成形，接著執行Add-ClusterSetMember指令將成員叢集加入，在本文實作環境中，兩個成員叢集的名稱為「MBR-Cluster01」、「MBR-Cluster02」，而屆時運作工作負載的SOFS名稱則是「MBR01-SOFS」、「MBR02-SOFS」，如圖7所示。
圖7 加入兩個成員叢集至叢集集合中。
同樣地，當兩個成員叢集順利加入叢集集合後，切換至MBR-Cluster01或MBR-Cluster02成員叢集時，如圖8所示，將發現系統已經自動新增「Infrastructure File Server」、「Scaleout Worker」這兩個角色。
圖8 管理叢集自動新增Infrastructure File Server和Scaleout Worker角色。
除了透過容錯移轉叢集管理員進行查看外，後續管理人員也可以隨時以PowerShell指令查詢叢集集合運作環境。接著，先執行「Get-ClusterSet」指令來查詢叢集集合中管理叢集和SOFS叢集集合命名空間，再執行「Get-ClusterSetMember」指令，查詢成員叢集的叢集名稱和運作狀態，最後透過「Get-ClusterSetNode」指令查詢成員叢集中節點主機名稱和運作狀態，如圖9所示。
圖9 查詢叢集集合、管理叢集、成員叢集、節點主機等運作狀態。
檢查叢集集合命名空間功能
叢集集合中的管理叢集和成員叢集已經建立完成，在開始下一步動作之前，先確認叢集集合命名空間的SOFS轉介機制是否運作正常，確保屆時SMB Client存取作業能夠自動導向至適合的成員叢集。
在管理叢集中執行Get-SmbShare指令，即可看到叢集集合命名空間「SOFS-ClusterSet」，以及屆時轉介至成員叢集所對應的SOFS儲存路徑和儲存資源「MBR01-Volume」、「MBR02-Volume」，如圖10所示。
圖10 檢查叢集集合命名空間是否運作正常。
除了透過指令檢查外，管理人員也可以開啟檔案總管，透過UNC路徑的方式存取叢集集合命名空間「\\SOFS-ClusterSet」，同樣可以看到轉介至成員叢集所對應的SOFS儲存路徑和儲存資源「MBR01-Volume」、「MBR02-Volume」，如圖11所示。
圖11 透過UNC路徑的方式存取叢集集合命名空間。
建立容錯網域
在本文實作環境中，兩個成員叢集分別部署在不同的機櫃，並且叢集節點採用不同的PDU機櫃排插，同時也連接至不同台網路交換器。因此，為了讓屆時運作於叢集集合中的工作負載具備高可用性，這裡將兩個成員叢集指定為不同的容錯網域。此時，執行New-ClusterSetFaultDomain指令，指定MBR-Cluster01成員叢集的容錯網域名稱為「FD1」，指定MBR-Cluster02成員叢集的容錯網域名稱為「FD2」，如圖12所示。
圖12 指定兩個成員叢集分別為不同的容錯網域。
在建立容錯網域之後，透過Get-ClusterSetFaultDomain指令，即可查詢每個容錯網域包括哪些成員叢集，以及每個成員叢集的詳細資訊，如圖13所示。
圖13 查詢容錯網域包括哪些成員叢集和運作資訊。
建立可用性集合
建立多個容錯網域後，最後透過可用性集合的方式將多個容錯網域包括至其中，屆時即可為叢集集合內運作的VM虛擬主機或容器等工作負載提供高可用性機制。在本文實作環境中，執行New-ClusterSetAvailabilitySet指令，建立名稱為「AvailabilitySet」的可用性集合，如圖14所示。
圖14 建立可用性集合。
組態設定即時遷移權限
為了因應叢集集合中，成員叢集工作負載進行負載平衡，或者發生災難事件時能夠進行「即時遷移」（Live Migration），因此必須為成員叢集中每台叢集節點主機的電腦帳戶，組態設定即時遷移權限，並且將管理叢集的電腦帳戶新增至每台叢集節點主機的本機Administrators群組成員中。
舉例來說，在MBR-Cluster01成員叢集中，共有兩台叢集節點主機Node01、Node02，必須為電腦帳戶組態設定權限委派作業，信任另一個MBR-Cluster02成員叢集中，叢集節點主機Node11、Node12，服務類型為「cifs」、「Microsoft Virtual System Migration Service」，如圖15所示。同樣地，在MBR-Cluster02成員叢集中，叢集節點主機Node11、Node12，必須為電腦帳戶組態設定權限委派作業，信任另一個MBR-Cluster01成員叢集中，叢集節點主機Node01、Node02，服務類型為「cifs」、「Microsoft Virtual System Migration Service」。
圖15 為叢集節點主機組態設定電腦帳戶權限委派作業。
接著，將管理叢集的「MGMT-Cluster」電腦帳戶，新增至每台叢集節點主機Node01、Node02、Node11、Node12的本機Administrators群組成員中，如圖16所示。
圖16 將管理叢集電腦帳戶新增至每台叢集節點主機本機Administrators群組成員中。
部署VM虛擬主機至叢集集合
在叢集集合運作環境中建立VM虛擬主機時，可以透過檢查機制讓即將部署的VM虛擬主機，能夠在獲得最佳資源的叢集節點主機上運作。例如，可以透過Get-ClusterSetOptimalNodeForVM指令，檢查目前叢集集合中，哪一台叢集節點主機最適合部署資源需求「2 vCPU、8GB vRAM、10% CPU運算資源」的VM虛擬主機。如圖17所示，可以看到系統建議依據資源需求條件，VM虛擬主機建議部署在「Node02」叢集節點主機。
圖17 系統建議依據資源需求條件來部署叢集節點主機。
獲得VM虛擬主機最佳部署建議後，在MBR-Cluster01的Node02叢集節點主機中，部署名稱為「CS-VM01」的VM虛擬主機，在MBR-Cluster02的Node12叢集節點主機中，部署名稱為「CS-VM02」的VM虛擬主機。然而，管理人員會發現部署的兩台VM虛擬主機，並非叢集集合類型的VM虛擬主機，如圖18所示。
圖18 VM虛擬主機尚未註冊為叢集集合類型。
管理人員必須執行Register-ClusterSetVM指令，將部署的VM虛擬主機註冊為叢集集合類型，並且將VM虛擬主機加入可用性集合當中，以便能夠受到可用性集合和容錯網域的保護。當VM虛擬主機註冊為叢集集合類型後，由於部署的兩台VM虛擬主機在不同的容錯網域中，便可以看到處於不同的更新網域中，如圖19所示。
圖19 註冊VM虛擬主機為叢集集合並啟用可用性集合。
跨成員叢集遷移VM虛擬主機
部署後的叢集集合VM虛擬主機，在同一個成員叢集中的VM虛擬主機可以隨心所欲地進行各種遷移。然而，在跨成員叢集遷移VM虛擬主機的部分卻與過去不同，在傳統容錯移轉叢集運作環境中，跨叢集遷移VM虛擬主機時，必須移除VM虛擬主機叢集角色、即時遷移至不同叢集和節點主機、加入新的叢集內並新增角色，在叢集集合運作環境中則無須執行上述步驟。
在叢集集合環境中的VM虛擬主機，只要執行Move-ClusterSetVM指令，並且指定欲遷移的VM虛擬主機名稱，以及目的地叢集節點主機名稱即可。如圖20所示，可以看到原本CS-VM01虛擬主機，運作於MBR-Cluster01的Node02節點主機中，遷移至MBR-Cluster02的Node12節點主機繼續運作。
圖20 跨成員叢集遷移VM虛擬主機。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞