Photobank - Fotolia

Cloud-Disaster-Recovery: Warum die Dokumentation so wichtig ist

Für einen Cloud-DR-Plan muss der Administrator stets die Infrastruktur und die DR-Anforderungen kennen und muss wissen, wie lange ein Failover dauert.

Die Public Cloud stellt zahlreiche Optionen für IT-Abteilungen bereit, um einen Business Continuity/Disaster Recovery zu planen und zu implementieren, ohne dabei das eigene Rechenzentrum erweitern zu müssen. Mit einem Cloud-Recovery-System im Einsatz, kann ein Unternehmen die Cloud als einfaches Daten-Repository oder als Standort nutzen, an dem Anwendungen betrieben werden, wenn das Primärsystem ausfällt.

Wer einen DR-Plan erstellen will, der muss zunächst die Applikationen beachten, die IT-Services bereitstellen und dann festlegen, was geschützt sein muss, wenn es zu einem Ausfall kommt. Dazu sollte der Administrator ein Verzeichnis über alle Anwendungen und Services pflegen, die für den Geschäftsbetrieb notwendig sind. Viele Unternehmen nutzen Server-Virtualisierung, trotzdem müssen auch physische Server nach wie vor Beachtung finden. Ein umfassender Cloud-DR-Plan sollte folgendes enthalten respektive dokumentieren.

  • Physische und virtuelle Server, die die Infrastruktur bereitstellen. Dazu können Active-Directory-Server, DNS/DHCP-Server und Anwendungen gehören.
  • Physische Server, die Applikationen zur Verfügung stellen. Es gibt verschiedene Gründe, Anwendungen noch immer auf physischen Servern zu betreiben. Das können Skalierungspotenziale, Performance-Anforderungen oder der Einsatz spezieller Hardware und Betriebssysteme sein. Ein Cloud-Recovery-Service kann die Möglichkeit bieten, diese Elemente zu virtualisieren.
  • Physische Server, die Anwendungen bereitstellen. Es kann durchaus vorkommen, dass Dutzende und Hunderte virtueller Maschinen genutzt werden, um Applikationen zu implementieren. Jede von ihnen muss identifiziert und inventarisiert werden, inklusive Storage, Memory und Anforderungen des virtuellen Prozessors.

Ebenso sollte der Administrator die Infrastrukturserver frühzeitig bestimmen, da diese Systeme nach einem Problemfall als erstes wiederhergestellt werden oder betriebsbereit sein müssen. Es ist möglich, AD-, DNS- und DHCP-Services vorzukonfigurieren, so dass sie in der Cloud betrieben werden können und eine Synchronisation mit den lokalen, äquivalenten Systemen erfahren. Das vereinfacht den DR-Prozess, der sich dadurch auch schneller implementieren lässt.

Genauso wichtig ist die Netzwerkkonfiguration, um Cloud-DR erfolgreich umzusetzen. As bedeutet, sich mit den gegenseitigen Abhängigkeiten der Anwendungen auf Netzwerkebene auseinanderzusetzen. Dazu gehören beispielsweise Security- und Firewall-Konfigurationen. Hierfür sollte sich der IT-Manager folgende Fragen stellen:

  • Sind irgendwelche Anwendungen oder Server abhängig voneinander in Sachen Latenz?
  • Gibt es Ost-West-Firewall-Regeln, um den Onsite-Traffic zu verwalten?
  • Was sind externe Bandbreitenanforderungen für Anwendungen, die sich an Endkunden richten?

Cloud-Recovery-Anforderungen bestimmen

