Disaster Recovery im Hypervisor Zerto und das Ende aller Snapshots

Redakteur: Ulrike Ostler

Keine Snapshots mehr! Das Bostoner Unternehmen Zerto hat eine Replikations-Software entwickelt, die in der Hypervisor-Ebene angesiedelt wird. Das führt zu einem fortwährenden, automatisierten Prozess, der Admins und Systeme entlastet und den Unternehmen erlaubt, Business Continuity/Disaster Recovery (BC/DR) als Cloud-Service anzubieten oder zu konsumieren.

Zerto verschiebt das Disaster Recovery in die Hypervisor-Ebene. Das Erstellen von Snapshots wie bisher gehört damit der Vergangenheit an. Die Aufgabe ist nun vielmehr ein permanenter, automatisierter Prozess.
Zerto verschiebt das Disaster Recovery in die Hypervisor-Ebene. Das Erstellen von Snapshots wie bisher gehört damit der Vergangenheit an. Die Aufgabe ist nun vielmehr ein permanenter, automatisierter Prozess.
(Bild: Zerto)

Obwohl die Virtualisierung längst kein neues Thema mehr ist, orientieren sich die jetzigen Verfahren und Methoden für BC/DR an den physischen IT-Umgebungen im Rechenzentrum. Sie funktionieren zwar auch in den virtuellen Erweiterungen, doch sind sie dafür werde gemacht, noch optimiert. Das macht die BC/DR zur nervigen Herausforderung.

Peter Godden ist Vice President bei Zerto, zuständig für den Raum Europa, Naher Osten und Afrika.
Peter Godden ist Vice President bei Zerto, zuständig für den Raum Europa, Naher Osten und Afrika.
(Bild: Ostler)

Zum Beispiel kann sich der Management-Overhead einer Replikations-Lösung sogar verdoppeln und viele Vorteile, die durch Virtualisierung gewonnen werden lösen sich in Nichts auf. Dazu kommt, dass Virtualisierung schon per Definition Skalierbarkeit bedeutet. Jetzige BC/DR-Methoden sind es nicht. Das aber heißt, dass die Replikations-Software mit dem exponentiellen Datenwachstum nicht Schritt halten kann.

Zudem sind nach wie vor viele Replikations-Methoden an die Produkte eines Herstellers gekoppelt. Nur eine Hardware als Voraussetzung für die Funktionsfähigkeit ist in virtuellen Umgebungen jedoch kaum zielführend.

Die Array-basierte Replikation

Da gibt es zum Beispiel die Array-basierte Replication. Das Problem hier sei laut Peter Godden, Vice President bei Zerto, zuständig für den Raum Europa, Naher Osten und Afrika. eine unzureichende Granularität. Die entsprechenden Produkte kommen von den Storage-Herstellern und sind Module im Array. Vertreter dieser Produktkategorie seien „EMC SRDF” und “Netapp Snapmirror“.

Dazu ein Beispiel: Das Mapping zwischen virtuellen Platten und dem Array-Volumen ist komplex und verändert sich konstant. Das bedeutet Herausforderungen im Management sowie zusätzlicher Storage-Overhead.

So befinden sich auf einem Array oder einer logischen Einheit häufig mehrere virtuelle Maschinen. Kommt eine Array-basierte Replikation zum Einsatz, wird das gesamte Volumen repliziert, selbst wenn nur eine virtuelle Maschine gesichert werden soll. Man spricht auch von „storage sprawl“.

Die Nachteile, wenn auf dem Array repliziert wird

Und weil die Sichtbarkeit fehlt, mit der sich einzelne virtuelle Maschinen an unterschiedlichen identifizieren ließen, tendieren die Unternehmen dazu, alle Platten einer Anwendung mit einer einzigen logischen Storage-Einheit zu verknüpfen, obwohl es günstiger wäre, sie auf verschiedene logische Units aufzuteilen.

Disaster Recovery (DR), wie es bis jetzt üblich ist.
Disaster Recovery (DR), wie es bis jetzt üblich ist.
(Bild: Zerto)

Zu den weiteren Nachteilen zählt, dass die Administratoren verschiedene Kontrollpunkte benötigen – für die Überwachung und Steuerung der physischen Arrays gibt es eine entsprechende Konsole und für die Handhabung der virtuellen Assets benötigen sie die Tools der Virtualisierungsanbieter, etwa „VMware vSphere“-Clients.

Replikation auf dem Guest/OS und auf Appliances

Die Replikation mit Hilfe des Konstrukts Guest/OS sei auch nicht viel besser, führt Godden aus. Auch hier gebe es nur unzureichende Möglichkeiten zur Skalierung, wenngleich die Portierung einfacher und die Verwaltung einfacher seien – allerdings aufgrund der überschaubaren Größe der machbaren Anwendungen.

Denn entsprechende Module müssten auf jedem einzelnen der zu verwaltenden Server installiert werden. Das mache in großen Umgebungen schlichtweg keinen Sinn. Zu dieser Art der Replikations-Software zählt Godden „Double-Take“ von Vision Solutions dazu und das Produkt „Veritas Volume Replicator“ von Symantec.

Auch die Appliance-basierte Replication fällt bei Godden angesichts der Möglichkeiten der hauseigenen Software durch. Hierbei läuft der Replikationscode extern, auf einem eigens zu diesem Zweck installierten Gerät. Der Vorteil gegenüber der Array-basierten Methode: Die Replikation verbraucht keine Storage-ressourcen und erweist sich als flexibler.

