Für den Schutz vor Standortausfällen bietet sich die Cloud als kostengünstige Disaster-Recovery-Alternative (DR) an. Unternehmen sparen sich damit die Kosten für ein Ausweichrechenzentrum und sind dennoch in der Lage, im DR-Fall wichtige Server schnell wieder online zu bringen. LANline untersucht, welche technischen Rahmenbedingungen dabei zu beachten sind, und geht darüber hinaus auf die DR-Lösungen von Veeam und Zerto näher ein.

Ob sich eine Cloudlösung für ein Unternehmen als Disaster-Recovery-Plattform eignet, hängt von verschiedenen Faktoren ab. Unter anderem ist im Vorfeld zu prüfen, ob sich die Anwendungen aus der Cloud mit annähernd derselben Performance bereitstellen lassen, wie im regulären Vor-Ort-Betrieb. Für Anwendungen, die eine sehr niedrige Latenz benötigen, kann der Zugriff über eine WAN-Verbindung ein K.-o.-Kriterium sein. Zudem muss sichergestellt sein, dass im Krisenfall der Zugriff auf die Anwendungen auf allen Wegen inklusive Mobilzugang über das Internet möglich ist.

Ebenso muss ein Unternehmen klären, wie es im DR-Fall mit physischen Servern umgehen will. Können diese temporär als virtuelle Replica beim Cloud-Provider laufen? Oder benötigt es hierfür physische Ersatzsysteme, die der Provider in seinem Rechenzentrum (RZ) bereitstellen muss? Kleinere und mittelständische Unternehmen wählen deshalb für ihre DR-Cloud-Strategie nicht selten einen Managed Service Provider (MSP), statt selbst Hyperscaler wie AWS oder Microsoft Azure zu nutzen. Ein MSP ist in der Lage, individuelle DRaaS-Angebote (Disaster Recovery as a Service) zu erstellen und zum Beispiel einen Pool an physischen Servern vorzuhalten, die ein Kunde im DR-Fall für ein Bare-Metal-Recovery nutzen kann. Auch Compliance-Anforderungen, die beispielsweise vorschreiben, dass man bestimmte Backup-Bänder aus der Tape Library entnehmen und an einem anderen Ort in einem Safe aufbewahren muss, kann ein MSP eher erfüllen als die großen Cloud-Provider.

Cloud als DR-Plattform ist für kleine Unternehmen interessant

Die Cloud als DR-Plattform für virtualisierte Server zu nutzen, ist insbesondere für kleinere und mittelständische Unternehmen interessant. Großunternehmen haben in der Regel mindestens zwei RZs an räumlich voneinander entfernten Standorten, sodass sie ihre wichtigen Systeme in das jeweils andere RZ replizieren können. Wobei es auch Beispiele gibt, dass Firmen ihre DR-Strategie für virtualisierte Work-loads komplett auf Cloud-Provider umstellen und die bisher selbst betriebenen Ausweich-RZs schließen.

Wenn ein Unternehmen die Cloud als DR-Plattform nutzen will, muss es zunächst überlegen, welche DR-Szenarien es damit abbilden will. Ein gängiges Verfahren ist es, die im eigenen RZ laufenden VMs zum Cloud-Provider zu replizieren. Fällt der komplette Unternehmensstandort längerfristig aus, tritt der DR-Plan in Kraft. Er startet die in der Cloud gespeicherten Replica-VMs und bringt sie online, sodass sie die ausgefallenen Anwendungen schnell wieder bereitstellen können.

Damit das reibungslos funktioniert, ist für den DR-Fall eine sorgfältige Planung der Netzkonfigurationen und der IP-Adressierung erforderlich. So muss zum Beispiel sichergestellt sein, dass die Replica-Instanz eines MS-Exchange-Frontend-Servers im Krisenfall für die Benutzer über das öffentliche Internet oder per VPN-Verbindung erreichbar ist. Einige Hersteller von DR-Lösungen bieten hierfür Orchestrierungslösungen an, mit denen sich die Anbindung der Netze und eine Rekonfiguration von Netz- und IP-Adressen weitgehend automatisiert durchführen lassen.

Die schnellste Lösung, um einzelne ausgefallene Systeme wiederherzustellen, ist nach wie vor eine lokale Replikation im eigenen RZ. Für Unternehmen, die sich die dazu erforderliche Storage-Infrastruktur und die höheren Kosten für die DR-Softwarelizenzen leisten können, ist dies eine sinnvolle Ergänzung des DR-Konzepts. Voraussetzung ist, dass die DR-Lösung in der Lage ist, eine primäre Replikationskopie auf einem DR-Speichersystem im eigenen RZ zu speichern und zusätzlich eine zweite Replikationskopie zu einem Cloud-Provider oder an einen anderen Standort zu übertragen.

