In professionellen Umgebungen stellt Ausfallsicherheit ein sehr wichtiger Aspekt dar. Dieser versucht die Verfügbarkeit eines Objekts, dies kann beispielsweise ein Server oder ein Dienst sein, konstant bereitzustellen. Im Idealfall kann 100% Verfügbarkeit, also das Ausbleiben jeglichen Ausfalls, erreicht werden. Um dies mit grösstmöglicher Zuverlässigkeit gewährleisten zu können, müssen jedoch verschiedene Vorkehrungen getroffen werden.

Stabilität als Grundlage

Einerseits muss die intrinsische Stabilität der Komponente gewährleistet werden können. Sie muss also im täglichen Betrieb zuverlässig agieren und reagieren können. Ein Webserver muss beispielsweise mit den üblichen HTTP-Anfragen zurechtkommen. Zusätzlich muss aber ebenfalls die Zuverlässigkeit der Schnittstellen zu anderen Komponenten, zum Beispiel weiterführende Datenbank-Zugriffe auf das Backend, gegeben sein.

Es gibt jedoch immerwieder Situationen, in denen diese Stabilität nicht mit absoluter Stetigkeit erreicht werden kann. Dies ist vor allem dann mindestens auf theoretischer Ebene möglich, wenn unvorhergesehene Ereignisse eintreffen. Dies können beispielsweise auf Software-Ebene deformierte HTTP-Anfragen eines böswilligen Benutzers sein. Es kann sich aber auch nur um fehlerhafte Datensätze einer korrupten Datenbank handeln. Viel schlimmer und permanenter sind hingegen Hardware-Fehler, die sehr schnell zum kompletten Ausfall eines Systems führen können.

Redundanz erhöht Verfügbarkeit

Um diesen unerwarteten Situationen gerecht werden zu können, wird versucht mittels redundanten Komponenten das gewünschte Mass an Ausfallsicherheit wiederherstellen zu können. Dabei werden jene Komponenten, die das Risiko eines Ausfalls mit sich bringen, mehrfach verfügbar gemacht. Beispielsweise können zwei Internet-Anbindungen vorhanden sein, um im Fall von Problemen mit Anbindung 1 auf Anbindung 2 zu wechseln.

Redundante Komponenten können dabei in verschiedenen Betriebsmodi vorhanden sein. Werden beispielsweise zwei Festplatten als RAID-1 eingesetzt, können die Daten auf diese zeitgleich geschrieben werden. Ist ein Ausfall einer Platte gegeben, kann nun ganz auf die Daten der anderen Platte zugegriffen werden. Es befinden sich hier beide Platten stets im Betrieb und die Übernahme des Dienstausfalls geschieht unverzüglich. Dies ist Teil des Failover und wird Hot-Standby genannt.

Der Betrieb einer Komponente, vor allem beim Mütführen von viel Mechanik oder Elektronik, verringert zwangsweise die Lebensdauer eben dieser. Aus diesem Grund werden mancherorts redundante Komponenten nicht zeitgleich betrieben, sondern stehen im Fall eines Ausfalls als Ersatz bereit. Jenachdem muss die neue Komponente manuell in den Betrieb eingeführt werden. Beim Beispiel der Festplatten könnte dies das Einspielen des Backups voraussetzen, wodurch eine gewisse Ausfallzeit einberechnet werden muss. Dies wird als Cold-Standby bezeichnet.

Missverständnis im Cloud Computing

Im Zusammenhang mit Cloud Computing wird eben diesem immerwieder die vielgewünschte und schwierig zu gewährleistende Hochverfügbarkeit angedichtet. Es wird behauptet, dass in der Cloud keine Daten verloren bzw. Dienste ausfallen können, da sich diese stetig und in dynamischer Weise neu organisieren kann. Diese Deklaration ist jedoch nicht per se zu beobachten. Die Ausfallsicherheit innerhalb einer Cloud ist dabei den gleichen Gesetzen unterworfen, wie bei jedem anderen Rechenzentrum auch: Auch hier müssen die jeweiligen Komponenten redundant betrieben werden.

Gerade Dienstleistungen im PaaS/IaaS-Bereich (z.B. Amazon EC2) warten mit verteilten Rechenzentren auf. Ob diese jedoch effektiv redundant betrieben und darin ebenfalls redundante Komponenten enthalten sind, lässt sich damit nicht automatisch bejahen.

Beispielsweise war beim Ausfall von Amazon EC2 im April 2011 (Technische Analyse) ein Routing-Fehler verantwortlich, der zur Überlastung geführt hat und damit die Synchronisation der EBS-Nodes (Elastic Block Store) unterbrochen war. Ironischerweise also gerade jener Mechanismus, der die Verteilung zur Erreichung der Redundanz ermöglichen sollte, zeichnete sich für den Ausfall verantwortlich. Da aufgrund einer Race Condition keine Schreibzugriffe mehr durchgeführt werden konnten, gingen Daten unwiederruflich verloren. Zu einem Problem ähnlichen Ausmasses hat im August des gleichen Jahres ein Unwetter geführt (Zeitlicher Ablauf).

Fazit

Das redundante Betreiben kritischer Komponenten zur Erhöhung der Ausfallsicherheit ist unabdingbar. Dies setzt jedoch ein durchdachtes Konzept voraus, welches die Wichtigkeiten und Abhängigkeiten der Komponenten untereinander berücksichtigt.

Gerade das Beispiel der Zwischenfälle in Amazon EC2 zeigt auf, dass Ausfallsicherheit nicht einfachso erreicht werden kann. Und auch wenn diese erreicht scheint, gibt es – solange nicht jede Komponente mehrfach und unabhängig betrieben wird – stets die Möglichkeit eines Ausfalls.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://aws.amazon.com/message/65648/
• http://blog.rightscale.com/2011/04/25/amazon-ec2-outage-summary-and-lessons-learned/
• http://techcrunch.com/2011/08/08/amazon-ec2-outage/
• https://forums.aws.amazon.com/thread.jspa?threadID=73428