vmug

Wer ruft an …

– Tanker vor der Kueste
– alle Daten auf 70 TB datastore
– Krankenhaus Bolivien
– Admin der bei Fehlschlag gefeuert wird
– VIP-VMware Kunde
– BKA und Polizei

 

Welche Probleme tauchen auf ?

– Raid 5 Rebuild
– Stromausfall
– Datastore ploetzlich leer
– Problem nach Panik-erst-reaktion
– Datastore vollgelaufen – oder kurz davor
– VMDKs sind gelockt
– VMDKs mit I/O errors
– VMware-support konnte nicht helfen
– erste Versuche mit Recovery-massnahmen nicht gut genug
– Ontrack zu teuer

Gute Faelle …

 

Traurige Faelle …

 


Vorhersehbare Probleme …

Probleme die bei Diagnose sofort zwingende Massnahmen erfordern
– VM startet mit veraltetem Datenstand …
– Austausch von defekten Platten eines Raid-controllers …

Probleme die duch erste Panik-reaktionen entstehen
– umbenennen von ploetzlich auftauchenden “komischen” Dateien …
– Datastore voll und es musste dringend Platz geschaffen werden …

Probleme die durch das GUI provoziert werden
– ausversehen voreilig geloescht …
– ausversehen formattiert …
– ausversehen falschen Button beim Update geklickt …

Probleme die durch mangelnde Admin-erfahrung unnoetig eskalieren


Ursachen …

Der NTFS – VMFS – vergleich

– warum das ein Problem ist …

 

Die drei Typen von VMware-umgebungen – oder die Kosten von Thinprovisioning

Umgebung Typ A : Verwendete Features – Thin-provisioning und Snapshots
– Datenverlust und Serviceausfall bei Restore eines Backups ist bei allen Mission-critical VMs einkalkuliert und tolerabel
– Automatische Backups laufen und werden staendig ueberwacht
– Datastores haben IMMER ausreichend freien Platz
– Restore von Backups scheitert nicht an mangelnden Resourcen
– Dokumentation ausreichend um zu jeder Zeit einen Notfall handhaben zu koennen
– Stromausfaelle werden durch geeignete Massnahmen abgefangen – die Verfahren werden regelmaessig getestet
– User sind auf Ausfaelle Ihrer VMs vorbereitet und wissen was bei Problemen zu tuen ist
– Admins wissen was bei Ausfall von Platten im SAN oder Raidcontroller zu tuen ist
– Admins wissen wie sie bei einem Ausfall eines Datastores eine Diagnose vornehmen koennen
– Admins beherrschen ein Resignature eines Datastores
– Admins beherrschen die Wiederherstellung von VMX-dateien und VMDK-beschreibungsdateien
– Admins beherrschen den Umgang mit eskalierenden Situationen (voll laufende Datastores)
– die Umgebung wird automatisch gemonitort und jemand liest die Reporte und reagiert taeglich
– keine Ausnahmen !!!
Betriebssicherheit der VMs: schlechter als bei Hardware-Windows-servern wird aber durch Kalkulierbarkeit der Ausfaelle mehr als gut kompensiert.
Risiko: keine Ausnahmen !!! ist schwer einzuhalten

 

Umgebung Typ B1: Verwendete Features – Thin-provisioning und Snapshots
– erfuellt nicht alle Bedingungen fuer Typ A
Betriebssicherheit der VMs: deutlich schlechter als bei Hardware-Windows-servern
Risiko: Handlungsbedarf wird nicht erkannt

Umgebung Typ B2: Verwendete Features – Thin-provisioning und Snapshots
– automatisches Backuptool aktiv
– kein Monitoring
Betriebssicherheit der VMs: Ausfall ist absehbar
Risiko: Handlungsbedarf wird nicht erkannt

Umgebung Typ B3: Verwendete Features – Thin-provisioning und Snapshots
– lokales VMFS-storage
– keine USV
Betriebssicherheit der VMs: inakzeptables Risiko
Risiko: Handlungsbedarf wird nicht erkannt

