filograph - Fotolia

Was ein AWS-Cloud-Disaster-Recovery-Plan enthalten sollte

Wer seine Anwendungen in der AWS-Cloud hat, muss den Disaster-Recovery-Plan entsprechend anpassen. Er unterscheidet sich von üblichen DR-Strategien.

Dieser Artikel behandelt

Disaster Recovery

Unternehmen, die völlig oder in hohem Maße von ihren Cloud-Providern wie zum Beispiel Amazon Web Services abhängig sind, müssen für ihre geschäftskritischen Anwendungen einen umfassenden Cloud-Disaster-Recovery-Plan erstellen und implementieren. Geschieht dies nicht, so können Störfälle wie ein Stromausfall zu Unannehmlichkeiten für die Anwender und zu potenziellem Geschäfts-/Umsatzverlust führen. Es gibt verschiedene Taktiken, mit der man Disaster Recovery für die Public Cloud vereinfachen kann.

Oft kommen Probleme zutage, da manche Unternehmen von einer Verantwortung des Providers ausgehen, die es aber so nicht gibt. Firmen unterschätzen oder vergessen häufig, wie groß die Auswirkungen eines Ausfalls – Downtime – sein können. Darum erstellen sie keine adäquaten Disaster-Recovery-Pläne. Man muss sich die Zeit nehmen, um herauszufinden, welche geschäftskritischen Anwendungen auf lokalen Ressourcen und welche in der Cloud gesichert sind und was passiert mit dem Geschäft, wenn ebendiese Anwendungen ausfallen.

Ebenso sollten Anwender nie die Wichtigkeit eines DR-Tests unterschätzen, nachdem der DR-Plan implementiert wurde. Viele Unternehmen überprüfen nie, ob ein Failover und ein Failback wirklich funktionieren und die aufkommenden Workloads bedienen können. Zu den in-house-Tests gehören unter anderem User Error Recovery, um verlorene Daten zurückzuholen, der Anbindungsverlust zum Standort oder der Stromausfall an einem Standort.

Unternehmen, die ganz auf die Public Cloud angewiesen sind, mögen bei den Testmöglichkeiten etwas eingeschränkt sein, aber in so einem Falle lassen sich Traffic-Failover aufsetzen, um die Antwortzeit von AWS Auto Scaling und deren Performance zu bewerten. Während eines Tests lassen sich auch gut Monitoring- und Fehlermeldungs-Tools ausprobieren. Dabei lässt sich feststellen, ob die Mitarbeiter umfassend informiert sind und Helpdesk-Aufträge richtig erstellt und bedient werden.

DR muss als kontinuierlicher Prozess angesehen werden und nicht als statisches, einmaliges Projekt. Die DR-Strategie sollte mehrfach im Jahr evaluiert werden. Das ist auch ein guter Zeitpunkt, seine DR und die Reaktionszeiten auf unvermeidliche Veränderungen im Unternehmen und der Cloud zu bemessen. Es könnte beispielsweise sein, dass der Provider neue Services, Regionen oder Verfügbarkeitszonen anbietet. Dies können Optionen sein, den Cloud-DR-Plan zu optimieren und dabei das Budget im überschaubaren Rahmen zu halten. Darüber hinaus können sich Compliance-Anforderungen ändern, weswegen die AWS-Region sorgfältig ausgewählt werden muss.

Keine Anwendung ist 24/7 und zu 100 Prozent verfügbar. Telekomanbieter und Public-Cloud-Provider erfahren hin und wieder Unterbrechungen, die in kurzfristigem Service-Verlust enden können. Jedes Unternehmen mit Workloads in der Public Cloud sollte Verfügbarkeitsprobleme antizipieren und entsprechend einen sinnvollen DR-Plan implementieren, um flexibel zu sein und adäquat darauf regieren zu können.

 

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

Artikel wurde zuletzt im Dezember 2015 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Disaster Recovery

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