System-Applikationen und Daten gehören zusammen. Deren Sicherungskonzepte in einer IT-Infrastruktur sind allerdings unterschiedlich. Um die Daten ordnungsgemäß zu sichern, wird meist auf traditionelle Sicherungskopien zurückgegriffen. Dabei ändert der Einsatz von VTL- (Virtual Tape Library) oder Deduplikations-Technologien nichts an den grundlegenden Konzepten. Gleiches gilt für die CDP-Verfahren. Diese reduzieren lediglich das Intervall der Sicherung. All diese Techniken sind auch im Kontext von virtuellen Infrastrukturen einsetzbar, zählen dabei aber nicht zu den Verfahren der ersten Wahl.
Die CDP-Verfahren allerdings bringen einen neuen Aspekt ins Spiel. Diese Techniken sichern nicht nur die Daten, sondern häufig auch den gesamten Rechnerzustand. Damit integrieren Daten und Applikationsprozesse in einem Image. Dies ist vergleichbar mit den Verfahren des Imaging oder der Snapshots. Auch hierbei wird ein gesamter Rechner in seiner Vollständigkeit gesichert. Das geht zwar konkurrenzlos schnell, allerdings verschlingt das Image sehr viel Platz. Um diesen Speicherplatz zu reduzieren, werden seit einigen Jahren sogenannte inkrementelle Images bevorzugt.
Images und Snapshots wurden ursprünglich in der Welt der physischen Rechner eingesetzt. Sie finden sich heute analog auch in virtuellen Umgebungen, denn virtuelle Maschinen bestehen aus Image-Dateien der Rechner. Die virtuellen Systeme erben damit die Vorzüge aller Imaging-Techniken. Und auch die Snapshots der virtuellen Systeme haben ihre Vorläufer in den Snapshots der physischen Rechner.
Imaging von virtuellen Maschinen
Bei einem kritischen Systemfehler wird der Rechner von dem letzten erstellten Image wieder neu eingerichtet (Restore). Im Fall eines schwerwiegenden Defektes des Servers oder einer seiner Komponenten muss der Anwender auf ein Ersatzgerät ausweichen. Um im Falle eines Falles den sogenannten Setup-Prozess zu beschleunigen, kann der Anwender den Ersatz-Server bereits im Vorfeld einrichten. Der Nachteil dabei ist, dass dieses Gerät dann bin zum Einsatz nutzlos herumsteht.
Vom Standpunkt der Auslastung der Rechnerhardware ist das Imaging-Verfahren in Verbindung mit einem bereitgestellten Ersatz-Server eines der schlechtesten Sicherungsmodelle. Viele Anwender verzichten auf dieses redundante System, und erst im Fehlerfall versuchen sie, ein identisches Ersatzgerät schnellstmöglich zu beschaffen. Oftmals wird diese Vorgehensweise auch in den Servicevereinbarungen mit dem Systemlieferanten festgelegt.
Beim Setup des Rechners durch Imaging werden die Festplatten-Partitionen eines Systems als eine Einheit kopiert. Da hierbei unter Umgehung des Dateisystems direkt auf die Festplatten zugegriffen wird, ist es besonders schnell. Es eignet sich vor allem dann, wenn von einem Rechner eine Systemkopie (Backup) erstellt werden soll beziehungsweise diese Kopie im Fehlerfall schnell wiederhergestellt werden muss (Restore). Dieses Verfahren wird auch als Bare-Metal-Restore bezeichnet.
Diese Verfahren finden sich analog bei den virtuellen Systemen. Auch hier lässt sich ein virtueller Server sehr schnell über eine Imagedatei wiederherstellen. Ein gravierender Nachteil des Imagings ist, dass die Rücksicherung meist nur auf eine nahezu identische Hardware erfolgen darf. Ähnlich – wenngleich nicht ganz so streng – verhält es sich in der virtuellen Server-Umgebung. Auch hierbei muss darauf geachtet werden, dass der Ziel-Host eine Konfiguration aufweist, die zumindest näherungsweise der des Quell-Hosts ähnelt. Wenn zum Beispiel eine virtuelle Maschine auf einem Quellsystem mit vier logischen CPUs ausgestattet ist, das Zielsystem diese aber nicht bereitstellen kann, so muss bei der Migration zwingend manuell eingegriffen werden.
Failover und Lastverteilung
Das Aufsetzen eines Servers im Fehlerfall erfordert in der physischen Welt eine entsprechende Hardware, in der virtuellen Welt dagegen muss die Ressource auf einem bestehenden Host zur Verfügung stehen. In jedem Fall ist das Ganze mit Ausfallzeiten verbunden. Diese sind in der virtuellen Umgebung meist bedeutend kürzer als in der physischen Server-Welt.
Um Ausfallzeiten gänzlich zu vermeiden, führt kein Weg an Clustern vorbei. Dies gilt auch im Kontext der virtuellen Maschinen. Allerdings gibt es im Vergleich hierbei erweiterte Möglichkeiten. Die Absicherung muss auf jeden Fall auch für den Host greifen. Er stellt in virtuellen Umgebungen den Single-Point-of-Failure dar. Fällt er aus, so zieht er alle virtuellen Maschinen unweigerlich in den Abgrund.
Darüber hinaus liefern die Hersteller Migrations-Tools zur Lastverteilung. VMware zum Beispiel hat dazu sein Dynamic Resource Scheduling (DRS) und vMotion, Citrix nennt sein Pendant XenMotion, und für den Hyper-V hat Microsoft/Citrix mit den Citrix Essentials for Hyper-V etwas Vergleichbares im Angebot. Ferner wird das Release 2 des Windows Server 2008 die Migration von Windows Server direkt aus dessen Cluster Manager unterstützen.
Sicherung von Daten im Kontext der Prozesse
Die Bildung von Clustern schützt gegen den Ausfall der Applikations-Server und deren Prozesse. Was passiert aber mit den Daten? Sofern diese durch den Server bearbeiteten Daten auch in seinem Verwaltungskontext liegen, sind sie in dem Sicherungskonzept eingeschlossen. Dies gilt insofern, als eine virtuelle Maschine immer vollständig gesichert oder verschoben wird. Das schließt auch die darauf befindlichen Daten mit ein. Infolgedessen ist dabei die Datenkonsistenz jederzeit gewährleistet.
In der Regel wird man jedoch umfangreiche Datenbestände auf separate und flexiblere Speichersubsysteme auslagern. Deshalb ist zu beachten, dass VMotion von VMware oder Quick Migration von Microsoft lediglich das Server-Image transferieren, die Daten auf dem separaten Speichersubsystem bleiben dabei außen vor. Außerdem verlangt VMotion ein Speichersubsystem mit Shared Storage als Voraussetzung für eine erfolgreiche Sicherung. Mit VMotion wird somit die “Server-Last“ übertragen, die Daten bleiben auf dem Speichersubsystem. Somit wird durch die Verfahren der Migration lediglich die Server-Last beziehungsweise der Applikationsdienst auf ein anderes virtuelles System ausgelagert.
Dynamische Lastverteilung in virtuellen Umgebungen
Genutzt wird VMotion auch von VMwares Distributed Resource Scheduling (DRS). Durch DRS und VMotion lassen sich virtuelle Maschinen im Betrieb transferieren. Dies ist ein dynamischer Vorgang, der durch Skripting auch vollautomatisiert erfolgen kann. DRS fungiert hier als die überwachende Komponente. Es verteilt die Last und nutzt dabei VMotion als Transportvehikel. Dabei wird das Speicherabbild von einem Host auf einen anderen kopiert. Dieser Vorgang findet in mehreren Schritten statt; das Delta im Speicher wird so lange verkleinert, bis es der Ziel-Host ohne Unterbrechung übernehmen kann. Auch bei DRS ändert sich nichts am Dateisystem der virtuellen Maschine. VMotion und DRS sorgen so für eine gleichmäßige Auslastung der ESX-Ressourcen. Gegen einen Ausfall eines Servers oder des Speichersubsystems sind sie aber trotzdem wirkungslos.
Um den geplanten Ausfall – zum Beispiel wegen Wartungsarbeiten – des Storage-Systems zu begegnen, bietet VMware Storage VMotion an. Mit Storage VMotion erfolgt der Transfer des Dateisystems – der VMDK-Files – von einem Speichersubsystem auf ein anderes. Analog zu VMotion operiert auch Storage VMotion im Betrieb.
VMotion, Storage Vmotion und DRS dienen dazu, eine geplante Downtime zu verhindern. Um allerdings ungeplante Ausfälle zu kompensieren, bietet VMware die Funktionen HA und Fault Tolerance an.
Windows Server und Clustered Shared Volumes
Die Absicherung des Microsoft Hyper-V und seiner virtuellen Maschinen ist im Vergleich zur VMware-Lösung gänzlich anders gelöst. Microsoft setzt hierzu auf die Dienste des Windows Failover Cluster. Dessen Funktionen sind in dem aktuellen Release R2 des Windows Server 2008 erweitert worden. Der Windows Failover Cluster, der bis zu 16 Knoten umfassen kann, ist auch mehr generisch zu sehen. Denn Windows Cluster sind nicht allein auf die Virtualisierung beschränkt. Durch sie erfolgt vielmehr die Absicherung eines Windows-Server-Systems und weiterer Dienste – wie auch des Hyper-V.
Microsoft stellt dazu eine Reihe von Hilfen zur Absicherung von Dateidiensten, Druckdiensten, DHCP oder WINS zur Verfügung. Ein zentrales Element eines Windows Cluster ist die Quorum Disk. Sie muss für alle Cluster-Knoten verfügbar sein. Seit Windows Server 2008 sorgt ein erweitertes Quorum Model auch für die Absicherung gegen den Ausfall der Quorum Disk.
Eine besondere Variante der Windows Cluster sind Stretched Cluster. Sie ermöglichen den Aufbau der Cluster über große Distanzen und WAN-Strecken. Ein weiterer Baustein zur Hochverfügbarkeit von Windows Server sind die Clustered Shared Volumes. Durch sie wird der parallele Zugriff der Knoten eines Windows Server 2008 R2 Failover Cluster auf die Speicher-Volumes abgebildet. Clustered Shared Volumes (CSV) stellen damit das Speicher-Backend für die Windows Failover Clustern dar. CSV stehen für alle Windows Server 2008 R2 Failover Cluster bereit. Sie sichern eine Umgebung auch gegen die Ausfälle der Speicher- oder Netzwerkanbindung ab. Im Zusammenhang von virtuellen Maschinen und dem Hyper-V erhalten die CSV eine besondere Rolle. Denn CSV sorgen dafür, dass die virtuellen Maschinen bei einem Speicherproblem ungehindert weiterarbeiten können. Ferner unterstützen sie die Live Migration.
Absicherung des Hyper-V durch Live-Migration
Bei der Live-Migration in Verbindung mit Clustered Shared Volumes läuft auf jedem Knoten der Cluster jeweils eine Instanz des Hyper-V. Durch die Live-Migration erfolgt dann eine kontrollierte Übertragung einer virtuellen Maschine vom Quell-Host auf den Ziel-Host. Die Übertragung der virtuellen Maschinen läuft dabei in mehreren Stufen ab. Zuerst erfolgt der Transfer des RAM-Inhalts der virtuellen Maschine vom Quell-Knoten zum neuen Ziel-Knoten. Anschließend werden der Zugang zum Festplattenspeicher und die Netzwerkanbindung umgeschaltet.
Die Verwendung der Windows-Cluster-Funktionen und CSV wird damit zu einer zwingenden Voraussetzung für die Live-Migration von virtuellen Maschinen des Hyper-V. Die CSV kümmern sich um das eigentliche Failover der Dienste. Bei einem Ausfall der Speicheranbindung greift eine interne Heartbeat-Funktion, die die Disk-Operationen über den Cluster Heartbeat-Link umleitet. Darüber hinaus lässt sich durch redundante Host-Bus-Adpatoren auf der Host-Seite deren Ausfall absichern.
Um auch gegen Fehler in der Speicherhardware Vorsorge zu treffen, wird diese redundant ausgelegt. Der Ausfall des Storage-Systems schließlich lässt sich durch entsprechende Funktionen, wie etwa eine Spiegelung auf ein zweites Speichersubsystem, abfedern. Dies geschieht allerdings in der Regel direkt durch die Funktionen der Speichersubsysteme.
Replikation des Hyper-V in Beispielen
Die Absicherung der virtuellen Prozesse nach dem CSV-Verfahren basiert auf einem gemeinsam genutzten Speicher. Es geht aber auch anders: So realisiert zum Beispiel DoubleTake für Hyper-V die Absicherung durch die lokalen Platten der Hyper-V-Rechner. Dabei erfolgt einmal zu Beginn des Sicherungsprozesses ein initialer Abgleich. Anschließend werden die Änderungen der Plattenimages – der VHD-Dateien – laufend von der Quelle auf das Zielsystem repliziert. Im Fehlerfall wird dann auf dem Ziel die aktuelle VM gestartet. Dieses Verfahren gleicht der Vorgehensweise der CDP-Technik.
So verzichtet auch die Lefthand-Speicherlösung von HP auf den Shared Storage. Stattdessen liefert diese Lösung eine virtuelle SAN-Appliance (LeftHand VSA). Die VSA stellt in VMware-Umgebungen eine vordefinierte VM dar, die aus den am oder im Server angeschlossenen Festplatten ein SAN bildet. Sind mehrere ESX-Server mit installierten VSA verfügbar, so können diese ihren jeweiligen SAN-Speicher in ein großes, gemeinsames SAN zusammenfassen.
Zu den Lefthand-Funktionen gehören auch Optionen wie Storage Clustering und Netzwerk-RAID. Sie sorgen dafür, dass die gespeicherten Daten auch für weitere physische ESX-Server erreicht werden können. Dies schafft die Voraussetzung für die VMware HA-Funktionen. Bei einem Ausfall eines physischen ESX-Hosts können die VMs auf anderen physischen Server neu gestartet werden, haben aber weiterhin Zugriff auf den gemeinsamen Shared Storage.
Sicherungsmöglichkeiten der Storage-Systeme
Intelligente Storage Array oder Appliance beherrschen weitaus mehr als nur einfache Kopiervorgänge. Snapshots, Klone, Weitverkehrsreplizierung, Kapazitätsoptimierung mittels Deduplizierung und die zugehörige Management-Intelligenz öffnen neue Einsatzgebiete. Fast alle Hersteller von Speichersubsystemen haben Replikationstechniken in ihre Storage-Systeme implementiert. Deren Mechanismen sorgen selbstständig für eine Replikation der Daten auf ein zweites Speichersystem. Eine separate Softwarelösung entfällt dabei.
Allerdings operieren die meisten Storage-basierten Replikationslösungen nur mit den jeweils eigenen Speichersystemen des jeweiligen Herstellers. Prinzipiell bieten die Unternehmen zwei Varianten an, die die jeweils synchrone oder die asynchrone Replikation der Daten beherrscht. Die synchrone Replikation sichert die Daten immer aktuell quasi in Echtzeit, sie benötigt dazu aber meist teure Fibre-Channel-Systeme und ist damit auch in der Entfernung begrenzt. Durch die asynchrone Replikation lassen sich auch weite Distanzen überbrücken, und sie erfordert keine spezielle Hardware, sondern begnügt sich mit kostengünstigen IP-Strecken.
Alle beschriebenen Zusatzfunktionen sind fast immer an die Speichersysteme gebunden, obwohl sie lediglich das Kopieren der Platten übernehmen. Storage VMotion von VMware geht darüber hinaus und sorgt auch für die Verknüpfung mit den Konsumenten, also den virtuellen Maschinen. Es verknüpft damit – analog zu VMotion – den Verbraucher mit den Laufwerken. Die Kombination DRS, VMotion und Storage VMotion kann also beim geplanten Herunterfahren des Rechners inklusive des Speichersystems wegen Wartungsarbeiten beides auf ein Ersatzsystem umziehen. Ähnliches gilt auch für die Clusted Shared Volumes von Microsoft.
Absicherung des Data Centers
Beim Einsatz mehrerer Server- und Speichersysteme sind die VMware-Funktionen VMotion, DRS und Storage Vmotion zwar auf jedem der Geräte einsetzbar und können damit auch größere Infrastrukturen absichern, allerdings laufen sie dann getrennt voneinander. Denn die verschiedenen Systeme wissen voneinander erst einmal nichts.
Um diese Lücke zu schließen, offeriert VMware den Site Recovery Manager. Dieser kümmert sich ausschließlich um die Koordination der einzelnen Systeme untereinander. Im Prinzip handelt es sich dabei um ein Workflow-Tool, das die Rechnersysteme eines Data Centers kontrolliert herunterfährt und die entsprechenden Dienste in einem Ausweichrechenzentrum hochfährt. Der Fokus liegt dabei auf kontrolliert. Denn meist müssen die Server und ihre Dienste in einer vordefinierten Reihenfolge aktiviert werden. Die Namensdienste zählen dabei zu den wichtigsten Server-Diensten.
Der Site Recovery Manager sorgt für die richtige Aktivierungsreihenfolge. Dazu stimmt sich das Programm über Schnittstellen mit den spezifischen Server-Diensten ab. Parallel dazu passt der Site Recovery Manager die Konfiguration, wie etwa IP-Adressen oder Kommunikationskanäle, an die jeweils notwendigen Anforderungen an. Die Replikation der Daten wiederum erfolgt durch die bereits erwähnten Verfahren oder die entsprechenden Storage-Systeme. Danach koordiniert der Site Recovery Manager ein kontrolliertes Herunterfahren des primären Rechenzentrums und das Hochfahren des Ausweich-RZ.
Fazit
Die Techniken des Disaster Recovery gelten auch für virtuelle Umgebungen. Gegenüber den traditionellen Konzepten in physischen Umgebungen mit einem Restore der Daten im Fehlerfall bieten virtuelle Systeme eine Reihe von Methoden, die weitaus leistungsfähiger sind und die Auswirkungen reduzieren können.
Durch die Bildung von Clustern und die Parallelisierung der Daten und Prozesse lasse sich dabei Applikationen, Prozesse und Standorte gleichermaßen absichern. Im Idealfall treten Ausfälle, zumindest aus der Sicht des Anwenders, gar nicht auf. (hal)