VMware-Forum

Hallo,

wir betreiben einen VMWare HA Cluster mit drei ESXi 5.0 Servern und noch diverse ESXi 5 und 4 er Hosts außerhalb des Clusters. Diese werden alle mit VCenter verwaltet. Für den HA Cluster setzen wir ein virtualisiertes Datacore SANSymphony V FC Storage ein. Wir haben in einem Ausfallrechenzentrum einen weiteren Datacore Server stehen, der in der Lage ist, zu den Synchron gespiegelten Disks einen asynchronen Spiegel aufzubauen. Nun habe ich eine virtual Disk erstellt, diese an einen ESXi gehängt und einen VMWare Datastore drauf gelegt mit VMFS 3. Auf diesen habe ich eine VM gelegt.

Diese virtual Disk spiegel ich asynchron auf das Storage im RZ. Dort habe ich also eine exakte Kopie inkl. disk identifier. Wenn ich jetzt diese virtual Disk vom Synchronen Spiegel trenne und an den dortigen ESXi 4 hänge (deshalb auch VMFS3), dann sollte dieser die Disk eigentlich erkennen und mounten.

Das tut er aber nicht. Er erkennt zwar das was auf der Disk drauf ist, aber möchte gerne alle Daten löschen um das Laufwerk als neuen Datenspeicher zu mounten.

Woran kann das liegen. Hat jemand erfahrung mit der asynchronen Spiegelung von VMWare Datastores mit Datacore?

Vielen Dank schon mal für die Hilfe.

Gruß

Andreas

P. s. Falls ich noch Informationen über mich oder das Setup liefern soll, bitte kurze Info.

Ich denke mal das VMFS-volume wird bei dir als snapshot erkannt - ueberpruef das mal mit

esxcli storage vmfs snapshot list

http://kb.vmware.com/kb/1011387

Du musst die Disk nach dem Split mit der gleichen LUN ID präsentieren, wie die Source Virtual Disk.

bla!zilla hat geschrieben:Du musst die Disk nach dem Split mit der gleichen LUN ID präsentieren, wie die Source Virtual Disk.

Hallo, danke für die Antwort. Du meinst wenn die Virtual Disk im synchronen Spiegel von beiden Datacore Servern mit der LUN 0 an die ESXer im HA Cluster präsentiert werden, dann muss auch die Kopie von dem entfernten Datacore Server mit der LUN 0 an den entfernten ESX Server präsentiert werden, richtig?

Danke

continuum hat geschrieben:Ich denke mal das VMFS-volume wird bei dir als snapshot erkannt - ueberpruef das mal mit

esxcli storage vmfs snapshot list

http://kb.vmware.com/kb/1011387

Danke für die Info, dass werde ich mal prüfen. Momentan habe ich den asynchronen Spiegel wieder gelöscht und baue ihn neu auf. Sobald das geschehen ist, werde ich den Befehl mal abschicken.

Ich glaube jedoch fast nicht daran, weil ich gar nicht die Möglichkeit bekomme, die Auswahl zu treffen ob ich eine neue Signatur schreiben oder die alte behalten möchte bzw. komplett neu Formatiere. Ein Fehler wird auch nicht angezeigt. Lediglich die LUN als fremdes Laufwerk. Der ESXer in der remote Lokation erkennt nicht mal, das VMFS auf der Disk ist.

Gruß

Andreas

andi74 hat geschrieben:Hallo, danke für die Antwort. Du meinst wenn die Virtual Disk im synchronen Spiegel von beiden Datacore Servern mit der LUN 0 an die ESXer im HA Cluster präsentiert werden, dann muss auch die Kopie von dem entfernten Datacore Server mit der LUN 0 an den entfernten ESX Server präsentiert werden, richtig?

Korrekt. Sobald ESXi Änderungen der Metadaten oder Volumeheader entdeckt, zickt er rum.

