Konfigurowanie zestawów klastrów Microsoft na Dell PowerEdge

Zestawy klastrów wprowadzone w systemie Windows Server 2019 (WS19) zwiększają elastyczność i odporność SDDC (Software Defined Data Center). Cluster Set to technologia, która umożliwia administratorom łączenie wielu klastrów systemu Windows 2019 w jeden zestaw klastrów.

Istniejące klastry przełączania awaryjnego mogą pomieścić maksymalnie 64 węzły. Technologia cluster sets łączy wiele klastrów WS19 w jednej domenie, a każdy z tych klastrów obsługuje do 64 węzłów WS19. W porównaniu z klastrem trybu failover zestaw klastra ma większą odporność. Na przykład klaster przełączania awaryjnego z 4 węzłami może przetrwać awarię 2 węzłów. W przypadku tego samego klastra 4-węzłowego, jeśli podzielimy się na dwa klastry 2-węzłowe i utworzymy z niego klaster, może on przetrwać jedną awarię klastra plus jedną awarię węzła z pozostałego klastra. W ten sposób może całkowicie przetrwać awarie 3 węzłów.

Aby uzyskać przegląd funkcji Zestawy klastrów w serwerze 2019, należy zapoznać się z tematem "Wprowadzenie do zestawów klastrów w systemie windows-server-2019" i "Zestawy klastrów". Zestawy klastrów zyskają elastyczność dzięki wykorzystaniu technologii bazowej o nazwie Infrastructure Scale-Out File Server. Ułatwia to również migrację między klastrami maszyn wirtualnych w ramach zestawu klastrów.

Konfiguracja laboratoryjna wdrożenia zestawu klastrów na serwerze PowerEdge

Używane serwery: Dwa dyski PowerEdge R730XD i dwa serwery PowerEdge R740XD

Utworzono pierwszy klaster przy użyciu dwóch dysków R730XD o nazwie S2D13G54 (o nazwie Member Cluster 1).

Utworzono drugi klaster przy użyciu dwóch dysków R740XD i nazwanych S2D14G54 (tzw. Klaster członkowski 2).

Utworzono dwa wolumeny CSV w każdym z powyższych klastrów.

Utworzono maszynę wirtualną "vm1" w klastrze 1 i maszynę wirtualną "vm2" w klastrze członkowskim 2. Następnie połączyłem te dwie maszyny wirtualne, aby utworzyć klaster zarządzania (o nazwie mgClus54) dla zestawu klastrów. Podczastworzenia klastra zarządzania wymagana jest współdzielona pamięć masowa N o.

Zainstalowano rolę File-Services w każdym z węzłów w klastrze członkowskim 1, klastrze członkowskim 2 i klastrze zarządzania:

Install-WindowsFeature File-Services -IncludeAllSubFeature –IncludeManagementTools –Restart

Utworzono serwer plików SOFS infrastruktury w klastrze członkowskim 1, klastrze członkowskim 2 i klastrze zarządzania:

Add-ClusterScaleOutFileServerRole - nazwa <infrastruktury SOFS> -Infrastructure

 

Utworzono zestaw klastrów o nazwie CLUSSET54:

New-ClusterSet -Name CLUSSET54 -NamespaceRoot <Management Cluster SOFS Name> -CimSession CIM session to <Management Cluster>

 

Następnie dodaj utworzony S2D14G54 i S2D13G54 klastra do klastra do programu ClusterSet:

Add-ClusterSetMember -ClusterName S2D14G54 -CimSession Cim Session to <ClusterSet> -InfraSOFSName <Name of SOFS created on S2D14G54 cluster>

 

Add-ClusterSetMember -ClusterName S2D13G54 -CimSession Cim Session to <ClusterSet> -InfraSOFSName <Name of SOFS created on S2D13G54 cluster>

 

 

 

Następnie wdrażam dwie maszyny wirtualne V213G i V214G odpowiednio w klastrze 1 i klastrze członkowskim 2 i rejestruję maszyny wirtualne w zestawie klastrów:

Get-ClusterSetMember -Nazwa> klastra <| Register-ClusterSetVM -nazwa maszyny wirtualnej VMName <>

 
W przypadku testowania migracji na żywo między klastrami, próbowałem migrować maszynę wirtualną "V213G" do klastra członkowskiego 2. Przed przeprowadzeniem migracji między klastrami należy wziąć pod uwagę poniższe punkty:

1. 1. Ustawienia maszyny wirtualnej, zgodność procesora powinna być włączona.
   2. Konfiguracja ograniczonej delegacji Kerberos (KCD) między wszystkimi parami węzłów między klastrami
      1. Wskazówki dotyczące ograniczonych delegacji od zespołu produktów Microsoft Hyper-V będą przydatne podczas konfigurowania tej konfiguracji.
      2. Konfiguracja typu uwierzytelniania na żywo maszyny wirtualnej między klastrami do Kerberos w każdym węźle w zestawie klastrów.

foreach($h in $hosts){Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -nazwa_komputera $h }

1. 1. 3. Dodaj klaster zarządzania do grupy administratorów lokalnych na każdym węźle w zestawie klastrów.

foreach($h w $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }

 

W celu wykonania czynności konserwacyjnych klastra w zestawie klastrów zmigruj wszystkie maszyny wirtualne, które są częścią klastra, do innych klastrów w zestawie klastrów, a następnie usuń klaster z zestawu klastrów:

 

Remove-ClusterSetMember -Nazwa_klastra <> -Sesja CimSession <utworzona dla ClusterSet>

 

Po wykonaniu czynności konserwacyjnych dodaj ponownie klaster do zestawu klastrów.

 

W przypadku nieoczekiwanej awarii klastra członkowskiego zestaw klastra nie jest wystarczająco inteligentny, aby obsłużyć przełączanie awaryjne. W systemie Windows Server 2019 obsługiwany jest tylko ręczny ruch zasobów z jednego klastra do innego klastra, mimo żeawaryjne przełączanie awaryjne utomatycznej maszyny wirtualnej nadal działa w ramach jednego elementu członkowskiego klastra.

 

 

 

 

 

 

 

 

 

 

 

Istniejące klastry przełączania awaryjnego mogą pomieścić maksymalnie 64 węzły. Technologia cluster sets łączy wiele klastrów WS19 w jednej domenie, a każdy z tych klastrów obsługuje do 64 węzłów WS19. W porównaniu z klastrem trybu failover zestaw klastra ma większą odporność. Na przykład klaster przełączania awaryjnego z 4 węzłami może przetrwać awarię 2 węzłów. W przypadku tego samego klastra 4-węzłowego, jeśli podzielimy się na dwa klastry 2-węzłowe i utworzymy z niego klaster, może on przetrwać jedną awarię klastra plus jedną awarię węzła z pozostałego klastra. W ten sposób może całkowicie przetrwać awarie 3 węzłów.

Po wykonaniu czynności konserwacyjnych dodaj ponownie klaster do zestawu klastrów.

 

W przypadku nieoczekiwanej awarii klastra członkowskiego zestaw klastra nie jest wystarczająco inteligentny, aby obsłużyć przełączanie awaryjne. System Windows Server 2019 obsługuje tylko ręczny ruch zasobów z jednego klastra do innego klastra; mimo że automatyczne przełączanie awaryjne maszyny wirtualnej nadal działa w ramach jednego zakresu klastra członkowskiego.