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
• Migration mit Verschiebung des Plattenplatzes bei nicht laufender VM (vmdk-Dateien also die Systemplatten der VM) aller VMs
• Anbinden der rawLUN vom alten Speicher an eine VM
• ggf. so konfigurieren, dass die VM ins BIOS startet, da wir den runlevel 1 benötigen um einen Start der Clusterdienste zu verhindern.
• diese VM starten
• !!! hier ist die Falle beim Wechsel von ESX3.0.x zu 3.5.x. Siehe unten !!! Anbinden der rawLUN vom neuen Speicher während die VM läuft.
• per dd die rawLUN(s) von alt auf neu kopieren.
• Hinweis: es ist sinnvoll den IO Sheduler auf „deadline“ stellen, da wir gerade nur kontinuierliche Lese- bzw. Schreibzugriffe haben und der ist besser als selbst „noop“
• VM stoppen
• die rawLUN mapping zum alten Speicher löschen
• Anbinden der rawLUN vom neuen Speicher (siehe unten)
• alle VMs starten
• Downtime laaaaaang bis seeeeeehr laaaaaang, abhängig von der Anzahl und der Größe des shared Storage

So nun zu unserem (faulen) Osterei. Ja es gibt da so eine Hürde über die ein Cluster springen muss. Bisher war es, wie schon gestern erwähnt, so, dass jeder Clusterknoten einen zusätzlichen SCSI-Controller und ein rawLUN Mapping Datei je LUN hat, die ja eigentlich mehr Link als Datei ist. Je Knoten weist die Mappingdatei auf eine einzige reele LUN. Einen eigenen SCSI Controller erhält man, sobald man beim rawLUN mapping Assistent angibt, dass die Platte die SCSI ID 1:X statt 0:X bekommen soll. ESX 3.5 kann bis zu 4 SCSI Controller je VM, also ist die höchste SCSI-ID 4:15. Dabei fügt der VI Client automatisch einen neuen Controller der VM hinzu. Diesen muss man bei Cluster LUNs eben auf shared physical oder shared virtuell stellen. Abhängig ist das davon, ob der Cluster aus VMs über mehrere ESX Server verteilt wird (am sinnvollsten) oder nur auf einem ESX läuft. Was hat sich daran nun zum 3.5’er geändert? Es ist nun so, dass keine andere VM mehr eine LUN sieht, so bald es dazu eine mapping Datei gibt also ein VM diese schon verwendet. Was heißt das nun für shared LUNs? Das man einen Platz finden muss um die Cluster rawLUN Mapping Datei aufzubewahren. Es gibt die Möglichkeit diese bei einem Knoten auf zu heben oder einen eigenen Storage pool dafür herzunehmen. Wir haben letzteres getan, da die mappings einfach wieder anlegbar und so etwas aufgeräumter sind. Der erste Knoten binden nach dem bekannten Schema ein rawLUN ein, wobei er die mapping Datei auf einen seperaten VMFS ablegt. Die restlichen Knoten binden dann nicht mehr eine rawLUN an, sondern eine „bestehende Platte“ die die gerade unter dem Namen des ersten Knoten angelegten rawLUN Mapping Datei ist. Nicht vergessen immer eine neue SCSI ID wählen und den zusätzlichen SCSI-Controller auf shared stellen. Natürlich kann man biszu 15 shared LUNs an den „cluster“ SCSI-Controller anbinden. Wir haben auch CLuster mit 4 LUNs.

Wenn man diese Neuerung erstmal erkannt hat, ist die Migration der Cluster auch nicht schwerer als die der VMs mit normaler rawLUN.

<to be continued>