Bereitstellen eines Clustersatzes

Artikel
10/06/2023

Gilt für: Windows Server 2019

Dieser Artikel enthält Informationen zum Bereitstellen eines Clustersets für Windows Server-Failovercluster mithilfe von PowerShell. Ein Clusterset ist eine Gruppe von mehreren Failoverclustern, die zusammen gruppiert sind. Mithilfe einer Clustergruppe können Sie die Anzahl der Serverknoten in einer einzelnen Software Defined Data Center-Cloud (SDDC) um Größenordnungen erhöhen.

Clustersets unterstützen insgesamt bis zu 64 Clusterknoten. Dies wurde in Tests nachgewiesen. Clustersets können jedoch auf wesentlich höhere Grenzwerte skaliert werden und sind nicht auf einen Grenzwert hartcodiert.

Vorteile

Clustersets bieten folgende Vorteile:

Erhöht die unterstützte SDDC-Cloudstaffelung für die Ausführung hoch verfügbarer virtueller Machinen (VMs) erheblich, indem mehrere kleinere Cluster zu einem einzelnen großen Fabric kombiniert werden, während die Softwarefehlergrenze auf einen einzelnen Cluster reduziert wird. Sie können VMs ganz einfach über das Clusterset migrieren.
Verbesserte Resilienz. Die Verwendung von vier Clustern mit vier Knoten in einem Clusterset bietet Ihnen eine bessere Resilienz als ein einzelner Cluster mit 16 Knoten, da mehrere Serverknoten heruntergefahren werden können und der Betrieb weiterläuft.
Verwaltung des Failoverclusterlebenszyklus, einschließlich Onboarding und Abschaltung von Clustern, ohne die Verfügbarkeit von Mandanten-VMs einzuschränken.
VM-Flexibilität über einzelne Cluster hinweg und ein einheitlicher Speichernamespace.
Einfache Änderung des Workloadverhältnisses zwischen Compute und Speicher in Ihrer hyperkonvergenten Umgebung.
Profitieren Sie Azure-ähnlichen Fehlerdomänen und Verfügbarkeitsgruppen über einzelne Cluster hinweg bei der anfänglichen VM-Platzierung und nachfolgenden Migration.
Kann auch dann verwendet werden, wenn die Compute- und Speicherhardware zwischen Serverknoten nicht identisch ist.
Livemigration von VMs zwischen Clustern.
Azure-ähnliche Verfügbarkeitsgruppen und Fehlerdomänen über mehrere Cluster hinweg.
Verschieben von SQL Server-VMs zwischen Clustern.

Anforderungen und Einschränkungen

Es gibt einige Anforderungen und Einschränkungen für die Verwendung von Clustersets:

Alle Mitgliedscluster in einem Clusterset müssen sich in derselben Active Directory (AD)-Gesamtstruktur befinden.
Mitgliedsserver im Set müssen dieselbe Betriebssystemversion ausführen. VMs können nicht live zwischen verschiedenen Betriebssystemen migriert werden. Ein Clusterset kann aus einer beliebigen (aber nicht aus mehreren) der folgenden Optionen bestehen:
- Windows Server 2019-Failovercluster und Windows Server 2019-Failovercluster
- Windows Server 2019-Failovercluster und „Direkte Speicherplätze“ in Windows Server 2019
- „Direkte Speicherplätze“ in Windows Server 2019 und „Direkte Speicherplätze“ in Windows Server 2019
Für die Livemigration zwischen Mitgliedsclustern müssen alle Mitgliedsserver über identische Prozessorhardware verfügen. Andernfalls müssen Sie in den VM-Einstellungen die Option CPU Processor Compatibility (CPU-Prozessorkompatibilität) auswählen.
Die clusterübergreifende Livemigration von Clusterset-VMs muss manuell erfolgen – ein automatisches Failover ist nicht möglich.
Zwischen Mitgliedsclustern muss ein Speicherreplikat verwendet werden, um bei Clusterfehlern eine Resilienz des Speichers sicherzustellen. Beachten Sie bei Verwendung von Speicherreplikaten, dass Namespace-Speicher-UNC-Pfade beim Speicherreplikatfailover zum Replikatzielcluster nicht automatisch geändert werden.
Direkte Speicherplätze funktionieren nicht über mehrere Mitgliedscluster in einem Clusterset. Stattdessen wirken direkte Speicherplätze auf einzelne Cluster, wobei jeder Cluster über einen eigenen Speicherpool verfügt.

Aufbau

Das folgende Diagramm zeigt ein High-Level-Clusterset:

