Sicherheitsabstand : Redundanz bei weit entfernten Rechenzentren meistern

Von Johan van den Boogaart, Dießen am Ammersee

Relativ unbemerkt brachte eine Entscheidung des BSI Ende 2018 die Welt der CIOs und CISOs vieler Branchen durcheinander: Das Bundesamt hatte seinerzeit den empfohlenen Mindestabstand für georedundante Rechenzentren von fünf Kilometern auf das Vierzigfache angehoben – ganze 200 km [1]. Da in unserer Region sehr viele Rechenzentren über sogenannte High-Availability- (HA)-Systeme synchron gespiegelt werden, betrifft diese neue Empfehlung etliche Unternehmen. Für viele ist die Empfehlung dabei nicht einmal optional: Für Betreiber der vom Gesetzgeber als „kritische Infrastrukturen“ angesehenen Rechenzentren ist die Entscheidung im Prinzip seitdem genauso bindend wie für alle öffentlichen Bundeseinrichtungen. Auch die Mitglieder zahlreicher Branchenverbände (etwa des Bankenverbands) sind dazu angehalten, den Empfehlungen des BSI Folge zu leisten.

Seitdem arbeiten viele Unternehmen daran, ihre Strategien so anzupassen, dass sie der Empfehlung des BSI entsprechen. In der Realität bedeuten die neuen Randbedingungen eine echte Zäsur und stellen viele Organisationen vor große Probleme. Denn es gilt nun nicht nur, in weiter entfernte Rechenzentren zu investieren – gleichzeitig muss die bisher genutzte Technik für Business-Continuity (BC) und Disaster-Recovery (DR) überdacht werden.

Grenzen synchroner Spiegel

Die Entfernung bisheriger georedundanter Rechenzentren lag im Allgemeinen bisher zwischen den mindestens geforderten fünf und meistens circa 35 Kilometern. Oft lagen die sich gegenseitig absichernden Rechenzentren auf dem gleichen Betriebsgelände, getrennt durch einen Brandabschnitt. Auch lokale Dienstleister oder Partnerunternehmen in der Nähe wurden zur Absicherung gern genutzt.

Die geringe Entfernung ist auch kein Zufall. Die neue Empfehlung hat somit das Potenzial, komplette DR- und Backupstrategien auf den Kopf zu stellen, die explizit auf Basis eines geringen Abstands erstellt worden sind. Bei synchron gespiegelten HA-Systemen muss, wie der Name schon sagt, jeder Schreibvorgang synchron repliziert und bestätigt werden, bevor die I/O geschrieben wird. Das ist für Applikationen wie SAP oder SQL-Datenbanken, die eine geringe Latenzzeit benötigen, eine Grundvoraussetzung.

Bei einer Entfernung von 200 Kilometern ist die nötige Latenz jedoch physikalisch unmöglich. Unternehmen stehen also vor dem Problem, ihre Anwendungen auch unter den neuen Voraussetzungen mit dem vergrößerten Abstand mit möglichst geringem Datenverlust, Ausfallzeiten, Performance-Overhead sowie Bandbreitennutzung effektiv und effizient schützen zu müssen.

Da dies mit der bisherigen Technik aufgrund geänderter Rahmenbedingungen nicht mehr funktioniert, benötigt man eine neue Methode, die es schafft, VMs auch über weite Entfernung mit minimalem Performance- und geringem Datenverlust (also kleinem Recovery-Point Objective, RPO) zu schützen. Tatsächlich gibt es mehrere Optionen: Man kann einen HA-Cluster auf 200 Kilometer auseinanderziehen, ein drittes, weiter entferntes Rechenzentrum aufbauen oder die Cloud als kostengünstige DR-Site verwenden.

Asynchrone Alternative

