FC-Datastore von alten ESX Hosts zu neuen Hosts umziehen

[pirx]

Hallo,

am Fr. sollen Teile unseres Clusters in ein anderes RZ umziehen. Ich hatte mir dazu auch schon einige Gedanken gemacht.

http://vmware-forum.de/viewtopic.php?p=129181#129181

Mir ist jetzt aber noch ein Problem aufgefallen.

Der Cluster sieht momentan so aus:

2 x ESXi 4.1, 2 x FC Switch, 1 x NetApp FAS2040, das vCenter ist auf einem anderen Host

Im neuen RZ wurden 2 neue ESXi 5 Hosts aufgebaut, die FC Switche und die NetApp ziehen am Fr um.

Der Plan war (wie im Link schon beschrieben), einige wichtige Gäste auf ein NFS Datastor per Storage vMotion zu verschieben und dort zu parken, bzw. laufen zu lassen, bis der Umzug der NetApp abgeschlossen ist. Damit verkürzen wir die Downtime. Die VMs müssen zum Einbinden an die neuen ESXi 5 Hosts eben kurz gestoppt und neu gestartet werden, da es keine vMotion Verbindung zw. alten und neuen Hosts gibt.

Nun aber der Punk der mit Kopfzerbrechen macht. Auf den Datastores die auf der NetApp liegen, werden am Fr. keine VMs mehr aktiv sein. Entweder die VMs werden den ganzen Tag gestoppt, oder sie laufen auf dem NFS DS.

Irgendwann müssen wir aber das SAN auflösen. Also Kabel abziehen, FC Switches und NetApp ausbauen und alles umziehen.

Wie ist da das saubere Vorgehen? Die Datastores sind ja bei den alten ESXi Hosts noch eingebunden. Wenn das SAN einfach aufgetrennt wird, fliegt uns ja sicher alles um die Ohren.

Müssen wir jedes Datastore auf den 2 alten ESX Servern über Configuration -> Storage -> delete entfernen und dann auf den 3 neuen einbinden? Was passiert mit den Datastore Namen?

Gibt's dafür einen besseren Weg?

[pirx]

So sollte es wohl gehen ohne das mir alles um die Ohren fliegt.

- alle VMs der Datastores aus dem Inventory entfernen
- auf den NetApp 'lun unmap' ausfürhren
- rescan
- umziehen
- luns mappen
- rescan
- VMs wieder rein holen

[continuum]

vergess nicht die Datastores zu entfernen BEVOR du die Luns in der Nat App entfernst

[pirx]

vergess nicht die Datastores zu entfernen BEVOR du die Luns in der Nat App entfernst

Was meinst du mit entfernen? Ich habe das heute so mit einer LUN getestet, außer dem Rescan über das vCenter habe ich dort nichts gemacht.

[kastlr]

Hallo,

hier die offizielle Prozedur von VMware.
Unpresenting a LUN containing a datastore from ESX 4.x and ESXi 4.x

Gruß
Ralf

[pirx]

Hallo,

hier die offizielle Prozedur von VMware.
Unpresenting a LUN containing a datastore from ESX 4.x and ESXi 4.x

das Dokument kenne ich. Das Vorgehen scheint mir aber kompliziere zu sein, vor allem mit dem unmasking auf der VMware Seite.

Ich habe gestern an anderer Stelle folgenden Rat bekommen:

i'd remove the vm's from the inventory, then unpresent the lun from the 2040

und nach dem ich auf den KB Artikel verwiesen habe noch mal:

i wouldn't mask, for the third time, i would unpresent the luns in the netapp

Was passiert denn, wenn ich nur die VMs aus dem Inventory entferne, die LUNs auf der NetApp unmappe, einen Rescan durchführe und die Kabel ziehe?

[kastlr]

Hallo,

üblicherweise funktioniert die von dir angedachte Vorgehensweise, alle VM's zu deregistrieren und anschließend die LUN zu entfernen.
Danach einen Rescan durchführen und das sollte es gewesen sein.

Allerdings besteht immer die Gefahr, das noch irgendein Prozeß die LUN im Zugriff hat.
Wenn du dann die Verbindung trennst, erzeugst du damit einen APD (all path down) Event.
Und im Anschluß an so einen Event bleibt nur noch ein Reboot übrig, da die Stabilität des ESX Servers dann nicht mehr gewährleistet ist.
Klare Anzeichen für so ein Problem gibt es leider nicht, das ist wie bei einem Memory Leak.

Somit kannst du mit Mut zum Risiko arbeiten oder dem von VMware vorgegebenen Prozeß folgen.

Gruß,
Ralf

[pirx]

Ok verstanden. Ich werde die einfacherer Variante wählen. Es bleibt glücklicherweise keine Produktion stehen wenn der Host rebootet. Schön wäre es zwar nicht, aber es entsteht kein wirtschaftlicher Schaden.

[pirx]

So, es hat alles ohne Problem funktioniert. Der neue Cluster läuft und alle VMs sind wieder auf das SAN umgezogen, bzw. eingebunden.