Alex_Mac - Fotolia

Disaster Recovery in der Cloud in sechs Schritten

Disaster Recovery in der Cloud ist eine Alternative oder Ergänzung zum Zweitrechenzentrum. Bei kritischen Ausfällen ist das hilfreich.

Möglicherweise ist die Cloud die seit Jahrzehnten am meisten überbewertete Technologie. Sie kann aber nützlich sein, wenn sie als Komponente des DR-Plans (Disaster-Recovery) eines Unternehmens eingesetzt wird.

Unternehmen können eine Cloud-basierte Recovery-Site aufbauen, die die Arbeit übernimmt, wenn das primäre Datenzentrum zusammenbricht oder aus Gründen wie Feuer oder Hochwasser ausfällt. Es gibt einige alternative Einsatzstrategien für die Cloud bei Disaster Recovery und Vorbeugung.

Evaluieren Sie Ihren Schutzbedarf

Der erste Schritt bei der Implementierung von DR-Angeboten ist die Analyse des eigenen Bedarfs. Das klingt einfach und ist es möglicherweise auch. Die Ergebnisse dieser Evaluierung sind aber der wichtigste Faktor, um die benötigte Infrastruktur und Konfiguration festzulegen, die errichtet werden muss, um den Cloud-basierten Schutz vor katastrophalen Ausfällen zu realisieren.

So nutzen einige Organisationen Cloud-Storage beispielsweise als Teil einer Backup-Lösung nach dem Verfahren Disk-to-Disk-to-Cloud. Die Primärsicherung bleibt am Primärstandort, aber wird auf Cloud Storage repliziert. Dort sind die Daten geschützt vor Einflüssen, die das Datenzentrum zerstören könnten, beispielsweise Überflutungen oder Brände. Andere Firmen replizieren ganze virtuelle Maschinen (VMs) in die Cloud, so dass sie dort hochgefahren und betrieben werden können, wenn sie im lokalen primären Rechenzentrum nicht mehr lauffähig sind.

Wählen Sie einen geeigneten Cloud-Provider

Nach Feststellung des Schutzbedarfs gilt es, geeignete Cloud-Provider zu finden, die diesen Bedarf befriedigen können. Nicht jeder Cloud-Provider ist nämlich so ausgerüstet, dass er diese Aufgabe übernehmen könnte. Beispielsweise übernehmen manche Provider die Replikation einer VM, hosten sie aber nicht. Ebenso gibt es Provider, die Speicher, aber wenig darüber hinaus anbieten. Wenn das Ziel ist, eine Cloud-basierende Disaster-Recovery-Site aufzubauen, braucht man einen Cloud Service Provider, der die dafür nötigen speziellen Fähigkeiten und Funktionen besitzt.

Wenn nur geplant ist, Daten in die Cloud zu replizieren, kann es andererseits besser sein, nur einen Speicherservice zu abonnieren und so nicht für unnötige Services und Funktionen zu bezahlen.

Um welchen Bedarf es auch immer geht, man sollte unterschiedliche Cloud Service Provider bewerten, um Kosten und Servicequalität und -verfügbarkeit zu vergleichen. Auch räumliche Nähe und Erreichbarkeit sprechen für ein lokales Systemhaus.

 Schätzen Sie die Kosten

Ist ein Cloud-Provider gefunden, der Ihre spezifischen Ansprüche befriedigt, folgt als Nächstes die Schätzung der Kosten, die der Einsatz einer Cloud-basierten Disaster Recovery verursacht. Jeder Cloud Service Provider hat in der Regel ein eigenes Preismodell, aber die monatlichen Gesamtkosten bestehen meist aus einer Kombination einer monatlichen Abo-Gebühr, der genutzten Internet-Bandbreite und Speicherkapazität sowie der Zahl der VMs oder virtuellen Prozessoren.

Einige Provider behandeln die Abo-Gebühr als anteilige Servicegebühr. Beispielsweise könnte die monatliche Abo-Gebühr eine bestimmte Menge Bandbreite einschließen. Wenn diese Bandbreite überschritten wird, entstehen zusätzliche Kosten.

