the Sky is the Limit
Die Standardinstallation von ESXi verwendet selbst-signierte Zertifikate. Bei Verwendung eigener CA signieter Zertifikate kommt es nach dem Upgrade auf vSphere 5 zu Problemen mit HA.
Zwei sehr gute Blogartikel behandeln die Problematik:
Mit Einführung von vSphere5 kam Storage-DRS als eine neue Funktionalität hinzu. Ähnlich dem herkömmlichen DRS, welches die VM Lastverteilung bezüglich Arbeitsspeicher und CPU zwischen den ESXi Knoten regelt, ermöglicht Storage-DRS eine automatische Lastverteilung in Bezug auf Speicherplatz und I/O.
In der Praxis beobachtet man jedoch häufiger, daß VMs oder einzelne ihrer vDisks nicht migriert werden, obwohl erhöhte Last über einen längeren Zeitraum auftritt. Die Ursache, warum Storage-DRS beispielsweise nicht die vDisk einer VM verschiebt, welche die stark beanspruchte Datenbank enthält, fand ich durch einen Blogartikel von Duncan Epping auf Yellow-Bricks.
Die Standard Einstellung eines jeden Storage Clusters ist “VMDKs zusammenhalten” bzw. “keep VMDK’s together”. Eine Default Einstellung, die sicherlich dem Admin entgegenkommen soll, damit er nicht alle Disks seiner VM auf mehrere LUNs verteilt suchen muß. Der Preis für diese “Ordnung” ist allerdings, daß die Dateien einer VM nur komplett oder gar nicht verschoben werden. In der Praxis bedeutet dies, daß z.B. eine VM mit 5 vDisks von je über 100 GB nur unter extremsten Bedingungen auf eine andere LUN wandern würde. Wünschenswert wäre jedoch, daß beispielsweise nur eine einzelne VMDK Datei verschoben wird, da diese gerade unter erhöhten I/O Druck geraten ist.
Die nett gemeinte, aber etwas unflexible Standardeinstellung dieses Verhaltens läßt sich leicht ändern:
Frank Denneman zum Thema impact of intra vm affinity rules on storage drs.
Normalerweise wird die Benennung von VM Dateien und Diskfiles bei einer Storage vMotion Aktion dem VM Namen angepasst, so daß alle Dateien den Namen der VM tragen. Genau das trat aber heute nicht ein. Der Ordner wurde zwar umbenannt, die VMX Datei und die VMDK Container behielten aber ihre ursprüngliche Bezeichnung. Warum? Eine kurze Suche brachte Licht ins Dunkel. Offensichtlich hat vSphere 5.0.0 in dieser Hinsicht noch einen Bug, der unter KB 2008877 beschrieben wird.
Derzeit bleibt also nur zwei mögliche Methoden:
Warten wir auf den nächsten Patch. 🙂
Einen Datenspeicher vom ESXi Host entfernen klingt zunächst einfach, aber gerade hier kann man sehr viel falsch machen.
Wird die LUN nicht richtig entfernt, so kann es zum All-Paths-Down (APD) Phänomen kommen. Hier ist eine LUN über keinen ihrer Pfade erreichbar. Im schlimmsten Fall kann sich das sogar auf unbeteiligte LUNs auswirken. D.h, eine VM wird unerreichbar, weil eine andere LUN im Cluster sich im Zustand APD befindet. Letzteres Phänomen wurde in vSphere 4.1 U1 beseitigt. „ESX – Datastore sauber entfernen“ weiterlesen