Remounting VMFS volumes after transition or async-replicate to another FlashArray
Aktualisiert: 9. Mai 2021
Bei der Arbeit mit Desaster Recovery (DR)-Tasks ist es manchmal erforderlich VMFS-Datenspeicher manuell zu mounten. Volumes welche nicht automatisch auf anderen Hosts an der DR-Site verbunden werden, müssen manuell gemountet werden. Idealerweise kümmert sich der VMware Site Recovery Manager (SRM) darum, da nicht jeder ein solches DR-Automatisierungs-Tool hat, möchte ich in diesem Beitrag zeigen, wie man dies manuell durchführen kann. SRM findet man selbst bei Enterprise-Umgebungen in Deutschland durch die Active-Active-Strategie eher selten vor, in Amerika - bedingt durch große Distanzen - ist SRM hingegen nahezu gängiger Standard.
Zu Beginn muss man hier kurz Aufmerksamkeit der Theorie von VMFS schenken und auf deren Signaturen eingehen. Wenn ein geklontes VMFS Volume an einem Host angehängt wird, gibt es prinzipiell die Möglichkeit die vorhandene VMFS Signatur beizubehalten oder eine neue Signatur zu vergeben (resignature).
Beibehalten der bestehenden Signatur
Grundsätzlich können nicht zwei VMFS-Datastores mit derselben Signatur/UUID (die UUID ist Inhalt der Signatur) auf demselben Host gemountet werden. VMware ESXi verwendet die UUID, um auf das Volume zu verweisen - ein eindeutiger Verweis. Sie können jedoch den initialen Datastore unmounten und das geklonte Volume jederzeit als Datastore mit derselben UUID/Signatur mounten. Zudem kann jederzeit ein geklontes/repliziertes Volume an einen anderen Host mounten, welcher zuvor keinen Zugriff auf den ursprünglichen Datastore hatte (Anwendung bei DR-Vorgängen).
Zuweisen einer neuen Signatur
Durch die Zuweisung einer neuen Signatur wird die UUID geändert. Hier gibt es einige Dinge zu beachten: das Erstellen einer neuen Signatur ist unwiderruflich, sobald die Signatur-Änderung bestätigt wurde, gibt es keinen Weg zurück. Außerdem müssen resignierte Datastores und dessen virtuelle Maschinen (VMs) in ihren Konfigurationsdateien erneut mit dem Datastore referenziert werden und die VMs im vCenter oder auf den Standalone-Hosts neu registriert werden.
Wir widmen uns nun dem manuellen Mounten am DR-Standort an einen dedizierten DR-Standalone-Host. Es gibt keine vCenter-Anbindung an die DR-Site. Ich habe die einzelnen Schritte in nachfolgender Grafik visualisiert:
Die abgebildete Schritte lassen sich wie folgt in Textform wiedergeben:
Einrichtung einer Protection Group (PG) "REPL-Test" auf dem Source-Array
Zuweisen des/der Volumes der erstellten PG
Definieren des "Snapshot Schedule" und "Replication Schedule"
Erstellen eines Snapshot-Klons/Klon-Volume am Async-Target (Target-FlashArray) am DR-Standort und mounten an den DR-ESXi
Registrieren der VM "PURE-HANA" aus dem gemounteten Datastore
ACHTUNG: eine falsche Bedienung beim Mounten von geklonten Datastores kann zu erheblichen Beeinträchtigungen der Produktivumgebung kommen!
Einrichtung Protection Group (Source-Array)
(Die Screenshots der FlashArray-Systeme sind auf Basis von Purity 6.0 erstellt worden! Abweichungen in der GUI-Darstellung sind zu älteren Purity-Versionen möglich.)
Zunächst legen wir eine neue Protection Group "REPL-Test" an und fügen das zu sichernde/replizierte Volume hinzu.
Danach verknüpfen wir das Replikations-Target (dies muss bereits konfiguriert sein - die Konfiguration wird in diesem Beitrag nicht berücksichtigt. Die Konfiguration der Targets erfolgt über Storage > Array > Array Connections).
Nun muss noch der Snapshot- und Replikation Schedule konfiguriert werden. Dies erfolgt gemäß der DR-Vorgaben/Strategie.
Auf dem Production/Source-Target werden alle 5 Minuten lokale Snapshots erzeugt, welche hier in vollständiger Granularität für 3 Tage verweilen. Der RPO am lokalen System liegt also bei 5 Minuten. Danach wird 1 Snapshot pro Tag für weitere 7 Tage aufbewahrt.
Die Replikation wird separat konfiguriert. Hier wurde ein kontinuierliches Replikations-Intervall von 10 Minuten definiert. RPO max. 10 Minuten. Am Target-FlashArray werden Snapshots in voller Granularität für 7 Tage aufbewahrt. Nach 7 Tagen wird je ein Snapshot für 14 weitere Tage aufbewahrt.
Nach der Aktivierung des Snapshot Schedule wird initial ein Baseline-Snapshot erstellt. Danach wird wie eingerichtet alle 5 Minuten ein Snapshot erstellt.
Die Konfiguration der Replikation auf dem Speicher-Layer ist hiermit abgeschlossen.
Es wird nun das Produktiv-Volume mit seinem Inhalt "PURE-HANA-1"/VM repliziert.
Wenn wir einen Blick auf das Target-FlashArray und seine Volumes werfen, werden wir das replizierte Volume "REPL-Test" vorerst nicht finden, da dies derzeit noch im Snapshot-Format der PG "REPL-Test" vorliegt und noch kein Volume darstellt. Ebenso werfen wir einen Blick auf unseren DR-ESXi und sehen auch hier noch keinen Datastore und keine Speichergeräte.
Replikation-Volume verfügbar machen
Zunächst müssen wir auf Basis der übertragenen PG-Snaps ein vollwertiges Volume erstellen. Hierfür wechseln wir zu Protection > Protection Groups > Target Protection Groups und wählen die PG "REPL-Test" aus (im PG-Namen taucht zudem nun der Zusatz des Source-Arrays "PURE-X50-1" auf.).
Innerhalb der PG "REPL-Test" muss nun aus den verfügbaren Snapshots - anhand des Zeitstempels (normalerweise der letztmögliche Stand) - der Recovery-Point ausgewählt werden. Man wählt den gewünschten Snapshot aus und hat nun die Möglichkeit den Kopiervorgang zu starten. Ich stelle das Volume mit demselben Namen des Source-Volumes "REPL-Test" her.
Nun finden wir das Volume am Target-FlashArray auch unter Storage > Volumes.
Auf der Storage müssen wir nun noch das Host-Mapping an unseren DR-ESXi "PURE-ESXi-1" vornehmen. Es wird automatisch eine LUN-ID zugeteilt und wir können außerdem sehen, dass das Volume "REPL-Test" aus der Source/Snapshot "PURE-X50-1:REPL-Test" stammt (wir haben hier jedoch keine Abhängigkeit zum Snapshot - heißt eine Löschung des Snapshots ist jederzeit möglich.).
Mounten Klon-Volume/VMFS
Werfen wir einen Blick auf die GUI des DR-ESXi.
Wir stellen - nach HBA Rescan - fest, dass das geklonte Volume bereits unter den Speichergeräten erscheint. Es gibt keine Möglichkeit über die ESXi-GUI Volumes mit bestehenden VMFS-Signaturen zu mounten. Dies ist ein Sicherheitsfeature innerhalb vSphere. Sollten Sie ein vCenter am DR-Standort haben, können Sie die Tätigkeiten über die vCenter-GUI durchführen.
Wir müssen hier also über die ESXi-CLI arbeiten.
Das Kommando zeigt uns den Namen des VMFS-Datastores und dessen UUID an:
esxcfg-volume -l 
Sollte das Volume nicht angezeigt werden, kann dies daran liegen, dass Sie dieses noch nicht an den ESXi gemountet haben oder ein Rescan des Speicheradapters ausstehend ist. Diesen Vorgang können Sie über die GUI oder per CLI auslösen:
esxcfg-rescan <vmkernel Adapter-Name>Um eine neue Signatur zu vergeben, verwendet man nachfolgendes Kommando (seien Sie sich den obig genannten Auswirkungen bewusst):
esxcfg-volume -r <UUID(mit der zuvor ausgelesenen UUID ersetzen)> Um einen Datastore mit der bestehenden Signatur zu mounten, verwenden Sie:
esxcfg-volume -M <UUID(mit der zuvor ausgelesenen UUID ersetzen)> Der Zusatz -M mountet ein Volume persistent. Bei der Verwendung von -m wird das Volume nur temporär gemountet und bei einem ESXi-Reboot automatisch un-mounted.
Unsere Volume-Kopie wurde nun also persistent vom Target-FlashArray an den DR-ESXi gemountet. Wir können dies über die GUI oder die CLI prüfen.
Sehen wir uns die ESXi-CLI an, haben wir die Möglichkeit über zwei Kommandos den Vorgang zu prüfen:
1.) Generiert eine Übersicht für alle Volumes mit UUID und Gerätenamen:
esxcli storage vmfs extent list
oder:
2.) Listet alle Volumes auf, auf die der ESXi-Host zugreifen kann. Die Ausgabe enthält den Dateisystemtyp, Datenträgerinformationen zusammen mit dem Volume-Namen, dem Pfad und der UUID:
esxcli storage filesystem listRegistrieren der virtuellen Maschine
Abschließend müssen wir aus dem Datastore noch unsere VM/VMs verfügbar machen. Hierzu kann man über den Datastore-Browser (Datenspeicherbrowser über Rechtsklick auf den entsprechenden Datastore) und den jeweiligen VM-Ordner die virtuelle Maschine registrieren. Dies erfolgt über einen Rechtsklick auf das VM VMX-File.
Die gezeigten Tasks erscheinen fürs Erste recht umfänglich...dies täuscht jedoch aufgrund der Ausführlichkeit dieses Beitrags. Es sei gesagt beim eigentlichen Hands-On sind die Tätigkeiten schnell durchgeführt. Wer über eine Automatisierung an dieser Stelle nachdenkt, kommt an einer Einführung von SRM an dieser Stelle nicht vorbei.
WOBEI?!: Pure Storage ActiveDR wird Ihnen hier auch helfen, da mit ActiveDR ein Host-PreConnect integriert ist und die manuellen Klon-/Mount-Tasks hinfällig sind. Hierzu in den nächsten Wochen mehr.
Weitere Infos - Links
Sämtliche offiziell veröffentlichten Einstellungsmöglichkeiten in der GUI, aber auch CLI können über die "on-board" User Guides der Pure Storage Systeme nachgelesen werden.
Im Purity Hauptmenü hierzu auf "Help" klicken.
Der User Guide ist wie das Hauptmenü gegliedert und kann von Ebene zu Ebene geöffnet werden. Eine Suchfunktion ist auch integriert - hier kann mit Schlagworten gesucht werden.
WEB: Pure Storage (Pure1) Supportportal - Ticketsystem und Unterstützung *(erfordert registrierte FlashSysteme)
TEL: Pure Storage Telefonsupport: GER - (+49) (0)800 7239467; INTERNATIONAL - (+1) 650 7294088
WEB: Pure Storage OFFICIAL Blog