Hochverfügbarkeit und Geo-Redundanz: Rechenzentren auch über große Entfernung absichern

München, Starnberg, 19. Dez. 2019 - Die Entfernung zwischen georedundanten Rechenzentren soll mindestens 200km betragen; so empfiehlt es das BSI seit diesem Jahr…

Zum Hintergrund: Der neue Mindestabstand, den das BSI (Bundesamt für Sicherheit in der Informationstechnik) seit Dezember 2018 zwischen sich Georedundanz gebenden Rechenzentren empfiehlt, liegt bei >200KM. Wer eine „kritische Infrastruktur“ betreibt (1), ist laut Gesetzgeber dazu verpflichtet, diese „angemessen zu schützen“. Aber wie sieht es in der Realität aus? Rechenzentren sind meist über synchrone Spiegel abgesichert, um einem Katastrophenfall vorzubeugen. Dieses Modell funktioniert wegen der mit dem Abstand steigender Latenzen in der Regel meist nur bis zu einer Entfernung von gut 35 Kilometer.

Wer Rechenzentren über längere Entfernung oder in die Cloud absichern will, benötigt somit andere Vorgehensweisen und Verfahren. Johan van den Boogaart von Zerto, einem Spezialisten für Disaster Recovery (DR) und Business Continuity (BC) Strategien, gibt in unserem nachfolgenden Beitrag dazu drei praxiserprobte Empfehlungen / Kommentare hinsichtlich der entstandenen Problematik.


+++ Anmerkung: als angemeldeter Benutzer dieser Webseite können Sie den Vortrag von Zerto, gehalten während unserer letzten Anwendertagung in Frankfurt hier frei herunterladen! Das PDF gibt Ihnen einen zusätzlichen detaillierten Überblick zu Lösungsszenarien und den dazu verwendeteten Technologien +++


Die geringe Distanz von fünf Kilometern zwischen georedundanten Rechenzentren erlaubte es Betreibern bislang, ihre Rechenzentren über HA-Systeme synchron zu spiegeln; das ist bei einem Abstand von 200km aber nicht mehr möglich: Die Latenz ist dann einfach zu groß, um mit traditionellen Hochverfügbarkeits- und Backup-Lösungen gegen Systemausfälle vorzubeugen.

Was können Unternehmen tun, um ihre IT etwa gegen logische Fehler oder Ransomware-Attacken abzusichern, um minimalen Datenverlust und kurze Ausfallzeiten zu garantieren?

Der neue Mindestabstand, den das BSI empfiehlt, stellt die Nutzung synchroner Spiegelung infrage und hat damit einen direkten Einfluss darauf, wie Rechenzentren hierzulande betrieben werden. Wer Teil eines Branchenverbandes ist, welcher den Empfehlungen des BSI folgt, wie z.B. Mitglieder der Bankenbranche Bafin, hat keine Wahl: der Abstand ihrer Rechenzentren muss bei mindestens 200km liegen.

BSI-Empfehlung hat direkte Folgen für BC/DR

Folgt man der Argumentation von Johan van den Boogaart, hat die Empfehlung jedoch weiterreichende Folgen als nur in weiter entfernte Rechenzentren zu investieren. Zitat: "Unternehmen müssen aufgrund der neuen Distanz ihre genutzten Technologien für BC/DR überdenken, die aufgrund der neuen Rahmenbedingungen jetzt nicht mehr funktionieren. Um VMs zukünftig mit minimalem Performanceverlust und geringen RPOs zu schützen, müssen Unternehmen nun nach einer neuen Methode suchen und ihre DR- und Backupstrategien entsprechend anpassen. Ein wichtiger Baustein der bisherigen Strategie funktioniert aufgrund der neuen Distanz nicht mehr: Synchrone Spiegelung."

Neuer Standort und neue BC/DR-Strategie?

Im Allgemeinen liegen georedundante Rechenzentren bisher zwischen fünf und 35 Kilometer auseinander. Dies sind keine zufällige Marken. Fünf Kilometer war der bisher empfohlene Mindestabstand und bei circa 35 Kilometer ist die Latenz noch ausreichend gering, um synchron zu spiegeln. Bei größeren Unternehmen liegen die sich gegenseitig absichernden RZ oft sogar am gleichen Standort, nur getrennt durch mindestens einen Brandabschnitt. Kleinere Unternehmen sichern oft in ein RZ eines Partners in unmittelbarer Nähe. So können die Systeme jeden Schreibvorgang replizieren und bestätigen, bevor jede I/O geschrieben wird.

Dies ist für schreibintensive Applikationen wie etwa SQL- und SAP-Datenbanken eine Grundvoraussetzung. Über 200km ist es jedoch nicht mehr möglich, eine entsprechend niedrige Latenz zu erreichen. Damit stehen Unternehmen jetzt vor gleich zwei Problemen. Sie müssen nicht nur in einen neuen Standort investieren, sondern auch gleichzeitig ihre BC/DR-Strategie anpassen. Denn ein weiterer wichtiger Baustein des bisherigen Systems kommt bei weiter Entfernung an ihre Grenzen: Die Snapshot-Technologie.

Ab 200 VMs nimmt die Komplexität und der Performance-Overhead von Snapshots exponentiell zu

Die beim Thema BC/DR bisher meist genutzte Snapshot-Technologie ist in vieler Hinsicht laut Zerto ein Problem. Sie verschlingt Speicherplatz, Bandbreite und Verwaltungsaufwand. Darüber hinaus erhöht sie den Performance-Overhead und die Komplexität. In der Praxis werden meist Storage-Snapshots auf LUN-Ebene und Snapshots auf VMDataStore-Ebene kombiniert. Nicht nur die hohe Anzahl der Snapshots ist ein Problem. IT-Manager müssen ständig entscheiden, wann und wo Snapshots erstellt, gelöscht oder konsolidiert werden müssen.