Ansonsten aber zeigen sich auch hier die Nachteile einer Hardware: Der Fokus liegt nicht auf virtuellen Maschinen, sondern auf logischen Einheiten. Es treten also Probleme bei der Granularität auf und es sind unterschiedliche Managment-Systeme erforderlich.

Die Replikation im Hypervisor

“Mit der Einführung einer Hypervisor-basierten Replikation bringt Zerto BC/DR dahin, wohin diese Aufgaben gehören: in die Virtualisierungsschicht, so VP Godden. Allerdings, um das gleich einmal vorweg zu nehmen, funktioniert das derzeit nur für VMware-basierte Umgebungen. Bald jedoch will Zerto auch „Hyper V“ von Microsoft unterstützen können.

Die Vorteile sind schnell erklärt: Die Virtualisierung erlaubt Replikationen quer durch´s Land und eine Installation innerhalb von Minuten. Das Produkt wird pro virtuelle Maschine lizenziert, für jeweils rund 600 Euro. Andere Ausgaben für Management-Produkte, spart sich der Anwender. Kunden sind bereits Colt und British Telekom.

Die Zerto-Software besteht aus zwei Teilen: „Zerto Virtual Manager“ (ZVM) und „Virtual Replication Appliance (VRA)“. ZVM ist ein Plug-in für eine Hypervisor-Management-Konsole wie „VMware vCenter“. Von hier aus lassen sich alle Ressourcen einsehen und steuern.

Wie es funktioniert

VRA wiederum ist ein Modul, das auf jedem physischen Host installiert werden muss. Das geschieht laut Godden automatisiert. Es repliziert die Daten von den Maschinen, die der Anwender auswählt, komprimiert sie und verschickt sie über einen Wide-Area-Network-Link an einen remote-angebundenen Standort.

VRA hängt quasi direkt am I/O-Strom der virtuellen Maschinen und bekommt daher jeden Schreibvorgang mit. Das Kommando wird aufgeschnappt, ein Clone erstellt und an den Recovery-Standort verschickt. „Das ist sowohl genauer als auch effizienter und leichter nachzuvollziehen als alle anderen Konkurrenzverfahren“, sagt Vice President Godden.

Die Vorteile, wenn im Hypervisor repliziert wird

Obwohl ständig repliziert werde, habe dieser Vorgang keinerlei Performance-Einbußen bei den Anwendungen zur Folge. Und weil die Software in der Hypervisor-Schicht angesiedelt ist, sei sie unabhängig vom darunterliegenden Storage, sowohl auf der Quell- als auch der Empfängerseite. Somit werden alle gängigen Storage-Systeme unterstützt, inklusive deren Eigenschaften hinsichtlich Verfügbarkeit Clustering beispielsweise.

Logische Gruppen bilden die Abhängigkeiten von virtuellen Maschinen und den zugehörigen logischen Platten ab.
Logische Gruppen bilden die Abhängigkeiten von virtuellen Maschinen und den zugehörigen logischen Platten ab.
(Bild: Zerto)

Darüber hinaus lassen sich, logische Gruppen für den Schutz von virtuellen Maschinen und den zugehörigen logischen Platten bilden, die „Virtual Protection Groups” (VPGs). Das zentrale Management per ZVM erkennt VPGs und die Beziehungen zwischen den einzelnen Komponenten. Das hilft Anwendungen schnell, komplett und sauber zu replizieren und im Fehlerfall wiederherzustellen.

Also: Eine CRM-Applikation kann ohne Weiteres auf acht virtuelle Maschinen verteilt sein, die auf vier physischen Servern liegen, fünft unterschiedliche Datenquellen haben und drei verschiedene logischen Storage-Units. „Für Zerto keine große Sache“, sagt Godden, „auch dann nicht wenn sich die Konfiguration sich ändert.“

Schnell, sicher, flexibel und neutral

Es sei schließlich einer der großen Vorteile der Virtualisierung, dass die Workloads einfach und unkompliziert auf andere Systeme verteilt werden können, zum Beispiel aus Gründen des Load-Balancing oder strategische Daten-Management-Gründen. Dafür brauchen Admins in der Regel „vMotion“ von VMware, dann geschieht das praktisch manuell, oder „Distributed Resource Scheduler“ (DRS), um das automatisch zu bewerkstelligen.

Hypervisor-basierte Replication mit Zerto funktioniere trotz, beziehungsweise mit diesem beweglichen Untergrund, so Godden, und das auch noch superschnell. Im Umfeld von BC/DR gibt es zwei Kenngrößen an denen das gemessen wird: Recovery Point Objective (RPO) und Recovery Time Objective (RTO).

Während RPO den Zeitraum benennt, der zwischen zwei Datensicherungen liegen darf, um zu bestimmen, wie viele Daten/Transaktionen da zwischen höchstens verloren gehen dürfen, bemisst RTO die Zeit, die für den Ausfall eines Geschäftsprozesses oder Systems vergehen darf, vom Zeitpunkt des Schadens bis zur vollständigen Wiederherstellung. Bei Zerto, so Godden liegt der RPO bei Secunden und RTO bei Minuten

Artikelfiles und Artikellinks

(ID:42797222)