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). Zestaw klastrów to technologia, która umożliwia administratorom łączenie wielu klastrów systemu Windows 2019 w jeden zestaw klastrów.

Istniejące klastry pracy awaryjnej mogą pomieścić maksymalnie 64 węzły. Technologia zestawów klastrów łączy wiele klastrów WS19 w jednej domenie, przy czym każdy z tych klastrów obsługuje do 64 węzłów WS19. W porównaniu z klastrem pracy awaryjnej zestaw klastrów ma większą odporność. Na przykład 4-węzłowy klaster pracy awaryjnej może przetrwać awarię 2-węzłową. W przypadku tego samego klastra 4-węzłowego, jeśli podzielimy go na dwa klastry 2-węzłowe i utworzymy z niego zestawy klastrów, może on przetrwać jedną awarię klastra plus awarię jednego węzła z pozostałego klastra. Dzięki temu może przetrwać łącznie 3 awarie węzłów.

Aby zapoznać się z omówieniem funkcji zestawów klastrów w serwerze Server 2019, zapoznaj się z sekcjami "Wprowadzenie-do-zestawów-klastrów-w-windows-serwerze-2019" i "Zestawy klastrów". Zestawy klastrów zyskują elastyczność dzięki zastosowaniu technologii o nazwie Infrastructure Scale-Out File Server, co ułatwia również migrację maszyn wirtualnych między klastrami w ramach zestawu klastrów.

Konfiguracja laboratoryjna do wdrażania zestawu klastrów na serwerach PowerEdge

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

Utworzono pierwszy klaster przy użyciu dwóch klastrów R730XD i nazwano go S2D13G54 (nazywanym klastrem członkowskim 1).

Utworzono drugi klaster przy użyciu dwóch klastrów R740XD i nazwano go S2D14G54 (nazywanym klastrem członkowskim 2).

Utworzono dwa woluminy CSV w każdym z utworzonych powyżej klastrów.

Utworzono maszynę wirtualną "vm1" w klastrze członkowskim 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. Podczas tworzenia klastra zarządzania nie jest wymagana współużytkowana pamięć masowa.

Rola usług plików została zainstalowana 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 –Uruchom ponownie

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

Add-ClusterScaleOutFileServerRole -Name <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 klaster S2D14G54 i S2D13G54 do klastra do zestawu klastrów:

Add-ClusterSetMember -ClusterName S2D14G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Nazwa serwera SOFS utworzonego S2D14G54 klastrze>

 

Add-ClusterSetMember -ClusterName S2D13G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Nazwa serwera SOFS utworzonego S2D13G54 klastrze>

 

 

 

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

Get-ClusterSetMember -ClusterName <Nazwa klastra> | Register-ClusterSetVM -VMName VMName <VM Name>

 
W celu przetestowania migracji w czasie rzeczywistym między klastrami podjęto próbę migracji maszyny wirtualnej "V213G" do klastra członkowskiego 2. Przed przeprowadzeniem migracji między klastrami należy wziąć pod uwagę następujące kwestie:

1. 1. Ustawienia maszyny wirtualnej, zgodność procesora powinna być włączona.
   2. Konfiguracja ograniczonego delegowania protokołu Kerberos (KCD) między wszystkimi parami węzłów między klastrami
      1. Wskazówki dotyczące ograniczonego delegowania od zespołu produktu Microsoft Hyper-V będą przydatne w konfigurowaniu tego.
      2. Skonfiguruj typ uwierzytelniania migracji na żywo maszyny wirtualnej między klastrami na 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 in $hosts){ invoke-command -nazwa_komputera $h -scriptBlock {net administratorzy grup lokalnych /add <management_cluster_name>$} }

 

W celu wykonania dowolnego działania konserwacyjnego klastra w zestawie klastrów należy zmigrować wszystkie maszyny wirtualne należące do klastra do innych klastrów w zestawie klastrów, a następnie usunąć klaster z zestawu klastrów:

 

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

 

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

 

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

 

 

 

 

 

 

 

 

 

 

 

Istniejące klastry pracy awaryjnej mogą pomieścić maksymalnie 64 węzły. Technologia zestawów klastrów łączy wiele klastrów WS19 w jednej domenie, przy czym każdy z tych klastrów obsługuje do 64 węzłów WS19. W porównaniu z klastrem pracy awaryjnej zestaw klastrów ma większą odporność. Na przykład 4-węzłowy klaster pracy awaryjnej może przetrwać awarię 2-węzłową. W przypadku tego samego klastra 4-węzłowego, jeśli podzielimy go na dwa klastry 2-węzłowe i utworzymy z niego zestawy klastrów, może on przetrwać jedną awarię klastra plus awarię jednego węzła z pozostałego klastra. Dzięki temu może przetrwać łącznie 3 awarie węzłów.

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

 

W przypadku nieoczekiwanej awarii klastra członkowskiego zestaw klastrów nie jest wystarczająco inteligentny, aby obsłużyć przełączanie awaryjne. W systemie Windows Server 2019 obsługiwane jest tylko ręczne przenoszenie zasobów z jednego klastra do innego; Mimo że automatyczne przełączanie awaryjne maszyny wirtualnej nadal działa w zakresie jednego klastra składowego.