.esxtop4rc zur Rettung

Beim Betrachten der verschiedenen Metriken in esxtop kann man via Taste ‘f’ Spalten ein- und ausblenden. Die so konfigurierte Ansicht kann man für zukünftige Aufrufe via ‘W’ abspeichern (Konfiguration wandert per Default .esxtop4rc) und das gilt – wie hier gefunden – nicht nur für interaktive, sondern auch für die Batch-Aufrufe.

Um also die in einem Batch-Lauf anfallende Datenmenge zu reduzieren, erstellt man sich eine auf die gewünschten Werte reduzierte .esxtop4rc. Mit etwas Perl-Unterstützung (vermeidet das mühselige Deselektieren ungewünschter Felder) funktioniert das folgendermaßen:

1) Bestehende Konfiguration kopieren und alle Felder deselektieren

    cp .esxtop4rc .esxtop4rc-batch
    perl -pi -e '$_ = lc if /^[[:alpha:]]/' .esxtop4rc-batch

2) Danach esxtop aufrufen, die gewünschten Spalten wieder hinzukonfigurieren und die Konfigurationsdatei abspeichern.

    esxtop -c .esxtop4rc-batch

3) Abschließend esxtop im Batch-Modus starten.

    esxtop -b -d 30 -n 240 -c .esxtop4rc-batch > esxtop-batch.csv

Die anfallenden Datenmengen sollten nun deutlich schlanker ausfallen. Vorher einmal Ausprobieren, Datenmenge vergleichen und Sicherstellen, dass alle gewünschten Werte zur Erfassung konfiguriert sind. Dann viel Spaß beim Sammeln und Analysieren!

Kommerzielle Backup-Lösungen

Virtualisierung ermöglicht bekannterweise neue Methoden der Datensicherung, z.B. die Komplettsicherung von virtuellen Maschinen. Das ist praktisch für Desaster-Recovery-Zwecke, bringt aber auch seine eigenen Herausforderungen mit sich: Wie sichert man eine laufende virtuelle Maschine ohne Downtime? Wie geht man intelligent mit den anfallenden Datenmengen um? Wie stellt man einzelne Dateien aus gesicherten virtuellen Maschinen wieder her?

Neben Agenten für gängige Backup-Lösungen (NetBackup, Legato, …) füllen diese Nische spezialisierte Lösungen wie Vizioncore vRanger Pro, Veeam Backup & Replication oder PHD Virtual esXpress. Zum Funktionsumfang gehören dabei meist

• eine zentrale GUI zum Verwalten der Backup-Jobs
• Deduplizierung auf Blockebene bzw. Komprimierung, um anfallende Sicherungsmengen zu reduzieren
• inkrementelle VM-Sicherungen
• Rücksicherung von einzelnen Dateien aus VM-Vollbackups
• oder aber Replikation zum Zwecke von Continuous Data Protection (CDP).

Kostenfrei: ghettoVCBg2.pl

Für virtuelle Infrastrukturen mit weniger ausgewachsenem Anforderungsprofil (und weniger Buzzword Bedarf) gibt es mit ghettoVCBg2.pl, der Weiterentwicklung von ghettoVCB.pl, eine kostenfreie, im Funktionsumfang reduzierte Alternative. Basierend auf dem Perl SDK nutzt es dynamisch erstellte Snapshots zum Abziehen von VM-Vollbackups – sprich: man erhält als Sicherungs-Endprodukt eine komplette Kopie der gesicherten VM, die man im Desaster-Fall auf einem anderen (oder dem wiederhergestellten) ESX Server in Betrieb nehmen kann.

Im Gegensatz zu seinem Vorgänger ist ghettoVCBg2.pl nicht mehr für den lokalen Einsatz auf einem ESX Server gedacht, sondern zum Einsatz auf dem eingangs erwähnten vMA ausgelegt. Der ermöglicht die Sicherung von VMs, ungeachtet der Frage auf welchem von mehreren potentiellen ESX Servern die VMs zum Zeitpunkt der Sicherung laufen. Was ghettoVCBg2.pl erklärterweise nicht unterstützt, ist die Sicherung von VMs mit bestehenden Snapshots. Wenn man bedenkt, welche Implikationen lang bestehende Snapshots aus betrieblicher Sicht haben (z.B. kein Storage Motion möglich) ein zu verschmerzender Sachverhalt.

Vorbereitende Arbeiten vMA / ESX Hosts

