Cloud-Optionen werden zum festen Teil von Disaster-Recovery-Strategien

Cloud-basiertes Disaster-Recovery stellen eine günstige und flexible Option dar, um Anwendungen nach einem Störfall weiterhin verfügbar zu halten.

Dieser Artikel kann auch im Premium Editorial Download gefunden werden: Storage-Magazin: Backup, DR und Hochverfügbarkeit in der Cloud:

In unserer IT-Welt ist Data Protection ein essentieller Teil und eine Voraussetzung, um Business Continuity im Falle eines IT-Desasters aufrecht zu erhalten. Daten sind der Kern – quasi die Lebensader – eines Unternehmens. Sie benötigen effiziente Prozesse, damit kritische Systeme erreicht werden können. Die Kosten einer Störung respektive einer Ausfallszeit können sich auf tausende Euro pro Stunde belaufen, je nachdem wie groß das Unternehmen ist und in welcher Branche es aktiv ist.

Disaster Recovery wurde oft als „Alles-oder-Nichts“-Szenario gesehen: Man drückte auf den DR-Knopf, wenn das Unternehmen in seinen IT-Services einen massiven Störfall erfuhr. In der Regel wurden diese Services auf einem monolithischen System wie zum Beispiel dem Mainframe betrieben. Das traditionelle DR-Model basierte auf Band-Backups, bei dem zusätzliche Bandmedien an einen externen Standort ausgelagert wurden. Dieser Ansatz kann zu langen Ausfallzeiten führen, da die Tapes zunächst wieder an den primären Standort transportiert werden müssen, bevor sich Daten und Anwendungen wiederherstellen lassen. Unternehmen, die schnellere Restore-Zeiten voraussetzten, replizierten in der Regel ihre Daten an ein eigenes zweites Rechenzentrum oder nutzten Shared Services von DR-Spezialisten, die bei Bedarf DR-Funktionen bereitstellten. Beide Methoden sind sehr kostenintensiv.

Das Internet, Virtualisierungs-Technologien und das Aufkommen der Public Cloud bieten nun einen praktischeren Ansatz für Unternehmen jeder Größe, einen BC/DR-Plan umzusetzen, ohne dabei in zusätzliche RZ-Standorte und -Ressourcen investieren zu müssen. Geschäftsprozesse lassen sich bei Bedarf on-demand mittels eines Cloud-basierten DR-Services in die Cloud verbringen, entweder kontrolliert oder als Teil eines ungeplanten Notfalls. Hierbei ist es wichtig, Business Continuity als den Prozess anzusehen, der gewährleistet, dass IT-Services stets verfügbar sind, während DR der Prozess ist, bei dem Services an einen sekundären Standort transferiert werden.

Vorteile von Cloud-DR

Heutzutage werden Anwendungen viel breiter verteilt und in virtualisierten Umgebungen betrieben, künftig wahrscheinlich auch in Containern. Das wiederum verschiebt das Backup-Paradigma und IT-Abteilungen haben mehr Flexibilität, alle oder nur einige IT-Services dort wiederherzustellen, wo sie benötigt werden. Cloud-basierte DR-Services bieten Unternehmen folgende Optionen:

  • Den Geschäftsbetrieb aufrecht zu erhalten, egal von wo aus die dafür nötigen Services bereitgestellt werden.
  • Im Falle eines Hardware- oder Softwareausfalles oder eines Komplettausfalls, ein Failover auf sekundäre Services durchzuführen.
  • Ein kontrolliertes Failover von Workloads umzusetzen, um andere Komponenten zu warten, beispielsweise das Netzwerk oder die Infrastruktur.
  • Workloads zu migrieren, um ungeplantes Wachstum oder unvorhersehbare Anforderungen bedienen zu können.
  • DR-Fähigkeiten zu testen (on-demand), ohne das Primärsystem dabei zu beeinflussen.

Natürlich ist der primäre Fokus von BC/DR, gesetzte SLAs und Ziele des Unternehmens zu bedienen. Das heißt, dass RTOs und RPOs für jede Anwendung spezifisch determiniert werden müssen. Abhängig von den speziellen internen RPO/RTO-Anforderungen, kann ein Unternehmen sich für eines der drei wichtigsten Cloud-Modelle entscheiden:

