Mit höheren Server-Konsolidierungsraten erhöht sich der Ausnutzungsgrad der IT-Infrastruktur. Doch wenn die Server besser ausgelastet sind, haben sie weniger Freiräume um typische Aufgaben wie etwa Sicherungs-Jobs abzuwickeln. Hier sind Konzepte gefordert, die vor allem die Systeme im Produktiveinsatz nicht über Gebühr belasten. Dazu muss der IT-Verantwortliche einige Aspekte beim Backup überdenken.

Die größte Verbreitung im Bereich der Server-Virtualisierung im Produktiveinsatz haben die Produktlinien von VMware. Dabei spielt die »VMware Infrastructure 3« (VI3) immer noch eine bedeutende Rolle, auch wenn mit »vSphere 4« die Nachfolge-Plattform nun schon in der Version 4.1 zur Verfügung steht. Der Erfolg der VI3 im Produktiveinsatz hat zur Folge, dass Unternehmen ihre Bemühungen im Bereich der Server-Konsolidierung vorantreiben. Damit kommen immer mehr virtuelle Maschinen (VMs) auf den physischen Hosts zum Einsatz.

Besonders interessant – und auch herausfordernd – wird diese Konstellation, wenn Unternehmen auch noch die Desktop-Virtualisierung in Form einer »Virtual Desktop Infrastructure« (VDI) ins Visier nehmen. Denn in einem derartigen Szenario steigt die Anzahl der VMs auf einem physischen Host extrem an. Und falls mit diesem physischen System etwas schief geht, kommt es zu einer massiven Katastrophe. Daher verdient das Thema Backup und Recovery – und im diesem Kielwasser auch das Disaster-Recovery (DR) – höchste Aufmerksamkeit.

Traditioneller Notfallplan ist zu adaptieren

Hat ein IT-Verantwortlicher einen Sicherungs- und Wiederherstellungsplan sowie einen Notfallplan für den Komplettausfall von Systemen zu erstellen, muss er die richtige Balance finden. Die wesentlichen Parameter dazu sind einerseits die Kosten und auf der anderen Seite stehen die Einfachheit des Konzepts, die Geschwindigkeit sowohl für das Sichern als auch das Wiederherstellen und zudem auch noch die Wiederherstellbarkeit an sich.

Speziell im Umfeld der VI3 sind dazu einige Aspekte zu beachten:

• Das Wiederherstellen der VMDK (Virtual Machine Disk): Die Sicherungsmethodik sollte es ermöglichen, konsistente komplette VMDKs wiederherzustellen. Bei der VMDK handelt es sich um eine portable Speichereinheit, die auch alle Einstellungen des jeweiligen Gastbetriebssystems enthält. Daher ist es die einfachste Möglichkeit, den Status einer VM wiederherzustellen. Andererseits ist eine VMDK ein enorm großer Datenbereich und deswegen scheuen viele Administratoren davor zurück, sie regelmäßig und in kurzen Abständen zu sichern. Allerdings bieten die VMDKs ein ideales Einsatzfeld für Deduplizierungs-Systeme, da sie sehr hohe Deduplizierungsraten erreichen. (Ein aktuelles White Paper von EMC spricht von einer maximalen Reduzierung um den Faktor 60.)
• Das Wiederherstellen von Dateien im Bereich des Gastbetriebssystems: Die allermeisten Wiederherstellungsjobs (etwa 80 Prozent) betreffen Dateien – so lautet die Aussage der Marktforscher von Gartner. Das trifft vor allem dann zu, wenn eine VM im Produktivbetrieb agiert. Das sollte das Sicherungskonzept auf alle Fälle mit in Betracht ziehen.
• Auswirkung des Sicherungslaufs auf die VM: Die Sicherungsjobs dürfen eine VM im Produktiveinsatz nicht beeinträchtigen. Das stellt in kleineren Umgebungen oft keine Probleme dar, doch wenn es darum geht, zum Beispiel 20 VMs auf einem physischen Host – womöglich gleichzeitig – zu sichern, wird das die Systemressourcen massiv beanspruchen.
• Auswirkungen der Sicherungsjobs auf den physischen Host: Wird der ESX-Host von den Anforderungen des Backups massiv belegt, bleiben nicht mehr genügend Ressourcen für den Betrieb der VMs mit ihren Gastbetriebssystemen und Applikationen übrig. Es gilt die wichtige Regel: Das Backup darf nicht zu Unterbrechung oder gar Ausfall der Applikationen führen.
• Geschwindigkeit des Backups: Dieser Faktor ist auch aus der traditionellen, nicht virtualisierten Welt bekannt: die Sicherung muss im Rahmen des Zeitfensters bleiben.
• Skalierbarkeit des Sicherungskonzepts: Wer heute seinen Backup-Plan definiert, der sollte auch an morgen denken. Denn es kommen viel schneller neue VMs mit ins Spiel, als das früher der Fall war. Denn VMs sind schneller aufgesetzt und gestartet als neue Server gekauft.

Zu diesen Anforderungsfaktoren gibt es im Umfeld der VI3 mehrere Lösungsmöglichkeiten. Von Prinzip her sind folgende Ansätze denkbar:

