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

4a von 11 jenseits von GsdF

morgen ist also „Wartungsfenster“ … die Vorboten stehen mitten im Zimmer und der Stressfaktor geht hoch.

Seit gestern haben wir nun die VMs in den Fingern die RawLUN mappings haben. Daraus ergibt sich eine Erweiterung des normalen Konzeptes:

• VM Gastsystem stoppen
• VM im alten VC deregistrieren
• VM im neuen VC registrieren
• die rawLUN mapping löschen
• VM neu konfigurieren (VM Hardwareversion von 3 auf 4, Netzumbau)
• VM starten
• VMWare-Tools updaten
• VM stoppen
• Migration mit Verschiebung des Plattenplatzes bei nicht laufender VM (vmdk-Dateien also die Systemplatten der VM)
• Anbinden der rawLUN vom alten Speicher
• VM starten
• Downtime 1 normalerweise  30-60 Minuten abhängig von Umgebung und Größe der Systemplatten
• Anbinden der rawLUN vom neuen Speicher während die VM läuft.
• Spiegelmöglichkeiten der Gastbetriebssysteme nutzend von alt auf neu die Daten kopieren
• VM stoppen
• die rawLUN mapping zum alten Speicher löschen
• VM starten
• Downtime 2 normalerweise weniger als 3 Minuten

wie zu erwarten war etwas umständlicher und diese VMs bedurften also etwas mehr Handarbeiten…<to be continued>