Wenn die aktive Knotenermittlung für die PlateSpin-Umgebung aktiviert ist (Standard), werden zum Migrieren eines Windows-Clusters die inkrementellen Reproduktionen der Änderungen auf dem aktiven Knoten an einen virtuellen Ein-Cluster-Knoten gestreamt. Wenn Sie die aktive Knotenermittlung deaktivieren, kann jeder Knoten in einem Windows-Cluster als eigenständiger Knoten ermittelt und migriert werden.
Bevor Sie Windows-Cluster für die Migration konfigurieren können, muss die Umgebung die Voraussetzungen erfüllen und Sie müssen sich mit den Bedingungen für die Migration von Cluster-Workloads vertraut machen.
Der Umfang der Unterstützung der Cluster-Migration ist von den Bedingungen unter Tabelle 25-1 abhängig. Beachten Sie diese Anforderungen, wenn Sie die Migration für Cluster in Ihrer PlateSpin-Umgebung konfigurieren.
Tabelle 25-1 Anforderungen für die Cluster-Migration
|
Anforderung |
Beschreibung |
|---|---|
|
Den aktiven Knoten als Windows-Cluster ermitteln |
Die globale PlateSpin-Konfigurationseinstellung DiscoverActiveNodeAsWindowsCluster legt fest, ob Windows-Cluster als Cluster oder als separate, eigenständige Computer migriert werden sollen:
Weitere Informationen hierzu finden Sie unter Abschnitt 25.2, Konfigurieren der Ermittlung des aktiven Windows-Knotens. |
|
Suchwerte für den Ressourcennamen |
Die globale PlateSpin-Konfigurationseinstellung MicrosoftClusterIPAddressNames bestimmt die Cluster-Ressourcennamen, die in Ihrer PlateSpin-Umgebung ermittelt werden können. Geben Sie Suchwerte an, mit denen der Name der gemeinsam genutzten Cluster-IP-Adressressource vom Namen anderer IP-Adressressourcen im Cluster unterschieden werden kann. Weitere Informationen hierzu finden Sie unter Abschnitt 25.4, Hinzufügen von Suchwerten für den Ressourcennamen. |
|
Windows-Cluster-Modus |
Die globale PlateSpin-Konfigurationseinstellung WindowsClusterMode bestimmt die Methode für die blockbasierte Datenübertragung bei inkrementellen Reproduktionen:
Informationen hierzu finden Sie in den folgenden Abschnitten: |
|
Hostname oder IP-Adresse des aktiven Knotens |
Beim Vorgang Workload hinzufügen müssen Sie den Hostnamen oder die IP-Adresse des aktiven Knotens im Cluster angeben. Aufgrund von Sicherheitsänderungen durch Microsoft können Windows-Cluster nicht mehr über den Namen des virtuellen Clusters (also über die IP-Adresse des gemeinsam genutzten Clusters) ermittelt werden. |
|
Auflösbarer Hostname |
Der PlateSpin-Server muss den Hostnamen der einzelnen Knoten im Cluster nach der IP-Adresse auflösen können. HINWEIS:Zum Auflösen des Hostnamens nach der IP-Adresse ist die DNS-Suche und die rekursive DNS-Suche erforderlich. |
|
Quorum-Ressource |
Die Quorum-Ressource eines Clusters muss in der Ressourcengruppe (Dienst) des zu migrierenden Clusters koexistieren. |
|
Ähnlichkeiten der Clusterknoten |
Im standardmäßigen Windows-Cluster-Modus kann die treiberlose Synchronisierung von jedem aktiv werdenden Knoten aus fortgesetzt werden, wenn die Knoten ähnlich sind. Stimmen sie nicht überein, können die Reproduktionen nur auf dem ursprünglich ermittelten aktiven Knoten erfolgen. Weitere Informationen hierzu finden Sie unter Clusterknotenähnlichkeit. |
|
PowerShell 2.0 |
Die Windows PowerShell 2.0 muss auf allen Knoten im Cluster installiert sein. |
Die blockbasierte Übertragung für Cluster unterscheidet sich von der Übertragung für eigenständige Server. Bei der ursprünglichen Reproduktion wird entweder eine vollständige Kopie angelegt (vollständige Reproduktion) oder es wird eine treiberlose Synchronisierung auf dem aktiven Knoten im Cluster ausgeführt. Bei nachfolgenden inkrementellen Reproduktionen kann eine treiberlose Methode oder eine treiberbasierte Methode für die blockbasierte Datenübertragung herangezogen werden.
HINWEIS:PlateSpin Migrate unterstützt keine dateibasierte Übertragung für Cluster.
Die globale PlateSpin-Konfigurationseinstellung WindowsClusterMode bestimmt die Methode für die blockbasierte Datenübertragung bei inkrementellen Reproduktionen:
Standard: Treiberlose Synchronisierung mit MD5-basierter Reproduktion auf dem derzeit aktiven Knoten.
SingleNodeBBT: Treiberbasierte Synchronisierung mit einem BBT-Treiber, der auf dem ursprünglich ermittelten aktiven Knoten installiert ist.
Beide Methoden unterstützen die Reproduktion von lokalem und gemeinsam genutztem Speicher auf Blockebene für Fibre Channel-SANs und iSCSI-SANs.
In Tabelle 25-2 werden die beiden Methoden beschrieben und verglichen.
Tabelle 25-2 Vergleich der blockbasierten Datenübertragungsmethoden für inkrementelle Reproduktionen
|
Überlegung |
Standard-BBT |
Einzelknoten-BBT |
|---|---|---|
|
Datenübertragungs-methode |
Verwendet die treiberlose Synchronisierung mit MD5-basierter Reproduktion auf dem derzeit aktiven Knoten. |
Verwendet einen BBT-Treiber, der auf dem ursprünglich ermittelten aktiven Knoten installiert ist. |
|
Leistung |
Potenziell langsame inkrementelle Reproduktionen. |
Erhöht die Leistung bei inkrementellen Reproduktionen erheblich. |
|
Unterstützte Windows-Cluster |
Für alle unterstützten Windows-Server-Cluster verwendbar. |
Für Cluster mit Windows Server 2008 R2 (oder höher). Andere unterstützte Windows-Cluster führen die Reproduktion mithilfe der treiberlosen Synchronisierung aus. |
|
Treiber |
|
|
|
Erste inkrementelle Reproduktion |
Verwendet die treiberlose Synchronisierung auf dem aktiven Knoten. |
Verwendet die treiberbasierte blockbasierte Datenübertragung auf dem ursprünglich ermittelten aktiven Knoten, wenn nach der Installation des BBT-Treibers eine vollständige Reproduktion ausgeführt wurde. Ansonsten wird die treiberlose Synchronisierung auf dem ursprünglich ermittelten aktiven Knoten ausgeführt. |
|
Nachfolgende inkrementelle Reproduktion |
Verwendet die treiberlose Synchronisierung auf dem aktiven Knoten. |
Verwendet die treiberbasierte blockbasierte Datenübertragung auf dem ursprünglich ermittelten aktiven Knoten. Wenn ein Cluster zu einem anderen Knoten wechselt, erfolgt die erste inkrementelle Reproduktion mit der treiberlosen Synchronisierungsmethode, sobald der ursprüngliche aktive Knoten wieder aktiv ist. Weitere Informationen hierzu finden Sie unter Auswirkungen des Clusterknoten-Failovers auf die Reproduktion. |
Tabelle 25-3 zeigt die Auswirkungen des Clusterknoten-Failovers auf die Reproduktion und die erforderlichen Maßnahmen durch den Migrate-Administrator.
Tabelle 25-3 Auswirkungen des Clusterknoten-Failovers auf die Reproduktion
|
Clusterknoten-Failover oder -Failback |
Standard-BBT |
Einzelknoten-BBT |
|---|---|---|
|
Clusterknoten-Failover erfolgt während der ersten vollständigen Reproduktion |
Die Reproduktion schlägt fehl. Die erste vollständige Reproduktion muss erfolgreich und ohne Cluster-Failover abgeschlossen werden.
|
|
|
Clusterknoten-Failover erfolgt während einer nachfolgenden vollständigen Reproduktion oder einer nachfolgenden inkrementellen Reproduktion |
Der Reproduktionsbefehl wird abgebrochen und eine Meldung wird angezeigt, dass die Reproduktion erneut ausgeführt werden muss. Falls das Profil des neuen aktiven Knotens dem des ausgefallenen aktiven Knotens entspricht, wird der Vertrag für die Migration fortgesetzt.
Falls das Profil des aktiven Knotens nicht dem des fehlgeschlagenen Knotens entspricht, gilt der Migrationsvertrag nur auf dem ursprünglich aktiven Knoten.
|
Der Reproduktionsbefehl wird abgebrochen und eine Meldung wird angezeigt, dass die Reproduktion erneut ausgeführt werden muss. Der Migrationsvertrag gilt nur auf dem ursprünglich ermittelten aktiven Knoten.
Bei der ersten inkrementellen Reproduktion nach einem Cluster-Failover/-Failback wird die treiberlose Synchronisierung verwendet. Bei nachfolgenden inkrementellen Reproduktionen wird der mit dem Einzelknoten-BBT festgelegte blockbasierte Treiber herangezogen. |
|
Clusterknoten-Failover erfolgt zwischen Reproduktionen |
Falls das Profil des neuen aktiven Knotens dem des fehlgeschlagenen aktiven Knotens entspricht, wird der Migrationsvertrag gemäß dem Zeitplan für die nächste inkrementelle Reproduktion fortgesetzt. Andernfalls wird der Befehl für die nächste inkrementelle Reproduktion nicht ausgeführt. Wenn eine geplante inkrementelle Reproduktion fehlschlägt:
|
Die inkrementelle Reproduktion schlägt fehl, wenn der aktive Knoten zwischen den Reproduktionen wechselt.
Bei der ersten inkrementellen Reproduktion nach einem Cluster-Failover/-Failback wird die treiberlose Synchronisierung verwendet. Bei nachfolgenden inkrementellen Reproduktionen wird der mit dem Einzelknoten-BBT festgelegte blockbasierte Treiber herangezogen. |
Im standardmäßigen Windows-Cluster-Modus müssen die Clusterknoten ähnliche Profile aufweisen, damit der Reproduktionsprozess nicht unterbrochen wird. Die Profile von Clusterknoten gelten als ähnlich, wenn alle folgenden Bedingungen erfüllt sind:
Seriennummern für die lokalen Volumes der Knoten (System-Volume und reserviertes System-Volume) müssen auf allen Clusterknoten gleich sein.
HINWEIS:Ändern Sie die Seriennummern des lokalen Volumes mit dem angepassten Dienstprogramm Volume Manager, damit sie mit den einzelnen Knoten des Clusters übereinstimmen. Weitere Informationen hierzu finden Sie unter Synchronisieren von Seriennummern im lokalen Clusterknoten-Speicher.
Wenn die lokalen Volumes auf allen Knoten des Clusters verschiedene Seriennummern aufweisen, können Sie nach einem Clusterknoten-Failover keine Reproduktion ausführen. Beispiel: Bei einem Clusterknoten-Failover tritt ein Fehler im aktiven Knoten 1 auf und die Cluster-Software bestimmt den Knoten 2 als aktiven Knoten. Wenn die lokalen Laufwerke auf den beiden Knoten unterschiedliche Seriennummern aufweisen, wird der Befehl für die nächste Reproduktion des Workloads nicht ausgeführt.
Die Knoten müssen dieselbe Anzahl an Volumes umfassen.
Alle Volumes auf allen Knoten müssen exakt gleich groß sein.
Die Knoten müssen eine identische Anzahl an Netzwerkverbindungen besitzen.
Zur Konfiguration der Migration für einen Windows-Cluster gehen Sie nach dem gleichen Ablaufplan wie für die normale Workload-Migration vor. Geben Sie den Hostnamen oder die IP-Adresse für den aktiven Knoten des Clusters an.
PlateSpin Migrate unterstützt gemeinsam genutzte RDM(Raw Device Mapping)-Datenträger (FC-SAN) auf Ziel-VMs bei der halbautomatisierten Migration eines Windows Server-Failoverclusters (WSFC) zu VMware, wobei sich jeder Ziel-VM-Knoten auf einem anderen Host in einem VMware-Cluster befindet. Weitere Informationen hierzu finden Sie unter Erweiterte Windows Cluster-Migration zu VMware-VMs mit RDM-Datenträgern.