Die technischen Grundlagen von Disaster Recovery sind bekannt. Es gibt aber Unsicherheiten und sogar falsche Behauptungen von Herstellern darüber, wie Virtualisierung Disaster Recovery beeinflusst.
Man kann sich leicht vorstellen, wie diese Vorstellung aufkam. Die meisten Virtualisierung-Administratoren haben sich von der Idee, traditionelle Backups und Tapes zu verwenden, längst verabschiedet.
Seit den Anfängen der Virtualisierungs-Technologie wurde das Hochverfügbarkeits-Clustering eingeführt und es sind Funktionen wie vMotion hinzugekommen, die die meisten Anforderungen des Datenschutzes erfüllen.
Aber wenn man ein bisschen genauer hinsieht, entdeckt man, dass diese Behauptungen ziemlich übertrieben sind.
Die Definition von Disaster Recovery
Es ist immer sinnvoll, einige grundlegende Definitionen zu entwickeln und bei der Planung der Wiederherstellung der IT nach katastrophalen Zwischenfällen ist es unabdingbar. Die Definitionen von Business Continuity und Disaster Recovery unterscheiden sich in Nuancen voneinander:
Business Continuity beschreibt den Prozess, der sicherstellt, dass der Geschäftsbetrieb weitergeht.
Disaster Recovery beschreibt den Prozess, der die IT-Dienste wieder in Gang setzt, nachdem es zu einem katastrophalen Zwischenfall gekommen ist. In der Regel wird versucht, dieses Szenario zu vermeiden oder zumindest so sehr wie möglich abzumildern.
Es gibt zwei weitere Definitionen rund um Disaster Recovery und Business Continuity: Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Beide beschreiben einen definierten Dienstgrad (Service Level) für die Wiederherstellung der Daten:
Recovery Time Objective legt den erwarteten Zeitbedarf fest, der benötigt wird, bis das Geschäft wieder normal weiterlaufen kann. Ein RTO von Null impliziert, dass die IT-Dienste sofort wieder laufen oder gar nicht erst ausfallen. Ein RTO von einer Stunde verlangt, dass die Applikation nach spätestens einer Stunde wieder normal läuft.
Recovery Point Objective bezeichnet den früheren Zeitpunkt, auf den der IT-Service zurückgesetzt werden soll. Ein RPO von Null bedeutet, dass der Service genau da wieder beginnen muss, wo er unterbrochen wurde, ohne dass Daten verloren gehen (unverzichtbar beispielsweise für Banking-Applikationen). Ein RPO von 24 Stunden bedeutet, dass die Daten vom Vortag gut genug sind (akzeptabel in Test- und Entwicklungsumgebungen).
Einen Disaster Recovery Plan entwickeln
In einer idealen Welt würden alle Applikationen mit einem RTO und einem RPO von Null wiederhergestellt. Aber aus praktischen und Kostengründen verbietet sich das.
Stattdessen beginnt jeder BC/DR-Plan damit, Szenarien katastrophaler Zwischenfälle zu definieren, ihre Bedeutung und ihren Einfluss zu bewerten und sie dann auf jede Applikation anzuwenden. Zu den Ausfallszenarien gehören beispielsweise:
Verlust oder Zerstörung von Systemen (Brand, Stromausfall, Überschwemmung, Erdbeben, Explosion)
Unerreichbarkeit der Einrichtung (Brand, Überschwemmung, chemische oder radiologische Verseuchung)
Zerstörung aus kriminellen oder böswilligen Motiven (unzufriedene Mitarbeiter oder Cyberangriffe)
Ausfälle von Systemen oder Applikationen (Softwarefehler, Upgradefehler, Datenkorruption)
Es lässt sich ermitteln, wie jeder Ausfalltyp jede Applikation beeinträchtigt. Daraus werden dann die Ziele für die zu definierenden Service Level ermittelt (Service Level Objectives, SLOs). Auch hier einige Beispiele:
E-Mail-System: Einfluss eines Ausfalls ist hoch; RTO = 30 Minuten, RPO = 0
Kern-Banking-Applikationen: Einfluss eines Ausfalls ist kritisch; RTO = 0, RPO = 0
Reporting vom Vortag: Einfluss eines Ausfalls ist gering; RTO = 4 Stunden, RPO = 24 Stunden.
In unserer Always-On-Welt sollen die meisten Applikationen, die von Endanwendern verwendet werden, etwa zum Online-Einkauf, 24/7 laufen. Das kann einige der SLOs verzerren, aber das Design der Anwendungen kann diese Einflüsse durch eine saubere Trennung der kundenseitigen von den Backend-Funktionen minimieren.
Klar ist: Ob eine Applikation virtualisiert ist oder nicht, unabhängig von der Technologie, müssen die Anforderungen für die Wiederherstellung zuerst festgelegt werden. Tatsächlich sollte das Unternehmen immer seine Anforderungen klar kommunizieren, statt dass die IT die Standards setzt, wie das traditionell lange üblich war und noch immer ist.
Wie Virtualisierung Disaster Recovery unterstützt
Virtualisierung abstrahiert die physischen Ressourcen des Servers in logische Konstrukte, die Festplatten, Netzkarten und Disk-Controller repräsentieren. Prozessoren, Speicher und Netz-Ports werden durch Parameter in einer Konfigurationsdatei erfasst und Festplatten in Form von Dateien auf lokalem oder gemeinsam genutztem Speicher.
Deshalb besteht das Backup einer virtuellen Maschine (VM) einfach darin, diese Dateien und die Konfigurationsdaten zu kopieren. Zusätzlich lässt sich eine virtuelle Maschine auf eine andere Hardware kopieren, selbst wenn es sich um eine nicht identische Hardware handelt. Dadurch wird es viel einfacher, Hardwareausfälle zu managen. Virtualisierungs-Funktionen lösen die Probleme von BC/DR so:
Einfaches Backup/Restore
Die Wiederinbetriebnahme basiert oft darauf, dass man diese Kopien sichert und von diesen Kopien im Katastrophenfall wiederherstellt. Dafür bieten Hypervisoren Funktionen, mit denen sich Backups durch das Kopieren von VM-Inhalten herstellen lassen. Um die Datenintegrität zu garantieren, laufen entweder Softwareagenten auf den virtuellen Maschinen, oder Softwarewerkzeuge stoppen Ein-/Ausgabevorgänge, während eine Kopie der VM-Dateien gezogen wird.
Ein einfaches Backup kann so dazu dienen, Dateien, Applikationen oder virtuelle Maschinen wiederherzustellen, je nachdem, wie ausgefeilt die Backup-Software ist. Die Sicherung eins kompletten VM-Snapshots kann den Betrieb beeinträchtigen, weshalb manche Systeme es ermöglichen, dass die Snapshot-Funktion auf dem Speichersystem mit Hypervisor-Snapshots kombiniert wird. Dadurch muss der Prozessor sie nicht verarbeiten und die Datenintegrität bleibt erhalten.
VM-Migration
Obwohl das dynamische Verschieben virtueller Maschinen von einer physischen Hardware auf die andere nicht wirklich zur Data Recovery gehört, verringert es doch den Einfluss von Hardwarefehlern. VM-Migration schützt nicht gegen Serverausfälle, kann aber verwendet werden, um VMs zu verschieben, wenn es zu Teilausfällen im Server oder anderen Komponenten, etwa dem Netz, kommt.
Ob eine Applikation virtualisiert ist oder nicht, unabhängig von der Technologie, müssen die Anforderungen für die Wiederherstellung zuerst festgelegt werden.
VM-Migration lässt sich auch als kontrollierter Prozess einsetzen, wenn Services aus Wartungsgründen von einem Hardwareelement auf ein anders verschoben werden müssen oder um das Risiko eines Rechenzentrumsausfalls zu vermindern (etwa, wenn ein Sturm oder ein Wirbelsturm aufzieht, der das Rechenzentrum beeinträchtigen könnte). In diesem Sinn ist die VM-Migration eher mit der Business Continuity zu vergleichen: Sie stellt sicher, dass die Maschinen weiterlaufen, auch wenn es potentiell oder tatsächlich zu einem Zwischenfall kommt.
Hochverfügbarkeit/Fehlertoleranz
Diese Funktionen des Hypervisors ermöglichen virtuellen Maschinen auch bei Hardwarefehlern weiter zu laufen. Zwei Service Level sind möglich: Hochverfügbarkeit überwacht virtuelle Maschinen und lässt sie auf alternativer Hardware bei einem Serverausfall wieder anlaufen. Das führt zu einem kurzen Ausfall, da die Applikation wieder hochfährt. Andernfalls läuft ein Ghost-VM-Image auf alternativer Hardware und das System wechselt zu diesem Image als Produktivsystem, falls der Server ausfällt. Hier entsteht keinerlei Applikationsausfall.
Um diese Funktionen nutzen zu können, ist möglicherweise gemeinsam genutzte Speicherhardware nötig, auf der die VM-Konfiguration und ihre Daten liegen. Außerdem sind diese Funktionen kostenpflichtig. Einige Hersteller unterstützen die Array-basierende Replikation zusammen mit Hochverfügbarkeits- und Fehlertoleranzfunktionen. Dadurch kann die Hardwarekonfiguration einige hundert Meter überspannen und es entsteht ein Metro-Cluster. Metro-Cluster entschärfen Rechenzentrums- oder schwere Hardwareausfälle ohne die Notwendigkeit, komplexe Applikations-Cluster aufzubauen.
Kontinuierliches Backup
Einige Applikationen von Drittherstellern nutzen Virtualisierung, um die Lese- und Schreibvorgänge auf einer virtuellen Maschine abzufangen und so ein Backup-Image im Hintergrund aufzubauen. Das findet asynchron statt und liefert eine Failover-Kopie der virtuellen Maschine, die anlaufen kann und bei einem Ausfall der Primär-Site die Arbeit übernimmt. Die RPO einer Anwendung, die so ein System nutzt, hängt davon ab, wie schnell Daten von der Site herunterkopiert werden können.
Resilienz von Applikationen
Wie schon dargestellt, liegen die Vorteile der Virtualisierung in der Abstraktion physischer Hardwarekomponenten. Eine weitere Überlegung beim Implementieren von DR/BC betrifft den Einbau von Recovery-Fähigkeiten direkt in die Applikation.
Resilienz von Applikationen erreicht man, indem mehrere Instanzen der Applikation parallel laufen, von denen jede ausfallen und auf alternativer Hardware wieder hochgefahren werden kann. Dieses Design ist nicht direkt abhängig von Virtualisierung. Es funktioniert auch gut in Umgebungen mit mehreren Hypervisoren und Hardwarekonfigurationen. Zukünftig wird man BC/DR-Resilienz mit Hilfe von Containern implementieren, einer Form der Applikations-Virtualisierung, deren Verbreitung gerade massiv zunimmt.
Bezogen auf DR/BC-Grundregeln wie RTO und RPO kann man Recovery-Optionen in die Anforderungen an Applikationen einbeziehen. Einige Applikationen werden vollständige Hochverfügbarkeit und Fehlertoleranz erreichen, andere wird man einfach mit Hypervisor-Snapshots sichern. In einigen Fällen lassen sich kontinuierliche Backups oder volle Hochverfügbarkeit und Fehlertoleranz mit Array-basierender Replikation rechtfertigen. Letztlich kommt es nur darauf an, die richtige Technologie für die jeweiligen Anforderungen zu wählen.
