PowerPath Migration Enabler: Cluster-Failover vor dem Commit führt zum Status needsRecovery (Bereinigung) bei Migrationen
Zusammenfassung: PowerPath Migration Enabler: Cluster-Failover vor dem Commit führt zum Status needsRecovery (Bereinigung) bei Migrationen
Symptome
PowerPath Migration Enabler: Cluster-Failover vor dem Commit führt bei Migrationen
zum Status needsRecovery (Bereinigung) Beispiel==================================================================Hnd Quelle Ziel Technischer Zustand
===== ========== ========= ============ ======================
c1 harddisk8 harddisk2 HostCopy(cl) needsRecovery (Bereinigung)
c2 harddisk9 harddisk3 HostCopy(
cl) needsRecovery (Bereinigung)
c3 harddisk10 harddisk4 HostCopy (cl) needsRecovery(Bereinigung)
c4 harddisk11 harddisk5 HostCopy(cl) needsRecovery(cleanup)
c5 harddisk12 harddisk6 HostCopy(cl) needsRecovery(cleanup)
Versuche, eine Bereinigung durchzuführen (mit oder ohne -force), führt zu folgendem Fehler
: C:\>powermig recover -handle c5
Migration für Handle c5 wiederherstellen? [yes]/no:
PPME-Fehler(75): Die zu migrierende Clusterfestplatte gehört diesem Node nicht
Ursache
Lösung
Es gibt keine andere Lösung, um entweder die Wiederaufnahme der Migration oder die Bereinigung der Migration zu ermöglichen. Höchstwahrscheinlich muss die Migration bereinigt und die Migration von Anfang an begonnen werden.
Weitere Informationen
Hinweis: PowerPath Migration Enabler-Befehle (powermig) müssen auf demselben Node ausgeführt werden, auf dem der Befehl powermig setup ausgeführt wurde, wobei die Quell- und Zielgeräte auf diesem Node vorhanden, aktiv und zugänglich sein müssen.
Abfrage 1:
Kann das Entfernen der Ziel-LUNs von beiden Cluster-Nodes zu einer Änderung des PPME-Status führen, sodass ein Abbruch/eine Bereinigung möglich ist, ohne dass ein Failback erforderlich ist? Kann dies helfen, die Migration abzubrechen?
Antwort>>: Nein, der Kernel verfügt weiterhin über einen Datensatz, der besagt, dass sich die Quelle in der Migration befindet, die derzeit nicht außerhalb von powemig aktualisiert werden kann.
Abfrage 2:
Was passiert mit dem "Bereinigungs"-Vorgang und ist ein manuelles Verfahren auf Basis des "Bereinigungs"-Codes möglich?
Antwort>>: Die Bereinigung benötigt jetzt den Status der Migration, der sich in der UMD befindet und sich nur auf dem MainNode (Node A) befindet. Dies ist nur über den Befehl powermig zugänglich.
Abfrage 3:
Besteht das Risiko doppelter Festplattensignaturen, da sich die Migration von Node A vor dem Cluster-Failover im Status sourceSelected befand? Wenn wir also die PPME-Migration manuell abbrechen, besteht dann das Risiko, dass das Windows-Betriebssystem zwei verschiedene Festplatten mit derselben Festplattensignatur erkennt, was zu Clusterproblemen führt?
Antwort>>: Ja, während der Synchronisierung werden die Festplattensignaturen auch auf das Ziel kopiert. Die Bereinigung durch powermig auf dem ursprünglichen Node verhindert, dass dieses Problem auftritt.
Abfrage 4:
Könnte der aktuelle Status (PPME auf Node A, Clusterservices auf Node B, Node A nach Cluster-Failover neu gestartet) zu Problemen führen, wenn Node B schließlich auf Node A zurückgeführt wird.
Antwort>>: Wenn ein Cluster-Failback durchgeführt wird, sollte es keine Probleme geben
Abfrage 5:
Wäre es sinnvoll, die Ziel-LUNs aus den beiden Nodes zu entfernen, sie zu löschen und dann neue LUNs bereitzustellen, nur um sicherzustellen, dass keine Daten auf den Ziel-LUNs vorhanden sind? Befolgen Sie also im Wesentlichen die folgende Vorgehensweise:
1. Entfernen Sie Registrierungseinträge und db*.*-Dateien von den Nodes A und B.
- Entfernen Sie Ziel-LUNs von beiden Nodes.
- Ziel-LUNs löschen/neu erstellen und auf beiden Nodes präsentieren.
- PPME-Migration von Node B starten (aktiver Node
Antwort>>: Funktioniert nicht, der Treiber gibt einen Fehler aus, weil sich die Geräte bereits in der Migration befinden und niemand seinen Eintrag gelöscht hat (d. h. im Speichereintrag).
Abfrage 6:
Ermöglicht ein Neustart des jetzt passiven Nodes die Bereinigung auf dem neuen Node?
Antwort>>: Nur ein passiver Node, d. h. ein Neustart von Node A, hilft möglicherweise nicht, da alle Nodes das Bewusstsein haben, dass die Migration über den Kernel-Modus-Treiber erfolgt und dies aktualisiert werden muss, was nur über powermig auf dem ursprünglichen Node möglich ist.