Kürzlich haben hier ein paar Entwickler SOS gefunkt, deren ESX zäh wie eine Schnecke vor sich dahin kroch. Wie der Zufall so wollte, wurde der Server kurz vorher auf 4.0 Update 2 gehoben, wodurch der Schuldige – zumindest von Seiten der Entwickler – schnell ausgemacht schien. Um kein vorschnelles Urteil zu fällen, haben wir erstmal ‘esxtop’ befragt, um zu schauen, wie es um das System bestellt war und wurden überrascht .. I/O-Latenzen im 4-stelligen (!) ms Bereich bekommt man nicht jeden Tag zu Gesicht.

I/O-Latenzen im Keller

Die I/O-Latenzen in esxtop (zu sehen mit den Tasten: ‘v’ -> ‘f’, ‘j’ -> GAVG/s) lagen in kleineren Bursts um die 4000 ms, womit nicht weiter verwunderlich war, warum Aktionen in den VMs als zäh empfunden wurden. Alles ab dauerhaft 25ms aufwärts sollte ja bereits hellhörig machen. Die Frage, warum sich das seit dem Update so drastisch verschlechtert hatte, konnten wir zwar nicht umgehend beantworten, aber im vCenter Tab “Performance” -> “Disk ms” war rückblickend zu sehen, dass die Werte tatsächlich erst seit dem Upgrade so schlecht wurden.

Interessanterweise waren die Latenzen stark auf einen Datastore begrenzt. Steilvorlage also, um erstmal ein paar betroffene VMs von dem Datastore wegzuziehen und zu schauen, wie sich die Performance auf den anderen Datastores verhalten würde.

Snapshot-Mania

Und das war der Moment in dem etwas ganz anderes ans Licht trat, denn die virtuellen Maschinen hatten durch die Bank weg jede Menge Snapshots (5-10 pro VM) von denen keiner etwas wusste – die VMs ließen sich demnach auch nicht via Storage VMotion verschieben.

Also haben wir die virtuellen Maschinen auf dem Datastore runtergefahren um die I/O-Last zu minimieren und dann die Snapshots konsolidiert …. was etwas dauerte, die unaussagekräftige Fortschrittsanzeige mit 95% bei der man sich lediglich behelfsmäßig über den Fortschritt informieren kann lässt grüßen. Ganz ehrlich, da war die 110% Installationsanzeige früherer MS-DOS-Spiele deutlich sympathischer . Eine Stunde später waren die Snapshots entfernt und damit plötzlich auch die I/O-Latenzen – so schnell sie aufgetaucht waren – wieder verschwunden. Und das bei lediglich ein paar VMs auf dem Datastore.

Und die Lektion der Geschichte?

Ausgelöst wurden die Snapshots (“Automatic Snapshot created when powering off”) durch die snapshot.action-Einstellung, die ich nur im .vmx, nicht aber im vSphere Client wiederfinden konnte. War mir so in ESX-Umgebungen auch noch nicht über den Weg gelaufen.

snapshot.action = "autoCommit"

In die Konfiguration gewandert durch easyvmx, welches die Entwickler einst verwendet hatten, um die VMs für lokale VMware Player Installationen zu generieren. Um das automatische Snapshotting für die Zukunft zu vermeiden, haben wir die Direktive auf der Service Console kurzerhand mit folgendem Einzeiler aus allen Konfigurationsdateien getilgt.

# vmware-cmd -l | grep vmx | while read vmx; do perl -i.bak -ne 'print unless /^snapshot.action/' "$vmx"; done

Jetzt würden mich für die Zukunft nur noch ein paar indikative Metriken interessieren, die (bei erhöhten I/O-Latenzen) eindeutig auf Snapshot-verursachen I/O-Overhead hinweisen bzw. mit deren Hilfe man diesen I/O-Overhead überhaupt beziffern kann. Denn in unserem Fall hatten wir die Snapshots primär konsolidiert, um den Umzug auf einen anderen Datastore zu ermöglichen, nicht weil wir sie als eigentlichen Verursacher für die Probleme (in beobachtetem Ausmaße) im Verdacht hatten. Vorerst gilt also weiterhin: Langlebige Snapshots sind böse.

2 Kommentare zu „Beware: Snapshots (& easyvmx)“