Wdrażanie zestawu klastrów

Dotyczy: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019

Ten artykuł zawiera informacje na temat wdrażania zestawu klastrów dla Windows Server Failover Clusters przy użyciu PowerShell. Zestaw klastrów to grupa wielu klastrów trybu przełączania awaryjnego, które są połączone razem w klaster. Korzystając z zestawu klastrów, można zwiększyć liczbę węzłów serwera w jednej chmurze centrum danych zdefiniowanych programowo (SDDC) według rzędów wielkości.

Zestawy klastrów zostały przetestowane i obsługiwane do 64 łącznych węzłów klastra. Jednak zestawy klastrów mogą być skalowane do znacznie większych rozmiarów i nie mają z góry ustalonych limitów.

Benefits

Zestawy klastrów oferują następujące korzyści:

Znacznie zwiększa obsługiwaną skalę chmury SDDC do uruchamiania maszyn wirtualnych o wysokiej dostępności, łącząc wiele mniejszych klastrów w jedną dużą sieć szkieletową, zachowując granicę błędów oprogramowania do jednego klastra. Możesz łatwo migrować maszyny wirtualne w obrębie zestawu klastrów.
Zwiększona odporność. Posiadanie czterech klastrów 4-węzłowych w zestawie klastrów zapewnia lepszą odporność niż jeden klaster 16 węzłów, w którym wiele węzłów obliczeniowych może spaść, a produkcja pozostaje nienaruszona.
Zarządzanie cyklem życia klastra przełączania awaryjnego, w tym dołączanie i wycofywanie klastrów, bez wpływu na dostępność maszyn wirtualnych najemców.
Elastyczność wirtualnej maszyny w poszczególnych klastrach i zapewnianie ujednoliconej przestrzeni nazw pamięci.
Łatwo zmień stosunek obciążenia zasobów obliczeniowych do magazynu w środowisku hiperkonwergentnym.
Skorzystaj z takich domen błędów platformy Azure i zestawów dostępności w poszczególnych klastrach w początkowym umieszczaniu maszyny wirtualnej i kolejnej migracji.
Można używać nawet wtedy, gdy sprzęt obliczeniowy i magazynowy między węzłami klastra nie jest identyczny.
Migracja na żywo maszyn wirtualnych między klastrami.
Podobne do platformy Azure zestawy dostępności i domeny błędów w wielu klastrach.
Przenoszenie maszyn wirtualnych programu SQL Server między klastrami.

Wymagania i ograniczenia

Istnieje kilka wymagań i ograniczeń dotyczących używania zestawów klastrów:

Wszystkie klastry członkowskie w zestawie klastrów muszą znajdować się w tym samym lesie usługi Active Directory (AD).
Serwery członkowskie w zestawie muszą uruchamiać tę samą wersję systemu operacyjnego. Maszyny wirtualne nie mogą być migrowane na żywo między różnymi systemami operacyjnymi. Możesz mieć zestaw klastrów, który składa się z jednego, ale nie wielokrotności, z następujących opcji:
- Klaster trybu failover systemu Windows Server 2019 i klaster trybu failover systemu Windows Server 2019
- Klaster trybu failover systemu Windows Server 2019 i bezpośrednie miejsca do magazynowania systemu Windows Server 2019
- Bezpośrednie miejsca do magazynowania systemu Windows Server 2019 i Bezpośrednie miejsca do magazynowania w systemie Windows Server 2019
Identyczny sprzęt procesora jest wymagany dla wszystkich serwerów członkowskich do migracji na żywo między klastrami składowymi; w przeciwnym razie należy wybrać opcję Zgodność procesora CPU w ustawieniach maszyn wirtualnych.
Maszyny wirtualne zestawu klastrów muszą być ręcznie migrowane na żywo między klastrami — nie mogą automatycznie przejmować trybu failover.
Replika magazynowania musi być używana między klastrami członkowskimi, aby zapewnić odporność magazynowania na awarie klastra. W przypadku korzystania z repliki magazynu należy pamiętać, że ścieżki UNC przestrzeni nazw nie zmienią się automatycznie w trybie failover repliki magazynu do klastra docelowego repliki.
Funkcja Bezpośrednie miejsca do magazynowania nie działa w klastrach członkowskich w zestawie klastrów. Zamiast tego bezpośrednie miejsca do magazynowania mają zastosowanie do jednego klastra, a każdy klaster ma własną pulę magazynów.