Im Folgenden finden Sie eine Zusammenfassung der jeweils dargestellten Elemente:

Verwaltungscluster

Der Verwaltungscluster hostet die hoch verfügbare Verwaltungsebene und den Namespaceweiterleitungs-SOFS (Dateiserver mit horizontaler Skalierung) für das Clusterset. Ein Verwaltungscluster ist logisch von einzelnen Mitgliedsclustern entkoppelt, die VM-Workloads ausführen. Dies macht die Verwaltungsebene des Clustersets gegenüber lokalisierten clusterweiten Ausfällen resilient, z. B. gegenüber dem Stromausfall eines Mitgliedsclusters.

Verweisdateiserver mit horizontaler Skalierung für Clusterset-Namespace

Ein Namespace für das Clusterset wird mit einer SOFS-Serverrolle bereitgestellt, die auf dem Verwaltungscluster ausgeführt wird. Dies ähnelt einem DFSN (Verteiltes Namespace-Dateisystem). Im Gegensatz zu DFSN werden Weiterleitungsmetadaten für Clustersetnamespaces allerdings automatisch ohne Benutzereingriff auf allen Clusterknoten eingetragen, sodass der Speicherzugriffspfad nahezu keine Leistungseinbußen verursacht. Dieser einfache Weiterleitungsmechanismus ist nicht Teil des E/A-Pfads.

Jede SMB-Weiterleitungsfreigabe im Clustersetnamespace-Weiterleitungs-SOFS ist vom Typ SimpleReferral. Dieser Verweis ermöglicht SMB-Clients Zugriff auf die SMB-Zielfreigabe, die auf dem Dateiserver mit horizontaler Skalierung des Mitgliedsclusters gehostet wird. Weiterleitungen werden unbefristet auf jedem Clientknoten zwischengespeichert und der Clustersetnamespace aktualisiert die Weiterleitungen bei Bedarf dynamisch / automatisch. Weiterleitungsinformationen werden in jedem Clustersetknoten dauerhaft zwischengespeichert, d. h. auch während Neustarts.

Clusterset-Master

Die Kommunikation zwischen Mitgliedsclustern ist lose gekoppelt und wird von der Clusterset-Masterressource (CS-Master) koordiniert. Wie andere Clustersetressourcen ist der CS-Master hoch verfügbar und resilient gegenüber einzelnen Mitgliedsclusterfehlern oder Verwaltungsclusterknotenfehlern. Über einen Clusterset-WMI-Anbieter stellt CS-Master den Verwaltungsendpunkt für alle Clusterset-Verwaltungsaktionen bereit.

Mitgliedscluster

Ein Mitgliedscluster führt Workloads für VM und direkte Speicherplätze aus. Mehrere Mitgliedscluster sind an einer Clustersetbereitstellung beteiligt, die das größere SDDC-Cloudfabric bildet. Mitgliedscluster unterscheiden sich vom Verwaltungscluster in zwei Hauptaspekten: Mitgliedscluster werden in Fehlerdomänen- und Verfügbarkeitsgruppenkonstrukten verwendet, und Mitgliedscluster werden so dimensioniert, dass sie Workloads für VM und direkte Speicherplätze hosten können. VMs, die sich über Mitgliedscluster hinweg bewegen, werden aus diesem Grund nicht im Verwaltungscluster gehostet.

Clusterset-Worker

Der CS-Master interagiert mit einer Clusterressource in Mitgliedsclustern, die als Clusterset-Worker (CS-Worker) bezeichnet wird. CS-Worker antwortet auf Anforderungen vom CS-Master, einschließlich VM-Platzierung und Ressourceninventarisierung. Es gibt eine CS-Worker-Instanz pro Mitgliedscluster.

Fehlerdomäne

Eine Fehlerdomäne ist eine Gruppe von Hardware und Software, die zusammen ausfallen könnten. Sie können zwar einen oder mehrere Cluster zusammen als Fehlerdomäne festlegen, aber jeder Knoten kann Teil einer Fehlerdomäne in einer Verfügbarkeitsgruppe sein. Fehlerdomänengrenzen basieren auf der Rechenzentrumstopologie, der Netzwerkarchitektur und anderen Überlegungen.

Verfügbarkeitsgruppe

