Große Clouds als Modell für RZ-Redundanz

Vielleicht kann man IT-Ausfälle mit krankheitsbedingten Personalausfällen vergleichen. Laut der Zeitung Rheinische Post führen Arbeitsausfälle zu beträchtlichen Produktionseinbußen. Rheinische Post zitiert eine unveröffentlichte Studie des Verbands der forschenden Pharma-Unternehmen (VfA) mit den Worten: „Ohne die überdurchschnittlichen Krankentage wäre die deutsche Wirtschaft gewachsen… Anstelle einer milden Rezession – das deutsche Bruttoinlandsprodukt ist im vergangenen Jahr um 0,3 Prozent geschrumpft – hätte es im Jahr 2023 einen Zuwachs von knapp einem halben Prozent gegeben.“ Krankheitsausfälle treffen gemäß der Studie die Industrie härter als Firmen in Dienstleistungsbereichen. Denn in der Industrie bestünden geringere Spielräume, Arbeitsausfälle durch kurzfristige Anpassungen in der Qualität der Produkte aufzufangen. Dagegen könnten Personalengpässe in der Gastronomie zum Beispiel mit etwas längeren Wartezeiten aufgefangen werden.

Wenn man gemäß der vereinfachten Berechnung von 400.000 Euro Verlust pro Stunde IT-Ausfall bei einem Unternehmen mit einer Milliarde Euro Umsatz pro Jahr ausgeht, folgt daraus, dass jede Maßnahme, die jährliche IT-Ausfälle um eine Stunde verringert, bis 400.000 Euro pro Jahr kosten darf. So kann ein Unternehmen eine einfache Rechnung anstellen: Reduziert die Umstellung auf Cloud Computing jährliche IT-Ausfälle um eine Stunde, darf die Cloud-Nutzung jährlich maximal 400.000 Euro mehr kosten. Man sehe mir auch diese sehr vereinfachte Berechnung nach. Es geht mir nur um ein Gedankenspiel.

Nun ist die vollständige Umstellung auf Cloud Computing für viele Unternehmen gar nicht realisierbar. Denken Sie bitte an die in der VfA-Studie besonders hervorgehobene Industrie. Für industrienahe IT ist die Cloud einfach zu weit weg und damit latenzbedingt nicht schnell genug. Automatische Steuerung vieler industrieller Abläufe aus der Cloud kann ich mir nicht vorstellen. Auch andere Aspekte wie datenschutzrechtliche Erwägungen können ein Unternehmen veranlassen, OnPrem-IT zu betreiben.

OnPrem-IT kann jedoch von Cloud-IT lernen, was Maßnahmen für Hochverfügbarkeit (High Availability, HA) angeht. In den großen Clouds gibt es HA-Mechanismen auf verschiedenen Ebenen. Innerhalb einer Metro-Region wie Frankfurt betreiben Cloud-Provider unterschiedliche Availability Zones (AZ). Eine AZ entspricht einem RZ-Standort mit eigener Stromversorgung, Klimatisierung, Zugangssicherung und sonstigen Standortressourcen, die von Ressourcen anderer AZs unabhängig sind. Die AZs sind über Glasfasern miteinander verbunden. Da sie sich in einer Metroregion befinden, ist die Synchronisation von Daten zwischen den AZs einer Metroregion möglich. So können Sie einen Datenbank-Service in einer Cloud-Region vorsehen, die mit synchroner Replikation zwischen Datenbank-Instanzen in verschiedenen AZs angeboten wird.

Das entspricht der sogenannten Betriebsredundanz, wie sie im BSI-Dokument namens „Kriterien für die Standortwahl von Rechenzentren“ beschrieben wird. Bei der Betriebsredundanz hat Datenkonsistenz vor „Schutzwirkung durch Abstand“ Vorrang, d.h. vor Absicherung eines RZ-Verbunds vor regionalen Großschäden, die eine ganze Metroregion betreffen können. Davor kann die sogenannte Georedundanz schützen, die vom BSI mit einer Mindestentfernung von 200 km zwischen RZ-Standorten (in begründeten Ausnahmen 100 km) spezifiziert wird.

In großen Clouds gibt es auch die Georedundanz. Sie wird durch die Nutzung verschiedener Cloud-Regionen realisiert, zum Beispiel in Frankfurt und Dublin. Die Umstellung von einer Region auf die andere kann dabei mittels einer anderen Namensauflösung per DNS (Domain Name System) erfolgen, am besten automatisiert. So kann ein Global Server Load Balancer (GSLB) im Normalfall DNS-Anfragen nach einem für eine Applikation als Front End genutzten Webserver mit IP-Adressen der Frankfurter Region beantworten und dabei den Dienst in Frankfurt permanent überwachen. Auf dessen Ausfall reagiert der GSLB so, dass er DNS-Anfragen für den ausgefallenen Dienst fortan mit IP-Adressen in Dublin beantwortet. Der GSLB selbst kann der für die betreffende DNS-Zone autoritative DNS-Server sein (d.h. der DNS-Server, der nicht andere DNS-Server fragen muss, sondern selbst antwortet). Er kann georedundant in Frankfurt und Dublin oder auch an anderen Standorten positioniert werden.

Auch das Georedundanzmodell der Cloud ist in eigenen RZs eines Unternehmens realisierbar. Georedundanz stellt sicher, dass ein Dienst bzw. eine Applikation auch bei Ausfall von zwei betriebsredundanten RZs verfügbar bleibt. Voraussetzung ist, dass die Daten zwischen georedundanten RZs repliziert werden. Wenn das entfernungsbedingt nicht synchron möglich ist, dann eben asynchron. Abhängig von der Häufigkeit asynchroner Replikationen kommt es beim Schwenk von einem RZ zum anderen zu einem partiellen Datenverlust, der jedoch für bestimmte Anwendungen besser sein kann als der vollständige Ausfall.

Der redundante Betrieb der ganzen für eine Anwendung notwendigen Gruppe von Ressourcen in verschiedenen Rechenzentren kann nicht nur bei hoffentlich seltenen regionalen Großausfällen helfen, sondern auch bei technischen Problemen, die gleichzeitig zwei RZs betreffen. Man denke etwa an einen durch einen Software-Fehler verursachten Netzausfall, der sich auf beide RZs auswirkt. Wenn das georedundante RZ von diesem Ausfall verschont bleibt, kann der Applikationsbetrieb dort weitergehen.

Natürlich ist die doppelte Absicherung durch Georedundanz und Betriebsredundanz teuer, doch ist der komplette IT-Ausfall manchmal noch teurer, wie das eingangs skizzierte Beispiel mit 400.000 Euro Schaden pro Stunde zeigt.

Was man von großen Clouds und Providern lernen kann, gehört neben einigen anderen sehr spannenden Themen zu den Inhalten, die auf unserer Sonderveranstaltung Netze behandelt werden.