• Die einfachste Sicherung erfolgt direkt in der laufenden VM.
• Es besteht die Möglichkeit, die Sicherung vom physischen Host, dem ESX-Server, auszuführen, auf dem die VMs laufen.
• Die VCB (Vmware Consolidated Backup) kommt zum Einsatz. Bei ihr findet ein zusätzlicher Server (auf Basis von Windows Server 2003 oder neuer) Einsatz, der als ein Proxy arbeitet. Er holt sich die zu sichernden Informationen vom physischen Host und schreibt sie danach auf das Sicherungsgerät.
• Eine weitere Sicherungsmöglichkeit setzt direkt im Speichernetzwerk (entweder im SAN oder im NAS) an. Dazu sind aber in der Regel Skripts nötig, die Kopien von Dateien beziehungsweise Snapshots erstellen.
• Der Einsatz einer kommerziellen Sicherungs-Software, die mit virtuellen Umgebungen richtig umgehen kann.

Lösung für kleinere Umgebungen

Ein Ansatz, der für IT-Personal ohne große Virtualisierungserfahrung und generell für kleinere Umgebungen gut geeignet ist, arbeitet mit einem Backup-Agenten, um die Gastbetriebssysteme in einer VM sowie die VMDK zu sichern. Dabei kommt in der Regel die bestehende Sicherungs-Software zum Einsatz, die auch für die anderen, nicht virtualisierten Systeme im Rechnerraum Verwendung findet. Allerdings besteht sie aus zwei Teilen:

Einmal wird die VM wie ein normales System betrachtet und es findet eine dateibasierte Sicherung des Gastbetriebssystems und der zugehörigen Applikationen mit Hilfe des Backup-Agenten statt. Der zweite Teil muss die Service Console von VI3 sichern. Dazu eignet sich ein Backup-Client, der mit dieser Linux-basierten Spezial-VM, der Service Console, umgehen kann. Damit werden die Konfigurationsdaten des ESX-Servers und die VMDKs als vollständige Systemwiederherstellungspunkte gesichert.

Beim Sichern der Dateien des Gastbetriebssystems in der VM bleibt alles beim üblichen Vorgehen. Ein Backup-Client (oder -Agent) wird in jeder VM installiert. Über einen Zeitplandienst lässt sich dann die Sicherung auf Dateiebene ausführen – alles so wie es auch bei einem einzelnen physischen (also nicht virtualisierten) Systems erfolgt. Auch die Wiederherstellung einzelner Dateien läuft ab wie üblich. Auch die komplette Infrastruktur für das Sichern der Systeme kann für alle VMs geteilt werden.

Doch dabei erkennt man bereits die Schwachstelle: Wenn sehr viele VMs zu sichern sind, wird die Verwaltung – und vor allem der Überblick für die Backup-Betreuer – schwieriger. Zudem dürfen nicht zu viele Sicherungs-Jobs gleichzeitig aktiviert werden. Die Frage der Skalierbarkeit dieses Ansatzes wird mit komplexerer Infrastruktur immer schlechter zu beantworten sein.

Sichern der VMDK

Beim Sichern des ESX-Servers und der kompletten VMDKs handelt es sich bei den VMDKs um ein komplettes Image-Backup. Dazu muss vom Prinzip her ein Linux-Backup-Agent in der Service Console agieren. Beim Wiederherstellen einer VM muss man dann den Ordner für die betreffende VM restaurieren, die die VMDK-Dateien enthalten. Wer sich nur auf diese zweite Methode verlässt, der kann bei der Wiederherstellung auch nur wieder das komplette Image zurückschreiben. Einzelne Dateien aus dem Gastbetriebssystem sind damit nicht möglich.

Mit dem VCB tritt eine dritte Methode auf den Plan. Diese Lösung hat Vmware mit Hilfe eines Proxy-Servers realisiert. Sie hat sich in den vielen Jahren, die sie im Einsatz ist, als eine gute Option für komplexere Konfigurationen erwiesen. Zudem unterstützen viele Backup-Pakete von Drittherstellern diese Technik und erweitern sie. Einen moderneren Ansatz hat Vmware ebenfalls im Programm, doch der geht über »vStorage API« (VAPI) und steht erst ab Vsphere 4 zur Verfügung.

Der VCB-Agent ist als eigenes Softwarepaket auf dem Proxy-Host mit Windows 2003 Server am Laufen. Er erstellt einen Snapshot einer individuellen Vmware-VM und kopiert die Daten in ein temporäres Verzeichnis. Diese Daten werden dann – nach Beendigung des Snapshot – für die Sicherung herangezogen. Bei Snapshot einer VMDK wird eine spezielle VMDK mit einer neuen Dateierweiterung angelegt. Diese Datei wird dann zu einer beschreibbaren Datei auf der Disk gemacht, wogegen die Ausgangs .vmdk-Datei für Schreibaktionen abgeschlossen wird (das Dateisystem VMFS von VMware schließt die Datei förmlich ab). Dann kann die derart geschlossene VMDK-Datei konsistent gesichert werden.

Diese Vorgehensweise hat nur sehr geringe Auswirkungen auf die produktiven Systeme. Die größte Last stemmt der Proxy-Server. Dabei stehen sowohl die VMDK-Images als auch die Dateien des Gastbetriebssystems für die Sicherung zur Verfügung. Allerdings wird bei diesem Konzept mit viel Overhead gesichert. Wenn man die VMDK plus die Dateien des Gastbetriebssystems sichert, werden viele Daten doppelt weggeschrieben. Daher kann der Einsatz von schnellen Deduplizierungs-Systemen hier einen Vorteil bringen.