EDIT: Du kannst die Destination Virtual Disk problemlos mappen. Solange die Replication läuft (also entweder bis du einen Split machst oder die Destination aktivierst), wird die Disk nicht präsentiert. Das passiert erst beim Split oder Aktivieren. Wichtig ist nur die gleiche LUN ID und das der Disk Identifier mit übertragen wird. Der SCSI Inquiry String wird bei den Storage Servern identisch sein, außer du hast in den Virtual Disk Properties bei den Advanced Settings etwas geändert.

Du wirst aber möglicherweise einen Rescan nach dem Split/ Aktivieren machen müssen. Transparent wird der Failover nicht sein.

bla!zilla hat geschrieben:

andi74 hat geschrieben:Hallo, danke für die Antwort. Du meinst wenn die Virtual Disk im synchronen Spiegel von beiden Datacore Servern mit der LUN 0 an die ESXer im HA Cluster präsentiert werden, dann muss auch die Kopie von dem entfernten Datacore Server mit der LUN 0 an den entfernten ESX Server präsentiert werden, richtig?

Korrekt. Sobald ESXi Änderungen der Metadaten oder Volumeheader entdeckt, zickt er rum.

..... Du wirst aber möglicherweise einen Rescan nach dem Split/ Aktivieren machen müssen. Transparent wird der Failover nicht sein.

Hallo, super Infos, Vielen Dank.

Da wir in regelmäßigen Abständen prüfen müssen, ob die replizierten Daten auch wirklich da sind, habe ich im RZ ein Datacore Checkpoint Snapshot von dem Replikat erstellt und dieses dem ESXi präsentiert. Dort habe ich die VM auf den ESXi gemappt. Und lasse sie ausgeschaltet. Kurz bevor wir eine Prüfung haben, löse ich einen Checkpoint aus und das Snapshot wird aktualisiert.

Das Problem ist einfach, dass ich bis zu einem Splitt des Replikats ja nicht an die Daten komme, um zu zeigen, dass diese komplett sind. Und nach einem Splitt bekommt man sie leider nicht mehr synchron und muss die Synchronisierung neu einrichten. Für das Snapshot benötige ich halt nochmal so viel Platz, da es ein volles Snapshot sein muss. Oder liege ich da falsch.

Vielleicht hat noch jemand ne Idee, wie man das geschickter lösen kann.

Vielen Dank für die Hilfe.

Gruß

Andreas

kannst du von einen Replikat (also Destination vDisk) ein diffential Snapshot anlegen und dieses "serven":
Hier als Beispiel der Blick auf den Destation Server

Der Snapshot des Volumes (Replication Destination) ist Differential und benötigt erstmal 0Byte

Nachtrag: Hab das ganze gerade auch mit Snapshot Marker ausprobiert.
Einen Differential Snapshot als Marker definiert und jede Stunde ein Snapshot Marker gesendet. Funktioniert.

MarcelMertens hat geschrieben:kannst du von einen Replikat (also Destination vDisk) ein diffential Snapshot anlegen und dieses "serven":
Hier als Beispiel der Blick auf den Destation Server

Der Snapshot des Volumes (Replication Destination) ist Differential und benötigt erstmal 0Byte

Nachtrag: Hab das ganze gerade auch mit Snapshot Marker ausprobiert.
Einen Differential Snapshot als Marker definiert und jede Stunde ein Snapshot Marker gesendet. Funktioniert.

Ok, verstanden. Wie verhält es sich denn dann, wenn ich die VM dann starte. Im Snapshot sind doch nur die Deltas. Den Rest nimmt er doch dann von der replizierten Disk, die noch im Spiegel ist. Gibt das keine Probleme? Ich meine, der Source Datacore Server versucht doch dann in das Replikat zu schreiben im RZ (ist ja nicht gesplittet), aber auf das Replikat wird doch im gleichen Moment von der VM zugegriffen. Im Gegenzug müssen doch an der eingeschalteten VM im Ausfall RZ auch Änderungen weggeschrieben werden. Wohin gehen die? In das differencial Snapshot?

Das wäre noch super spannend.

Aber die Tipps sind schon mal spitze und dafür bedanke ich mich ganz herzlich.

Gruß

Andreas

