Georedundanz-Regeln aus der Sicht eines Kolokateurs

Die Konzepte für (Geo-)Redundanz ändern sich

| Autor / Redakteur: Ariane Rüdiger / Ulrike Ostler

Georedundante Rechenzentren müssen jetzt nach BSI-Regeln 200 km auseinanderliegen
Georedundante Rechenzentren müssen jetzt nach BSI-Regeln 200 km auseinanderliegen (Bild: gemeinfrei Pixabay / Pixabay)

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.

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.

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

Nachgefragt: Die Empfehlungen für Georedundanz

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

01.03.19 - Unter Co-Location-Anbietern und Rechenzentrumsbetreibern generell sorgt die BSI-Empfehlung für Datacenter, die eine Tier 3-, Tier-4-Zertifizierung beziehungsweise einen entsprechend sicheren Betrieb anstreben, eine 200-Kilometer-Distanz einzuhalten, um Georedundanz herzustellen, für Aufregung. Immerhin bedeutet das zum vorher empfohlenen Sicherheitsabstand eine Erhöhung um das 40fache. DataCenter-Insider hat beim BSI nachgefragt. lesen

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.

"Viele kleinere Unternehmen werden sich für Georedundanz Provider-Partner aus der Nähe suchen", Klaas Mertens, Global Solutions Architect, Equinix
"Viele kleinere Unternehmen werden sich für Georedundanz Provider-Partner aus der Nähe suchen", Klaas Mertens, Global Solutions Architect, Equinix (Bild: 2014 Frank Fennema)

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.

Georedundante Rechenzentren brauchen 200 km Abstand

BSI zur Georedundanz

Georedundante Rechenzentren brauchen 200 km Abstand

30.01.19 - Im Dezember 2018 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Version 1.0 der „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“ herausgegeben. Es geht dabei um ein oder mehrere Ausweich-Datacenter als Maßnahme zur Notfallvorsorge. Also um die Überlegung, ob und wie ein solches möglichst den gesamten zentralen IT-Betrieb übernehmen kann, sollte das jeweils andere nicht voll funktionsfähig sein. lesen

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.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45958582 / Risk Management)