VMware und Hyper-V: Disaster Recovery von virtuellen Maschinen

Innerhalb von VMware und Microsoft Hyper-V gibt es Hypervisor-Funktionen, die Administratoren beim Disaster Recovery unter die Arme greifen.

Dieser Artikel behandelt

Disaster Recovery

Eines der wichtigsten Komponenten einer IT-Infrastruktur ist die Sicherstellung von Business Continuity (BC). Anders ausgedrückt könnte man es auch als gute Planung von Disaster Recovery (DR) bezeichnen.

Was genau unter Disaster verstanden wird, variiert ziemlich. In diesem Beitrag verstehen wir darunter Ausfälle durch Hardware, Software und äußere Einflüsse. Im Speziellen gehen wir auf das Disaster Recovery von virtuellen Maschinen (VM) ein, die entweder mit VMware oder Microsofts Hyper-V erstellt wurden. Innerhalb dieser Produkte existieren diverse Tools, die neben dem Komplettausfall eines Standorts verschiedene Disaster-Szenarien abdecken.

Die meisten Disaster-Recovery-Produkte für virtuelle Maschinen benötigen zusätzliche Hardware an Standorten oder Außenstellen. In einigen Fällen ist auch gemeinsam genutzter Speicher notwendig. Mit Umsicht bei der Planung können Administratoren diese Produkte in ihren Designs für die virtuellen Server implementieren. Somit stellen sie effiziente Business Continuity sicher und mildern das Ausmaß von Ausfällen.

Grundlagen von Disaster Recovery: Backup und Replikation

Um Business Continuity sicherstellen zu können, müssen in der Regel folgende Kriterien gewährleistet sein:

  • Daten- und System-Backups auf Bändern oder Festplatten, die eine Wiederherstellung kompletter Systeme auf neuer Hardware ermöglichen. Das gilt sowohl für einen Wiederaufbau am selben als auch die Installation an anderen Standorten.
  • Alternativ lässt sich Replikation in Echtzeit einsetzen. Damit werden Daten über das WAN (Wide Area Network) und entsprechender Replikations-Technologie Standort-übergreifend dupliziert. Natürlich ist Daten-Replikation teurer und man setzt sie in der Regel nur für wichtige produktive Systeme ein.

Bevor Virtualisierung existierte, wurden Datensicherungen mithilfe von Backup-Agents unterstützt, die auf den entsprechenden Servern installiert waren. Backups wurden danach manuell ausgelagert oder über das Netzwerk an einen sicheren Ort transportiert.

Replikation lief in der Regel im Storage-Array ab. Dabei fanden Technologien wie SRDF von EMC oder TrueCopy von Hitachi Verwendung. Replikation auf Server- oder Applikations-Ebene war zum Beispiel mithilfe von Oracles Data Guard möglich.

Array-basierte Replikation funktioniert in groß angelegten Umgebungen besser. Wir sprechen hier von Szenarien, in denen die Komplexität und benötigte Zeit die angeforderten RTO (Recovery Time Objectives) nicht erfüllen können.

Backup und Replikation virtueller Maschinen

Server-Virtualisierung bringt neue Herausforderungen für Disaster Recovery. Traditionelle Backup-Prozesse funktionieren nicht wirklich gut für die Absicherung virtueller Server. Eine virtuelle Umgebung teilt sich Hardware, wie zum Beispiel Netzwerk und Storage. Die Kosteneinsparungen beruhen auf dem Vorteil, dass die meiste Serverhardware nicht komplett ausgenutzt wird.

Während des Backup-Fensters in traditionellen Umgebungen verfolgt man das Ziel, Daten so schnell wie möglich zu sichern. Das bedeutet auch, dass man alle verfügbaren Netzwerk-Kapazitäten voll ausnutzt. Deswegen kann es bei herkömmlichen Backup-Methoden zu Engpässen und Performance-Problemen in virtuellen Umgebungen kommen.

Daten-Replikation ist ähnlichen Herausforderungen ausgesetzt. Die empfohlene Konfiguration sowohl für vSphere als auch Hyper-V ist das Erschaffen großer Datenträger (oder auch LUNs) innerhalb des Storage-Arrays. Auf diesen lassen sich mehrere virtuelle Maschinen ablegen.

Somit sind Server auf demselben LUN für Disaster-Recovery-Zwecke gruppiert, weil ein komplettes LUN durch das Storage-Array repliziert wird. Bei einem Ausfall wirkt sich die Übernahme auf das gesamte LUN aus. Administratoren müssen hier einen genauen Plan bei einem Array-basierten Daten-Layout austüfteln, um den Spagat zwischen Platz-Nutzung und Flexibilität bei Disaster Recovery zu meistern.

Zusätzliche Intelligenz: Hypervisor-basierte Lösungen

Hypervisor-Entwickler haben das Problem mit Disaster-Recovery-Management im Bezug auf virtuelle Umgebungen realisiert. Ihren Produkten wurden daher spezielle Funktionen spendiert, die dieses Anliegen adressieren. Zunächst sehen wir uns diese Funktionen in VMware an. Danach kümmern wir uns um Hyper-V.

VMware – VADP und VDP

VADP (VStorage APIs for Data Protection) ist ein API-Framework, das eine Reihe von Funktionen für die Verwaltung von Backups virtueller Maschinen zur Verfügung stellt. Die Software ersetzt VCB (VMware Consolidated Backup) und ist ein fest eingebauter Teil des Hypervisors.