Es ist nicht sinnvoll anzunehmen, dass jede Anwendung sofort wiederhergestellt werden muss, wenn es zu einem Ausfall kommt. Stattdessen sollten Applikationen priorisiert werden, je nachdem wie schnell welche Anwendungen, Systeme und Daten wieder betriebsbereit sein müssen. Es gibt zahlreiche Standard-Metriken, die sich für die Festlegung von SLAs für Anwendungs-Recoverys nutzen lassen:

  • Recovery Time Objectiv (RTO). Dieser Begriff beschreibt die tolerierbare Ausfallzeit, bevor die Anwendung wieder betriebsbereit ist, üblicherweise in Minuten oder Stunden angegeben. Ein RTO-Wert von Null bedeutet keine Ausfalltoleranz, während ein RTO-Wert von einer Stunde heißt, dass die Anwendung innerhalb einer Stunde (vom Beginn des Ausfalls an gezählt) wieder verfügbar sein muss.
  • Recovery Point Objective (RPO). Diese Einheit gibt an, wie viele Daten maximal verloren gehen können, bis die Anwendung wieder verfügbar ist, ohne dass der Geschäftsbetrieb beeinträchtigt wird. Ein RPO-Wert von Null besagt, dass alle Daten bis zum Zeitpunkt des Desasters wiederhergestellt sein müssen. Ein RPO von 24 Stunden bedeutet, dass die Anwendung bis zu 24 Stunden an Daten (vor dem Ausfall) verlieren kann.
  • Service-Level Objective (SLO). SLOs bestimmen das Ziel der gesamten Anwendungswiederherstellung. So kann ein SLO zum Beispiel bestimmen, dass 90 Prozent der Applikation innerhalb von 90 Prozent wiederhergestellt sein müssen. Ein enger gefasstes SLO benötigt mehr Infrastruktur und mehr IT-Angestellte, so dass mehr Flexibilität helfen kann, DR-Kosten besser zu managen.

SLOs erlauben eine Priorisierung der Daten- und Applikations-Werte. So hat ein Kreditkartenverarbeitungssystem beispielsweise ein RPO von Null und sehr geringe RTO. Man kann erwarten, dass diese Systeme keine Daten verlieren. Am anderen Ende kann bei Reporting-Applikationen toleriert werden, dass sie 24 bis 48 Stunden ohne Daten sind, da sie ihre Informationen aus anderen Anwendungen extrahieren. Andere Systeme liegen irgendwo zwischen diesen beiden Extremen.

Um die richtigen Cloud-Recovery-Anforderungen zu bestimmen, muss der Admin mit den Applikations-Inhabern (Owner) reden, da sie genau einschätzen können, wie wichtig ihre Anwendung ist. Geschäftsführer vermuten oftmals, dass alle Anwendungen wichtig sind, bis sie die Kosten für eine solche Recovery-Strategie sehen. Hier empfiehlt sich eine Kostenbewertung.

Ein weiteres Kriterium für die SLOs: strenge Anforderungen wie ein RPO von Null kann aufgrund der Latenzen zwischen dem lokalen Standort und der Cloud nicht mit einem Cloud-basierten DR umgesetzt werden. Diese Applikationen müssen eventuell aus dem Cloud-DR herausgenommen und mit einem anderen DR-Produkt bedient werden.

Wie lange der DR-Service in Betrieb ist

Zusätzlich zum oben genannten muss auf jeden Fall dokumentiert werden, wie lange der DR-Service in der Public Cloud betrieben wird. Das hängt allerdings oft von der Art des Desasters oder der Störung ab. Nicht alle Störfälle resultieren in einem Totalausfall der lokalen Ressourcen. Hier sollte eine Skala verschiedener Störungstypen dokumentiert werden, zum Beispiel folgende:

  • Serververlust. Entweder fällt hier ein physischer oder ein Host-Server für VMs aus. Den Host eines virtuellen Servers zu verlieren, heißt häufig, dass nur einige und nicht alle Anwendungen in der Cloud betrieben werden müssen.
  • Ausfall mehrerer Systeme. Mehrere Anwendungen stehen nicht mehr zur Verfügung, wenn zum Beispiel ein Shared-Storage-Array ausfällt.
  • RZ-Ausfall. Im schlimmsten Falle fällt das gesamte Rechenzentrum aus oder kann nicht mehr adressiert werden. Dann müssen alle Services im DR-Modus betrieben werden.

In einigen Szenarien müssen Services für einige Stunden oder Tage verschoben werden. Geht ein gesamter Standort verloren, so kann es sein, dass die DR-Services für Wochen oder Monate in der Cloud betrieben werden, bevor alle Systeme und Daten wiederhergestellt sind. Cloud-Services werden für die Zeit berechnet, die sie in der Cloud aktiv betrieben werden, was ebenso ein wichtiger Faktor ist, den es zu beachten gilt.

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

Artikel wurde zuletzt im April 2016 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Public Cloud

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