• 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. Universität Passau, Passau
  2. Landesbetrieb Mobilität Rheinland-Pfalz, Koblenz

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
Spiele-Angebote
  1. (u. a. Sniper Ghost Warrior 3 - Season Pass Edition für 4,99€, Sherlock Holmes: The Devil's...
  2. 11,99€
  3. 4,19€

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
       


Die Tesla-Baustelle von oben (Januar-November 2020)

Wir haben den Fortschritt in Grünheide dokumentiert.

Die Tesla-Baustelle von oben (Januar-November 2020) Video aufrufen
Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme

      •  /