Georedundanz-Regeln aus der Sicht eines Kolokateurs Die Konzepte für (Geo-)Redundanz ändern sich

Das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat eine neue Richtlinie zur Standortwahl höchstverfügbarer und georedundanter Rechenzentren erlassen. Dabei wird Georedundanz strenger definiert.

Anbieter zum Thema

Dell GmbH

Vogel IT-Medien GmbH

FTAPI Software GmbH

Equinix (Germany) GmbH

Für uns sprach Ariane Rüdiger mit Klaas Mertens,Global Solutions Architect beim Co-Location-Anbieter Equinix. Ein wichtiges Thema war bei dem Gespräch, wie sich die neuen Regeln auswirken.

Nachgefragt: Die Empfehlungen für Georedundanz

BSI-Kriterien für Redundanz-Datacenter - Ist das Bundesamt übers Ziel hinausgeschossen?

Was bedeuten die neuen Bestimmungen im praktischen Datacenter-Alltag?

Klaas Mertens: Man muss sehen, dass das BSI mit dieser Richtlinie nichts Revolutionäres tut. Denn eigentlich bewegen sich die verschiedenen Komponenten einer IT-Infrastruktur durch den Trend zur Cloud-Nutzung sowieso auseinander. Es gibt hier das oder Unternehmensrechenzentrum und dort die unterschiedlichen Cloud-Provider, von denen dasselbe Unternehmen Teile seiner IT bezieht – meistens ohne große Berücksichtigung von Entfernungen.

Können Betriebsmodelle also unverändert bleiben?

Klaas Mertens: Das kommt darauf an. Wenn ein Unternehmen bisher Hochverfügbarkeit, Disaster Recovery und Backup dadurch gemeinsam gestemmt hat, dass man in wenigen Kilometern Entfernung ein zweites Rechenzentrum betreibt und zwischen den Datacenter symmetrisch spiegelt, muss sich das sicher ändern. Aber diese Konzepte funktionieren bei der Nutzung von Cloud-Computing sowieso nicht. Vielmehr geht es in Zukunft vor allem um die Verfügbarkeit von Anwendungen, nicht mehr so sehr um die von physischer Infrastruktur.

Was bedeutet das konkret?

Klaas Mertens: Man muss sich entsprechende Gesamtkonzepte überlegen. Hochverfügbarkeit lässt sich vielleicht auch vor Ort realisieren, zum Beispiel durch das Aufsetzen von Systemen in verschiedenen Brandzonen desselben Gebäudes oder in benachbarten Gebäuden. Hier geht es ja meist um das Abfangen menschlicher Fehler, beispielsweise zieht jemand aus Versehen ein Kabel oder löscht eine Datei.

Solche Dinge passieren auch bei Providern. So wurde vor kurzem ein großer Ausfall bei AWS verursacht, weil ein Mitarbeiter versehentlich 30.000 statt 3.000 virtuelle Maschinen löschte.

Und die Disaster Recovery?

Klaas Mertens: Wirkliche Schadensgroßereignisse lassen sich nur durch eine ausreichend weit entfernte Ersatzressource auffangen, also etwa Brände, Überschwemmungen oder größere Stromausfälle.

Unter solchen und ähnlichen Umständen funktioniert aber eine synchrone Spiegelung nicht mehr, denn dazu braucht man sehr kurze Latenzen. Und es ist auch durchaus eine Überlegung, ob ich dann für Disaster Recovery eine noch größere Distanz wähle. Ich könnte etwa in ein anderes europäisches Land gehen.

Dann würde man nur noch minütlich synchronisieren und im Zweifel bei einem wirklichen Schadensgroßereignis auch mal den Verlust der Daten aus 10 oder 15 Minuten in Kauf nehmen. So etwas könnte in einer Situation beispielsweise mit einem großflächigem Stromausfall oder bürgerkriegsähnlichen Unruhen in einem Land die bessere Lösung sein als sich auf eine räumlich nähere Ressource zu verlassen.

Nun gibt es in Deutschland durchaus viele regional aktive Anbieter von IT-Services. Sollen die ihr Ausfall-Datacenter auch ins Ausland legen?

Klaas Mertens: Viele werden wohl Backup und gegebenenfalls auch DR zu einem Cloud Provider in die Nähe, etwa aus Frankfurt legen können, wenn sie die 200-Kilometer-Regel einhalten wollen.

Was gibt es sonst noch bei der Desaster-Vorsorge im Zeitalter der Cloud zu berücksichtigen?

Klaas Mertens: Im Cloud-Zeitalter denkt ja jeder, alles wäre nur noch Software. Doch so ganz stimmt das auch nicht. Denn die Software muss ja irgendwo laufen. Bei Wells Fargo hatte man bei einem Ausfall des Primärrechenzentrums zwar ein Redundanz-Rechenzentrum und auch alle Daten gerettet, doch dann konnte man die Systeme nicht entsprechend schnell hochfahren. Man muss also darauf achten, dass am Redundanzstandort auch tatsächlich Systeme sind, die sofort hochfahren können und diese Abläufe regelmässig testen.

BSI zur Georedundanz

Georedundante Rechenzentren brauchen 200 km Abstand

Was bedeuten Trends wie Modularisierung und Mikroservices für das DR- und Backup-Thema?

Klaas Mertens: Tatsächlich bedeutet die Kommunikation von Apps und Services untereinander und deren Zugriff auf Datenressourcen häufig eine Herausforderung, die mit den modernen Technologien, die IT stärker modularisieren, einhergeht. Denn wenn Apps miteinander sprechen müssen, geht es oft um 1 bis 2 Millisekunden – 200 Kilometer machen aber schon eine Verzögerung von 5 bis 10 Millisekunden aus. Hier muss man sich also genau überlegen, wo man was hinlegt.

Wie müssen solche Infrastrukturen konzipiert werden?

Klaas Mertens: Entweder muss man dafür sorgen, dass Apps, die miteinander sprechen sollen, mit Verzögerungen klarkommen, oder man muss sie so dicht beieinander platzieren, dass keine Verzögerungen entstehen. Noch wichtiger ist aber die Platzierung der Daten, sowohl der primären als auch der gesicherten.

Denn was nutzt es, wenn die App irgendwo wieder hochfährt, Datenzugriffe aber zu lange dauern? Man sollte Module immer so entwickeln, dass sie möglichst wenig auf externe Komponenten angewiesen, also relativ autark sind.

Wie sieht es mit den Daten aus?

Klaas Mertens: Daten kann man in ein großes Repository tun, auf das alle Zugriff haben, statt sie in verschiedene Silos zu verteilen, was im Zweifel zu Zugriffsproblemen führen kann. Aber man muss sich sehr gut überlegen, wohin man dieses Repository legt. Im Zweifel ist es oft einfacher, die Apps zu den Daten respektive den gesicherten Daten zu bringen als umgekehrt. Das liegt ganz einfach an den Volumina, die zu bewegen sind.

(ID:45958582)