Hallo zusammen,
ich benötige eure Ideen / Erfahrungen bei einer recht kniffligen Aufgabe.
Zunächst mal eine Architekturbeschreibung, danach die Frage
1. ESX 3.0.2 Cluster bestehend auf 6 Hosts, angebunden an eine IBM DS4800:
über 40 VMs, ca. 20 davon (leider) auf lokalen HDDs und ca. 20 im shared storage - die OS Partitionen der Lotus Domino Server auf einer vmfs-LUN + jeweils 2x 200 GB RAW-LUNs auf dem selben Storage
2. vSphere 4.0.0 Cluster bestehend aus 8 Hosts, angebunden an die selbe IBM DS4800, aber in einer anderen Host Gruppe als 1.: alle 70 VMs im shared storage.
Die Aufgabe ist die VMs aus 1. inkl. der zugehörigen RAW-LUNs in das 2. Cluster zu migrieren. Die LUNs, egal ob RAW oder vmfs können / dürfen nicht beiden Host Gruppen gleichzeitig zugeordnet werden.
Da auf den 20 VMs mit RAW-LUNs 5000 Notes-User arbeiten, muß die Migration step-by-step und mit möglichst kurzer downtime erfolgen.
Habt ihr eine Idee wie ich das umsetzen kann?
Einfach alles raus, was euch einfällt...
Danke vorab!
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Migrationskonzept
LUN Zuordnung
1. Cluster "Lotus Domino" VMs:
ca 20 VMs, deren OS Partitionen alle auf einer vmfs LUN liegen. Jede dieser VMs hat jeweils 2x 200 GB RAW-LUNs zugeordnet
Alle LUNs hier befinden sich in einer logischen Host-Gruppe im SAN Director auf einer IBM DS 4800
2. Cluster:
alle VMs auf vmfs LUNs auf dem selben Storage wie 1., jedoch in einer anderen Host-Gruppe im SAN Director.
Ich habe ein kleines Schaubild zur Visualisierung angehängt.
ca 20 VMs, deren OS Partitionen alle auf einer vmfs LUN liegen. Jede dieser VMs hat jeweils 2x 200 GB RAW-LUNs zugeordnet
Alle LUNs hier befinden sich in einer logischen Host-Gruppe im SAN Director auf einer IBM DS 4800
2. Cluster:
alle VMs auf vmfs LUNs auf dem selben Storage wie 1., jedoch in einer anderen Host-Gruppe im SAN Director.
Ich habe ein kleines Schaubild zur Visualisierung angehängt.
Ich denke die Notes VMs sind geclustert, also der Ausfall einzelner VMs wird von den anderen abgefangen? Wenn nein, wirst du um eine Downtime der Services nicht herumkommen.
Sollte Notes doch geclustert sein, dann ist das "relativ" problemlos, die einzelnen Server müssen zwar runter gefahren werden, aber die Services stehen zumindest für Benutzer zur Verfügung, auch wenn das Notes Failover etwas "eigen" ist.
Eine Migration von 3.5 auf 4.0 verlief bei uns weitgehend ohne Probleme, den konkreten Updatepfad für 3.0er Vms auf 4.0 musst du dir aber nochmal anschauen.
In unserem Fall war das einfach VMware Tools updaten, Neustart. Herunterfahren. Virtuelle Hardware Updaten. Starten. Neustart. Fertig. Zumindest für das Update auf neue ESX Version.
Da die LUNs aber jeweils zu anderen ESX Server gehören und du schreibst de können nicht gleichzeitig beiden VMware Clustern zur Verfügung gestellt werden, müsst ihr die jeweilige LUN auf die andere Hostgruppe umkonfigurieren, was mit dem Tools von IBM ja auch Problemlos ging (zumindest mit einer Ds4400 und 4500).
Zu den oben genannten Tätigkeiten würde also davor noch hinzukommen. Die VM herunterfahren, LUN umhängen, auf dem neuen Cluster die neue LUN einrichten. Die VM selbst muss leider kopiert werden, denn die liegt auf einer LUN die nicht umgehängt werden kann. Das geht ganz gut mit VEEAM FastSCP zum Beispiel (damit haben wir ca. 100 VMs über eine WAN 100 MBit Leitung NACHEINANDER in ein neues RZ verschoben).
Ist die VM in der neuen Umgebung angekommen, kann die registriert werden, das RAW Device hinzugefügt werden und die schon Anfangs genannten updates durchgeführt werden.
So müsste das eigentlich gehen, nichts desto trotz muss alles an TEST LUNs und Test VMs geprüft werden um Hindernisse zu erkennen, bevor ihr mit der Migration loslegt.
Sollte Notes doch geclustert sein, dann ist das "relativ" problemlos, die einzelnen Server müssen zwar runter gefahren werden, aber die Services stehen zumindest für Benutzer zur Verfügung, auch wenn das Notes Failover etwas "eigen" ist.
Eine Migration von 3.5 auf 4.0 verlief bei uns weitgehend ohne Probleme, den konkreten Updatepfad für 3.0er Vms auf 4.0 musst du dir aber nochmal anschauen.
In unserem Fall war das einfach VMware Tools updaten, Neustart. Herunterfahren. Virtuelle Hardware Updaten. Starten. Neustart. Fertig. Zumindest für das Update auf neue ESX Version.
Da die LUNs aber jeweils zu anderen ESX Server gehören und du schreibst de können nicht gleichzeitig beiden VMware Clustern zur Verfügung gestellt werden, müsst ihr die jeweilige LUN auf die andere Hostgruppe umkonfigurieren, was mit dem Tools von IBM ja auch Problemlos ging (zumindest mit einer Ds4400 und 4500).
Zu den oben genannten Tätigkeiten würde also davor noch hinzukommen. Die VM herunterfahren, LUN umhängen, auf dem neuen Cluster die neue LUN einrichten. Die VM selbst muss leider kopiert werden, denn die liegt auf einer LUN die nicht umgehängt werden kann. Das geht ganz gut mit VEEAM FastSCP zum Beispiel (damit haben wir ca. 100 VMs über eine WAN 100 MBit Leitung NACHEINANDER in ein neues RZ verschoben).
Ist die VM in der neuen Umgebung angekommen, kann die registriert werden, das RAW Device hinzugefügt werden und die schon Anfangs genannten updates durchgeführt werden.
So müsste das eigentlich gehen, nichts desto trotz muss alles an TEST LUNs und Test VMs geprüft werden um Hindernisse zu erkennen, bevor ihr mit der Migration loslegt.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 20 Gäste