Ob sich auch die in einem Unternehmen vorhandenen physischen Server per Physical-to-Virtual-Conversion (P2V) in eine VM-Replica umwandeln lassen und diese im DR-Fall die jeweiligen Anwendungen aus der Cloud performant bereitstellen kann, gilt es im Einzelfall zu prüfen. P2V- und V2V-Funktionen unterstützen die meisten DR-Lösungen, wobei es Unterschiede beim Cross-Hypervisor-Support gibt. Bei den von den Hyperscalern wie AWS mit CloudEndure oder Microsoft mit Azure Site Recovery angebotenen Replikations-Tools ist in der Regel nur eine Umwandlung von physischen oder virtuellen Servern in das VM-Format der eigenen Plattform vorgesehen.

Andere DR-Lösungen wie die von Veeam oder Zerto unterstützen zudem eine Umwandlung von beispielsweise AWS-VMs in Azure-VMs oder von VMware vSphere nach Hyper-V sowie in die jeweils umgekehrte Richtung. Dadurch sind auch Migrationen von einem Cloud-Provider zu einem anderen möglich.

DR-Techniken von Veeam und Zerto

LANline hat sich die DR-Lösungen von Veeam und Zerto genauer angeschaut. Bei Veeam Backup & Replication handelt es sich um eine Software, die sowohl ein regelmäßiges Backup von Servern als auch eine Replikation von VM-Images zu einem anderen RZ-Standort oder in die Cloud unterstützt. Die replizierten VM-Images aktualisiert die Lösung regelmäßig zum Beispiel täglich oder stündlich. Dies kann offline geschehen, ohne dass man die Replica-VM vorher starten muss.

Die von Zerto entwickelte DR-Software verfolgt einen anderen technischen Ansatz. Zerto überträgt mittels einer Hypervisor-basierten Replikation fortlaufend alle IOs einer VM asynchron zur Replica-VM und ist dadurch im Zusammenspiel mit einem Change-Journal in der Lage, VMs sekundengenau wiederherzustellen. Diese Replikation erfolgt offline. Die Replica-VMs werden erst im DR-Fall oder für DR-Tests erstellt und hochgefahren. Die im Herbst 2019 fertig gestellte Version 7.5 bezeichnet Zerto als IT-Resilienzplattform, die in der Lage sein soll, alle Unternehmensdaten jederzeit Plattform- und Multi-Cloud-übergreifend in ihrem aktuellen oder einem zeitlich zurückliegenden Zustand wiederherzustellen.

Zerto ist vor rund zehn Jahren als reines DR-Produkt gestartet, entwickelt sich mittlerweile aber immer stärker in Richtung Backup-Lösung. Die 7.5-Version unterstützt mit dem Elastic Journal eine Langzeitarchivierung mit Indizierungsfunktionen, für die sich kostengünstige Secondary-Storage-Systeme nutzen lassen. Veeam dagegen bietet schon immer eine Backup- und DR-Lösung an und arbeitet derzeit gewissermaßen in umgekehrter Richtung daran, ähnlich wie Zerto eine Continuous Data Protection (CDP) zu unterstützen.

Zu den wichtigsten Fragen beim Entwurf einer DR-Strategie zählt, wie schnell die IT-Infrastruktur beziehungsweise die kritischsten IT-Systeme wieder laufen müssen. Hierbei ist auch festzulegen, welche Recovery Point Objectives (RPO) und Recovery Time Objectives (RTO) für die verschiedenen Anwendungen gelten sollen. Beim RPO geht es darum, zu welchem Zeitpunkt sich die Daten wiederherstellen lassen und wie groß damit die maximale Zeitspanne ist, für die Daten verloren gehen dürfen. Die RTO-Angabe bezieht sich auf die maximale Dauer, bis die ausgefallenen Systeme und ihre Anwendungen spätestens wieder verfügbar sein müssen.

In den meisten Fällen wird es sinnvoll sein, für den DR-Fall einen abgestuften Wiederanlaufplan zu erstellen. Dieser definiert unter anderem, welche Replica-Systeme die Lösung als erstes hochfahren muss, in welcher Reihenfolge sie diese starten soll und welche Systeme unkritisch sind und nicht repliziert werden müssen. Bei der Erstellung eines DR-Konzeptes sollte ein Unternehmen auch überprüfen, ob es für das Backup die 3-2-1-Regel anwendet. Sie besagt, dass die verwendete Backup-Lösung von den Originaldaten immer zwei Kopien erstellen sollte, die es auf zwei unterschiedlichen Speicher-Techniken speichert, wovon eine Kopie nicht am selben Standort hinterlegt ist. Um sich vor Ransomware-Attacken zu schützen, kann es zudem sinnvoll sein, eine Kopie auf Offline-Medien wie Bändern zu speichern und diese an einem anderen Ort in einem Tresor zu lagern.