Architecture

Na poniższym diagramie przedstawiono zestaw klastrów na wysokim poziomie:

Poniżej przedstawiono podsumowanie każdego z pokazanych elementów:

Klaster zarządzania

Klaster zarządzania hostuje płaszczyznę zarządzania o wysokiej dostępności i serwer plików skalowalny w poziomie przestrzeni nazw (SOFS) dla zestawu klastrów. Klaster zarządzania jest logicznie oddzielony od poszczególnych klastrów członkowskich, które uruchamiają obciążenia maszyn wirtualnych. Dzięki temu płaszczyzna zarządzania zestawu klastrów jest odporna na wszelkie zlokalizowane awarie całego klastra, takie jak utrata mocy klastra członkowskiego.

Odwołanie dotyczące przestrzeni nazw zestawu klastrów w SOFS

Przestrzeń nazw dla zestawu klastrów jest dostarczana przy użyciu roli serwera SOFS uruchamianego w klastrze zarządzania. Jest to podobne do rozproszonej przestrzeni nazw systemu plików (DFSN). Jednak w przeciwieństwie do DFSN, metadane odwołań do przestrzeni nazw zestawu klastrów są automatycznie wypełniane na wszystkich węzłach klastra bez żadnej interwencji. Dzięki temu w ścieżce dostępu do przestrzeni magazynowej nie występuje prawie żaden dodatkowy narzut wydajności. Ten uproszczony mechanizm odwołań nie uczestniczy w ścieżce we/wy.

Każdy udział odwołań bloku komunikatów serwera (SMB) w zestawie nazw klastra odwołania SOFS jest typu SimpleReferral. Ta referencja umożliwia klientom SMB dostęp do docelowego udziału SMB hostowanego na klastrze, na którym znajduje się członek SOFS. Odwołania są buforowane w sposób ciągły na każdym z węzłów klienta, a przestrzeń nazw zestawu klastrów dynamicznie aktualizuje odwołania zgodnie z potrzebami automatycznie. Informacje o przekierowaniach są trwale buforowane na każdym węźle w zestawie klastrów, nawet podczas ponownego uruchamiania.

Główny zestaw klastrów

Komunikacja między klastrami składowymi jest luźno połączona i koordynowana przez zasób głównego zestawu klastrów (CS-Master). Podobnie jak inne zasoby zestawu klastrów, CS-Master jest wysoce dostępna i odporna na awarie poszczególnych klastrów członkowskich lub awarie węzłów klastra zarządzania. Za pośrednictwem dostawcy usługi WMI zestawu klastrów, CS-Master udostępnia punkt końcowy dla wszystkich operacji zarządzania zestawem klastrów.

Klaster członkowski

Klaster uruchamia obciążenia maszyn wirtualnych i Storage Spaces Direct. Wiele klastrów członkowskich uczestniczy we wdrożeniu zestawu klastrów, tworząc większą sieć szkieletową chmury SDDC. Klastry członkowskie różnią się od klastra zarządzania w dwóch kluczowych aspektach: klastry członkowskie uczestniczą w konstrukcjach domeny błędów i zestawu dostępności, a klastry członkowskie są skrojone pod hostowanie usług maszyn wirtualnych i Storage Spaces Direct. Z tego powodu maszyny wirtualne przenoszone między klastrami członkowskimi nie są hostowane w klastrze zarządzania.

Element roboczy zestawu klastrów

CS-Master współdziała z zasobem w klastrach członkowskich, który nazywany jest pracownikiem zestawu klastrów (CS-Worker). CS-Worker odpowiada na żądania serwera CS-Master, w tym umieszczanie maszyn wirtualnych i tworzenie spisu zasobów. Istnieje jedno wystąpienie CS-Worker na klaster członkowski.