Man sollte auch die Vorgehensweise des Providers hinsichtlich abgeschalteter VMs kennen. Einige Provider berechnen Gebühren basierend auf der Menge und der Art erzeugter VMs, egal, ob diese VMs aktiv sind oder nicht. Andere berechnen nur die tatsächliche Nutzung und ihre Preisstruktur basiert daher auf den Minuten oder Stunden, in denen eine VM tatsächlich läuft.

Wie ein Cloud Provider abrechnet, kann die Kosten der Cloud-basierenden Disaster-Recovery-Initiative beeinflussen. Deshalb sind genaue Kostenschätzungen vor Vertragsabschluss eminent wichtig. Obwohl manche Provider sehr komplizierte Berechnungsformeln benutzen, gibt es in der Regel Werkzeuge, die die Kostenschätzung vereinfachen. So bieten Microsoft und Amazon Web Services Tools zur Kostenschätzung an. Auch einige Softwarewerkzeuge von Drittherstellern haben integrierte Tools für die Kostenabschätzung. Veeam Backup und Replication Cloud Edition beispielsweise hat einen eigenen Rechner für die Kostenkalkulation, der mit diversen Cloud-Anbietern funktioniert.

Disaster Recovery: Eine neue Cloud-App

Cloud-basierte Disaster Recovery (DR) beschreibt normalerweise die Replikation von Daten oder ganzen virtuellen Maschinen in die Cloud. Für Unternehmen jedoch, die bereits ein Ausfallrechenzentrum für DR eingerichtet haben, kann es sinnvoller sein, um Cloud Services als Mechanismus zur Erleichterung des DR-Prozesses zu nutzen, als dort die Daten zu speichern. Microsoft beispielsweise bietet den Microsoft Azure Hyper-V Recovery Manager als Azure-Dienst an.

Der Hyper-V Recovery Manager ist ein hybrider Service, mit dem man Windows Azure nutzen kann, um den Replikationsprozess zwischen primärem und sekundärem Datenzentrum zu verwalten.

Hyper-V Recovery Manager soll die proprietären Replikationstechnologien, die einzelne Hersteller für die Replikation zwischen SANs anbieten, ersetzen. Stattdessen wird die Replikation auf der Hypervisor-Ebene mittels des nativen Hyper-V-3.0-Replikationsmechanismus durchgeführt. Obwohl der Replikationsprozess von virtuellen Maschinen von einem Datenzentrum zum anderen erfolgt, wird Windows Azure als Cloud-basierte Lösung für die Verwaltung der Replikation, des Umschaltprozesses und den DR-Test verwendet. Administratoren können eine Reihe von Recovery-Plänen über die Windows-Azure-Schnittstelle festlegen und sie ebenfalls verwenden, um zwischen den Rechenzentren umzuschalten oder den Umschaltvorgang zu testen.

Azure kommuniziert mit den beim Kunden befindlichen Installationen von System Center Virtual Machine Manager (VMM) auf den Servern im Unternehmen (eine in jedem Rechenzentrum). Umgekehrt übernimmt VMM die Aufgaben, die Rechenleistung verschlingen, indem individuelle Host-Server angewiesen werden, Daten zu replizieren, umzuschalten und so weiter. Diese Lösung ist besonders für Organisationen effizient, die Kosten und Komplexität des Umschaltens auf ein anderes Rechenzentrum verringern wollen.

Entwickeln Sie eine Strategie für das Bandbreiten-Management

