Essential Guide

Mehr Datensicherheit durch Replikation und Snapshots

Eine umfassende Auswahl von Artikeln, Videos und mehr, die von unseren Redakteuren gewählt wurden.

Im Vergleich: Hardware- vs. Software-basierte Replikation für Disaster Recovery

Für die DR-Strategie muss sich der Anwender entscheiden, ob er seine Daten mit Hardware- oder Software-basierter Replikation schützen möchte.

Disaster Recovery (DR) und Backup einer neuen VMware-Infrastruktur sind oft die letzten Dinge, die angegangen werden,...

wenn eine solche Umgebung eingerichtet wird. Allerdings sollte dies nicht so sein, denn es gibt keine Entschuldigung, dies nicht zu tun. Was würden beispielsweise sechs Stunden Ausfall der produktiven Umgebung kosten? Sicherlich mehr als ein vernünftiges DR-Setup.

Mit den modernen Virtualisierungs-Stacks ist es heutzutage einfach und günstig, DR-Standorte aufzusetzen, in Betrieb zu nehmen und zu nutzen. Failover und Failback ganzer IT-Standorte lassen sich so mit einigen Mausklicks umsetzen. Failover ist mittlerweile ein einfacher Prozess geworden, dank Produkten wie VMware Site Recovery Manager (SRM) und Angeboten von Zerto oder Veeam.

Backup und DR sind unterschiedliche Prozesse, die beide sehr wichtig für Unternehmensdaten sind. Ein Backup stellt sicher, dass stets eine sichere und konsistente Kopie aller wichtigen Daten außerhalb – off-site – des eigenen Standortes zur Verfügung steht. Diese Backups sollten regelmäßig mit Test-Restores überprüft werden, um die Datenintegrität und die Datenverfügbarkeit zu garantieren.

Disaster Recovery hingegen ist eine durchdachte, stets getestete und immer verfügbare Failover-Option. In virtuellen Welten lässt sich DR wesentlich leichter nutzen und ist zudem günstig. Es gibt eine breite Auswahl an DR-Optionen, die sich generell in zwei Arten aufteilen lassen: hardwarebasierte Replikation und softwarebasierte Replikation.

Hardwarebasierte Replikation

Hardwarebasierte Produkte wie SRM zusammen mit hardwarebasierter LUN-Replikation replizieren eher die gesamte LUN als nur die individuellen virtuellen Maschinen (VMs). Das war bislang die einzige Methode für ein Failover in einer VMware-Umgebung. Das Konfigurieren von SRM ist sehr komplex und bedarf neben aufwendigem Konfigurieren auch den Einsatz replizierter LUNs zwischen produktivem und DR-Standort. Der Support dieser Technologie ist komplex und teuer. Die hohen Kosten rühren daher, dass man verschiedene Lizenzen benötigt, sowohl für die SAN- als auch die VMware-Umgebung. Ebenso bedarf es eines fähigen Administrators, der nicht nur VMware versteht, sondern auch das komplexe SAN-Management sowie Mapping-Replikation (raw-device).

Ein anderes Problem der SRM-ähnlichen Produkte ist das Fehlen granularer Kontrolle darüber, was das Failover umfasst. Repliziert man die gesamte LUN, so werden auch ungewollte VMs repliziert und benötigte VMs findet man eventuell nicht, wenn sie nicht auf der korrekten LUN sind oder wenn der Cluster nicht repliziert wurde.

Softwarebasierte Replikation

Demgegenüber steht softwarebasierte Replikation von Anbietern wie Veeam oder Zerto. Diese Produkte sind einfacher zu nutzen. Die erlauben eine viel granularere Konfiguration. Das heißt, der Administrator kann einzelne VMs oder VM-Gruppen auswählen, die dann statt der ganzen LUN für ein Failover bereitgestellt werden. Im Gegensatz zu hardwarebasierter Replikation gibt es hier kein komplexes Storage-Array-Management oder Replikationslizenzen.