Umgebung Typ C: Verwendete Features – Eager-zeroed-provisioning und keine Snapshots
– vmkfstools -p 0 flat.vmdk > map.txt
Betriebssicherheit der VMs: vergleichbar mit Hardware-Windows-servern
Benoetigt fast kein Monitoring

 

 


 

 

Anweisungen fuer User der VMs die sich daraus ergeben …

Immer wenn eine wichtige VM nicht startet, nicht auffindbar ist, nicht auf dem erwarteten Stand ist …

– mehrfache Starts mit einem unerwartetem Status erschweren die Fehlersuche – daher ist ein zweiter Start gerade noch erlaubt aber keinesfalls oefter.
– dem User sollte bekannt sein, was es bedeutet wenn sich im Datastorebrowser ein Icon aendert oder flat- und delta- vmdks auftauchen
– bei nicht startenden VMs ist der Datastorebrowser fuer Fehlersuche ungeeignet – daher auf WinSCP wechseln
– grundsaetzlich verboten: loeschen und umbenennen von Dateien
– versehentlich geloeschte Dateien sollten sofort dem Admin gemeldet werden
– falls eine VM mit altem Stand startet sollte kurz nachgeschaut werden, von wann dieser Stand ist – danach schnell herunterfahren
– bei VMs mit Problemen sollten die vmware.logs gesichert werden und Massnahmen getroffen werden, dass die VM nicht versehentlich gestartet wird.

Zusaetzliche Anforderungen an den Admin …

– Arbeiten mit Ordnern und Dateien:
– bestes Werkzeug WinSCP – dabei den Internen Texteditor als Default-editor aussuchen und alle Textedits an vmx und vmdks hiermit erledigen
– Freiraeumen von Ordnern – neuen Unter-Ordner “delete-me-later” anlegen und Dateien mit WinSCP verschieben
– Loeschen von Dateien – statt loeschen erst umbenennen und “delete-me-later” hinter die Extension setzen
– Kopieren und Verschieben von vmdks – grundsaetzlich per vmkfstools

– Datastore laeuft voll:
– unbedingt vermeiden dass die VM im laufendem Betrieb abbricht und “Datastore voll” meldet. Sesparse Snapshots sind so gut wie sicher defekt – delta Snapshots wahrscheinlich
– im Notfall besser vorher abschalten
– falls das Datastore doch schon voll gelaufen ist – im Idealfall moeglichst bald komplett neuaufsetzen

– Geloeschte VMs, VMDKs oder sonstige Dateien:
– moeglichst schnell einen Headerdump erstellen – siehe vm-sickbay
– moeglichst schnell alles Thin-provisioning beenden – falls unmoeglich wenigstens weitest gehend beruhigen
– geloeschte VMX und VMDK-descriptorfiles aus Headerdump auslesen
– Chancen: VMFS 6 = schlecht , VMFS 5 = recovery-versuch macht Sinn , VMFS 3 = Versuch lohnt immer

– Wiederherstellen von vmx oder vmdk-descriptorfiles:
– Nicht die VMknowledgebase beachten
– Nicht googeln
– VMX-dateien: aus letztem log extrahieren oder aus Headerdump kopieren
– VMDK-descriptors: bei einfachen Faellen aus Sample erstellen und mit Daten aus logs anpassen, bei komplexen Faellen aus Headerdump

– Locked files:
– VMFS 5 – vmkfstools und voma anhand KB reicht meistens – ansonsten ueber sshfs Zugriff herauskopieren – im Zweifelfsfall anrufen
– VMFS 6 – vmkfstools und voma anhand KB schlaegt oefter fehl – im Zweifelsfall anrufen
– ein Verfahren zum Beheben fuer Experten – siehe sickbay – im Zweifelsfall anrufen

– Datastore laesst sich nicht mounten:
– Was ist passiert ? – Feststellen ob ein Stromausfall vorher ging oder ein Raidproblem vorliegt wie Rebuild, AUsfall oder Ersatz von Platten
– Headerdump erstellen
– Erste Diagnose die nicht schadet: Pruefen der Partitionstabellen und feststellen ob das Datastore als snapshot erkannt wurde
– Unbedingt vermeiden per Vsphere-wizard voreilig neu zu formattieren
– Resignature ist unbedenklich
– Falls ein Resignature nicht weiter hilft
– Nicht googeln