Das Internet-Bandbreiten-Management ist bei der Entscheidung für eine Cloud-basierte Recovery-Strategie sehr wichtig. Dafür gibt es eine Reihe wichtiger Gründe: Manche Cloud Service Provider berechnen den Bandbreitenverbrauch. Ihr eigener Internet Service Provider nutzt möglicherweise monatliche Bandbreitenbegrenzungen oder erhebt Extra-Gebühren bei Überschreitung bestimmter Volumenvorgaben. Es muss genügend Bandbreite vorhanden sein, damit die Daten rechtzeitig gesichert oder repliziert werden können. Cloud-Backups oder replizierte Daten dürfen nicht so viel Bandbreite verbrauchen, dass andere Anwendungen nicht mehr auf ausreichend Bandbreite zugreifen können.

Wie man die Bandbreite verwaltet, hängt davon ab, welche Methode beim Kopieren der Daten in die Cloud angewendet wird. Einige Backup-Lösungen und viele Cloud-Storage-Gateways bieten Funktionen, um den Bandbreitenverbrauch zu planen. Solche Funktionen ermöglichen es, die Gesamtbandbreite, die die Daten kopierende Applikation nutzt, zu begrenzen. Manchmal lässt sich auch dieser Grenzwert bedarfsgesteuert verändern, also zum Beispiel erhöhen, wenn andere Applikationen in der Nacht keine Bandbreite nutzen.

Mit ähnlichem Ziel verwenden viele Organisationen QoS-Mechanismen (Quality of Service), um Bandbreite für Cloud-Backups und andere bandbreitenintensive Dienste zu reservieren. Das stellt sicher, dass jeder internetbasierende Service die benötigte Bandbreite bekommt, ohne zu viel von der vorhandenen Bandbreite zu verkaufen.

Unabhängig von der für den Cloud-basierende Backup- oder Replikationsdienst verbrauchten Bandbreite muss die vorhandene Kapazität effizient verwendet werden, zum Beispiel durch den Einsatz von Daten-Deduplizierung.

Definieren Sie die logistischen Anforderungen

Verwendet Ihr Unternehmen die Cloud nur zum Speichern von Daten, muss nur wenig logistisch geplant werden. Sind jedoch komplette Umschaltvorgänge in die Cloud vorgesehen, dann gilt es einige Aspekte zu berücksichtigen.

Die Logistik muss geplant werden und kann sich im individuellen Fall sehr unterschiedlich gestalten. Das hängt von der Infrastruktur des Unternehmens, dem genutzten Cloud Service und dem gewünschten Endergebnis ab. Doch es gibt einige Aspekte, die alle derartigen Planungen gemeinsam haben.

Erstens beeinflusst die Methode, mit der Daten vom eigenen Rechenzentrum in die Cloud kopiert werden, die logistischen Maßnahmen. Falls eine Public Cloud genutzt wird, basiert der Replikationsprozess höchstwahrscheinlich auf Software. In jedem Fall muss ein Replikationsmechanismus verwendet werden, den der gewählte Cloud Provider unterstützt und der auch kompatibel mit den Ressourcen ist, die repliziert werden sollen.

Weiter ist die Synchronisierung des Active Directory (AD) zu berücksichtigen. Bei Windows-basierten Cluster-Lösungen müssen Cluster-Knoten einer Active-Directory-Domain zugeordnet sein. Dieses Konzept gilt auch für viele andere Fehlertoleranzlösungen von Microsoft (zum Beispiel Datenbank-Verfügbarkeitsgruppen beim Exchange Server), weil diese Technologien auf Failover-Cluster-Komponenten aufsetzen. Das bedeutet: Will man einen Cluster für die Disaster Recovery in die Cloud erweitern, wird man sehr wahrscheinlich auch eine im eigenen RZ gehaltene AD-Domäne in die Cloud ausdehnen müssen.

Die derzeitige Methode dafür unterscheidet sich von Cloud Provider zu Cloud Provider. Bei Windows Azure bietet Microsoft einen Cloud-basierenden Directory-Dienst, das Windows Azure Active Directory. Er kann mit dem Active Directory und dem DNS-Server im Rechenzentrum des Unternehmens synchronisiert werden. Damit die Synchronisierung funktioniert, ist es unabdingbar, dass das Unternehmensnetz und das virtuelle Netz innerhalb von Windows Azure miteinander kommunizieren können. Das lässt sich am einfachsten dadurch erreichen, dass im Unternehmensnetz ein Server für Roting und Remote-Zugriff (oder ein VPN-Server) installiert wird. Windows Azure konfiguriert man so, dass es auf das Unternehmensnetz über ein VPN zugreift.