Allen drei Optionen ist gemein, dass es quasi unmöglich ist, ein bestehendes DR-Rechenzentrum mit dem gleichen Design des synchronen Spiegelns einfach in ein anderes, 200 Kilometer entferntes Rechenzentrum zu migrieren. Wo die synchrone Spiegelung keine Alternative ist, lässt sich nur noch asynchrone Replikation nutzen. Berücksichtigt man mögliche Datenverluste, die Latenz, die Größe von Snapshots, die Bandbreite und den Performance-Overhead, bleibt nahezu nur eine technische Möglichkeit, um auf diese weite Entfernung Redundanz zu gewährleisten: Continuous Data-Protection (CDP, aka Real-Time-Backup) mit asynchroner Replikation.

Nachteile synchroner Replikation

Obwohl hochverfügbare Rechenzentren für ihre Absicherung bisher unisono auf synchrone Spiegel gesetzt haben, hat dieses Verfahren doch auch einige Nachteile: Er schützt an sich nur gegen Systemausfälle, schützt keine Daten „in-Flight“, ist aufwendig in der Verwaltung und obendrein teuer in der Anschaffung. Und um den Spiegel etwa vor logischen Fehlern oder Angriffen wie Ransomware zu schützen, muss in zusätzliche Backup-Soft- und -Hardware investiert werden.

Diese zusätzlichen Lösungen erhöhen jedoch die Komplexität und machen die Umgebung fehleranfälliger. Gleichzeitig werden auch mehr und mehr große Applikationen virtualisiert und Hypervisors speichern immer mehr Daten in ihren Caches, wo sie die synchrone Replikation nicht effektiv schützen kann. Dieser Umstand führt das eigentliche Ziel des synchronen Spiegels ad absurdum: Ein RPO von Null ist nicht mehr zu erreichen.

Unternehmen, die ihre Umgebungen und Applikationen längst virtualisiert haben, stehen nun vor dem teuren Problem, dass ihr synchroner Spiegel den ursprünglichen Idealzweck gar nicht mehr erfüllt. Ein Teil des Problems, Rechenzentren über weite Strecken effektiv abzusichern, ist die noch immer weit verbreitete Snapshot-Technologie.

Snapshots sind ein Problem für VMs

Das Wichtigste, das Unternehmen heute absichern, sind nicht Daten, sondern virtuelle Maschinen (VMs). Aus deren Sicht wäre es besser, auch den Schutz auf der VM-Ebene zu gewährleisten, da bei einem Problem eventuell andere VMs von einem Failover auf einer logischen Speichereinheit (LUN) in Mitleidenschaft gezogen würden – Storage-Snapshots schützen jedoch keine VMs, sondern LUNs.

Darüber hinaus ist es ein Problem, dass man pro VM-Datastore maximal zwei bis drei aktive Snapshots laufen lassen kann. Und da eine RPO von acht bis zwölf Stunden nicht akzeptabel ist, werden darüber hinaus noch Storage-Snapshots erstellt, die nicht nur die Komplexität erhöhen, sondern auch zusätzliche Bandbreite und Speicherplatz verbrauchen.

Bei einer Zahl von etwa 200 VMs, die über 200 Kilometer repliziert werden müssten, kann man diese wegen zu hoher Nutzung von Bandbreite und Storage nicht mehr effektiv mit Snapshots schützen. Hierfür wird eine andere Lösung benötigt, wie etwa journalbasierte Checkpoints, die ein Journaling ähnlich einer Datenbank bieten, dies aber auf der Ebene des Hypervisors realisieren. Wer weiterhin auf ein zweites physisches Rechenzentrum setzen will, kann das dann technologisch auch über mehr als 200 Kilometer Entfernung tun – allerdings mit asynchroner Replikation per CDP und Journaling anstatt mit synchroner Replikation und Snapshots.

Vorteile asynchroner Replikation