Domena błędów

Domena błędów to grupa sprzętu i oprogramowania, które mogą ulec awarii. Chociaż można wyznaczyć jeden lub więcej klastrów razem jako domenę błędów, każdy węzeł może uczestniczyć w domenie błędów w zestawie dostępności. Granice domeny błędów są oparte na topologii centrum danych, architekturze sieci i innych zagadnieniach.

Zestaw dostępności

Zestaw dostępności służy do konfigurowania żądanej nadmiarowości obciążeń klastrowanych w różnych domenach błędów przez grupowanie i wdrażanie obciążeń. W przypadku aplikacji dwuwarstwowej należy skonfigurować co najmniej dwie maszyny wirtualne w zestawie dostępności dla każdej warstwy, co gwarantuje, że w przypadku awarii domeny w zestawie dostępności aplikacja będzie mieć co najmniej jedną maszynę wirtualną w każdej warstwie hostowanej w innej domenie błędów.

Tworzenie zestawu klastrów

Użyj programu PowerShell w poniższym przykładowym przepływie pracy, aby utworzyć zestaw klastrów przy użyciu dwóch klastrów. Nazwa klastra ustawionego w tym miejscu to CSMASTER.

Nazwa klastra	Nazwa serwera SOFS infrastruktury
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Użyj komputera klienckiego zarządzania z systemem Windows Server 2022 lub Windows Server 2019.
Zainstaluj narzędzia do klastra trybu failover na serwerze zarządzania klastrem.
Utwórz dwa węzły klastra oraz przynajmniej dwa udostępnione woluminy klastra (CSV) w każdym klastrze.
Utwórz klaster zarządzający (fizyczny lub gość), który obejmuje klastry członkowskie. Gwarantuje to, że płaszczyzna zarządzania zestawu klastrów będzie nadal dostępna pomimo możliwych awarii klastra członkowskiego.
Aby utworzyć zestaw klastrów:
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
Note

Jeśli używasz statycznego adresu IP, musisz dołączyć parametr -StaticAddress x.x.x.x.x w poleceniu New-ClusterSet .

Aby dodać członków klastra do zestawu klastrów:

Add-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER1
Add-ClusterSetMember -ClusterName CLUSTER2 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER2

Aby wyliczyć wszystkie klastry członkowskie w zestawie klastrów:
```
Get-ClusterSetMember -CimSession CSMASTER
```
Aby wyliczyć wszystkie klastry członkowskie w zestawie klastrów, w tym węzły klastra zarządzania:
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
Aby wyświetlić listę wszystkich węzłów serwera ze wszystkich klastrów członkowskich:
```
Get-ClusterSetNode -CimSession CSMASTER
```

Aby wyświetlić listę wszystkich grup zasobów w zestawie klastrów:

Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterGroup

