Ausfallrechenzentren in der Cloud
Extinction-Level Event
Veröffentlicht in Ausgabe 01/2026 - SCHWERPUNKT
Fällt ein Server aus, sollte das keinen Administrator aus der Ruhe bringen, denn moderne Failover-Tools im Rechenzentrum kümmern sich automatisiert darum. Erwischt es eine VM oder einen Container, sorgen der Hypervisor oder Kubernetes für einen Neustart, und zerlegt es gar den kompletten Hypervisor oder Kubernetes-Knoten, greift das Hypervisor-Management ein und startet alle ausgefallenen VMs auf einem anderen Knoten.
Aber was, wenn das berüchtigte "Smoking Crater"-Szenario eintritt, also ein herabstürzender Asteroid das komplette RZ sprengt? Auch wenn bei diesem Szenario die Verfügbarkeit von IT-Diensten vermutlich ein nachgelagertes Problem ist, sind Disaster heute präsenter denn je. So manches Rechenzentrum in einem Keller wurde bereits Opfer der Fluten eines Hagel- oder Starkregensturms.
Drei Säulen des Disaster Recovery
Große Unternehmen verfügen über das Budget, um mehrere verteilte Rechenzentren in verschiedenen Brandabschnitten, Gebäuden und auch Etagen zu betreiben. Kleine oder mittelständische Unternehmen sind hingegen nur selten in der Lage, ein komplettes Ausfall-RZ in der Hinterhand zu haben. Aber mit modernen Technologien wie Cloud und Automatisierung müssen Administratoren in KMU nicht zwingend ein stets startbereites Rechenzentrum für Notfälle vorhalten. Cloudprovider werben mit stets zügig verfügbaren Ressourcen wie VMs. Mit wenigen architekturellen Änderungen im heimischen Rechenzentrum und Automatisierung ist es somit im Notfall möglich, flott und günstig auf ein temporäres Cloud-RZ ausweichen.
Fällt ein Server aus, sollte das keinen Administrator aus der Ruhe bringen, denn moderne Failover-Tools im Rechenzentrum kümmern sich automatisiert darum. Erwischt es eine VM oder einen Container, sorgen der Hypervisor oder Kubernetes für einen Neustart, und zerlegt es gar den kompletten Hypervisor oder Kubernetes-Knoten, greift das Hypervisor-Management ein und startet alle ausgefallenen VMs auf einem anderen Knoten.
Aber was, wenn das berüchtigte "Smoking Crater"-Szenario eintritt, also ein herabstürzender Asteroid das komplette RZ sprengt? Auch wenn bei diesem Szenario die Verfügbarkeit von IT-Diensten vermutlich ein nachgelagertes Problem ist, sind Disaster heute präsenter denn je. So manches Rechenzentrum in einem Keller wurde bereits Opfer der Fluten eines Hagel- oder Starkregensturms.
Drei Säulen des Disaster Recovery
Große Unternehmen verfügen über das Budget, um mehrere verteilte Rechenzentren in verschiedenen Brandabschnitten, Gebäuden und auch Etagen zu betreiben. Kleine oder mittelständische Unternehmen sind hingegen nur selten in der Lage, ein komplettes Ausfall-RZ in der Hinterhand zu haben. Aber mit modernen Technologien wie Cloud und Automatisierung müssen Administratoren in KMU nicht zwingend ein stets startbereites Rechenzentrum für Notfälle vorhalten. Cloudprovider werben mit stets zügig verfügbaren Ressourcen wie VMs. Mit wenigen architekturellen Änderungen im heimischen Rechenzentrum und Automatisierung ist es somit im Notfall möglich, flott und günstig auf ein temporäres Cloud-RZ ausweichen.
Viele Disaster-Recovery-Konzepte sehen noch immer vor, dass Unternehmen auf ein RZ ausweichen, das möglichst identisch zum produktiven Original ist – mit den gleichen Maschinen, Systemen, Hypervisoren, Storage und Switches. Das macht DR teuer, inflexibel und komplex. Im Kern geht es darum, in einem Disaster-Fall eine funktionierende, temporäre Umgebung zügig ans Laufen zu bekommen, die Sie nach Reparatur des Originals und Failback aller Daten wieder abschalten. Daher sollten die Dienste im heimischen Rechenzentrum so unabhängig wie möglich von Maschinen, Hypervisoren, Betriebssystemen und Netzwerken operieren.
Und auch wenn wir aufgrund der unterschiedlichen Infrastrukturen nicht in der Lage sind, Ihnen eine Schritt-für-Schritt-Anleitung für einen Disaster-Failover an die Hand zu geben, können IT-Verantwortliche doch mit der passenden Architektur und den richtigen Mitteln eine flotte Recovery auf die Beine stellen. Grundsätzlich benötigen Sie dafür die drei folgenden Basiskomponenten:
- Eine fortlaufende Datenreplikation zu der Cloudumgebung, die Sie im Notfall einsetzen.
- Einen Automatismus, der im Disaster-Fall eine Spiegelumgebung Ihres Rechenzentrums möglichst zügig in der Cloud ausrollt, das Netzwerk passend konfiguriert und den Spiegelsystemen die replizierten Daten zur Verfügung stellt.
- Ein Konzept für die Rückabwicklung, das nach erfolgtem Wiederaufbau der ausgefallenen Systeme die Daten aus der Cloud in das Rechenzentrum zurück bringt.
Kontinuierliche Replikation einrichten
Es ist nach wie vor ein Mythos, dass die sehr beliebten Volume-Snapshot-Tools alleine sichere Spiegel wichtiger Datenbestände erstellen können. Dateisystemabbilder funktionieren nur dann als Backup, wenn schreibende Applikationen vor einem Snapshot informiert wurden und offene Dateien schließen. Zudem setzen Snapshots identische Speicher- beziehungsweise Dateisysteme auf beiden Failover-Seiten voraus. Wie wir jedoch gleich sehen werden, nutzen Sie bei einem Cloud-Failover unterschiedliche Systeme – auch beim Storage. Sollten Sie im RZ den Fileserver eines bekannten Herstellers einsetzen, helfen Ihnen dessen Bordmittel für Backup, Snapshots und Failover in der Regel nicht. Denn auf dem Cloud-Notsystem steht Ihnen vielleicht nur eine Linux-Maschine mit NFS- oder Samba-Server zur Verfügung. Sie sollten die Replikation der Daten also lieber auf Datei- oder Objektebene mit Tools wie Syncthing, rsync oder anderen dateibasierten Werkzeugen aufsetzen. Alternativ liefert Ihre Kernapplikation selbst einen Replikationsmechanismus.
Datenbanken unterstützen durch die Bank Replikationsfeatures, egal ob SQL oder No-SQL. Die meisten setzen dabei einen sekundären Server ein, was in der Cloud ein kostenpflichtiges, dauerhaft aktives System als "Receiver" erfordert. Allerdings kann dieser Replikationsempfänger viel kleiner als das produktive Original ausfallen. Erst das Disaster-Failover ersetzt den minimalistischen DB-Host mit einem System für den produktiven Betrieb.
Techniken wie Log-Shipping (SQL-Server) erfordern zunächst einmal nur Storage auf der Empfängerseite. Das Disaster-Failover startet einen leeren DB-Server und baut die Datenbanken aus den Logdateien auf. Auch eine Kombination beider Ansätze ist möglich: Ihre Datenbank erstellt zeitlich getaktete Dumps, die ein Synchronisationstool dann auf den Cloudspeicher überträgt.
Mit flexibler Adressierung arbeiten
Nach wie vor konfigurieren Administratoren Kernsysteme im RZ mit statischen IP-Adressen. Zudem setzen sie für die Kommunikation wichtiger Dienste eine IP- und keine Namensadressierung ein. Der Hintergedanke dabei: Die Kommunikation der wichtigsten Systeme soll weiterhin funktionieren, auch wenn der DNS-Server ausfällt. Aber genau diese statische Adressierung erschwert einen Disaster-Failover, denn sie erfordert entweder, dass alle IP-Adressen in der Disaster-Umgebung identisch sind oder, dass das Recovery-Tool diese Konfigurationen automatisiert ändert.
Mit einer korrekten primären/sekundären DNS-Konfiguration muss der Admin heutzutage aber keinen DNS-Ausfall mehr fürchten. Zudem setzen moderne (Linux)-Server in der Regel auf den lokalen DNS-Caching-Service. Sollte dieser seinen Upstream-DNS nicht erreichen, beantwortet er DNS-Anfragen aus dem Cache. Das löst schon einmal das Problem der Dienstkommunikation via Namen statt IP-Adressen.
Mithilfe des DHCP-Diensts lösen Sie zudem die IP-Adressvergabe für Kernsysteme. DHCP bedeutet dabei nicht, dass alle anfragenden Rechner und VMs zufällige Adressen aus dem Pool erhalten. Vielmehr kann DHCP vordefinierten Systemen auf Basis der MAC-Adresse feste IP-Adressen vermitteln, zum Beispiel: "dhcp-host=52: 54:C0:A8:02:79, 192.168.2.121,infinite".
Hier muss der Administrator nur ein einziges Mal die MAC-Adressen der Kernsysteme ermitteln und in der DHCP-Konfiguration verewigen. Der Vorteil dieses Ansatzes: Die textbasierte Konfiguration des DNS/DHCP-Servers lässt sich relativ einfach kopieren und automatisiert an die Adressierung eines Failover-Setups in einer Cloud anpassen, beispielsweise über ein Jinja2-Template für Ansible. Das gilt nicht nur für DHCP-Server unter Linux. Auch der DHCP-Dienst von Windows erlaubt "Address reservations". Diese stehen dann zwar nicht in einer Textdatei, dafür aber in der Windows-Registry. Und diese lässt sich ebenfalls per Automatisierung im Cloud-Datacenter anpassen.
Im Disaster-Fall legen Sie in der Cloudumgebung zuerst ein privates Netzwerk für Ihre VMs an und rollen die DNS/ DHCP-Server mit der dazu angepassten Konfiguration aus. Dann erstellen Sie die Kernsysteme als VMs. Je nach Cloud vergeben Sie vor dem Rollout dieser Maschinen deren IP- beziehungsweise MAC-Adresse, die zur zuvor vergebenen DNS- Konfiguration passt (zum Beispiel AWS EC2). Sind Sie beim automatisierten VM-Rollout nicht in der Lage, private MAC/ IP-Adressen zu vergeben (etwa in der Hetzner Cloud), können Sie deren IP-Adresse auch im Nachgang ermitteln und in die DNS-Konfiguration übertragen.
Das geht beispielsweise via Ansible mit den Modulen "hetzner.hcloud.server_info", das im Array "private_networks" die IP-Adresse der VM zurückgibt, um diese via "ansible.builtin.lineinfile" in den DNS-Server einzubauen. Bei einem Windows-DNS-Server übernimmt dies das Modul "community.windows.win_dns_record".
Vom Betriebssystem unabhängig
Die LAN-Kommunikation adressunabhängig zu gestalten, ist ein wichtiger Schritt, um Dienste auf beliebige Zielnetzwerke übertragen zu können. Allerdings bleibt das Limit bestehen, dass manche Dienste stark von einem Betriebssystem und dessen Konfiguration abhängen. Hier müssen Sie geeignete, angepasste OS-Templates für Ihre jeweilige Failover-Plattform erstellen, warten und bereithalten. Das funktioniert nicht überall, denn nicht alle Cloudanbieter erlauben selbstgebaute Images. Um das zu umgehen, empfiehlt sich der nächste Schritt in Sachen Dienstabstraktion, auch wenn dieser mehr Aufwand bedeutet: Migrieren Sie Ihre Dienste wo immer es geht in Container.
Ein Container-Image enthält neben dem Betriebssystem die erforderlichen Bibliotheken und Abhängigkeiten des jeweiligen Diensts. Richtig aufgesetzt abstrahiert das Image den Service vollständig vom darunterliegenden OS oder der Container-Plattform. Ein auf RHEL erstellter Podman-Container mit PostgreSQL oder einer anderen Applikation läuft ebenso unter Podman auf einem Debian- oder Fedora-System, das Ihnen der Cloudprovider zur Verfügung stellt. Vielleicht erhalten Sie vom Applikationshersteller in der Notlaufzeit in der Cloud keinen Support, bis sie wieder auf einer zertifizierten Plattform arbeiten – aber das ist allemal besser, als gar keine Dienste nutzen zu können.
Der Vorteil für ein Disaster-Failover-Szenario liegt auf der Hand: Sie können als Basis ein beliebiges, Container-kompatibles Cloud-OS-Image einsetzen, die benötigten Abhängigkeiten des Diensts gehören zum Container-Image. Zudem blenden Sie den persistenten Speicher via Loop-Mount ein. Der Dienst hat dabei keine Ahnung, ob er seine Daten von einer lokalen Platte oder einer NFS-Freigabe bezieht. Das wiederum vereinfacht es, den mit Dateitools gespiegelten Datenbestand zu nutzen.
Natürlich bevorzugen Container zumeist Linux-Dienste und Windows-Container kommen nur sehr selten zum Einsatz. Im Gegenzug stellt Microsoft aber immer mehr seiner Applikationen für Linux und damit auch für Container zur Verfügung, beispielsweise den MS SQL-Server, der unter Linux mit Podman oder Docker (zertifiziert) arbeitet. Auch die Failover-Tools für den SQL-Server unterstützen Spiegelungen zwischen Windows- und Linux-Systemen.
Noch einfacher mit Kubernetes
Mit Kubernetes fällt ein Disaster-Failover in die Cloud noch leichter. Mit einem kleinen Kubernetes-Cluster, der nur Knoten für Management und Persistent-Storage umfasst, nutzen Sie die vorgestellten Replikationsmethoden, um Anwendungsdaten kontinuierliche vom lokalen PV auf ein cloudbasiertes zu spiegeln. Da Kubernetes grundsätzlich alle laufenden Ressourcen "as Code" definiert, sichern Sie diese "Running Config" regelmäßig. Bei einem Ausfall erweitern Sie zuerst mit Ansible oder Terraform die auf der Cloudplattform laufende Kubernetes-Umgebung um weitere Knoten. Dann installieren Sie alle benötigten Operatoren direkt über Kubernetes oder via Helm-Charts und laden im Anschluss Ihre Applikationskonfiguration hoch. Dabei müssen Sie lediglich die PV-Zuweisung vom Original zur Spiegelumgebung ändern. Sie sollten dabei aber keinen Cluster mit öffentlichen IP-Adressen verwenden, sondern diesen hinter einem VPN-Gateway verbergen. Daher funktionieren nicht alle fertigen Kubernetes-Cloudservices. Je nach Setup ist es auch hier besser oder sogar günstiger, einfach Linux-VMs mit privaten Adressen auszurollen und darauf eine Distribution wie Openshift oder K3s/Rancher einzusetzen.
Entkopplung durch Umwandlung
Manche Anwendungen lassen sich jedoch nicht containerisieren oder sind so tief mit einem bestimmten OS verwurzelt, dass dieses Verfahren nicht funktioniert. Hier hilft nur, die komplette VM auf die Ausfallplattform zu übertragen. Zahlreiche Cloudanbieter offerieren physische Root-Server, die sich flott und automatisiert bereitstellen lassen.
Darauf installieren Sie einzelne oder gemanagte Hypervisor-Knoten – VMware läuft dort allerdings nur mit komplexen Umwegen. Hier unterstützt "Virt V2V", eines der Libguestfs-Tools [1]. Damit lassen sich VMs von diversen Hypervisoren wie VMware nach KVM konvertieren und dort nutzen.
Der Haken ist dabei, dass Virt V2V laufende VMs überträgt, es aber im Disaster-Fall keine arbeitende Quelle mehr gibt. Sie müssen daher einen KVM-tauglichen Klon seiner VM zu Lebzeiten erstellen und als Vorlage sichern. Mit dieser fahren Sie auf dem Notfall-Cloudsystem einen Klon hoch und starten diesen mit den letzten gesicherten Datenbeständen des Originals. Die Voraussetzung dafür ist natürlich, dass sich die Daten dieses Diensts separat sichern und replizieren lassen. Bei Hetzner beispielsweise können Sie praktischerweise Cloud-VMs und Root-Server über Ihre privaten Netze via vSwitch zusammenschalten. Containerisierte Dienste laufen dann auf simplen Cloud-VMs während andere VMs auf KVM-Knoten der physischen Root-Server arbeiten.
Mit Infrastructure-as-Code vollständig automatisieren
Um ein Ausfall-RZ zügig in einer Cloud auszurollen, benötigen Sie den passenden Automatismus mit der "Konfiguration-as-Code". Dazu bieten sich in erster Linie zwei Tools, beziehungsweise die Kombination aus beiden an: Ansible und Terraform. Ansible kann dabei zwar alles automatisieren, jedoch fällt eine As-Code-Definition einer kompletten RZ-Infrastruktur recht aufwändig aus. Für diesen Job ist Terraform – oder dessen Open-Source-Ableger OpenTofu – das bessere und in der Regel auch schnellere Werkzeug.
In der Praxis hat sich die Kombination aus beiden Tools bewährt: Terraform beschreibt die Infrastruktur und kümmert sich darum, diese funktionstüchtig auszurollen. Nach getaner Arbeit übergibt Terraform an Ansible, das dann die detaillierte Konfiguration der Dienste und deren Zuweisung zu den replizierten Daten übernimmt.
Nur wenige Unternehmen verfügen bereits über eine Definition des laufenden Rechenzentrums als Code. Vielmehr kommen bei den meisten Anwendern gewachsene Infrastrukturen zum Einsatz. Also bedeutet eine Codedefinition der Ausfallumgebung erst einmal einen Haufen Arbeit und viele Tests. Der Lohn zeigt sich jedoch im Fall eines wirklichen Ausfalls und auch in der Failback-Phase. Terraform erlaubt es, die Infrastrukturbeschreibung weitgehend unabhängig von der Zielplattform zu gestalten. Die Infrastruktursysteme deklarieren Sie als "Ressourcen", die Anpassung an die verschiedenen Hypervisoren übernehmen die so genannten "Provider".
Sie können Ihre Terraform-Automation daher sowohl für den Rollout der Disaster-Umgebung in der Cloud nutzen, als auch – mit geänderten Provider-Definitionen – zum Rollback zur nach dem Ausfall neu aufgesetzten Umgebung im Rechenzentrum. Sie müssen den Codierungsaufwand also nur ein Mal betreiben und den Ressourcenteil pflegen. Sollten Sie sich aus irgendeinem Grund einmal für eine andere Cloud als Disaster-Zielplattform entscheiden, behalten Sie die Ressourcendefinition von Terraform und fügen dieser nur einen geänderten Provider hinzu.
Mit Tunnelnetzen Anwender schnell unterstützen
Um das Ausfall-RZ in der Cloud nutzen zu können, benötigen Ihre Anwender darauf Zugriff. Alle Systeme offen im Internet mit öffentlichen IP-Adressen zugänglich zu machen, wie sonst bei Cloudsystemen üblich, wäre dabei ein Sicherheitsrisiko – daher rollen Sie die Systeme nur mit privaten IP-Adressen aus. Den Zugang verschafft ein zentraler VPN-Gateway-Server, beispielsweise mit OpenVPN. Diesen Dienst kann die zuvor erwähnte Infrastrukturmaschine mit den DNS/DHCP-Services gleich mit übernehmen. Dieses Setup ist vor allem dann sinnvoll, wenn Ihre Mitarbeiter aus getrennten Netzwerken, wie beispielsweise Homeoffices auf die Ressourcen zugreifen.
Anders können Sie die Sache angehen, wenn Ihr Büronetzwerk samt den dort vorhandenen Arbeitsplätzen noch funktioniert. Im Artikel "Datenschleuse" [2] haben wir in Ausgabe 08/2023 den Aufbau eines Layer-2-Bridge-VPN via SSH beschrieben. Eine solche Konfiguration nutzen Sie, um Ihr lokales Netz sicher und transparent mit dem Ausfall-RZ in der Cloud zu verbinden. Mit der passenden LAN- und VPN-Bridge-Kombination sollten die Anwender keinen Unterschied bemerken — außer, dass das Cloud-DC vielleicht etwas langsamer ist. Allerdings ist dafür eine Cloudanbindung mit hoher Bandbreite vonnöten.
Ein Vorteil der transparenten Bridge ist, dass Sie Dienste sowohl im lokalen als auch im entfernten Netzwerk gleichzeitig betreiben können. Die Layer-2-Bridge gibt ihnen damit auch die Möglichkeit für ein sanftes Fallback, bei dem Sie ein System nach dem anderen zurück ins lokale LAN übertragen und dort bereits wieder nutzen, während andere Dienste noch in der Cloud arbeiten.
Fazit
Das Buch "Disaster Failover for Dummies", das ein simples und universelles Notfallszenario für Rechenzentren aller Art beschreibt, wartet immer noch auf seinen Autor. Doch dazu sind die individuellen Konfigurationen und Dienste der Unternehmen zu verschieden. Zudem setzen die meisten klassischen Failover-Ansätze nach wie vor auf aufwändige, herstellereigene Tools wie beispielsweise VMwares Site Recovery Manager.
Dieses und ähnliche Werkzeuge verursachen enorme Kosten, nicht nur für die Lizenz, sondern für alle damit verbundenen Standby-Failover-Systeme und deren Lizenzierung. Das hier vorgestellte "Recover to Cloud"-Szenario aufzusetzen kostet zwar Zeit, Arbeit und bedarf der Anpassung bestehender lokaler Ressourcen. Doch je unabhängiger Ihre Dienste von Netz, Hypervisor oder OS arbeiten, desto flexibler und einfacher sind Ihre Optionen und Sie erhalten ein vergleichsweise günstiges Disaster-Failover-Szenario.
(jp)
Links
[1] virt-v2v: https://libguestfs.org/virt-v2v.1.html
[2] Artikel "Datenschleuse" in 08/2023: https://it-a.eu/paz42