Georedundanz von Rechenzentren
Die Folgen der BSI-Vorgabe meistern
Die neue Empfehlung zum Mindestabstand redundanter Rechenzentren des BSI stellt Unternehmen vor neue Herausforderungen: Die Latenz zwischen den Rechenzentren wird beim neuen Mindestabstand von 200 Kilometern zu hoch, um Unternehmen mit traditionellen Hochverfügbarkeits- und Backup-Lösungen gegen Systemausfälle, logische Fehler und Ransomware-Angriffe zu schützen. Unternehmen benötigen also neue Ansätze, um ihre IT bei dieser Entfernung mit minimalem Datenverlust und kurzen Ausfallzeiten zu sichern und wiederherzustellen.
Die Entscheidung des BSI (Bundesamt für Sicherheit in der Informationstechnik) im Dezember 2018 kam für viele überraschend und sandte eine Schockwelle durch die Branche: Das Bundesamt erhöhte den empfohlenen Mindestabstand der Georedundanz für Rechenzentren von gerade einmal fünf auf satte 200 Kilometer. Da hierzulande sehr viele Rechenzentren über HA-Systeme (HA: High Availability, Hochverfügbarkeit) synchron gespiegelt sind, betrifft die neue Empfehlung einen sehr hohen Prozentsatz aller Unternehmen. Für Betreiber von vom Gesetzgeber als "kritische Infrastrukturen" (Kritis) angesehener Rechenzentren ist die Entscheidung ebenso bindend wie für alle öffentlichen Einrichtungen des Bundes. Auch zahlreiche Branchenverbände, etwa der Bankenverband Bafin, halten ihre Mitglieder dazu an, den Empfehlungen des BSI zu entsprechen. Somit müssen Tausende von Organisationen mit gespiegelten Rechenzentren auf diese Empfehlung reagieren.
Für Experten war die neue BSI-Empfehlung deshalb auf den ersten Blick dahingehend ein Meilenstein, dass Unternehmen nicht nur in weiter entfernte Rechenzentren investieren, sondern gleichzeitig ihre bisher genutzte BC/DR-Technik (Business Continuity/Disaster Recovery, ununterbrochener Geschäftsbetrieb/Wiederherstellung des Betriebs nach einem Störfall) überdenken müssen, um sie den neuen Gegebenheiten anzupassen. Denn wenn die verwendete Technik aufgrund geänderter Rahmenbedingungen nicht mehr funktioniert, müssen Unternehmen nach einer neuen Methode suchen, um ihre VMs zukünftig mit minimalem Performance-Verlust und geringen RPOs (Recovery Point Objective, Zeitraum zwischen zwei Backups) zu schützen. Die neue Empfehlung hat somit das Potenzial, komplette DR- und Backup-Strategien auf den Kopf zu stellen, die man auf Basis der bisherigen Richtlinien etabliert hatte.
Grenzen synchroner Spiegelung
Der Absatz zwischen zwei georedundanten Rechenzentren liegt im Allgemeinen zwischen den bisher mindestens geforderten fünf und maximal zirka 35 Kilometern. Oft sind sie in einem anderen Brandabschnitt auf dem gleichen Betriebsgelände angesiedelt oder befinden sich bei einem Dienstleister oder Partner in der Nähe. Diese Entfernung ist auch nicht zufällig: Bei solchen synchron gespiegelten Systemen muss jeder Schreibvorgang repliziert und bestätigt sein, bevor die I/O geschrieben wird. Für schreibintensive Applikationen, zum Beispiel SAP-Systeme oder SQL-Datenbanken, ist niedrige Latenz eine Kernanforderung. Aufgrund der neuen Entfernung von 200 Kilometern ist es physikalisch unmöglich, für dieses Setup die notwendig niedrige Latenz zu erreichen. Doch wie können es Unternehmen schaffen, ihre Applikationen unter den neuen Voraussetzungen mit minimalem Datenverlust, Ausfallzeiten, Performance Overhead und Bandbreitenbedarf effektiv und effizient zu schützen? Tatsächlich gibt es mehrere Optionen.
Prinzipiell stehen Unternehmen jetzt vor der Wahl, den HA-Cluster auf 200 Kilometer auszudehnen, ein weiter entferntes drittes Rechenzentrum aufzubauen oder die Cloud als kostengünstige DR-Site zu verwenden. Da alle Optionen voraussetzen, dass das DR-Rechenzentrum mindestens 200 Kilometer entfernt liegt, ist es technisch so gut wie unmöglich, das klassische DR-Rechenzentrum mit dem gleichen Setup des synchronen Spiegels einfach in ein neues, 200 Kilometer entferntes zu migrieren. Somit kommt nur noch asynchrone Replikation im Frage. Unter Berücksichtigung möglichen Datenverlusts, der Latenz, der Größe von Snapshots, Bandbreite und des Performance-Overheads bleibt nahezu nur eine technische Möglichkeit, auf diese weite Entfernung Redundanz zu gewährleisten: Continuous Data Protection, kurz CDP, mit asynchroner Replikation.
Synchrone vs. asynchrone Replikation
Der synchrone Spiegel war bislang die Standardtechnik für ein hochverfügbares Rechenzentrum, hat aber zahlreiche Nachteile: Er ist teuer, aufwendig in der Verwaltung, sichert keine Daten während der Übertragung ("In-Flight") und schützt generell nur gegen Systemausfälle. Um sich etwa vor logischen Fehlern zu schützen, muss die IT-Abteilung in zusätzliche Technik wie Backup-Software und -Hardware investieren. Diese Sicherungslösungen machen die Umgebung jedoch komplexer und damit fehleranfälliger.
Gleichzeitig speichern Hypervisoren und Anwendungen mehr Daten im Cache, wo synchrone Replikation sie nicht effektiv schützen kann. Dies sabotiert das eigentliche Ziel des synchronen Spiegels: den RPO von null. Sehen Unternehmen, die ihre Applikationen bereits virtualisiert haben, erst einmal ein, dass der teure synchrone Spiegel den eigentlichen Zweck eines Null-RPOs nicht erfüllt, ist der Schritt zur asynchronen Replikation nicht mehr weit. Denn diese bietet RPOs im Sekundenbereich sowie viele weitere Vorteile.
Problem Storage-Snapshot
Eines der größten Probleme beim Thema BC/DR ist die heute noch immer weit verbreitete Snapshot-Technik. Denn zum einen schützen Storage-Snapshots LUNs (Logical Unit Number, logischer Speicherplatz) und nicht VMs. Aus Sicht der VM-Sicherheit wäre es jedoch besser, Schutz auf VM-Ebene zu gewährleisten, da ein Failover eventuell andere VMs auf einer LUN in Mitleidenschaft zieht. Des Weiteren ist es ein Problem, dass man pro VM-Data-Store maximal zwei bis drei aktive Snapshots laufen lassen kann. Bei 200 geschützten VMs wären dies 600 Snapshots. Und da eine RPO von acht bis zwölf Stunden nicht akzeptabel ist, werden dazu noch Storage-Snapshots erstellt, die nicht nur die Komplexität erhöhen, sondern auch zusätzliche Bandbreite und Speicherplatz verschlingen. Bei einer Anzahl von etwa 200 VMs, die über 200 Kilometer zu replizieren sind, kann man VMs nicht mehr effektiv mit Snapshots schützen. Dies erfordert eine andere Lösung, etwa journalbasierte Checkpoints, die ein Journaling ähnlich einer Datenbank bieten, aber eben auf Hypervisor-Ebene.
Unternehmen, die auch weiterhin auf ein zweites physisches Rechenzentrum setzen wollen, können dies mit asynchroner Replikation auch bei einem Abstand von mehr als 200 Kilometern erreichen. Die asynchrone Replikation mit CDP und Journaling hat im Vergleich zur Replikation mit Snapshots zahlreiche Vorteile: Es bedingt nur minimale Investitionen in weitere Hardware wie Proxy-Server, Netzwerk oder dedizierte Hosts. Die Replikation auf Basis von Journaling erfordert zudem eine minimale Nutzung von Bandbreite und bietet gegen Datenverlust RPOs von nur wenigen Sekunden statt von Stunden.
Praxisbeispiele
Die folgenden drei Praxisbeispiele zeigen, wie Unternehmen von einem klassischen HA-Cluster mit synchroner Spiegelung auf asynchrone Replikation mit CDP wechseln können.
Beispiel 1: Auseinanderziehen des synchronen Spiegels auf über 200 Kilometer und Umstieg auf asynchrone Replikation. Unternehmen, die ungern in ein neues Speichersystem investieren wollen, können ihr bestehendes HA-System auf die gewünschte Entfernung "ausdehnen" 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 Hardware als Basis nutzt. Nachteil ist ein schlechterer RPO bei etwaigen Systemausfällen und sehr wahrscheinlich Investitionen für Netzwerktechnik, um den erhöhten Bedarf für Bandbreite zu stillen. Das größere Problem dieser Option besteht weniger in der Umstellung auf die neue Replikationstechnik, sondern eher in der Migration: Denn wer sein DR-Rechenzentrum als Ganzes verschiebt, steht vor dem Problem, dies ohne Risiko leisten zu müssen. Dauert eine Migration zehn Tage, so wären die Unternehmensdaten diese zehn Tage lang nicht abgesichert - für moderne Unternehmen ein nicht hinnehmbarer Zustand.
Beispiel 2: Umstieg auf asynchrone Replikation und CDP, Aufbrechen des Clusters und Migration an einen neuen Standort. Grundsätzlich gibt es hier zwei Szenarien, mit einem Zwei-Controller- oder einem Vier-Controller-Metro-Cluster, wobei das erste das häufigste ist. Der Umstieg auf asynchrone Replikation mittels einer Replikationssoftware folgt prinzipiell in sechs Schritten:
- Die neue Replikationssoftware wird in der Umgebung installiert. Für die Migration repliziert die Lösung die Umgebung vorübergehend in die Cloud. So bleibt das RZ während des Wechsels geschützt und es fallen keine Kosten für ein Speichersystem an.
- Da die VMs nun in der Cloud geschützt sind, kann man den synchronen Spiegel aufbrechen.
Im nächsten Schritt wechselt man von FC-Switches zu direkt angeschlossenen Arrays, verbindet also die Disk-Arrays direkt mit dem Controller. - Um die Redundanz der Controller vor Ort zu erhalten, sind bei einem Zwei-Controller-Metro-Cluster zwei zusätzliche Controller zu installieren.
- Nach dem Hardwarewechsel kann man die Replikationssoftware verwenden, um nun die Daten auf den zweiten Cluster zu replizieren. Dafür muss die Replikationssoftware eine 1:n-Replikation ("one to many") unterstützen, da das IT-Team in diesem Beispiel von einem Hauptrechenzentrum auf die Cloud und den zweiten Standort repliziert.
- Ist die Replikation auf den neuen Cluster abgeschlossen, kann man die für die Migration verwendete Cloud-Replikation beenden.
Das Ergebnis ist ein Cluster in zwei weit entfernten Rechenzentren mit asynchroner Replikation und CDP, aufbauend auf Journaling-Technik. Diese Lösung garantiert RPOs im Bereich weniger Sekunden, benötigt deutlich weniger Speicherbedarf als Snapshots und bietet bei der Wahl einer fortschrittlichen Lösung die zusätzliche Orchestrierung der Wiederherstellung.
Beispiel 3: Umstieg auf asynchrone Replikation und CDP mit Migration in die Cloud und kompletter Auflösung des DR-Rechenzentrums. Für Unternehmen, die schon länger damit liebäugelten, ihr DR-Rechenzentrum aufzulösen, bietet die neue BSI-Empfehlung eine ideale Gelegenheit. Anstatt in ein neues, weiter entferntes Rechenzentrum als DR-Standort zu investieren, nutzt man einfach die Cloud als DR-Ziel. Nach der Installation der neuen Replikationssoftware und der Wahl des passenden Cloud-Anbieters repliziert die Software in die Cloud und bietet fortan Disaster Recovery und Backup aus der Cloud. Das DR-Rechenzentrum kann man dann abschalten. Cloud-Anbieter haben das Potenzial dieser sehr einfachen Methode erkannt und haben längst Partnerschaften mit Lösungsanbietern geschmiedet, die ihre Replikationssoftware "as a Service" anbieten.
Da gesicherte VMs in Azures Blob-Storage liegen, entstehen kaum Kosten für Rechenleistung. Erst bei einem eventuellen Failover müsste man dafür bezahlen. Zudem lässt sich der Failover mit der richtigen Lösung komplett automatisieren, inklusive der Boot-Reihenfolge der VMs und IP-Adressen. Test-Failovers kann das IT-Personal per Mausklick durchführen. Unabhängig davon, für welche Option sich ein Unternehmen entscheidet: Bevor das Setup den aktuellen Mindestabstand einhalten kann, muss man die Daten an den neuen Standort migrieren. Migrationen sind in vielen IT-Umgebungen seit jeher ein äußerst unbeliebtes Szenario. Ein ganzes Backup-Rechenzentrum mit allen Workloads und Daten zu migrieren, selbstverständlich ohne jeglichen Einfluss auf den Geschäftsbetrieb, ist Stress pur und läuft in den seltensten Fällen nach Plan.
Als veraltet erscheint hier der klassische "Lift & Shift"-Ansatz, also die gesamte Hardware eines DR-Rechenzentrum einfach an einen neuen, weiter entfernten Standort zu verfrachten und dort neu aufzubauen. Denn heute besteht die deutlich einfachere Möglichkeit, die Migration mit intelligenten Softwarelösungen per Mausklick zu vollenden. Moderne IT-Resilienzlösungen bieten einem Unternehmen hier diverse Möglichkeiten für BC/DR, Cloud-Mobilität und Migrationen. Unternehmen, die sich mit dem Themenkomplex befassen, ihr georedundantes Rechenzentrum an einen neuen Standort zu migrieren, sollten sich genau mit den Alternativen befassen und die asynchrone Replikation mit CDP und ohne Snapshots in ihre Liste der Optionen aufnehmen.
Lesen Sie mehr zum Thema