Im Vergleich zur Replikation mit Snapshots hat diese Verfahrensweise zahlreiche Vorteile: Es sind nur minimale Investitionen in weitere Hardware notwendig – etwa Proxy-Server, im Netzwerk oder für dedizierte Hosts. Darüber hinaus erfordert die Replikation auf Basis von Journaling nur eine minimale Bandbreite und bietet gegen Datenverlust RPOs von nur wenigen Sekunden – statt von Stunden bei synchroner Replikation und Snapshots.

Praxis-Beispiele

Im Folgenden sollen drei praktische Beispiele für den Wechsel von einem klassischen HA-Cluster mit synchroner Spiegelung auf eine asynchrone Replikation mit CDP beleuchtet werden.

Auseinanderziehen des synchronen Spiegels auf über 200 km mit Umstieg auf asynchrone Replikation

Unternehmen, die ungern in ein neues Speichersystem investieren wollen, können ihr bestehendes HA-System auf die gewünschte Entfernung „auseinanderziehen“ und auf asynchrone Replikation umstellen. Der Vorteil scheint auf den ersten Blick, dass keine Investitionen in Hardware nötig sind, da man einfach weiterhin dieselbe Geräte-Basis nutzt. Der Nachteil ist allerdings ein schlechterer RPO bei etwaigen Systemausfällen und sehr wahrscheinlich Investitionen für Netzwerktechnik, um den erhöhten Bandbreitenbedarf zu stillen.

Das größere Problem bei dieser Option besteht jedoch weniger in der Umstellung auf die neue Replizierungstechnik, sondern eher bei der Migration: Denn wer sein DR-Rechenzentrum als Ganzes verschiebt, steht vor dem Problem, dies ohne Risiko leisten zu müssen. Dauert eine Migration 10 Tage, so wären die Unternehmensdaten 10 Tage nicht abgesichert – für moderne Unternehmen ein nicht hinnehmbarer Zustand.

Umstieg auf asynchrone Replikation und CDP, Aufbrechen des Clusters und Migration an einen neuen Standort

Grundsätzlich gibt es hier zwei Szenarien mit einem 2-Controller- oder einem 4-Controller-Metrocluster, wobei das erste das häufigste ist. Der Umstieg auf asynchrone Replikation mittels einer Replikationssoftware erfolgt prinzipiell in sechs Schritten:

• Die neue Replizierungs-Software wird in der Umgebung installiert. Für die Migration repliziert die Lösung die Umgebung vorübergehend in die Cloud. So bleibt das Rechenzentrum während des Wechsels geschützt und es sind keine Kosten für ein zusätzliches Speichersystem notwendig.
• Da die VMs nun in der Cloud geschützt sind, kann der synchrone Spiegel aufgebrochen werden.
• Im nächsten Schritt wird von Fibre-Channel-(FC)-Switches zu direkt angeschlossenen Arrays gewechselt, was bedeutet, dass man die Disk-Arrays direkt mit dem Controller verbindet.
• Um die Redundanz der Controller vor Ort zu erhalten, müssen bei einem 2-Controller-Metrocluster zwei zusätzliche Controller installiert werden.
• Ist der Hardware-Wechsel vollzogen, kann man die Replikationssoftware verwenden, um nun auf den zweiten Cluster zu replizieren. Hierfür muss die Replikationssoftware die sogenannte 1-to-many-Replikation unterstützen, da in diesem Beispiel von einem Hauptrechenzentrum auf die Cloud und den zweiten Standort repliziert wird.
• Ist die Replikation auf den neuen Cluster abgeschlossen, kann die für die Migration verwendete Cloud-Replikation beendet werden.

Das Ergebnis ist ein Cluster in zwei weit entfernten Rechenzentren mit asynchroner Replikation und CDP, aufbauend auf Journaling-Technologie. Diese Lösung garantiert RPOs von wenigen Sekunden, benötigt deutlich weniger Speicherbedarf als Snapshots und bietet bei der Wahl einer fortschrittlichen Lösung die zusätzliche Orchestrierung der Wiederherstellung.

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

