Windows Server: 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 Cluster-Sets w Server 2019, zapoznaj się z "Wprowadzenie-to-cluster-sets-in-windows-server-2019 " i "Cluster sets ". Zestawy klastrów zyskują elastyczność dzięki zastosowaniu podstawowej technologii zwanej serwerem plików skalowalnego w poziomie infrastruktury, 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 S2D13G54 (zwanym klastrem członkowskim 1).
• Utworzono drugi klaster przy użyciu dwóch serwerów R740XD i nazwano S2D14G54 (zwany klastrem członkowskim 2).
• Utworzono dwa woluminy CSV w każdym z utworzonych powyżej klastrów.
• Utworzono maszynę wirtualną 'vm1' w dniu Member Cluster 1 i maszynę wirtualną 'vm2' w dniu Member Cluster 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 –Restart 

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

Add-ClusterScaleOutFileServerRole -Name -Infrastructure 

Utworzono zestaw klastrów o nazwie CLUSSET54:

New-ClusterSet -Name CLUSSET54 -NamespaceRoot  -CimSession  

Następnie dodaj utworzony klaster S2D14G54 i S2D13G54 do klastra do zestawu klastrów:

Add-ClusterSetMember -ClusterName S2D14G54 -CimSession  -InfraSOFSName

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  | Register-ClusterSetVM -VMName  

 
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. 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
   • Ograniczone wytyczne dotyczące delegowania od zespołu produktu Microsoft Hyper-V będzie przydatny w konfiguracji tego.
   • 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 }

• • • 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 {administratorzy grup lokalnych sieci /add $} }

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  -CimSession  

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.

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.