Windows Server2019 SDDC 軟體定義資料中心 容錯移轉 HCI All-Flash儲存

善用WS 2019新功能 建構容錯網域/可用性集合機制

動手部署叢集集合 彙整容錯資源組成大群

2020-04-13
叢集集合能夠將多個各自運作的容錯移轉叢集,透過「鬆散耦合」方式將資源彙整叢集,建構出一個採用「統一儲存命名空間」的超大型融合式容錯移轉叢集。為此,本文將對叢集集合做深入剖析,並實際操作示範。

 

在現代化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。>

 


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!