Zusaetzliche Anforderungen an die Dokumentation einer Umgebung …

Minimal-anforderungen an die Dokumentation der Umgebung:
– Welche VMs sind mission-critical ?
– Welche Daten sind mission-critical ?
– Wo liegen die genau ?
– Welcher Mitarbeiter kann im Notfall diese VMs neu aufsetzen …

Hinweise fuer das Management …

Entscheidungs-findung :
– Plan A1 : Restore Backup oder Plan A2: Neuaufsetzen der VMs
– Plan B : Recovery
– Kategorien der VMs:
– 1. Service-kritisch und Daten-kritisch ( … muss Montag laufen und Daten duerfen maximal x Tage alt sein)
– 2. Service-kritisch (… muss Montag laufen kann neu aufgesetzt werden)
– 3. Daten-kritisch (… Daten sind kritisch – und muessen wieder beschafft werden)
– Festsetzen von Deadlines:
– 1. Wann muessen die VMs wieder laufen (wenn auf die aktuellen Daten verzichtet werden kann)
– 2. Wann muessen die VMs wieder laufen (wenn der aktuelle Stand dabei erreicht werden kann)
– 3. Bis wann muesste der aktuelle Stand recovered sein um noch sinnvoll eingebunden werden zu koennen)
– Einfluss der Hardware
– 1. Optimal: Plan A und Plan B sind unabhaengig voneinander und koennen beide direkt gestartet werden
– 2a. Plan B wird sofort gestartet und fuer Plan A wird kurzfristig zusaetzliche Hardware beschafft
– 2b. Plan B wird ausgelagert – dafuer wird ein diskimage erstellt und danach Plan A auf der betroffenen Hardware gestartet
– 3. Plan A laesst sich erst starten nachdem Plan B abgeschlossen ist oder aus Kosten- oder Zeitgruenden aufgegeben wurde
– 4. Die Daten sind so unersetzbar das alle Optionen der Recovery ausgeschoepft werden muessen

– Bewertung der Notwendigkeit den Schadensgrund heraus zu finden: Hoch bei Sabotage-verdacht , unwichtig bei Stromausfall
– Bewertung der Dauer und Qualitaet von Plan A – Absprache mit “Backup-team”
– Bewertung der Dauer, Prognose und Kosten von Plan B – Dump-erstanalyse

Eine gute Loesung ist vor allem pragmatisch.
Plan A muss frueh genug und in der erwarteten Qualitaet erfolgreich sein.
Plan B ist nicht berechenbar und sollte daher als “optional” betrachtet werden.
Wenn die Abwicklung eines DatenGAUs einmal entschieden ist sollte konsequent danach gearbeitet werden.
Aenderungen des Plans nach 2 Tagen sind meistens contra-produktiv.

 

Fehler die im Vorfeld immer wieder gemacht werden:

– nur ein Datastore
– zu grosse Datastores
– Unkenntnis ueber Details der mission-critical Vms
– Tolerieren von Ausnahmen
– Knowhow ueber mission-critical Vms nur bei einer Person
– RAID 5

Was geht zu oft schief bei Recoveries ?

Fehler die immer wieder gemacht werden:
– Fehleinschaetzungen der Brauchbarkeit der Backups
– Fehleinschaetzung der Dauer von Restore-massnahmen
– Fehleinschaetzung der Dauer von Recovery-massnahmen
– Verzoegern von Entscheidungen
– Team A weiss nicht was Team B macht …
– Ungeeignete Recovery-tools
– Ausbauen der Hardware und Analyse von Windows aus
– Starten der ESXi-server von Boot-CDs wenn das nicht noetig ist
– Massive Zeitvergeudung durch langwierige Scans
– Unkenntnis ueber die zu recovernden Objekte

Problem Nummer 1: google