Eine wichtige Rolle spielt bei Cloud-DR-Konzepten naturgemäß die Art der WAN-Anbindung. Am kostengünstigsten sind Verbindungen über das öffentliche Internet, die man durch den Einsatz von VPN-Gateways im eigenen RZ und beim Provider absichern sollte. Eine hohe Sicherheit bieten private WAN-Anbindungen, die sich direkt zwischen dem eigenen RZ und dem Cloud-Provider-RZ schalten lassen.

In beiden Fällen ist es wichtig, gemeinsam mit dem Provider ein Netz- und IP-Adressenkonzept zu entwickeln, damit im DR-Fall der Zugriff auf die dann von den Replica-VMs bereitgestellten Anwendungen für alle Mitarbeiter möglich ist. Auch den Fallback-Plan sollte das Unternehmen bereits im Vorfeld erstellen, damit klar ist, wie sich der aktuelle Stand der DR-Systeme nach der Wiederherstellung wieder zurück auf die Originalsysteme übertragen lässt. Hierbei ist zu beachten, dass Provider für den Datenverkehr von der Cloud zum Kunden meist deutlich höhere Gebühren verlangen als für den Upstream-Traffic.

Auswahlkriterien für eine Cloud-DR-Lösung

Bei der Auswahl einer Cloud-DR-Lösung sind vor allem die vom jeweiligen Produkt unterstützten Funktionen von Interesse. Unterschiede gibt es zum Beispiel beim Hypervisor-Support. VMware ESX und Microsoft Hyper-V werden in der Regel von den meisten Lösungen unterstützt. Bei KVM, Citrix Xen oder Nutanix AHV ist die Auswahl jedoch schon kleiner. Zudem sollte die DR-Software möglichst viele Cloud-Provider unterstützen, damit ein späterer Wechsel zu einem anderen Provider mit einem vertretbaren Aufwand möglich ist.

Bei der Konfiguration von Replica-VMs spielen die Netzwerk- und IP-Einstellungen eine wichtige Rolle. Bild: Christoph Lange

Für die initiale Replikation ist es hilfreich, wenn ein sogenanntes Seeding unterstützt wird. Dabei speichert das Unternehmen die zu replizierenden Daten auf einem physischen Speichermedium, das zum Provider transportiert und dann dort eingelesen wird. Auch der Betriebssystem-Support für Replikationsagenten sowie die Möglichkeiten für eine Replikation von physischen Systemen sind zu betrachten.

Des Weiteren ist zu prüfen, ob die Software applikationskonsistente Backups zum Beispiel für Datenbanken unterstützt und ob sich Server mit gegenseitigen Abhängigkeiten in Replikationsgruppen zusammenfassen lassen. Um Szenarien mit lokaler und zusätzlicher Cloudreplikation abbilden zu können, muss die Lösung eine One-to-Many-Replikation unterstützen. Für eine möglichst ressourcenschonende Replikation sollte sie zudem eine Datenkomprimierung und Deduplizierung unterstützen. Bei Image-basierten Replikationslösungen reduzieren inkrementelle Updates das zu übertragende Datenvolumen. Auch die WAN-Übertragung sollte sich durch Komprimierungstechniken optimieren lassen. Eine Verschlüsselung der gespeicherten Daten und der Datenübertragungen schützt vor Datenmissbrauch.

Für den Schutz vor Ransomware integrieren einige DR-Lösungen inzwischen Machine-Learning-Funktionen, um Angriffe zu erkennen. Einige DR-Produkte bieten außerdem Sandbox-Funktionalitäten für automatisierte DR-Tests. Nützlich sind hierbei zudem Reporting-Funktionen, um nachzuweisen, dass man regelmäßig DR-Tests durchgeführt hat. Wichtig ist ein externer Zugang zur DR-Management-Konsole, der auch dann nutzbar ist, wenn ein Unternehmens-RZ komplett ausfällt.

Besonders für größere Unternehmen ist es wichtig, dass sich im DR-Fall die Replica-Systeme möglichst automatisiert online bringen lassen. Hierfür stehen je nach Hersteller unterschiedliche Orchestrierungswerkzeuge zur Verfügung. Für eine Langzeitarchivierung von Replica-VMs sollte die verwendete Lösung eine Speicherung auf Object-Storage-Systemen unterstützen. In der Cloud ist dieser Speicher deutlich günstiger als der Standard-Block-Storage. Die Integration mit anderen Anwendungen sollte über offene Schnittstellen wie eine REST-API möglich sein.

