Fehlertolerantes Design

Dabei ist – nüchtern betrachtet – eigentlich nichts Besonderes passiert. Für Dienste gleich welcher Art braucht es in letzter Konsequenz Hardware, sowohl Server als auch Infrastruktur wie Switches, Router und nicht zuletzt eine gute Stromversorgung und entsprechende Klimatisierung. All diese Komponenten können ausfallen, weshalb sie möglichst ausfallsicher ausgelegt sein müssen, auch und gerade in einer Wolke, egal ob Private, Hybrid oder Public.

Cloudanbieter leisten sich aufgrund ihrer Größe aber deutlich aufwändigere Ausfallsicherheitskonzepte als ein kleines Unternehmen. Welches Kleinunternehmen kann für die von seiner IT angebotenen Dienste eine Verfügbarkeit von 99,95 Prozent zusichern, so wie dies Amazon verspricht? [9]

George Reese beschreibt in [10], dass der Ausfall nicht einen grundsätzlichen Designfehler im Cloudkonzept entlarvt, sondern einen Architekturfehler auf der Nutzerseite, also beim Einsatz von Clouddiensten. So sollte wie bei allen verteilten Systemen Verständnis dafür vorhanden sein, dass Ausfälle einfach dazugehören. Ein fehlertolerantes Design (Design for Failure) ist Pflicht.

Das ist teilweise auch schon bei einem einzelnen Anbieter wie Amazon möglich, wenn der Kunde Systeme an mehreren Standorten bucht. Amazon bietet beispielsweise fünf Standorte in über den Globus verteilten Zonen an. Aber hier beginnt schon die Verantwortung der Cloudnutzer: Sie müssen die Redundanz in der Wolke schaffen, indem sie in ihrer IT-Architektur Clouddienste als unsicher klassifizieren und entsprechende Ausweichmöglichkeiten im Fehlerfalle einplanen.

Ebenfalls eine verbreitete Ursache für derart fehleranfällige Architekturen ist der so genannte Vendor-Lock-in. Nicht nur aus Kostendruck, sondern auch durch vom Hersteller gewollt inkompatible Technologien sehen sich viele Unternehmen gezwungen, nur einen Cloudanbieter zu nutzen. Das liegt beispielsweise an Management-Tools, die nur für einen Dienst ausgelegt sind, und reicht bis zu Dateiformaten. Vor allem bei einem Anbieterwechsel, aber auch beim Zurück auf eigene Systeme, stellen sich hier große Hindernisse in den Weg.

Schritt für Schritt in die eigene Cloud

Die Auswahl eines Cloudpartners – beziehungsweise sinnvollerweise mehrerer – muss deshalb mit der Ermittlung der unternehmenskritischen Daten und Dienste und einer entsprechenden Risikoabschätzung beginnen. Meist verdienen hier die rechtlichen Rahmenbedingungen ein besonderes Augenmerk.

Die Klassifikation in Tabelle 1 hilft bei der Auswahl der Dienste, die für die Wolke – ob Private oder Public – in Frage kommen. Im nächsten Schritt ist zu prüfen, welche Anbieter sich eignen. Dabei spielt vor allem dessen Standort und der seiner genutzten Systeme eine Rolle, wobei Reputation und Zertifizierungen die Vorauswahl erleichtern. Danach sind entsprechende Verträge auszuarbeiten, die SLAs auszuwählen, Zuständigkeiten und Rechte des Anbieters widerspruchsfrei zu definieren.

Tabelle 1: Strategieplaner Cloud Computing

Eine längere Testphase, sinnvollerweise mit Dummydaten, untersucht die Qualität der erbrachten Leistungen, die getroffenen Zusagen, die generelle Akzeptanz der Lösung und die Umsetzbarkeit von Notfallkonzepten. Erst nach eingehender Prüfung sollten Produktivdaten in der externen Wolke landen.