Eine Verfügbarkeitsgruppe wird verwendet, um die gewünschte Redundanz von Clusterworkloads über Fehlerdomänen hinweg zu konfigurieren, indem Workloads gruppiert und bereitgestellt werden. Für eine Anwendung mit zwei Ebenen sollten Sie mindestens zwei VMs in einer Verfügbarkeitsgruppe für jede Ebene konfigurieren. Dadurch wird sichergestellt, dass Ihre Anwendung bei Ausfall einer Fehlerdomäne in einer Verfügbarkeitsgruppe mindestens eine VM auf jeder Ebene hat, die in einer anderen Fehlerdomäne gehostet wird.

Erstellen eines Clustersets

Verwenden Sie PowerShell im folgenden Beispielworkflow, um ein Clusterset mit zwei Clustern zu erstellen. Der Name des hier festgelegten Clusters lautet CSMASTER.

Clustername	SOFS-Name der Infrastruktur
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Verwenden Sie einen Verwaltungsclientcomputer unter Windows Server 2022 oder Windows Server 2019.
Installieren Sie Failoverclustertools auf dem Verwaltungsclusterserver.
Erstellen Sie zwei Clustermitglieder und mit mindestens zwei CSVs (Cluster Shared Volumes) in jedem Cluster.
Erstellen Sie einen Verwaltungscluster (physisch oder als Gast), der sich über die Mitgliedscluster erstreckt. Dadurch wird sichergestellt, dass die Verwaltungsebene des Clustersets trotz möglicher Mitgliedsclusterfehler weiterhin verfügbar ist.
So erstellen Sie das Clusterset:
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
Hinweis

Wenn Sie eine statische IP-Adresse verwenden, müssen Sie -StaticAddress x.x.x.x in den New-ClusterSet-Befehl einschließen.

So fügen Sie Clustermitglieder zum Clusterset hinzu:

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

So benennen Sie alle Mitgliedscluster im Clusterset:
```
Get-ClusterSetMember -CimSession CSMASTER
```
So listen Sie alle Mitgliedscluster im Clusterset auf, einschließlich der Verwaltungsclusterknoten:
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
So listen Sie alle Serverknoten aus allen Mitgliedsclustern auf:
```
Get-ClusterSetNode -CimSession CSMASTER
```

So listen Sie alle Ressourcengruppen über das Clusterset auf:

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