Mithilfe von VADP können Backup-Softwarehersteller mit einem vSphere-Host kommunizieren und komplette virtuelle Maschinen sichern. Dabei ist ein Backup des kompletten Abbildes oder inkrementelle Datensicherung möglich. Verwendet wird hierbei Changed Block Tracking (CBT).

CBT stellt eine hohe Granularität im Hinblick auf die Nachverfolgung von Änderungen in einer virtuellen Maschine zur Verfügung. Das lässt sich mit herkömmlichen Backups vergleichen, die nach geänderten Dateien suchen.

VADP kann auch mit VSS (Volume Shadow Copy Services) in Windows 2008 und höher verzahnt werden. Damit wird die Host-Konsistenz während des Backup-Prozesses gewährleistet. Das ist besser als die Standard-Backups, bei denen keine Synchronisation Verwendung findet.

VDP oder vSphere Data Protection ist VMwares Appliance für Backups. Es benutzt EMC Avamar, um Backups auf einem Datenträger abzulegen. Damit benutzt es Funktionen wie Daten-Deduplizierung, um den Platz optimal auszunutzen.

Viele Drittanbieter unterstützen VADP. Dazu gehören auch Symantec mit NetBackup und Backup Exec. Weitere Anbieter sind Veeam, CommVault, Arkeia, HP mit Data Protector und EMC mit Avamar sowie Networker.

VMware – Fault Tolerance

Fault Tolerance ist ein vSphere-Feature, das die Verfügbarkeit virtueller Maschinen während eines Hardwareausfalls garantiert. Fault Tolerance hält mit einer „Schatten“-Kopie die virtuellen Maschine am Laufen. Diese wird permanent mit der primären Instanz synchronisiert. Sollte es zu einem Ausfall kommen, startet Fault Tolerance automatisch den zweiten Server. Kommt es zum Beispiel zu einem Stromausfall des Primärsystems, gibt es praktisch keine Ausfallzeit.

Fault Tolerance ist am besten für lokales Disaster Recovery geeignet, bei dem ein Ausfall nicht alle lokalen Systeme betrifft und kein RPO (Recovery Point Objective) notwendig ist.

Denkbar sind beispielsweise zwei Systeme, die physikalisch getrennt sind und an verschiedenen Stromnetzen hängen. Ist die Distanz zwischen primärem und sekundärem System zu groß, können Latenzzeiten beim Synchronisieren zu einem Problem werden.

VMware – Replication

vSpheres Replication nutzt Changed Block Tracking, um Daten mit einer Außenstelle zu replizieren. Daten werden auf der Ebene der virtuellen Maschine (VMDK) bewegt. Deswegen ist diese Methode vom darunterliegenden Storage unabhängig. Es handelt sich hier um eine passende Lösung, um Daten zwischen verschiedenen Storage-Arrays zu replizieren. Somit ist es denkbar, den Disaster-Recovery-Standort mit günstigerer Hardware auszustatten.

Replication wird mithilfe einer dedizierten virtuellen Appliance an der Quelle betrieben. Auf jeder im Kopier-Prozess involvierten virtuellen Maschine ist ein Agent installiert. Somit ist diese Lösung etwas aufdringlicher als eine alleinige Array-Replication.

Replication lässt sich zusammen mit VMwares SRM (Site Recovery Manager) einsetzen. Anwender erhalten damit eine umfassende Disaster-Recovery-Lösung an die Hand. Diese deckt Failover und Failback im Falle eines Ausfalls ab.

VMware – Alternativen zu Replication

Es gibt von Drittanbietern einige Alternativen zur nativen VMware Replication: Zerto bietet Virtual Replication an. Dieses Produkt liefert ein komplettes Management für den Wiederherstellungs-Prozess virtueller Maschinen. Zusätzlich können die Daten in eine Public Cloud kopiert werden. VirtualSharp, das von PHD Virtual Technologies akquiriert wurde, bietet via PHD Virtual ReliableDR eine Disaster-Recovery-Lösung an. Damit können Sie Disaster-Recovery-Szenarien regelmäßig testen und validieren. Somit versichern Sie sich, dass die Konfiguration im Falle eines Ausfalls korrekt ist.

Hyper-V – Cluster Shared Volumes

Mit Windows Server 2008 R2 hat Microsoft das Konzept der Cluster Shared Volumes eingeführt. Es handelt sich um Storage-Laufwerke, auf die alle Hyper-V-Knoten in einer gemeinsam genutzten Cluster-Umgebung zugreifen können. Sollte ein Knoten ausfallen, kann ein anderer innerhalb des Clusters die virtuelle Maschine des nicht funktionierenden Servers übernehmen.

Cluster Shared Volumes eignen sich für lokales Disaster Recovery, wo sich die Hardware physikalisch und hinsichtlich der Stromkreise trennen lässt. Sind außenstehende Systeme im Spiel, ist die auftretende Latenzzeit ein Problem. Hier sind Cluster Shared Volumes weniger vorteilhaft.

Hyper-V – Replica

Mit der Veröffentlichung von Windows Server 2012 und Hyper-V 3.0 hat Microsoft eine neue Funktion mit Namen Replica eingeführt. Sie erlaubt die asynchrone Replikation virtueller Maschinen zu entfernt liegenden Systemen.

Bei der ersten Version ist das Replikations-Intervall fix und nicht einstellbar. Mit Windows 2012 R2 ändert sich das, da sich das Intervall manuell konfigurieren lässt. Schließlich wird Microsoft die Unterstützung für standortunabhängige Systeme erweitern. Damit ist eine Kopie an einem dritten Standort möglich. Das erhöht die Flexibilität hinsichtlich Disaster Recovery.

Artikel wurde zuletzt im November 2013 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Disaster Recovery

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close