Aby zweryfikować, czy zestaw klastrów zawiera dokładnie jeden udział SMB (ScopeName jest nazwą serwera plików infrastruktury) na infrastrukturze SOFS dla każdego woluminu CSV członka klastra:
```
Get-SmbShare -CimSession CSMASTER
```
Przejrzyj pliki dziennika debugowania zestawu klastrów dla zestawu klastrów, klastra zarządzania i każdego elementu członkowskiego klastra:
```
Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>
```
Skonfiguruj protokół Kerberos z ograniczonym delegowaniem między wszystkimi członkami zestawu klastrów.
Skonfiguruj typ uwierzytelniania migracji na żywo maszyn wirtualnych między klastrami na Kerberos na każdym węźle w zestawie klastrów.
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```

Dodaj klaster zarządzania do lokalnej grupy administratorów na każdym serwerze członkowskim w zestawie klastrów:

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

Utwórz maszyny wirtualne zestawu klastrów

Po utworzeniu zestawu klastrów następnym krokiem jest utworzenie maszyn wirtualnych. Przedtem należy wykonać następujące kontrole:

Sprawdzanie dostępnej pamięci w każdym węźle serwera klastra
Sprawdzanie dostępnego miejsca na dysku w każdym węźle serwera klastra
Sprawdź wszelkie określone wymagania dotyczące magazynu maszyn wirtualnych pod względem szybkości i wydajności

Polecenie Get-ClusterSetOptimalNodeForVM identyfikuje optymalny klaster i węzeł w zestawie klastra, a następnie wdraża na niej maszynę wirtualną. W poniższym przykładzie tworzona jest nowa maszyna wirtualna:

Dostępne 4 GB
Jeden procesor wirtualny
10% minimalna dostępna liczba dostępnych procesorów

# Identify the optimal node to create a new virtual machine
$memoryinMB=4096
$vpcount = 1
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

# Deploy the virtual machine on the optimal node
Invoke-Command -ComputerName $targetnode.name -scriptblock { param([String]$storagepath); New-VM CSVM1 -MemoryStartupBytes 3072MB -path $storagepath -NewVHDPath CSVM.vhdx -NewVHDSizeBytes 4194304 } -ArgumentList @("\\SOFS-CLUSTER1\VOLUME1") -Credential $cred | Out-Null

Start-VM CSVM1 -ComputerName $targetnode.name | Out-Null
Get-VM CSVM1 -ComputerName $targetnode.name | fl State, ComputerName

Po zakończeniu jest wyświetlany węzeł klastra, w którym wdrożono maszynę wirtualną. W powyższym przykładzie zostanie wyświetlony następujący kod:

State         : Running
ComputerName  : 1-S2D2

Jeśli nie ma wystarczającej ilości pamięci, pojemności procesora CPU lub miejsca na dysku dostępnego do dodania maszyny wirtualnej, zostanie wyświetlony następujący błąd:

Get-ClusterSetOptimalNodeForVM : A cluster node isn't available for this operation.

Po utworzeniu maszyny wirtualnej jest ona wyświetlana w menedżerze Hyper-V w określonym węźle. Aby dodać ją jako maszynę wirtualną zestawu klastrów i dodać ją do klastra, użyj następującego polecenia:

Register-ClusterSetVM -CimSession CSMASTER -MemberName $targetnode.Member -VMName CSVM1

Po zakończeniu dane wyjściowe to:

Id  VMName  State  MemberName  PSComputerName
--  ------  -----  ----------  --------------
 1  CSVM1     On   CLUSTER1    CSMASTER

Jeśli klaster został utworzony przy użyciu istniejących maszyn wirtualnych, maszyny wirtualne muszą być zarejestrowane w zestawie klastrów. Aby zarejestrować wszystkie maszyny wirtualne jednocześnie, użyj:

Get-ClusterSetMember -Name CLUSTER3 -CimSession CSMASTER | Register-ClusterSetVM -RegisterAll -CimSession CSMASTER

Następnie dodaj ścieżkę maszyny wirtualnej do przestrzeni nazw zestawu klastrów.

Załóżmy na przykład, że istniejący klaster jest dodawany do zestawu klastrów ze wstępnie skonfigurowanymi maszynami wirtualnymi, które znajdują się na lokalnym udostępnionym woluminie klastra (CSV). Ścieżka VHDX będzie podobna do C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1.

Migracja magazynu jest wymagana, ponieważ ścieżki CSV są z założenia lokalne dla jednego klastra członkowskiego i dlatego nie są dostępne dla maszyny wirtualnej, kiedy zostaną migratowane na żywo pomiędzy klastrami członkowskimi.

W tym przykładzie, CLUSTER3 jest dodawany do zestawu klastrów przy użyciu serwera plików skalowalnego w poziomie SOFS-CLUSTER3. Aby przenieść konfigurację i magazyn maszyny wirtualnej, polecenie to:

Move-VMStorage -DestinationStoragePath \\SOFS-CLUSTER3\Volume1 -Name MyVM

Po zakończeniu może zostać wyświetlone ostrzeżenie:

WARNING: There were issues updating the virtual machine configuration that may prevent the virtual machine from running. For more information view the report file below.
WARNING: Report file location: C:\Windows\Cluster\Reports\Update-ClusterVirtualMachineConfiguration '' on date at time.htm.

To ostrzeżenie może zostać zignorowane, ponieważ nie nastąpiły żadne zmiany fizyczne w konfiguracji magazynu roli maszyny wirtualnej. Rzeczywista lokalizacja fizyczna nie zmienia się; tylko ścieżki konfiguracji.

Aby uzyskać więcej informacji na temat Move-VMStorage, zobacz Move-VMStorage.

Migracja na żywo maszyny wirtualnej w zestawie klastrów obejmuje następujące elementy:

Set-VMHost -UseAnyNetworkForMigration $true

Na przykład, aby przenieść maszynę wirtualną zestawu klastrów z CLUSTER1 do NODE2-CL3 na CLUSTER3, polecenie to:

Move-ClusterSetVM -CimSession CSMASTER -VMName CSVM1 -Node NODE2-CL3

To polecenie nie przenosi plików magazynu ani konfiguracji maszyny wirtualnej i nie jest konieczne, ponieważ ścieżka do maszyny wirtualnej pozostaje następująca: \\SOFS-CLUSTER1\VOLUME1. Po zarejestrowaniu maszyny wirtualnej na ścieżce udziału serwera plików infrastruktury, dyski i maszyna wirtualna nie muszą znajdować się na tym samym węźle.

Tworzenie serwera plików skalowalnego w poziomie infrastruktury

W klastrze istnieje jedna rola klastra SOFS infrastruktury. Rola infrastruktury SOFS jest tworzona przez określenie przełącznika -Infrastructure dla polecenia Add-ClusterScaleOutFileServerRole cmdlet. Przykład:

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

Każdy wolumin CSV utworzony automatycznie wyzwala stworzenie udziału SMB o nazwie wygenerowanej automatycznie na podstawie nazwy woluminu CSV. Nie można bezpośrednio tworzyć ani modyfikować udziałów SMB w ramach roli SOFS, poza użyciem operacji tworzenia i modyfikowania woluminu CSV.

W konfiguracjach hiperkonwergentnych infrastruktura SOFS umożliwia klientowi SMB (hostowiHyper-V) komunikację z serwerem SMB infrastruktury SOFS z ciągłą dostępnością (CA). Ten hiperkonwergentny urząd certyfikacji dla lokalnego sprzężenia zwrotnego SMB jest realizowany przez maszyny wirtualne, które uzyskują dostęp do plików dysku wirtualnego (VHDX), gdzie tożsamość maszyny wirtualnej będąca właścicielem jest przekazywana między klientem a serwerem. To przekazywanie tożsamości umożliwia korzystanie z list ACL dla plików VHDx tak samo jak w standardowych konfiguracjach klastra hiperkonwergentnego, jak poprzednio.

Po utworzeniu zestawu klastrów przestrzeń nazw zestawu klastrów opiera się na SOFS infrastruktury w każdym z klastrów członkowskich oraz dodatkowo na SOFS infrastruktury w klastrze zarządzania.

Gdy klaster będący członkiem zostanie dodany do grupy klastrów, możesz określić nazwę SOFS infrastruktury w tym klastrze, jeśli już istnieje. Jeśli SOFS infrastruktury nie istnieje, na nowym klastrze członkowskim zostanie utworzona nowa rola SOFS infrastruktury. Jeśli rola infrastruktury SOFS już istnieje w klastrze członkowskim, operacja dodawania niejawnie zmienia jej nazwę na określoną, zgodnie z potrzebami. Żadne istniejące serwery SMB ani role SOFS niebędące częścią infrastruktury w klastrach członkowskich nie są używane przez zestaw klastrów.

Po utworzeniu zestawu klastrów możesz użyć istniejącego obiektu komputera AD jako korzenia przestrzeni nazw w klastrze zarządzania. Tworzenie zestawu klastrów powoduje utworzenie roli klastra SOFS Infrastruktury w klastrze zarządzania lub zmianę nazwy istniejącej roli Infrastruktury SOFS. Serwer SOFS infrastruktury w klastrze zarządzania jest używany jako serwer SOFS w zestawie nazw klastra.

Utwórz domeny błędów i zestawy dostępności

Domeny błędów podobne do platformy Azure i zestawy dostępności można skonfigurować w zestawie klastrów. Jest to korzystne w przypadku początkowego umieszczania maszyn wirtualnych i migracji między klastrami.

Poniższy przykład zawiera cztery klastry w zestawie klastrów. W zestawie jest tworzona jedna domena błędów z dwoma klastrami, a druga domena błędów jest tworzona z dwoma pozostałymi klastrami. Te dwie domeny błędów składają się na zestaw dostępności.

W poniższym przykładzie CLUSTER1 i CLUSTER2 znajdują się w domenie błędów FD1 , a CLUSTER3 i CLUSTER4 znajdują się w domenie błędów FD2. Zestaw dostępności to CSMASTER-AS.

Aby utworzyć domeny błędów, polecenia to:

New-ClusterSetFaultDomain -Name FD1 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER1,CLUSTER2 -Description "First fault domain"

New-ClusterSetFaultDomain -Name FD2 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER3,CLUSTER4 -Description "Second fault domain"

Aby upewnić się, że zostały one utworzone pomyślnie, Get-ClusterSetFaultDomain można uruchomić, aby wyświetlić dane wyjściowe dla FD1.

PS C:\> Get-ClusterSetFaultDomain -CimSession CSMASTER -FdName FD1 | fl *

PSShowComputerName    : True
FaultDomainType       : Logical
ClusterName           : {CLUSTER1, CLUSTER2}
Description           : First fault domain
FDName                : FD1
Id                    : 1
PSComputerName        : CSMASTER

Po utworzeniu domen błędów tworzony jest zestaw dostępności:

New-ClusterSetAvailabilitySet -Name CSMASTER-AS -FdType Logical -CimSession CSMASTER -ParticipantName FD1,FD2

Aby sprawdzić, czy został utworzony, użyj:

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

Podczas tworzenia nowych maszyn wirtualnych użyj parametru -AvailabilitySet, aby określić optymalny węzeł dla umiejscowienia. Oto przykład:

# Identify the optimal node to create a new VM
$memoryinMB=4096
$vpcount = 1
$av = Get-ClusterSetAvailabilitySet -Name CSMASTER-AS -CimSession CSMASTER
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10 -AvailabilitySet $av
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

Usuwanie klastra z zestawu

Czasami klaster musi zostać usunięty z zestawu klastrów. Najlepszą praktyką jest wcześniejsze przeniesienie wszystkich maszyn wirtualnych z klastra. Można to zrobić przy użyciu poleceń Move-ClusterSetVM i Move-VMStorage.

Jeśli maszyny wirtualne nie zostaną najpierw przeniesione z klastra, wszystkie pozostałe maszyny wirtualne zestawu klastra hostowane w usuwanym klastrze staną się maszynami o wysokiej dostępności powiązanymi z tym klastrem, zakładając, że mają dostęp do ich magazynu. Zestawy klastrów automatycznie aktualizują spis, nie śledząc już kondycji usuniętego klastra i uruchomionych na nim maszyn wirtualnych, a także usuwając przestrzeń nazw i wszystkie odwołania do udziałów hostowanych w usuniętym klastrze.

Na przykład polecenie usuwania klastra CLUSTER1 z zestawu klastrów jest następujące:

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

Kopia zapasowa stanu systemu

Kopia zapasowa stanu systemu utworzy kopię zapasową stanu klastra i metadanych. Korzystając z kopii zapasowej systemu Windows Server, można przywrócić tylko bazę danych klastra węzła w razie potrzeby lub wykonać autorytatywne przywracanie, aby przywrócić całą bazę danych klastra we wszystkich węzłach. W przypadku zestawów klastrów zalecamy najpierw wykonanie autorytatywnego przywracania danych dla klastrów członkowskich, a następnie dla klastra zarządzania. Aby uzyskać więcej informacji na temat tworzenia kopii zapasowej stanu systemu, zobacz także Tworzenie kopii zapasowej stanu systemu i surowego sprzętu.

Dalsze kroki

Dowiedz się więcej o Replice Magazynowej.

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-04-07