Datenbasiert. Der DR-Prozess sorgt dafür, dass eine Backup-Kopie der Daten in der Cloud-Plattform verfügbar ist, was dem geringsten Recovery-Level entspricht. Das bedeutet, dass Daten gespeichert werden, die in File-Servern vorgehalten werden. Das umfasst auch Home Directories und Shared Folder. Kommt es zu einem Störfall, kann auf die Daten des Cloud-DR-Standorts zugegriffen werden. Abhängig von der Größe des Datenbestandes, der wiederhergestellt werden muss, kann die Ausfallzeit recht lange dauern. Es kann darüber hinaus der Fall sein, dass Daten physisch wieder an den Primärstandort gesendet werden müssen, damit sie hier auf einer Appliance rekonstruiert werden.

Applikations-basiert. Der DR-Prozess repliziert Anwendungsdaten zu einer Zweitinstallation der Applikation in der Cloud. Daten werden mittels nativer Applikations-Funktionen oder mittels Produkten von Drittanbietern verschoben. Bei einem Failover wird Zugriff auf die Anwendung in der Cloud ermöglicht (normalerweise durch DNS-Änderungen). Die sekundäre Applikation läuft dann permanent in der Cloud und erhält regelmäßig Daten.

VM-Image. Der DR-Prozess repliziert ein komplettes Image einer virtuellen Maschine mit allen Daten in die Cloud. Das VM-Image ruht quasi in der Cloud und ist nicht im Betrieb, bis ein Notfall eintritt. Dann kann dieses Image mittels DNS-Änderungen in Betrieb genommen und zur Verfügung gestellt werden. Mit diesem Image-Backup lassen sich auch physische (Bare Metal) Anwendungsinstallationen über P2V-Replikation (physisch-zu-virtuell) sichern.

Potenzielle Probleme eines Cloud-DR

Natürlich gibt es auch mögliche Risiken oder Probleme bei einem Cloud-basierten DR. Viele der folgenden Beispiele könnten auftreten, wenn ein DR-System implementiert wird. Allerdings gelten einige insbesondere für Cloud-Konfigurationen.

Netzwerkbandbreite. Bandbreite ist aus vielen Perspektiven ein zentrales Problem. Zunächst benötigt man einen ausreichenden Datendurchsatz zwischen der Primärseite und der Cloud, um sicherzustellen, dass Daten zeitnah und ohne Verzögerungen repliziert werden können, was wiederum den RPO beeinträchtigen würde. Des Weiteren benötigt man eine vernünftige Bandbreite, um die veränderten Daten wieder am Primärstandort zu rekonstruieren, wenn das DR vorüber ist. Ebenso muss es möglich sein, die Services in der Cloud abzurufen, entweder vom internen Unternehmensnetzwerk oder vom Internet aus.

Netzwerksicherheit. Daten in die Cloud zu verschieben bedeutet, dass sie außerhalb des geschützten privaten Netzwerk der Firma residieren, weswegen sie in-flight verschlüsselt werden müssen. Darüber hinaus kann es sein, dass Compliance- oder andere Richtlinien vorgeben, die Daten at-rest, also am Zielstandort, zu verschlüsseln. Das kann Auswirkungen darauf haben, wie Applikationen lokal implementiert werden, damit sichergestellt ist, dass der Verschlüsselungsprozess die normalen Geschäftsabläufe nicht behindert.

Netzwerkadressierung. Da Applikations-Workloads in die Cloud verschoben werden, ändern sich die IP-Adressen. Werden primäre und sekundäre Applikations-Server lokal vorgehalten, so lässt sich die IP-Adressierung relativ einfach umsetzen. Entweder implementiert man hier ein Level-3-Netzwerk zwischen den Standorten oder nutzt Routing. Wenn eine Anwendung in die Cloud verschoben wird, werden DNS-Änderungen notwendig, um auf den neuen Server respektive den Datenstandort zu verweisen. In manchen Fällen sind auch Modifizierungen an der Anwendung vonnöten.

Netzwerklatenzen. Anwendungen in der Cloud zu betreiben, kann Performance-Probleme aufgrund von höheren Latenzen hervorrufen. Das passiert zum Beispiel, wenn nur ein Teil eines Services in DR migriert wird und es dann aufgrund dessen zu Kommunikationsschwierigkeiten zwischen dem lokalen und dem externen Standort kommt.

Lizenzierung. Für DR-Instanzen von Applikationen müssen Unternehmen Lizenzen erwerben, die je nach Anbieter variieren können. Diese Lizenzoptionen können für Cloud-Implementierungen anders ausfallen oder im schlimmsten Fall gar nicht unterstützt sein.