Insofern noch nicht in Betrieb, kann der VMware Virtual Management Assistant hier kostenfrei heruntergeladen werden. Diesen nimmt man in Betrieb (VM importieren und starten), loggt sich als vi-admin ein und bringt ihm initial die Credentials für das vCenter und die ESX Server bei.

$ vifp addserver <vcenter-hostname> [--username user]
$ vifp addserver <esx1-hostname> [--username user]
$ vifp addserver <esx1-hostname> [--username user]
$ vifp addserver ….

Die so hinzugefügten Server lassen sich via

$ vifp listservers

anzeigen und sind in ~/.vmware/credstore/vicredentials.xml fest hinterlegt. Perl Skripte, welche die vifp Features unterstützen (und dazu gehört ghettoVCBg2.pl) haben somit “authentifizierungs-losen” Zugriff auf die Server. Falls es beim Hinzufügen von ESX-Hosts zu Timeouts kommt, hat sich erfahrungsgemäß der hostd auf dem betroffenen Host verklemmt und muss neu gestartet werden (hier hilft VMware KB #1003490 “Restarting the Management agents on an ESX or ESXi Server” weiter).

Weiterhin empfiehlt es sich, als Zieldatenspeicher für die Sicherungen ein zentrales NAS Dateisystem auf seinen ESX Hosts zu mounten – über die GUI oder via esxcfg-nas. Das NAS Dateisystem kann von einem Enterprise-Storage (NetApp, Sun Unified Storage, etc.) oder aber auch ein OpenFiler bzw. FreeNAS kommen. Damit hat man seine Sicherungsdaten an zentraler Stelle und im Bedarf auf allen ESX Hosts verfügbar.

Konfiguration und Inbetriebnahme

Nun kann ghettoVCBg2.pl heruntergeladen und auf dem vMA abgelegt werden. Zur Konfiguration editiert man das Skript und passt im oberen Teil die folgenden Variablen entsprechend seiner individuellen Bedürfnisse an. Als Beispiel:

my $VM_BACKUP_DATASTORE = “nfs-esx-share”;
my $VM_BACKUP_DIRECTORY = “ghettoVCBg2-backup”;
my $VM_BACKUP_ROTATION_COUNT = “3″;
my $DISK_BACKUP_FORMAT = “thin”;
my $POWER_VM_DOWN_BEFORE_BACKUP = “0″;
my $VM_SNAPSHOT_MEMORY = “1″;
my $VM_SNAPSHOT_QUIESCE = “1″;

Backups werden hier auf dem Share namens “nfs-esx-share” im Ordner “ghettoVCBg2-backup” abgelegt. Es werden jeweils drei Kopien aufgehoben (Achtung: Das Rotieren geschieht erst nach erfolgtem Backup, also Platz für bis zu n + 1 Sicherungen kalkulieren) und die Sicherungen erfolgen im thin Format (siehe ESX Disk Options). Der Arbeitsspeicher der VMs wird mitgesichert und vor dem Erstellen des zur Sicherung benötigten Snapshots wird Gast-seitig ein Flushen vorhandener Dateisystem-Buffer ausgelöst (benötigt installierte VMware Tools im Gast).

Abschließend stellt man die Liste von ein paar zu sichernder Test-VMs in einer Datei mit beliebigem Namen zusammen (beispielsweise vmlist) und startet ghettoVCBg2.pl zu einem ersten Testlauf

$ ./ghettoVCBg2.pl –output /dev/stdout –vmlist vmlist

Wenn soweit alles passt, kann man diesen Aufruf mit angepasster –output Zieldatei in die crontab des vi-admin Nutzers packen und hat somit periodische Vollsicherungen seiner virtuellen Maschinen.

Ausblick

An einigen Ecken ist sicherlich noch Anpassungsaufwand notwendig: Windows VMs fühlen sich zu Sicherungszwecken mit Volume Shadow Services am wohlsten, Datenbanken oder andere Dienste wollen vor der Sicherung ggf. in einen konsistenten Zustand versetzt werden und eine Überwachung des Backup-Logs mit z.B. Nagios ist empfehlenswert.

Vieles ist denkbar, der letztendlich wichtigste Aspekt ist wie bei allen Dingen das Testen der Funktionalität für die eigene Infrastruktur (Sicherung/Rücksicherung, sonstige funktionale Anforderungen sowie betriebliche Aspekte – passt die Lösung in unsere Umgebung?) … und das gilt sowohl fŭr die kommerziellen Varianten als auch für ghettoVCBg2.pl.

Erfolgreiches Sichern!