Die Konsolidierung und Flexibilisierung der Ressourcen bewirkt zugleich ein rapides Datenwachstum auf dem physikalischen Server, wobei immer mehr geschäftskritische Daten in vielen verschiedenen virtuellen Servern abgelegt werden. Das Resultat: höhere Anforderungen an die Absicherung dieser Umgebungen.

Die bestehenden Prozesse und Methoden im Backup reichen in einer virtualisierten Umgebung nur dann aus, wenn wenige virtuelle Maschinen gesichert werden müssen. Ein Agent auf jeder VM (Virtual Machine) schiebt das Backup entweder über das LAN auf einen Media-Server oder über SAN beziehungsweise ein schnelles FC-Interface (FC = Fibre Channel) direkt auf das Backup-Gerät. Sobald die Zahl der VMs aber wächst, entstehen die ersten Probleme. Zunächst steigt der Verwaltungsaufwand für Administratoren, die einen Backup-Agenten für jede virtuelle Maschine managen müssen. Daneben können auch die Aufwendungen steigen, wenn Lizenzkosten für jeden Agenten fällig werden.

Alle Theorie ist grau

Zudem brauchen Backup-Läufe Rechenleistung. Das ist zwar prinzipiell bei der chronisch geringen Auslastung von Servern in einer bislang üblichen Umgebung kein Problem. Schwierig wird es aber, wenn sich viele VMs die physikalischen Ressourcen teilen müssen, also CPUs, NICs (NIC = Netzwerkkarte/Network Interface Card), Arbeits- und Plattenspeicher. Das Backup einer VM kann einen wesentlichen Teil dieser Ressourcen beanspruchen. Dabei werden die restlichen VMs regelrecht ausgehungert. Hier hilft es nicht viel, die VMs zwischen den physikalischen Ressourcen zu migrieren, denn dann besteht die Gefahr, dass ein Backup-Job während der Migration nicht ordnungsgemäß erledigt wird.

Ein Ausweg kann sein, einen einzigen Backup-Agenten auf die Servicekonsole der virtuellen Maschine zu setzen (siehe Grafik). Bei diesem Verfahren wird das Backup für alle Maschinen auf einmal erledigt, ein SAN ist nicht notwendig. So sinken auch die Kosten für Connectivity und Lizenzen. Doch auch diese Lösung ist nicht ohne Wermutstropfen. Inkrementelle Backups sind nicht mehr möglich. Vielmehr wird das gesamte Backup zu einem einzigen, riesigen File, das bei jedem Backup neu abgelegt wird. Ein Recovery auf File-Ebene ist nicht möglich. Das hat zur Folge, dass hierfür doch wieder ein Backup-Agent auf jeder VM gebraucht wird.

Hohe I/O- und CPU-Last

Alle Anwenderdaten und Informationen zur Konfiguration des virtuellen Servers werden beim Backup in .vmdk-Files gespeichert. Die Übertragung dieser oft über 2 TB großen Dateien bedingt eine hohe Input-Output- und CPU-Last. Dies kann schnell zu Engpässen im Storage-Controller oder im Netzwerk führen. Selbst wenn diese Ressourcen ausreichen, müssen immer noch auch Netzwerk- und StorageAdapter geteilt werden. Ressourcen werden so zum kontinuierlichen Problem.

Schlimmer noch: Da etwa Betriebssysteme oder Anwendungen innerhalb der VMs redundant sind, steigt die Datenmenge weiter. Auch muss die Virtualisierungsschicht selbst gesichert werden.

Diese .vmx-Files enthalten wichtige Konfigurationsdaten jeder virtuellen Maschine. Und dann gibt es noch die Host-Daten des physikalischen Servers, also Systemdaten, virtuelle Netzwerkdaten und Speicherkonfigurationen. All dies muss für den Fall eines Disaster Recovery rasch wiederherstellbar sein. Keine kleine Aufgabe für ein Backup - das noch dazu schnell ablaufen muss.

Mit VMware Consolidated Backup (VCB) wird das Backup von VMs erleichtert: Hier wird der Status einer virtuellen Maschine in hardwareunabhängigen Files gekapselt und als Snapshot auf eine Festplatte mit iSCSI- oder Fibre-Channel-Verbindung abgelegt. Der Impuls dazu geht vom VCB-Proxy-Server aus, der ESX-Server generiert die Snapshots von .vdmk-Dateien auf dem Shared Storage, leitet sie über SAN an einen Backup-Server, von wo aus die Dateien zum Backup-Gerät verschoben werden.

Wenig Overhead

Das VCB-Backup beeinträchtigt den ESX-Host, auf dem die zu sichernden VMs liegen, kaum. Dies ist mithin eine schnelle und einfache Lösung mit wenig Overhead bei den physikalischen Ressourcen. Zudem können sowohl komplette als auch inkrementelle und differenzielle Backups von Windows-VMs geschaffen werden. VCB löst gewissermaßen den Backup-Prozess aus der VM heraus und bringt ihn in die Infrastruktur.

Doch unterstützt VCB Backups auf File-Ebene nicht für alle VM-Gast-Betriebssysteme. Für Nicht-Windows-Systeme ist VCB nicht die beste Alternative, wenn man applikationsspezifische und zusammenhängende Sicherungen fahren will. Außerhalb einer Windows-Umgebung kann zudem die minimale Kontrolle zum Problem werden: Es gibt bei VCB keine Garantie für Konsistenz bei der Datenverarbeitung. Müssen aber Applikationen, die Logs ausführen, eingesetzt werden, verlängert sich der Backup-Prozess. Damit wird es notwendig, die Backup-Jobs genau zu planen, um Ressourcen-Engpässe zu vermeiden.

Ob Netzwerk-, Host- oder Array-basierende Replikation genutzt wird, VCB oder agentengestütztes Backup zum Einsatz kommt, ist dabei fast immer eine individuelle Entscheidung.

Wählt man heute eine Lösung, so wird vermutlich ein gemischter Ansatz für den jeweiligen Anspruch verfolgt.

(jm)