Storage Replication

[heldchen]

Hi

Also ich setze Fujitsu DX90 mit remote replication ein. Das heisst ich habe auf Storage 1 eine Lun die auf eine Lun von Storage 2 repliziert wird, nahezu in Echtzeit.
In einem Desasterfall wäre ja jetzt Storage 1 tot. Storage 2 wird dem ESX noch nicht präsentiert. Jetziger Vorgehensplan: Storage 2 präsentieren, Datastore connecten, alte VM im Vcenter löschen, den neuen Datastore durchsuchen, VM der Datenbank hinzufügen und starten.

Kann ich das ganze auch verkürzen indem ich ihm das Storage 2 präsentiere auf welchem ja identische Maschinen liegen? Oder findet der Vcenter dann diese Maschinen auch im Normalbetrieb und meckert?

Ich möchte nur die Downtime im Falle eines Defekts von Storage 1 minimieren, bzw die Vorgehensweise möglichst leicht halten für den Fall der immer eintritt, nämlich dass Storage 1 ausfällt während ich in Land XY im Urlaub bin!

[bla!zilla]

Sofern die DX90 die LUNs so präsentieren kann, dass der ESXi sie nicht discoverd (read-only reicht also nicht!), kannst du sie präsentieren. Im Failoverfall müsste die Presentation auf R/W geändert werden. Sofern der SCSI Inquiry String identisch ist, könnte das sogar ohne Neuregistrieren der VMs klappen.

[heldchen]

Hmm ich dachte eigentlich gerade an bereitstellen so dass der der die Störung beseitigt NICHT erst in die Storagekonfig muss. genau diesen weg wollte ich ja ersparen und verkürzen.

[bla!zilla]

Ich kann dir das aus sicht einer HP EVA mit Continuous Access erklären: Dort kann ich logische Laufwerke an Server präsentieren, ohne das diese vom Server erkannt werden. Fällt eine EVA aus und ich initiiere in der Administrationssoftwar Command View einen Failover, dann wird der Zugriffsmodus der logischen Laufwerke geändert und ich kann am Server nach einem Rescan zugreifen. Sofern es sich um die gleichen EVA Modelle handelt und man schnell genug ist, bekommen die Gäste davon nichts mit. Wenn beide Systeme online sind, kann ich damit auch problemlos im laufenden Betrieb einen Failover machen.

Bei der DX90 muss das ähnlich gestrickt sein, wenn du sowas machen willst. Sonst geht es nur mit Downtime, Rescan und Neuregistrierung im Inventory.

[heldchen]

Also in dieser Richtung habe ich dort nichts gefunden. Die Software am Server für beide Systeme ist auch nur zum Einrichten von Luns und anstossen der Replicajobs. Für mehr nicht wirklich. Ausser ich bin blind. Ne kurtze Downtime ist nicht sooo tragisch, mir gehts eher um das eindämmen von Fehlerquellen im Falle eines Falles wenn man sowieso Kopflos ist weil dauernd das Telefon klingelt weil selbst die Putzfrau bescheidsagen muss dass der Server nich geht

[JustMe]

Ein ganz kleines bischen mehr muesste die Software schon hergeben: Naemlich den Status der Copy Groups (Suspended etc. oder so aehnlich).

Ohne das Storage-Management wird man aber hier wohl doch nicht weiterkommen. In der "ueberlebenden" DX90 muessen die Groups aktiviert, und dann die Hosts rebootet werden, um die LUNs zu erkennen. Aber das sollte es auch schon gewesen sein (ausser natuerlich, den vorher primaeren, jetzigen Spiegel zu reparieren).

Grundsaetzlich sollten die beiden DX90 ihre LUNS dauerhaft an alle beteiligten Hosts praesentieren (koennen); die Remote Replication kuemmert sich darum, dass die Spiegel nur als READ-ONLY zu sehen sind.

[heldchen]

Genau den Modus bzw Status der Replicagruppen kann ich ändern und sehen. Ich schau mir das nochmal genauer an.

[bla!zilla]

Grundsaetzlich sollten die beiden DX90 ihre LUNS dauerhaft an alle beteiligten Hosts praesentieren (koennen); die Remote Replication kuemmert sich darum, dass die Spiegel nur als READ-ONLY zu sehen sind.

Read-Only ist aber keine gute Idee. ESXi sieht in dem Fall zwei Datastores von unterschiedlichen Systemen mit den gleichen VMFS Metadaten. Das geht i.d.R. schief, je nach handling des Speichersystems.

[JustMe]

Jein...

Die LUNs werden zwar gesehen, aber wegen der unterschiedlichen Pfade (d.h. nicht passend zu den Metadaten in der LUN) nur als snap-* LUNs erkannt, und somit nicht eingebunden.

Ist halt ein Kompromiss zwischen ganz sauber und ganz ohne zusaetzlichen Eingriff, denke ich...

[heldchen]

Hmm ich bin da etwas unschlüssig. Will eben auch ausschliesssen dass der ESX "versehentlich" die VM auf der Replizierten Lun startet. das wäre ja dann tödlich....

[euro]

Hallo
ich hatte die Tage einen ähnlichen Fall
EMC VNX Storage, nur die aktive Lun wird präsentiert

für den Failover des Storage war es dann zusätzlich nötig, Disallowsnapshotlun auf 0 zu setzen (default ist 1)
ansonsten wurden die Failover Datastores nicht als die Originalen" erkannt, sondern wie bereits geschrieben als snap..XX (und dann müssen alle VM^s neu registriert werden ..

mfg
Stefan

[vMario156]

Wenn manuell das replizierte VMFS Datastore eingebunden wird, darf man natürlich keine neue Signatur darauf schreiben lassen (damit eben nicht alle VMs neu registiert werden müssen).

Ansonsten gibt es dafür den Site Recovery Manager von VMware, der einem diese ganzen manuellen Schritte abnimmt. Sehr starkes Produkt....

[heldchen]

Ich hätte theoretishc kein Problem damit die Maschinen im desasterfall neu zu registrieren. es sind "nur" 16 Server die laufen, also kein allzu großer Aufwand.

Mir geht es wie gesagt darum einfach die Fehlerquellen überschaubar zu halten, da im Desasterfall sowieso dann hektik pur herrscht

[vMario156]

Wenn SRM aus Budgetgründen o.ä. nicht in frage kommt, kann man auch mithilfe von Scripts sich ein paar Dinge leichter machen.

Gruß Mario

[heldchen]

Da ich keine Hausnummer kenne kann ich leider nicht beurteilen ob er in Frage käme :-/

[vMario156]

Hier findest du weitere Infos:

http://www.vmware.com/products/site-rec ... r/buy.html


Offizeler Preis von VMware sind knapp 4900$ für ein 25er Pack der Standard Version.