So überprüfen Sie, ob das Clusterset eine SMB-Freigabe (ScopeName Name des Infrastrukturdateiservers) im Infrastruktur-SOFS für jedes Clustermitglied-CSV-Volume enthält:
```
Get-SmbShare -CimSession CSMASTER
```
Überprüfen Sie die Debugprotokolldateien des Clustersets für das Clusterset, den Verwaltungscluster und jedes Clustermitglied:
```
Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>
```
Konfigurieren Sie Kerberos mit eingeschränkter Delegierung zwischen allen Clustersatzmitgliedern.
Konfigurieren Sie den Authentifizierungstyp für die clusterübergreifende VM-Livemigration zu Kerberos auf jedem Knoten im Clusterset:
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```

Fügen Sie den Verwaltungscluster der lokalen Administratorgruppe auf jedem Clustermitgliedsserverknoten im Clusterset hinzu:

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

Erstellen von Clusterset-VMs

Nach dem Erstellen des Clustersets besteht der nächste Schritt im Erstellen von VMs. Führen Sie die folgenden Überprüfungen aus:

Überprüfen Sie den verfügbaren Arbeitsspeicher auf jedem Clusterserverknoten
Überprüfen Sie den verfügbaren Datenträgerspeicher auf jedem Clusterserverknoten
Überprüfen Sie alle spezifischen VM-Speicheranforderungen in Bezug auf Geschwindigkeit und Leistung

Der Get-ClusterSetOptimalNodeForVM Befehl identifiziert den optimalen Cluster und Knoten im Clusterset und stellt darauf dann die VM bereit. Im folgenden Beispiel wird eine neue VM erstellt mit:

4 GB verfügbarer Speicher
Ein virtueller Prozessor
Mindestens 10 % CPU verfügbar

# 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

Wenn Sie fertig sind, wird angezeigt, auf welchem Clusterknoten die VM bereitgestellt wurde. Für das obige Beispiel würde Folgendes angezeigt werden:

State         : Running
ComputerName  : 1-S2D2

Wenn nicht genügend Arbeitsspeicher, CPU-Kapazität oder Speicherplatz verfügbar ist, um die VM hinzuzufügen, erhalten Sie den folgenden Fehler:

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

Nachdem die VM erstellt wurde, wird sie im Hyper-V-Manager auf dem betreffenden Knoten angezeigt. Verwenden Sie den folgenden Befehl, um sie als Clusterset-VM bzw. auch dem Cluster hinzuzufügen:

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

Wenn Sie fertig sind, ist die Ausgabe folgende:

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

Wenn Sie einen Cluster mit vorhandenen VMs erstellt haben, müssen die VMs beim Clusterset registriert werden. Um alle VMs gleichzeitig zu registrieren, verwenden Sie:

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

Fügen Sie als Nächstes den VM-Pfad zum Clustersetnamespace hinzu.

Als Bspw. können Sie sich vorstellen, dass einem Clusterset ein vorhandener Cluster mit vorkonfigurierten VMs hinzugefügt wird, die sich auf dem lokalen CSV (Cluster Shared Volume) befinden. Der Pfad für die VHDX würde in etwa wie bei C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1 lauten.

Eine Speichermigration ist erforderlich, da CSV-Pfade standardmäßig lokal für einen einzelnen Mitgliedscluster vorhanden sind und daher für die VM nach der Livemigration zwischen Mitgliedsclustern nicht zugänglich sind.

In diesem Beispiel wird CLUSTER3 dem Clusterset mithilfe von Add-ClusterSetMember mit dem Dateiserver mit horizontaler Skalierung SOFS-CLUSTER3 hinzugefügt. Um die VM-Konfiguration und den Speicher zu verschieben, lautet der Befehl wie folgt:

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

Nach Abschluss des Vorgangs erhalten Sie möglicherweise eine Warnung:

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.

Diese Warnung wird möglicherweise ignoriert, da keine physischen Änderungen an der Speicherkonfiguration der VM-Rolle vorgenommen wurden. Der tatsächliche physische Standort ändert sich nicht, es ändern sich nur die Konfigurationspfade.

Weitere Informationen zu Move-VMStorage finden Sie unter Move-VMStorage.

Die Livemigration einer VM innerhalb eines Clustersets umfasst Folgendes:

Set-VMHost -UseAnyNetworkForMigration $true

Zum Verschieben einer Clusterset-VM von CLUSTER1 zu KNOTEN2-CL3 auf CLUSTER3 würde der Befehl dann z. B. so lauten:

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

Mit diesem Befehl werden die VM-Speicher- oder Konfigurationsdateien nicht verschoben, und er ist nicht erforderlich, da der Pfad zur VM bestehen bleibt, d. h. \\SOFS-CLUSTER1\VOLUME1. Nachdem eine VM beim Freigabepfad des Infrastrukturdateiservers registriert wurde, müssen sich die Laufwerke und die VM nicht auf demselben Knoten wie die VM befinden.

Erstellen Sie den Infrastrukturdateiserver mit horizontaler Skalierung

In einem Cluster ist eine SOFS-Clusterrolle für die Infrastruktur vorhanden. Die Infrastruktur-SOFS-Rolle wird erstellt, indem der -Infrastructure Switch-Parameter für das Add-ClusterScaleOutFileServerRole cmdlet angegeben wird. Zum Beispiel:

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

Jedes erstellte CSV-Volume löst automatisch die Erstellung einer SMB-Freigabe mit einem automatisch generierten Namen basierend auf dem Namen des CSV-Volumens aus. Sie können SMB-Freigaben nicht direkt unter einer SOFS-Rolle erstellen oder ändern, außer mithilfe der Prozesse zur Erstellung und Änderung von CSV-Volumen.

Bei hyperkonvergenten Konfigurationen ermöglicht es ein Infrastruktur-SOFS einem SMB-Client (Hyper-V-Host), mit permanenter Verfügbarkeit (CA) mit dem Infrastruktur-SOFS-SMB-Server zu kommunizieren. Diese hyperkonvergente SMB-Loopback-CA wird erreicht, indem die VMs auf ihre VHDX-Dateien (Virtueller Datenträger) zugreifen, wobei die Identität der betreffenden VM zwischen Client und Server weitergeleitet wird. Diese Identitätsweiterleitung ermöglicht die Verwendung von ACLs für VHDx-Dateien wie zuvor in hyperkonvergierten Standardclusterkonfigurationen.

Sobald ein Clusterset erstellt wurde, stützt sich der Clusterset-Namespace auf einen Infrastrukturdateiserver mit horizontaler Skalierung in jedem Mitgliedscluster und zusätzlich auf einen Infrastrukturdateiserver mit horizontaler Skalierung im Verwaltungscluster.

Wenn einem Clusterset ein Mitgliedscluster hinzugefügt wird, können Sie den Namen eines Infrastruktur-SOFS für diesen Cluster angeben, sofern bereits vorhanden. Wenn der Infrastruktur-SOFS nicht vorhanden ist, wird eine neue Infrastruktur-SOFS-Rolle für den neuen Mitgliedscluster erstellt. Wenn für den Mitgliedscluster bereits eine Infrastruktur-SOFS-Rolle vorhanden ist, wird sie durch den Vorgang zum Hinzufügen bei Bedarf implizit in den angegebenen Namen umbenannt. Vorhandene SMB-Server oder Nicht-Infrastruktur-SOFS-Rollen in den Mitgliedsclustern werden vom Clusterset nicht verwendet.

Wenn das Clusterset erstellt wird, haben Sie die Möglichkeit, ein vorhandenes AD-Computerobjekt als Namespacestamm im Verwaltungscluster zu verwenden. Bei der Clusterseterstellung wird die Infrastruktur-SOFS-Clusterrolle im Verwaltungscluster erstellt oder die vorhandene Infrastruktur-SOFS-Rolle umbenannt. Das Infrastruktur-SOFS im Verwaltungscluster wird als SOFS für die Namespaceweiterleitung des Clustersets verwendet.

Erstellen von Fehlerdomänen und Verfügbarkeitsgruppen

Azure-ähnliche Fehlerdomänen und Verfügbarkeitsgruppen können in einem Clusterset konfiguriert werden. Dies ist für anfängliche VM-Platzierungen und Migrationen zwischen Clustern von Vorteil.

Das folgende Beispiel enthält vier Cluster in einem Clusterset. Innerhalb des Sets wird eine Fehlerdomäne mit zwei der Cluster und eine zweite Fehlerdomäne mit den anderen beiden Clustern erstellt. Diese beiden Fehlerdomänen umfassen die Verfügbarkeitsgruppe.

Im folgenden Beispiel befinden sich CLUSTER1 und CLUSTER2 in der Fehlerdomäne FD1 und CLUSTER3 und CLUSTER4 in der Fehlerdomäne FD2. Die Verfügbarkeitsgruppe ist CSMASTER-AS.

Die Befehle zum Erstellen der Fehlerdomänen lauten wie folgt:

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"

Um sicherzustellen, dass die Erstellung erfolgreich war, kann Get-ClusterSetFaultDomain ausgeführt und die Ausgabe für FD1 angezeigt werden:

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

Nachdem die Fehlerdomänen erstellt wurden, wird die Verfügbarkeitsgruppe erstellt:

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

Um die Erstellung zu überprüfen, verwenden Sie:

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

Verwenden Sie beim Erstellen neuer VMs den -AvailabilitySet Parameter, um den optimalen Knoten für die Platzierung zu bestimmen. Hier sehen Sie ein Beispiel:

# 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)

Entfernen eines Servers aus einem Set

In bestimmten Situationen muss ein Cluster aus einem Clusterset entfernt werden. Als bewährte Methode sollten alle Clusterset-VMs zuvor aus dem Cluster verschoben werden. Dies kann mit den Befehlen Move-ClusterSetVM und Move-VMStorage erfolgen.

Wenn die VMs nicht zuerst aus dem Cluster verschoben werden, werden alle verbleibenden Clusterset-VMs, die im zu entfernenden Cluster gehostet werden, zu hoch verfügbaren, an diesen Cluster gebundenen VMs, sofern sie auf ihren Speicher zugreifen können. Clustersets aktualisieren auch automatisch ihren Bestand, indem sie die Integrität eines entfernten Clusters und der darauf ausgeführten VMs nicht mehr nachverfolgen und den Namespace und alle Verweise auf Freigaben entfernen, die im entfernten Cluster gehostet werden.

Der Befehl zum Entfernen des Clusters CLUSTER1 aus einem Clusterset lautet beispielsweise wie folgt:

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

Systemstatussicherung

Durch die Sicherung des Systemstatus werden der Clusterstatus und die Metadaten gesichert. Mit der Windows-Server-Sicherung können Sie bei Bedarf auch nur die Clusterdatenbank eines Knotens wiederherstellen oder eine autoritative Wiederherstellung durchführen, um ein Rollback für die gesamte Clusterdatenbank auf allen Knoten durchzuführen. Für Clustersets wird empfohlen, zuerst für die Mitgliedscluster und dann für den Verwaltungscluster eine autoritative Wiederherstellung zu durchführen. Weitere Informationen zur Sicherung des Systemstatus finden Sie unter Sichern des Systemstatus und des Bare-Metal-Computers.

Nächste Schritte

Informieren Sie sich über die Speicherreplikate.