Kosten. Die Kosten für eine Cloud-DR-Implementierung umfassen die Cloud-Services, zusätzliche Netzwerkkapazitäten, Backup-Softwarelizenzen und zusätzliche Anwendungslizenzen. Dies variiert, je nachdem, wie das Cloud-DR umgesetzt wird.

Qual der Wahl: Do it yourself oder kaufen?

Sollte eine Firma die DR-Funktionalitäten selbst erstellen oder einen Cloud-basierten DR-Service kaufen? Datenbasierte DR lässt sich relativ einfach umsetzen, indem die Daten zu einem Cloud-basierten File-Service kopiert werden. Auch Produkte wie Acronis Cloud Backup oder DataProtect von Zetta lassen sich hier nutzen.

Applikations-basiertes DR kann umgesetzt werden, indem eine Ziel-VM mit einem Cloud-Provider erstellt und dann eine Replikation auf Anwendungsebene konfiguriert wird. In diesem Fall ist die IT-Abteilung dafür verantwortlich, dass das DR-VM-Image vernünftig gepflegt wird (Patches, Upgrades), um im Abgleich mit der produktiven Installation zu bleiben. Wird ein Failover initiiert, muss das IT-Team die Daten nach dem Failover wieder zurückholen. Einige datenbankbasierte Replikationsprodukte unterstützen keine inkrementelle Datenreplikation zurück zur primären Datenbankinstanz, was ein Problem darstellt.

VM-Replikation ermöglicht das Verschieben einer vollständigen Anwendung als VM in die Cloud. Das eignet sich für Szenarien, in denen komplexe Applikations- oder Serverabhängigkeiten vorhanden sind, wie beispielsweise bei Microsoft SharePoint. Hier muss der IT-Leiter kein separates VM-Image anlegen und pflegen. Produkte von Herstellern wie Zerto sind im Hypervisor integriert und replizieren alle I/Os in die Cloud-Instanz. In einer Recovery-Situation wird das Cloud-basierte Image genutzt, um den produktiven Betrieb zu gewährleisten. Dafür müssen Konfigurationsänderungen vorgenommen werden, wie beispielsweise die IP-Adressen zu ändern oder Anpassungen an die DR-Hardware vorzunehmen.

Bei den meisten Block-basierten Replikationsprodukten kann das Cloud-Image als Crash-konsistente Kopie der Anwendung dargestellt werden, die beim Starten eventuell ein erweitertes Recovery benötigt. Deswegen sind Tests des Recovery-Images wichtig. Im Test wird die Applikation isoliert und im DR-Modus gestartet, was Integritätstests ermöglicht, ohne die produktive Applikation zu beeinflussen.

Cloud-DR-Services vergleichen

Worauf sollten Anwender achten, wenn sie einen Cloud-basierten DR-Service in Erwägung ziehen? Hier sind ein paar zusätzliche Kriterien.

  • Kosten. Wie wird der Service abgerechnet: pro TByte oder pro VM? Entstehen Zusatzkosten, wenn der DR-Modus aktiviert ist?
  • Zeiteinschränkungen. Wie lang kann der DR-Modus aufrecht erhalten werden beziehungsweise gibt es eine maximale Laufzeit? Gibt es Beschränkungen für die Anzahl an Systemen in einem Failover?
  • Wie funktioniert das Failback? Kann der Anwender inkrementell zum produktiven Modus zurückkehren (und nur die Veränderungen zurückkopieren) oder muss er all seine Daten wiederherstellen?
  • Bietet der Service erweiterten Schutz? Kann der Anwender im DR-Modus seine Daten auch in einer dritten Kopie anlegen und an einen weiteren Standort replizieren (zum Beispiel an einen anderen Cloud-Standort), bevor der produktive Betrieb wieder aufgenommen wird?

Ein Cloud-basierter DR-Service offeriert Flexibilität für die Data Protection der eigenen, lokalen Umgebung. Da sich die Anwendungen immer weiterentwickeln, wird vielleicht der Unterschied zwischen DR und verteilten Applikationen verwischen. DR wird dann Applikations-Schutz und Skalierbarkeit bieten. Die Notwendigkeit, Anwendungen und Data Protection aufrecht zu erhalten, wird auf jeden Fall bestehen bleiben.

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

Artikel wurde zuletzt im Mai 2016 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Sichere Datenspeicherung

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close