Für Unternehmen, die schon länger damit liebäugeln, ihr DR-Rechenzentrum ganz aufzulösen, bietet die neue Empfehlung des BSI eine ideale Gelegenheit. Anstatt in ein neues, weiter entferntes Rechenzentrum als DR-Standort zu investieren, nimmt man einfach die Cloud als DR-Ziel.

Nach der Installation einer neuen Replikationssoftware und der Wahl des passenden Cloudanbieters repliziert die Software in die Cloud und bietet fortan Disaster-Recovery und Backup aus der Cloud – das bisherige DR-Rechenzentrum kann man dann einfach abschalten. Cloud-Anbieter haben das Potenzial dieser sehr einfachen Methode erkannt und haben längst Partnerschaften mit Lösungsanbietern geschmiedet, die ihre Replizierungssoftware „as a Service“ in der Cloud anbieten.

Da gesicherte VMs in Azures Blob-Storage gespeichert werden, entstehen kaum Compute-Kosten – erst bei einem eventuellen Failover würde man dafür bezahlen müssen. Darüber hinaus lässt sich der Failover mit der richtigen Lösung komplett automatisieren, inklusive der Bootreihenfolge der VMs und IP-Adressen. Zudem können auch Test-Failover per Mausklick durchgeführt werden.

Migration braucht neue Lösungsansätze

Egal, für welche Option sich ein Unternehmen letzten Endes entscheidet, um den neuen Mindestabstand einzuhalten: Bevor das neue Setup funktioniert, muss in den neuen Standort migriert werden. Damit ist die Planung der Migration ein wichtiger Bestandteil des Prozesses.

Migrationen waren und sind in vielen Organisationen äußerst unbeliebt und laufen in den seltensten Fällen reibungslos ab – immerhin ist ein ganzes Backup-Rechenzentrum mit allen Workloads und Daten zu migrieren, selbstverständlich ohne jeglichen Einfluss auf den laufenden Geschäftsbetrieb. Die gesamte Hardware eines DR-Rechenzentrum einfach an einen neuen, weiter entfernten Standort zu verfrachten und dort neu aufzubauen, scheint in Anbetracht der deutlich einfacheren Möglichkeit, die Migration mit intelligenten Softwarelösungen per Mausklick zu vollenden, veraltet zu sein. Moderne IT-Resilience-Lösungen bieten Unternehmen hier multiple Möglichkeiten, sowohl für BC/DR als auch für Cloud-Mobilität und Migrationen.

Fazit

Unternehmen, die sich mit der neuen Empfehlung des BSI befassen und ein georedundantes Rechenzentrum in mindestens 200 Kilometern Entfernung aufbauen wollen, sollten auch mögliche Alternativen detailliert ergründen. Asynchrone Replikation mit CDP und ohne Snapshots ist eine elegante Option, die auf jeder Liste stehen sollte. Dieses Verfahren löst das Problem der mit der größeren Entfernung einhergehenden Latenz traditioneller Setups und schützt gleichzeitig auch vor logischen Fehlern, wie etwa Ransomware-Attacken.

Einen RPO von Null kann man in virtualisierten Umgebungen mit traditionellen HA-Lösungen, aufbauend auf synchronen Spiegeln, kaum noch erreichen. Hat man dies erst einmal erkannt, ist der Schritt zur asynchronen Replikation nicht mehr weit, die RPOs von Sekunden bieten kann und darüber hinaus noch viele weitere Vorteile mit sich bringt.

Johan van den Boogaart ist Regional Sales Manager bei Zerto.

Literatur

[1] Bundesamt für Sicherheit in der Informationstechnik, Kriterien für die Standortwahl von Rechenzentren (RZ), Version 2.0, Oktober 2019, www.bsi.bund.de/DE/Themen/Sicherheitsberatung/Hochverfuegbarkeit/StandortKriterien_HV-RZ/Standort-Kriterien_HV-RZ_node.html