Auch die Abhängigkeiten der VMs sind bei Wiederherstellung mit Snapshots laut Zerto zu beachten: Ab etwa 200 produktiven VMs steigt der Aufwand für dieses Setup exponentiell an. Zieht man die Probleme von Snapshots und die Latenzprobleme bei einer Entfernung von mehr als 200km in Betracht, kommt man zum Ergebnis, dass eine neue Lösung zwingend benötigt wird. Wenn synchrone Replikation nicht mehr funktioniert, muss zwangsläufig asynchron repliziert werden. Hierfür bieten sich Lösungen an, die journalbasierte Checkpoints setzen. Im Folgenden werden drei Szenarien erklärt, die CDP mit asynchroner Replikation nutzen um BC/DR auch über weite Entfernungen möglich zu machen.

CDP mit asynchroner Replikation - Drei Optionen um den neuen Abstand einzuhalten:

So können Unternehmen ihre Applikationen mit den neuen Voraussetzungen mit minimalem Datenverlust, Ausfallzeiten, Performance Overhead und Bandbreitenutzung effektiv und effizient schützen. Bei allen drei Optionen kann der zweite Standort mehr als 200 Kilometer entfernt liegen. Da Synchrone Spiegelung aufgrund dieser Distanz keine Option ist, kommt nur asynchrone Replikation in Frage. Eine einfache Migration des bestehenden Setups ist deshalb unmöglich.

1. Umstieg auf asynchrone Replikation und Auseinanderziehen des Synchronen Spiegels auf über 200 Kilometer

  • Unternehmen können ihr bestehendes HA-System auf die gewünschte Entfernung ziehen und auf asynchrone Replikation umstellen. Eine Herausforderung dieser Möglichkeit ist die Vermeidung des Risikos bei der Migration. Dauert diese etwa 10 Tage, so wären die Unternehmensdaten 10 Tage nicht abgesichert. Für wichtige Applikationen natürlich ein nicht akzeptables Risiko.

2. Aufbrechen des Synchronen Spiegels und Migration an einen neuen Standort mit Umstieg auf asynchrone Replikation und CDP

  • Der Umstieg auf asynchrone Replikation mittels einer Replikationssoftware ist relativ einfach. Für die Migration an den neuen Standort repliziert die Lösung die Umgebung vorübergehend in die Cloud. Der Cluster kann anschließend aufgebrochen werden. Nach der Installation der neuen Hardware am neuen Standort wird per 1-to-many-Replikation an den zweiten Standpunkt repliziert. Ergebnis ist ein Cluster über zwei weit entfernte RZs mit CDP und asynchroner Replikation, aufbauend auf Journaling. Ein solches Setup bietet RPOs von wenigen Sekunden, bietet die Möglichkeit die Wiederherstellung zu orchestrieren und benötigt darüber hinaus deutlich weniger Speicherbedarf als Snapshots.

3. Migration in die Cloud und komplette Auflösung des DR-Rechenzentrums und Umstieg auf asynchrone Replikation und CDP

  • Die neuen Rahmenbedingungen bieten tatsächlich eine passende Gelegenheit ein DR-Rechenzentrum sogar komplett aufzulösen. Anstatt in einen neuen Standort zu investieren, kann man einfach direkt die Cloud als DR-Ziel wählen. Dies ist tatsächlich auch relativ einfach: Es muss prinzipiell nur eine entsprechende Replikationssoftware installiert und ein passender Cloudanbieter ausgewählt werden. Die Software repliziert fortan in die Cloud und bietet Disaster Recovery und Backup von dort aus. Das DR-Rechenzentrum wird einfach abgeschaltet.


Abb. 1: Beispiel einer (VM-)Hochverfügbarkeit-Architektur mit asynchrone Replikation auf Basis CDP und Journaling (Bildquelle: Zerto).


Um über weite Entfernung, wie sie etwa das BSI jetzt empfiehlt, Redundanz zu gewährleisten, bleibt als technologische Lösung eigentlich nur noch Continuous Data Protection (CDP) mit Journaling und asynchroner Replikation übrig. Die Technologie löst die Probleme mit möglichem Datenverlust, Latenz, der Größe von Snapshots, Bandbreite und den Performance-Overhead. Die Asynchrone Replikation bietet RPOs in Sekunden, ist deutlich günstiger, weniger verwaltungsaufwändig und schützt auch vor logischen Fehlern.

Fazit:

Unternehmen, die nach Möglichkeiten suchen, ihr Rechenzentrum auch über einen Abstand von mehr als 200 Kilometer abzusichern, können dies wie gerade beschrieben mit asynchroner Replikation und CDP mit Journaling erreichen. Dabei steht ihnen die Wahl offen, weiterhin ein zweites physisches Rechenzentrum zu betreiben oder das zweite Rechenzentrum einfach abzuschalten und in die Cloud zu replizieren. Im Vergleich zur Replikation mit Snapshots hat die asynchrone Replikation mit CDP und Journaling zahlreiche Vorteile. Außerdem werden minimale Investitionen in weitere Hardware, wie etwa Proxy Server, Netzwerk oder dedizierte Hosts benötigt.

Die Replikation auf Basis von Journaling erfordert darüber hinaus eine minimale Nutzung von Bandbreite und bietet gegen Datenverlust RPOs von nur wenigen Sekunden, anstatt von Stunden. Unternehmen, die sich mit den Folgen der BSI-Empfehlung befassen und planen ihr georedundantes Rechenzentrum an einen neuen Standort zu migrieren, sollten sich im Detail mit den möglichen Alternativen befassen.


(1) Quellenangabe /Querverweis zum Thema: