Backups - was es in virtualisierten Umgebungen zu beachten gilt

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.

Probleme bei wachsender Zahl der VMs

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 (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.

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.

Dramatisch wachsende Datenmengen

Ein Ausweg kann sein, einen einzigen Backup-Agenten auf die Service-Console der virtuellen Maschine zu setzen. 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 Folg, dass hierfür doch wieder ein Backup-Agent auf jeder VM gebraucht wird.

Alle Anwenderdaten und Informationen zur Konfiguration des Virtuellen Servers werden beim Backup in .vmdk-Files gespeichert. Die Übertragung dieser oft über zwei TB großen Dateien bedingt eine hohe I/O- 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 Storage-Adapter 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 VM. Und dann gibt es noch die Host-Daten des physikalischen Servers, also Systemdaten, virtuelle Netzwerk-Daten und Speicherkonfigurationen. All dies muss für ein Disaster Recovery schnell wieder herstellbar sein. Keine kleine Aufgabe für ein Backup - das noch dazu schnell ablaufen muss.

VMware Consolidated Backup

Mit VMware Consolidated Backup (VCB) wird das Backup von VMs erleichtert: Hier wird der Status einer Virtuellen Maschine in Hardware-unabhä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. 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-basierte Replikation genutzt wird, VCB oder Agenten-basiertes Backup zum Einsatz kommt, ist dabei fast immer eine individuelle Entscheidung.

Individuell statt "one solution fits all"

Wählt man heute eine Lösung, so wird vermutlich ein gemischter Ansatz gefahren, der den jeweiligen Ansprüchen am besten genügt. Dies gilt umso mehr, als in Unternehmen ja nicht vollkommen virtualisierte Umgebungen gesichert werden müssen, sondern beispielsweise auch Highend-Unix-Server. VCB deckt die meisten Anwendungen sehr gut ab, zumindest wenn man sich im Windows-Umfeld bewegt. Für Datenbanken, Mailsysteme und andere ressourcenintensive Applikationen bietet sich eher Agenten-basiertes Backup an. Doch sollte man berücksichtigen, dass die Umgebungen sich dynamisch verändern.

Für Backups müssen auch neu aufkommende Technologien in Erwägung gezogen werden - etwa Deduplikation, wie sie beispielweise bei Quantum-Festplattenspeichern genutzt werden. Sie versprechen einen optimierten Ressourceneinsatz - ein Faktor, der gerade in virtualisierten Umgebungen immer bedeutsamer wird, denn viele der Daten in den VMs sind redundant. Dies gilt sowohl für Agenten-basierte als auch für VCB-Sicherungen.

Tipps für Backup-Strategien:

Virtualisierung mag ein willkommener Anlass sein, seine gesamten Backup-Strukturen zu überdenken. Doch gibt es einige Faktoren, die man gleich zu Beginn bedenken sollte:

1. Vor allen technischen Überlegungen sollte noch einmal die Diskussion über notwendige SLAs (RTO/RPO = Recovery Time Objective/Recovery Point Objective) für jeden einzelnen Prozess oder jede einzelne VM geführt werden, um die sich daraus ableitenden Anforderungen zu definieren.

2. Die Kosten für Lizenzen können einen Gutteil der Einsparungen wieder zunichte machen. Ein genauer Blick auf die Bestimmungen in den verschiedenen Lizenzmodellen lohnt auf jeden Fall.

3. Eine Umgebung ist fast nie zu 100 Prozent virtualisiert. Jede Backup-Lösung muss also sowohl für eine traditionelle als auch für eine virtualisierte Umgebung geeignet sein.

4. Ohne hinreichende und zentrale Management-Funktionen wird das Backup vor allem auch in virtualisierten Umgebungen zum Alptraum.

5. Integration wird zum Schlüssel für ein funktionierendes Backup. Eine Lösung sollte deshalb über FC- und IP-Connectivity verfügen.

6. Beim Backup in virtualisierten Umgebungen sollten die RTO und RPO für jede VM genau definiert werden. Nur so kann man die Vor- und Nachteile jedes Ansatzes bewerten.

7. Backup und Recovery ist quasi der Fallschirm, wenn eine Replikation oder ein Application-Failover nicht funktioniert. Die Lösungen sollten deshalb zumindest teilweise für Hochverfügbarkeits- und Business Continuity-Aktivitäten einsetzbar sein.

8. Jede Technologie, die zur Ressourcenoptimierung führt, ist in diesen Umgebungen noch wertvoller. Deduplikation wird hier oft zum Schlüssel für mehr Effizienz. (jm)