Hot Standby: Kurze Pause

Im Kern ist das Prinzip der standortübergreifenden Redundanz nach dem Hot-Standby-Prinzip darauf ausgelegt, eine möglichst kurze Wiederanlaufzeit zu ermöglichen. Im Klartext: Geht ein Standort offline, dauert es im Idealfall nicht länger als eine Minute, bis das Setup am anderen Standort bereit ist und Nutzeranfragen beantworten kann. Damit das funktionieren kann, müssen allerdings mehrere Anforderungen erfüllt sein.

Stellenmarkt
  1. Software-Entwickler (m/w/d)
    Isochem & Datenverarbeitung GmbH, Bodenheim
  2. Sachbearbeitung IT-Strategie Gebäudemanagement
    Landeshauptstadt Düsseldorf, Düsseldorf
Detailsuche

Zunächst muss das Setup am Ausweichstandort natürlich dem Setup, dessen Backup es sein soll, möglichst genau entsprechen. Hier zahlt es sich nicht aus zu sparen: Im Falle eines Fails bringt es schließlich nichts, wenn das Setup zwar ordnungsgemäß am zweiten Standort anläuft, die Last eingehender Anfragen aber unmittelbar wieder dazu führt, dass nichts mehr geht. Dieser Aspekt ist der ausschlaggebende Grund dafür, dass Disaster-Recovery-Setups nach dem Hot-Standby-Prinzip eine teure Angelegenheit sind. Für jede Erweiterung des Setups am ersten Standort steht automatisch auch eine Erweiterung am zweiten Standort an.

Der zweite relevante Faktor in Sachen Hot-Standby-Setup besteht darin, die Hardware eben nicht nur am zweiten Standort zu haben, sondern sie dort auch aktiv zu betreiben. Im Grunde ist der zweite Standort ein Spiegel des ersten Standorts und jede Änderung an der ersten Site gehört am zweiten Standort ebenfalls vollzogen. Wohl dem, der in Sachen Automation aufgepasst hat: Mit Git & Co. lassen sich wunderbar Automatismen in Form von CI/CD-Setups basteln, die Konfigurationsänderungen automatisch sowohl an Standort 1 als auch an Standort 2 ausrollen. Auf diese Weise stellt ein Unternehmen sicher, dass beide Standorte stets über dieselbe Konfiguration verfügen - fernab jener Parameter freilich, die zwischen den Setups aus technischen Gründen unterschiedlich sein müssen.

Auf die Daten kommt es an

Am wichtigsten für Disaster-Recovery-Szenarien ist jedoch das Thema Daten. Klar: Die Daten sind quasi das Blut in den Adern praktisch jeder Applikation. Datenbanken sind Teil praktisch jedes modernen IT-Setups und meist enthalten sie sämtliche Nutzdaten, die für ein Setup relevant sind. Damit ein Setup an einem anderen Standort nach dem Ausfall von Site 1 den Betrieb möglichst zeitnah fortsetzen kann, braucht es die Daten des anderen Standorts, und zwar möglichst aktuell. Das Feature, das diese Funktion garantieren soll, nennt sich im Fachsprech Offsite-Replikation - und ist technisch anspruchsvoller, als mancher glauben mag.

  • Pacemaker eignet sich gut als lokaler Cluster-Manager, doch wenn es um die Redundanz über Standorte hinweg geht, braucht es andere Konzepte. (Bild: Martin Loschwitz)
  • BGP ist das zentrale Routing-Protokoll des Internets und sorgt dafür, dass die verschiedenen autonomen Systeme miteinander kommunizieren können (Bild: Wikipedia)
  • Clouds bieten meist mehrere physische Regionen an, in denen Anwender ihre Applikationen betreiben können - wie hier AWS (Bild: AWS)
Pacemaker eignet sich gut als lokaler Cluster-Manager, doch wenn es um die Redundanz über Standorte hinweg geht, braucht es andere Konzepte. (Bild: Martin Loschwitz)
Golem Akademie
  1. Elastic Stack Fundamentals – Elasticsearch, Logstash, Kibana, Beats: virtueller Drei-Tage-Workshop
    26.–28. Oktober 2021, Virtuell
  2. C++ Programmierung Basics: virtueller Fünf-Tage-Workshop
    13.–17. Dezember 2021, virtuell
Weitere IT-Trainings

Denn es ist nötig, die Daten zwischen den zwei Sites permanent synchron zu halten. Welche Wege dafür zur Verfügung stehen, hängt von der genutzten Technologie ab. Kommt ein klassisches NAS- oder SAN-System zum Einsatz, ist man auf dessen Features für Offsite-Replikation angewiesen. Die meisten Geräte bieten die Funktion, wollen jedoch eine separate Lizenz dafür, die durchaus teuer werden kann. Zumal man ja eben nicht nur ein Storage dieser Art braucht, sondern gleich zwei.

