AWS-Ausfall bringt Thema „Downtime“ in die Schlagzeilen

architecture-1138967_1920Vor wenigen Tagen hatte Amazon Web Services (AWS) einen Ausfall seines S3-Dienstes in der „US-East-1“-Region. Etwa 148.213 Websites waren betroffen. Die gute Nachricht: Die Websites waren in vier Stunden wieder online. Die schlechte Nachricht: Sie waren vier Stunden offline!

„Dies mag für Public-Cloud-Skeptiker ein gefundenes Fressen sein, aber dennoch sind die Vorteile der öffentlichen Cloud zu attraktiv, um wegen eines seltenen Ausfalls von der Nutzung Abstand zu nehmen. Eines der größten Vorteile von Public-Cloud-Architekturen ist die Geschwindigkeit, um Projekte zu realisieren. Die Cloud-Anbieter werden zudem noch härter daran arbeiten, um die Wahrscheinlichkeit für die ohnehin seltenen Ausfälle noch weiter zu reduzieren“, erklärt Thorsten Eckert, Sales Director DACH bei Actifio. „Trotzdem ist dies eine Erinnerung für Unternehmen, sicherzustellen, dass sie eine Redundanz in die Applikations- und Datenebene ihrer IT-Dienste einbauen – egal ob vor Ort oder in der Cloud.“

Werden Produktionsanwendungsdaten in mehreren Regionen gespeichert, besteht die Möglichkeit, bei einem Ausfall in eine andere Region zu wechseln. So können die tatsächlichen Ausfallzeiten der Produktionsanwendung minimiert werden. Die Speicherung einer Kopie in einer entfernten Region verursacht zwar zusätzliche Kosten, aber das ist nun einmal der Preis, der für Redundanz und Verfügbarkeit bezahlt werden muss. Dies beginnt bereits im eigenen Rechenzentrum, wo jedoch nicht immer sämtliche Maßnahmen für Redundanz ausgeschöpft werden. Dies würde zwei redundante Firewalls und Netzwerk-Switches, ein Cluster von Rechenressourcen für geschäftskritische Anwendungen und redundante Datenspeicherung erfordern. Daten sollten zudem für den Katstrophenfall sowohl am eigenen Standort gespeichert als auch in einem  entfernten Rechenzentrum gespiegelt werden.

Überlegungen zur Redundanz in der Cloud sind ebenso entscheidend, um für Cloud-Ausfälle gewappnet zu sein, genauso wie Datenredundanz für intern gehostete Anwendungen erforderlich ist. Es gibt einige Möglichkeiten, wie die Copy-Data-Virtualisierung hier helfen kann.

Netz mit doppeltem Boden: Copy-Data-Virtualisierung

Anwendungsfall 1: Wiederherstellung von Vor-Ort-Produktionsanwendungen in die Cloud

Eine Appliance kann eingesetzt werden, um eine lokale Kopie der Produktionsdaten vor Ort zu sichern und vorzuhalten, um sofortige Wiederherstellungen für den täglichen Betrieb durchführen zu können. Die Appliance kann auch eingesetzt werden für die sofortige Bereitstellung von Daten „as a Service“ für DevOps-, Sicherheits- oder Analytik-Teams. Zur Wiederherstellung in die öffentliche Cloud gibt es verschiedene Möglichkeiten der Replizierung.

Anwendungsfall 2: Inter-regionale Disaster Recovery für Produktionsanwendungen in der Cloud

Die Cloud-basierte Virtualisierungssoftware wird in der gleichen Region betrieben, in der die Produktionsanwendungen laufen. Sie wird eingesetzt, um eine lokale Sicherungskopie in dieser Region zu erstellen und dann in einer anderen Region des gleichen Cloud-Herstellers zu replizieren, z.B. von #AWS Frankfurt nach AWS London. So lassen sich bei einem Ausfall in einer Region die Anwendungen in der zweiten Region schnell wieder verfügbar machen. Dies sorgt für Unabhängigkeit von proprietären Schutzsystemen der Cloud-Infrastruktur und ermöglicht Redundanz, während weiterhin ein einziger bevorzugter Cloud-Anbieter genutzt werden kann.

Anwendungsfall 3: Wiederherstellung von Produktionsanwendungen zu einem anderen Cloud-Anbieter

Wird noch mehr Vorsorge und Schutz vor multiregionalen Ausfällen bei einem einzelnen Cloud-Anbieter gewünscht, besteht die Möglichkeit, einen zweiten Cloud-Anbieter als #Disaster-Recovery-Standort zu nutzen. Wenn beispielsweise die Produktionsanwendung bei #AWS in Irland gehostet wird, könnte eine #Virtualisierungslösung in AWS verwendet werden, um eine lokale Sicherungskopie zu erstellen und diese zu replizieren – oder umgekehrt. Zu beachten gilt es hier, dass Cloud-Anbieter typischerweise für den Datenaustausch, d.h. alle Daten, die die #Cloud verlassen, Gebühren verlangen. Angenommen, es bestehen 30 TByte Daten aus der Produktionsanwendung, mit einer täglichen Datenänderungsrate von 2 Prozent, 50 Prozent Deduplizierung für geänderte Daten und 85 Euro pro TByte für ausgehende Daten: Die monatlichen Kosten, um Daten an einen anderen Cloud-Anbieter zu replizieren, würden dann etwa 765 Euro pro Monat betragen. Dieses Geld müsste investiert werden für die zusätzliche Sicherheit durch #Replikation zwischen zwei Cloud-Anbietern.

„Zusammenfassend lässt sich sagen, dass die Nutzung der öffentlichen Cloud bereits unvermeidlich ist. Immer mehr Unternehmen wollen von der Geschwindigkeit, Agilität und potenziellen Kostenoptimierung profitieren. Widerstand gegen die Nutzung der Cloud ist praktisch zwecklos“, schließt Thorsten Eckert von #Actifio. „Allerdings ist die richtige Mischung aus Architektur, Plattform und Tools erforderlich, um zu gewährleisten, dass Anwendungsdaten sicher geschützt und leicht zugänglich sind, wann immer diese benötigt werden.“

#Netzpalaver