Alle geänderten Blöcke im Replikat seit dem auslösen des Snapshots gehen in den selbigen.
Gehen wir davon aus du hast eine vDisk "Disk1" diese wird in die Disk "REPL_Disk1" repliziert. Jetzt erstellst du um 11 Uhr einen Snapshot von "REPL_Disk1". Dieser Snapshot ist am Anfang leer. Jetzt werden um 11:05 uhr die Blöcke 17,23 und 85 in "Disk1" geändert.
Diese Änderungen werden in die "REPL_Disk1" geschrieben. Vor dem Schreiben der neuen Blöcke 17,23,85 (die von 11:05) werden die originalblöcke 17,23,85 (die ja seit dem Snapshot um 11 Uhr nicht geändert wurden) in den Snapshot kopiert. Je mehr änderungen du an "Disk1" hast, desto größer wird auch dein Snapshot.
Mountest du nun den Snapshot von "REPL_Disk1" an einen Server und ließt um 11:23 Uhr die Blöcke 11 und 17, wird Block 11 aus der Disk "REPL_Disk1" und Block 17 aus dem Snapshot gelesen. Schreibst du was in Block 11, wird dieses in den Snapshot geschrieben und anschließend auch nur aus dem Snapshot gelesen. Lößt du nun einen Checkpoint Marker aus, werden alle Informationen aus dem Snapshot verworfen und es fängt von vorne an.
Dieses gilt natürlich nur für einen Differential Snapshot. Bei einem "Complete Snapshot" werden alle Blöcke aus "REPL_DISK1" in den Snapshot geschrieben.

Nachtrag: Zum Verständis: Du Mountest den Snapshot von REPL_DISK1, nicht REPL_DISK1 an den ESX Hosts!

Marcel

Dickes Danke und Daumen hoch für das Forum. Ich werde das mal alles durchtesten und melde mich ob es läuft.

Eine Sache fällt mir noch ein. Ist es auch möglich bzw. ratsam auf diese Weise einen SQL Server zu replizieren? Die Datenbanken sind natürlich dann Crashkonsistent. Hat jemand Erfahrung damit. Welche Lösung wäre die beste. Der Einsatz von CDP???

Any suggestions? Schon mal realisiert?

Danke schon mal im Voraus.

Hallo, also ich habe die letzten Tage wie wild getestet und bin etwas unglücklich, über die unterschiedlichen Ergebnisse.

Testaufbau:

40 GB Datacore Virtual Disk bereitgestellt auf 3 ESXi Hosts und dort als VMFS 3 Datenspeicher bereit gestellt.

40 GB Datacore Virtual Disk am Remotestandort bereit gestellt.

Asynchrone Synchronisation mit Duplizierung des Disk Identifiers von lokalem zu remoten Standort eingerichtet.

Nachdem die Synchronisation abgeschlossen war, habe ich den Spiegel im Remotestandort gesplittet und an den dortigen ESXi publiziert mit gleicher LUN, mit der auch das Original / Quelle an die drei ESXi Server publiziert wird.

Am Remotestandort im ESXi in der Speicherkonfiguration erneut auf Speicher prüf lassen. Nix passiert. Schon mal ein schlechtes Zeichen, weil ein VMWare Speicher normalerweise sofort angezeigt wird.

Dann auf Speicher hinzufügen gegangen, LUN wird angezeigt ohne VMFS Bezeichner. Auf Weiter geklickt nun die folgenden Informationen zur LUN:

Primäre Partitionen: VMFS (DataCore Fibre Channel Disk ("Ídentifier")
Alle verfügbaren Partitionen werden verwendet. Diese Konfiguration löscht das aktuelle Festplattenlayour. Alle Dateisysteme und Daten gehen dauerhaft verloren.

Identifier geprüft, ist der gleiche. LUN die gleiche, Kapazität der VMFS Partition ist die gleiche. Keine Ahnung wo es hängt.

Wieso akzeptiert der ESXi nicht die Partition. Was bedeutet "Alle verfügbaren Partitionen werden verwendet"? Das sie bereits in Verwendung sind und nicht vom ESXi genutzt werden können?

Please Help. Was könnte noch das Problem sein.

Gruß

Andreas