DRBD-Replikation

© Khursaini A Fatah, 123RF

Storage für HA-Cluster

Hochverfügbarkeit ist in modernen IT-Setups ein Muss. Ein kritischer Faktor ist dabei das redundante Speichern von Daten. Um dieses Problem kümmert sich LINBITs freies DRBD, das zum vollständigen Ersatz für ein SAN werden kann. Dieser Beitrag beschreibt die brandneue Version 8.4.
Was das Backup wert war, erweist sich, sobald man es versucht ganz oder teilweise wiederherzustellen. Spätestens dann macht sich die Wahl des richtigen Tools ... (mehr)

Computer sind fehleranfällig – eine Binsenweisheit, die schon so manchem Admin schlaflose Nächte bereitet hat. Die Antwort heißt Hochverfügbarkeit. Das ist kein Produkt, sondern vielmehr ein Konzept aus verschiedenen Komponenten. Eine häufige Ausprägung dieses Konzepts ist der sogenannte HochverfügbarkeitsCluster. Er beruht auf dem simplen Prinzip, dass ein zweiter Rechner die Aufgaben eines ausgefallenen Systems übernimmt. Dieser Prozess heißt Failover.

Hochverfügbarkeit

Damit der Failover funktionieren kann, müssen einige Bedingungen erfüllt sein. Allen voran steht die doppelte Transparenz: Der Failover muss sowohl für den Client wie auch für die betroffene Applikation transparent sein. Damit nach der Verlagerung von Diensten auf ein anderes, noch funktionierendes System nicht die IP-Adressen geändert werden müssen, unter denen die Clients die umgezogenen Dienste erreichen, gehört zu einem Failover-Setup typischerweise eine IP-Adresse, die fest mit einem Dienst statt mit einem spezifischen Server verbunden ist. Aber auch die Netzwerkprotokolle müssen mitspielen. Stateless-Protokolle wie HTTP funktionieren perfekt, denn ob eine Antwort auf einen Request von einem oder dem anderen Server zum Client wandert, ist einerlei. Stateful-Protokolle – oft geht es dabei um Datenbanken – müssen sich selbst darum kümmern, dass ihre Clients im Anschluss an einen Failover die Verbindung zu ihrem Dienst wiederherstellen. Sämtliche gängigen Datenbank-Clients haben aber entsprechende Funktionen.

Hochverfügbare Daten

Transparent ist ein Failover für eine Applikation vor allem dann, wenn es für sie keinen Unterschied macht, auf welchem Rechner eines Hochverfügbarkeitsclusters sie läuft. Idealerweise sind auf allen Servern die gleichen Versionen der Applikation vorhanden, außerdem müssen sämtliche wichtigen Konfigurationsdateien identisch sein. Der wichtigste Faktor sind aber die Daten, die die Applikation verwendet. Niemandem wäre geholfen, würde die Applikation auf dem überlebenden Knoten nicht mit denselben Daten weiterarbeiten können, die vorher der ausgefallenen Instanz zur Verfügung standen.

Die klassische Lösung für dieses Problem sind SANs. Hauptbestandteil eines SAN ist im einfachsten Fall ein einzelner Computer mit vielen Festplatten und einem speziellen Storage-Controller, der seine Daten den Clients im angrenzenden Netz direkt zur Verfügung stellt – beispielsweise mittels iSCSI oder NFS. Typische SANs sind aber auch Single Points of Failure, weil die Daten verloren sind, sollte das komplette System trotz interner Redundanz abgeschaltet werden müssen oder ein Concurrent Write stattfinden – also gleichzeitiger, unkoordinierter Schreibzugriff von zwei Seiten. Beides ist zwar nicht hochwahrscheinlich, aber auch nicht ausgeschlossen. Beispielsweise kann ein Brand im Rechenzentrum dazu zwingen, die Stromversorgung komplett zu unterbrechen.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023