Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.12.2008

Backups - was es in virtualisierten Umgebungen zu beachten gilt

Marina Baader
Unternehmen konsolidieren heute durchschnittlich zwölf virtuelle Maschinen auf einem physikalischen Server. Das hört sich gut an, hat aber erhebliche Folgen für die Datensicherung und für Backups.

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

Foto: Quantum

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.

Auf jeder virtuellen Maschine löst ein Agent die Sicherung aus.
Auf jeder virtuellen Maschine löst ein Agent die Sicherung aus.

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)

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 ergebenden Anforderungen zu definieren.

  2. Die Kosten für Lizenzen können einen Gutteil der Einsparungen wieder zunichte- machen.

  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 in virtualisierten Umgebungen zum Alptraum.

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

  6. Beim Backup in virtualisierten Umgebungen sollten RTO und RPO für jede VM genau definiert werden.

  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.