Softwarebasiertes DR ist einfach konzipiert und simpel zu implementieren. Die meisten Produkte basieren auf einem Standard-VM-Management-Tool, bei dem ein Agent auf jedem Host liegt und ein virtueller Server den Replikationsfluss zwischen den Standorten kontrolliert. Der Management-Server verfügt über ein GUI. Hiermit verwaltet der Administrator, was er wann replizieren möchte sowie andere wichtige Informationen. Obwohl Veeam und Zerto unterschiedlich sind, nutzen beide doch ein System, das auf diesem Szenario virtueller DR-Setups basiert.

Schlüsselfaktoren

Bevor man eine IT-Lösung erwirbt, müssen Entscheidungen seitens der IT-Abteilung getroffen werden. Zwei der wichtigen Faktoren beim DR sind Recovery Time Objective (RTO) und Recovery Point Objective (RPO). RTO steht dafür, wie lang die akzeptable Zeitspanne eines Ausfalls ist beziehungsweise wie lange es dauern darf, bis das Unternehmen wieder online und produktiv sein muss. Der RPO bestimmt die Aktualität der Failover-Informationen. Werden alle Daten benötigt, beispielsweise in einer Finanzfirma, dann ist ein RTO von 15 Minuten üblich. Dafür sind viele Ressourcen nötig, um eine konsistente und korrekte Replikation zu gewährleisten. Je aktueller die Informationen sein müssen, desto mehr Ressourcen werden benötigt (und natürlich Budget), um den RPO zu garantieren.

RPO und RTO sind mehr als reine IT-Entscheidungen. Sie stellen aber einen Ausgangspunkt dar, von dem aus Programme konzipiert und umgesetzt werden können. Es gibt auch andere Faktoren, die eine Entscheidung in Richtung softwarebasierte Replikation treiben. So könnte es beispielsweise sein, das Ihr existierendes Storage-Produkt keine Replikation unterstützt oder der Replikations-Overhead sowie die Kosten einfach zu groß werden.

Die softwarebasierten Angebote von Zerto und Veeam funktionieren in jeder Umgebung und erfordern keine teure Storage-Lizenz. Softwarebasierte Replikationen sind Provider-agnostisch und eignen sich für jede DR-Strategie. Eines dieser beiden Lösungen auszuprobieren ist recht einfach und nicht sehr teuer. Ein Cluster aus drei Nodes kann schon für 4000 US-Dollar DR-fähig gemacht werden, allerdings ohne die Hardware-Anforderungen. Hier benötigt man zudem keine teure proprietäre Hardware oder SAN-Replikationslizenzen.

Softwarebasierte Replikationen sind eine sichere Sache, erst recht, wenn das IT-Team nicht in Storage geschult ist. Storage-Fehler können die Situation verschlimmern. Einige der weltweit größten Firmen setzen auf virtuelles DR und verabschieden sich von teuren SAN-basierten Systemen, wobei sie ein kleines Vermögen dabei einsparen.

Zuverlässigkeit garantieren

IT-Verantwortliche sollten auf potentielle gegenseitige Abhängigkeiten zwischen VMs achten. Ein Beispiel hierfür ist eine klassische 3-Tier gehostete Anwendung. Um DR effizient umzusetzen, müssen alle VMs in einem konsistenten Zustand sein. Das ist nur die Spitze anderer Abhängigkeiten, die von Authentifizierung und Managementinfrastruktur erfordert werden.

Das Problem der Konsistenz wird mittels Konsistenzgruppen (consistency groups) behoben. Wie der Name schon sagt, werden hier VMs gruppiert, die zusammenbleiben müssen, um potentielle Korruption zu verhindern und Konsistenz zu gewährleisten.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Juli 2015 aktualisiert

Pro+

Premium-Inhalte

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

Essential Guide

Mehr Datensicherheit durch Replikation und Snapshots

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