4b von 11 der Fluch der shared rawLUN

Auf geschoben ist nicht aufgehoben, dass trifft leider auch auf die ungeliebten Arbeiten zu. Ja ich habe mir die Cluster aufgehoben. Schließlich sind das meine Prunkstücke, etwas edles, die Diven unserer Sammlung virtueller Server. Derartig wollen diese auch behandelt werden. Aber ach, da hat uns VMWare noch ein schönes Osterei beschert. Aber der Reihe nach, erstmal das angewendete Konzept:

• alle VM Gastsysteme stoppen (ganzer Cluster)
• alle VM im alten VC deregistrieren
• alle VM im neuen VC registrieren
• die rawLUN mapping aller VMs löschen
• alle VMs neu konfigurieren (VM Hardwareversion von 3 auf 4, Netzumbau)
• alle VMs starten
• VMWare-Tools updaten
• alle VMs stoppen

Die hohe Weihe des SAN

Heute also soll es beginnen. Ich glaube die Profis im IT Gewerbe nennen so etwas „kick off“.

Was haben wir?

• eine alte Serverlandschaft
• eine neue leere Serverlandschaft
• 2 Server mit der Lizenz zum SAN virtualisieren
• ein alter SAN-Turm mit all unseren Schätzchen in Terabytes gehäuft
• ein neues SAN System das noch nahezu jungfräulich im Rechenzentrum steht

Worin nun die hohe Weihe besteht? Wer das jetzt noch fragen muss, gehe weiter mit der Aldi IT im Laufgitter murmeln. 😉

Aber mal ernsthaft, also wie man die alle so mit einander verkuppelt, ist ein Planspielchen sonders gleichen. Die eigentliche Aufgabe ist aber:

Wie sorgt man dafür, dass die SAN Virtualisierung alles sieht, die alten Server und der alte SAN Turm nicht in der täglichen Arbeit behindert wird und trotzdem die neuen Server und das neue SAN so angebunden und konfiguriert werden, dass am Ende nur die beiden neuen Systeme und die Virtualisierung des SANs überbleiben. Natürlich sollte die Migration der Server so unterbrechungsarm wie möglich erfolgen. Okay es sind (nur) virtuelle Maschinen, was das ein klein wenig vereinfacht.

Gewisse Vergleiche mir dem Gordischen Knoten liegen nicht so fern. Mit LWL ist sowas wohl eher nicht zu empfehlen. 😀