Günstiger geht es mit Lösungen im Eigenbau. DRBD für Linux gehört zu den Bordmitteln und beherrscht die Replikation hin zu einem anderen Standort. Dabei ist zu bedenken: In den allermeisten Fällen ist Offsite-Replikation asynchron, damit schreibende Clients am ersten Standort nicht für jeden Write die volle Latenz abbekommen, die zwischen den beiden Sites anfällt. Das gilt für Storage-Appliances wie für Lösungen wie DRBD in gleichem Maße. DRBD beherrscht die asynchrone Replikation ("Protokoll A") ebenfalls ab Werk. Weil es im Linux-Kernel auf der Blockdevice-Ebene andockt, ist es agnostisch im Hinblick auf die Applikation, die es nutzt; ein POSIX-kompatibles Dateisystem zwischen der Applikation und einem DRBD-Laufwerk machen es möglich.

Noch mal anders ist die Situation, wenn man ein Setup mit einem modernen Objektspeicher wie Ceph betreibt. Ceph selbst bietet ab Werk etwa keine Features zur Replikation hin zu einem zweiten Standort. Stattdessen sollen Admins das Ceph Object Gateway nutzen, um ausgewählte Teile des Ceph-Datensates zu einem Standort zu spiegeln. Wer Daten von virtuellen Ceph-Blockgeräten kopieren muss, greift alternativ zu rbd-mirror, das die Ceph-Entwickler für eben diese Aufgabe zur Verfügung stellen.

Viel zu tun bei Hot Standby

Wer ein Hot-Standby-Setup fahren möchte, muss gleich mehrere Bedingungen erfüllen: Das zweite Setup sollte dem ersten möglichst ähnlich sein, und zwar sowohl was Hard- als auch Software angeht. Obendrein müssen die Daten zwischen den beiden Standorten während des laufenden Betriebs kontinuierlich so synchron wie möglich sein. Wegen der bereits erwähnten Latenz-Problematik wird volle Synchronität kaum funktionieren; manche Daten treten beim Schwenk von einer ausgefallenen Site hin zum Ersatz zwangsläufig den Weg in die ewigen Jagdgründe an. Ein Zeitsprung ist meist unvermeidlich, das Ziel besteht daher darin, ihn so klein wie möglich zu halten.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
 Disaster Recovery: Für die Katastrophe gewappnetCold Standby als Alternative 
  1.  
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7.  


Aktuell auf der Startseite von Golem.de
Feldversuch E-Mobility-Chaussee
So schnell bringen E-Autos das Stromnetz ans Limit

Das Laden von Elektroautos stellt Netzbetreiber auf dem Land vor besondere Herausforderungen. Ein Pilotprojekt hat verschiedene Lösungen getestet.
Ein Bericht von Friedhelm Greis

Feldversuch E-Mobility-Chaussee: So schnell bringen E-Autos das Stromnetz ans Limit
Artikel
  1. Encrochat-Hack: Damit würde man keinen Geschwindigkeitsverstoß verurteilen
    Encrochat-Hack
    "Damit würde man keinen Geschwindigkeitsverstoß verurteilen"

    Der Anwalt Johannes Eisenberg hat sich die Daten aus dem Encrochat-Hack genauer angesehen und viel Merkwürdiges entdeckt.
    Ein Interview von Moritz Tremmel

  2. Geforce Now (RTX 3080) im Test: 1440p120 mit Raytracing aus der Cloud
    Geforce Now (RTX 3080) im Test
    1440p120 mit Raytracing aus der Cloud

    Höhere Auflösung, mehr Bilder pro Sekunde, kürzere Latenzen: Geforce Now mit virtueller Geforce RTX 3080 ist Cloud-Gaming par excellence.
    Ein Test von Marc Sauter

  3. SpaceX: Starlink testet Satelliteninternet in Flugzeugen
    SpaceX
    Starlink testet Satelliteninternet in Flugzeugen

    Bald dürften mehrere Flugesellschaften Starlink-Service anbieten. Laut einem Manager soll es so schnell wie möglich gehen.

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • Gaming-Monitore zu Bestpreisen (u. a. Samsung G9 49" 32:9 Curved QLED 240Hz 1.149€) • Spiele günstiger: PC, PS5, Xbox, Switch • Zurück in die Zukunft Trilogie 4K 31,97€ • be quiet 750W-PC-Netzteil 87,90€ • Cambridge Audio Melomonia Touch 89,95€ • Gaming-Stühle zu Bestpreisen [Werbung]
    •  /