• IT-Karriere:
  • Services:

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. Stadtverwaltung Kaiserslautern, Kaiserslautern
  2. Fraunhofer-Institut für Software- und Systemtechnik ISST, Dortmund

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)

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.  


Anzeige
Top-Angebote
  1. Seagate Game Drive Xbox GamePass Edition JEDI externe USB-3.0-Festplatte 2TB für 69,99€, Seagate...
  2. Bei Kartenzahlung bis zu 3% auf Amazon-Käufe, bis zu 0,5% auf Käufe außerhalb von Amazon
  3. 1.311,11€ (Bestpreis!)
  4. vom 13. bis 14. Oktober (nur für Prime-Mitglieder)

peddy_hh 13. Mär 2020

Hallo zusammen, also beim Lesen des Artikels hab ich gedacht, ich les was aus dem letzten...

cpi 11. Mär 2020

Der Artikel spricht in erster Linie von Replikation auf Storage Ebene. Und das sind in...


Folgen Sie uns
       


    •  /