Disaster Recovery in der Cloud

Der Aufwand für die Einrichtung einer Cloud-DR-Lösung hängt stark von der Anzahl der zu sichernden VMs ab. Kleinere Unternehmen, die nur ein oder zwei Dutzend VMs in die Cloud replizieren möchten, können mit Tools wie Veeam ihre VMs relativ einfach zu AWS oder Azure übertragen, um eine Replica-Kopie zu erstellen. Die Cloud-Anbindung lässt sich mit wenigen Mausklicks unter Angabe der Cloud- und Storage-Account-Zugangsdaten erledigen. Dies haben wir anhand der LANline-Testumgebung mit Veeam in der Praxis ausprobiert.

Bei größeren Unternehmen mit einer Vielzahl zu schützender VMs muss man auf beiden Seiten die vom jeweiligen DR-Hersteller angebotenen Steuerungs-VMs installieren. Zerto benötigt beispielsweise auf den Hypervisor-Hosts des Kunden sogenannte Virtual Replication Appliances und in der Cloud eine Zerto Cloud Appliance. Gesteuert wird die Replikation sowie der Failover und Failback über den Zerto Virtual Manager, der mit anderen VM-Management-Systemen wie VMware vCenter oder Microsoft Virtual Machine Manager zusammenarbeitet und im DR-Fall die Netz- und IP-Adressenkonfiguration automatisiert anpasst. Hinzu kommt bei Bedarf die Virtual Backup Appliance, die einzelne Dateien und Verzeichnisse wiederherstellen kann. Für Service-Provider bietet Zerto mit dem Cloud Manager zudem eine mandantenfähige DRaaS-Lösung an.

Die Cloud-Appliance von Zerto integriert die DR-Lösung mit Cloud-Providern wie Azure oder AWS. Bild: Zerto

Wer mit Veeam eine größere Zahl an VMs in die Cloud replizieren will, sollte ebenfalls beim Provider Veeam Backup & Replication sowie dedizierte Cloud-Gateways installieren. Für die WAN-Anbindung bietet Veeam neben einer VPN-Lösung auch eine Network-Extension-Appliance an, die einen Layer-2-Tunnel zum Provider aufbaut. Die Replica-VMs verwenden damit dieselben IP-Adressen wie die Quell-Maschinen. Mit Cloud Connect Backup bietet Veeam ebenfalls eine auf Service-Provider zugeschnittene DRaaS-Lösung an.

VM-Backup in der Cloud

Um die Cloudanbindung mit Veeam zu testen, fügten wir im Konfigurationsmenü einen Azure- und einen AWS-Test-Account hinzu. Im AWS-Konto erstellten wir zudem einen neuen S3-Bucket, den wir in Veeam als externes Repository konfigurierten. Bei Azure konnten wir dafür den vorhandenen Storage-Account nutzen.

Anschließend richteten wir einen Backup-Job ein, der die VM zunächst in ein lokales Repository sicherte und von dort automatisiert jeden Abend zu Azure und zu AWS replizierte. Nach einigen Tagen löschten wir die virtuelle Disk dieser virtuellen Maschine und konnten sie aus dem Cloud-Backup erfolgreich wiederherstellen.
Der kleine Test zeigte, dass sich ein VM-Backup in die Cloud mittlerweile relativ einfach einrichten lässt. Um eine Cloud-DR-Lösung aufzubauen, die bei einem Standortausfall alle Replica-VMs schnell online bringt und mit der richtigen IP- und DNS-Konfiguration für die Anwender erreichbar macht, sind allerdings wie beschrieben deutlich mehr Installations- und Konfigurationsarbeiten erforderlich.

Fazit

Viele Backup- und DR-Lösungen bieten heutzutage die Möglichkeit, die Cloud als Disaster-Recovery-Plattform zu nutzen. Um ein tragfähiges Cloud-DR-Konzept zu erstellen, ist eine sorgfältige Planung erforderlich. Ein besonderes Augenmerk sollte ein IT-Verantwortlicher dabei auf die Netzanbindung und die damit verbundenen Themen wie IP-Adressierung und DNS-Konfiguration legen. Bei der Auswahl einer geeigneten DR-Lösung ist zudem zu beachten, dass sich damit die gewünschten RPO- und RTO-Zeiten einhalten lassen.

Darüber hinaus sollte man nicht vergessen, dass auch eine optimal geplante Cloud-DR-Lösung im Zweifelsfall ins Leere läuft, wenn sie der IT-Verantwortliche nicht regelmäßig testet.

Christoph Lange.