Weiter muss man daran denken, das Cluster-Quorum richtig zu nutzen. Windows-Faliover-Cluster verwenden das Modell „Majority Node Set“: Für jeden Cluster, der das Quorum behalten, also weiterarbeiten will, bleiben die Hälfte plus ein Closter-Knoten online. Wenn beispielsweise ein Cluster sieben Knoten hat, müssen mindestens vier Knoten funktionieren, damit der Cluster weiterläuft.

Das Konzept ist allerdings problematisch: Windows kann nicht zwischen einem Fehler mehrerer Knoten und einer Unterbrechung des WAN-Links unterscheiden. Steht die Mehrzahl der Knoten im Unternehmensnetz, würde das einen Umschaltvorgang in die Cloud wegen einer ausgefallenen WAN-Verbindung verhindern, aber nicht gegen einen Fehler auf Rechenzentrumsebene schützen, weil eine nicht ausreichende Knotenzahl in der Cloud vorhanden wäre.

Eine weithin verwendete Lösung dieses Problems besteht darin, in der Cloud und im Unternehmensnetz gleich viele Knoten vorzuhalten und den Knoten, der bei Ausfällen über die Mehrheitsbildung entscheidet, an einem dritten Ort zu platzieren. Das stellt sicher, dass eine der beiden Standorte immer ein Quorum bekommt und senkt die Möglichkeit durch fehlerhafte Verbindungen verursachter Umschaltvorgänge. Dabei ist es wichtig, dafür zu sorgen, dass alle drei Standorte so schnell miteinander kommunizieren können, dass sie die Verzögerungsgrenzen von Microsofts Cluster-Technologie unterschreiten.

Replikation virtueller Maschinen

Clustering passt nicht zu jeder Situation und nicht jede Applikation oder jeder virtuelle Server lässt sich clustern. Eine Alternative für Cloud-basierte Disaster Recovery ist in solchen Fällen einfach VMs in die Cloud zu replizieren. Wenn eine Organisation so vorgeht, muss sie die Ziele des Replikationsprozesses festlegen. VM-basierende Replikation kann auf exakte Zeitpunkte bezogene Image-basierende Recovery erstellen und aus gemounteten Cloud-Kopien von VMs Daten extrahieren. Anwender können auf eine Cloud-basierende VM-Replikation umgeleitet werden, wenn das Unternehmensrechenzentrum zusammenbricht.

Sollen Anwender bei Ausfällen auf eine Cloud-basierende VM umgeleitet werden, sind die schwierigsten Themen die Injektion von IP-Adressen und die Veränderung von DNS-Dateien. Damit man sie verwenden kann, brauchen die VMs lokale IP-Adressen im Cloud-basierten Subnetz des virtuellen Netzwerks, in dem sie sich nach einem Umschaltvorgang befinden. Die DNS-Dateien sind so zu verändern, dass der virtuelle Server in der Cloud gefunden werden kann.

Die wichtigen Hypervisor-Anbieter bieten Funktionen für diese Aufgaben und die Umleitung der Anwendern zugeordneten Verarbeitungslasten an. Einige Backup-Lösungen von Drittanbietern haben ähnliche Fähigkeiten, sie ersparen Administratoren die lästige Konfiguration von IP-Addressinjektionen und Veränderungen des DNS.

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

Nächste Schritte

Essential Guide: Alles zu Business Continuity und Disaster Recovery.

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

DR-Test-Pläne mit verfügbaren Technologien optimieren.

Erste Schritte für die Nutzung von Disaster-Recovery-as-a-Service.

Artikel wurde zuletzt im August 2016 aktualisiert

Erfahren Sie mehr über Disaster Recovery

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