In der heutigen IT-Welt ist die Hochverfügbarkeit (HA) von Diensten und Daten nicht nur ein „nice-to-have“, sondern eine absolute Notwendigkeit. Niemand möchte Ausfallzeiten erleben, sei es bei einer Datenbank, einem Dateiserver oder einer virtuellen Maschine. Genau hier kommt eine beeindruckende Open-Source-Lösung ins Spiel, die ich Ihnen heute näherbringen möchte: DRBD – Distributed Replicated Block Device. Wenn Sie sich gefragt haben, wer Erfahrung mit DRBD hat und die ersten Schritte verständlich erklären kann, dann sind Sie hier genau richtig. Ich nehme Sie mit auf eine Reise, die Ihnen zeigt, wie Sie Ihre Daten widerstandsfähiger machen können.
Vielleicht kennen Sie das Szenario: Sie betreiben einen kritischen Dienst auf einem Server und stellen sich die Frage: Was passiert, wenn diese Maschine plötzlich ausfällt? Wie schnell kann ich den Dienst wieder online bringen? Traditionelle Lösungen wie Shared Storage sind oft teuer und komplex. DRBD bietet hier eine elegante und kostengünstige Alternative, indem es eine blockbasierte Replikation zwischen zwei Servern ermöglicht. Es ist die Basis vieler Open-Source-HA-Cluster und ein echter Game-Changer für die Zuverlässigkeit Ihrer Infrastruktur.
Was ist DRBD überhaupt und warum sollte ich es nutzen?
Stellen Sie sich DRBD als eine Art Netzwerkkabel vor, das zwei Festplatten auf unterschiedlichen Servern miteinander verbindet, sodass sie immer den gleichen Inhalt haben. Technisch gesprochen ist DRBD ein Kernel-Modul, das eine block-level Replikation von Daten über ein Netzwerk hinweg ermöglicht. Es dupliziert Änderungen auf einer lokalen Block-Device-Partition synchron oder asynchron auf eine identische Partition auf einem anderen Host.
Das Besondere daran ist, dass DRBD ein virtuelles Block-Gerät erstellt (z.B. `/dev/drbd0`), das Sie genau wie eine physikalische Festplatte oder Partition behandeln können. Auf diesem DRBD-Gerät können Sie dann ein Dateisystem anlegen (z.B. ext4, XFS), oder es direkt als Rohdatenträger für Datenbanken oder virtuelle Maschinen nutzen. Einer der beiden Server agiert dabei als Primärsystem (lesen/schreiben), der andere als Sekundärsystem (schreibgeschützt, wartet auf Umschaltung).
Die Vorteile liegen auf der Hand:
- Kosteneffizienz: Sie benötigen keine teure Shared-Storage-Hardware wie Fibre Channel SANs. Standard-Server und eine gute Netzwerkverbindung genügen.
- Ausfallsicherheit: Bei einem Ausfall des Primärservers kann der Sekundärserver die Rolle übernehmen und den Dienst mit den identischen Daten fortsetzen.
- Einfachheit: Im Vergleich zu vielen Enterprise-Lösungen ist DRBD relativ einfach zu konfigurieren und zu verwalten.
- Flexibilität: Es ist Open Source und läuft auf Linux-Systemen, was eine hohe Anpassungsfähigkeit ermöglicht.
- Synchrone Replikation: Im Standardmodus (Protokoll C) wird jede Schreiboperation erst dann als abgeschlossen gemeldet, wenn sie auf *beiden* Servern erfolgreich geschrieben wurde. Das garantiert keinen Datenverlust bei einem Ausfall.
Die Voraussetzungen: Was brauche ich, um mit DRBD zu starten?
Bevor wir uns in die Konfiguration stürzen, lassen Sie uns klären, was Sie für Ihre ersten DRBD-Schritte benötigen:
- Zwei Linux-Server: Idealerweise mit identischer Hardware und der gleichen Linux-Distribution (z.B. Debian, Ubuntu, CentOS, RHEL). Wir nennen sie Node A (Primär) und Node B (Sekundär).
- Dedizierte Block-Geräte: Auf jedem Server benötigen Sie eine physikalische Partition oder eine Logical Volume (LV), die *nicht* anderweitig genutzt wird und in der Größe identisch ist. Zum Beispiel
/dev/sdb1oder ein LV wie/dev/vgdata/lvdrbd. Diese Geräte dürfen kein Dateisystem enthalten, DRBD wird es darauf erstellen. - Netzwerkkonnektivität: Eine schnelle, zuverlässige Netzwerkverbindung zwischen den beiden Servern ist essenziell. Für Produktionsumgebungen empfiehlt sich eine dedizierte Netzwerkschnittstelle nur für die DRBD-Replikation, um Konflikte mit dem Anwendungsnetzwerk zu vermeiden und die Leistung zu optimieren. Stellen Sie sicher, dass Firewalls (z.B. UFW, Firewalld, iptables) den DRBD-Port (standardmäßig 7788) auf beiden Seiten zulassen.
- Grundlegende Linux-Kenntnisse: Umgang mit der Kommandozeile, Editoren wie
nanoodervimund Paketmanagement (aptoderyum/dnf). - Root-Rechte: Alle Schritte erfordern Administratorrechte.
Für dieses Tutorial gehen wir davon aus, dass unsere beiden Server node-a.example.com (IP: 192.168.1.10) und node-b.example.com (IP: 192.168.1.11) heißen und jeweils eine ungenutzte Partition /dev/sdb1 besitzen.
Erste Schritte: DRBD installieren
Die Installation von DRBD ist auf den meisten gängigen Linux-Distributionen recht unkompliziert. Sie müssen die DRBD-Tools und das Kernel-Modul installieren.
Auf beiden Servern ausführen:
Debian/Ubuntu:
sudo apt update sudo apt install drbd-utils
drbd-utils installiert die notwendigen Benutzertools und Abhängigkeiten, einschließlich des Kernel-Moduls.
CentOS/RHEL/Fedora:
sudo dnf install drbd-utils kmod-drbd
Hier müssen Sie oft explizit kmod-drbd installieren, um das Kernel-Modul zu erhalten. Bei älteren CentOS-Versionen müssen Sie möglicherweise das EPEL-Repository aktivieren.
Nach der Installation sollten Sie überprüfen, ob das DRBD-Kernel-Modul geladen ist:
sudo modprobe drbd lsmod | grep drbd
Wenn drbd in der Ausgabe erscheint, ist das Modul erfolgreich geladen.
Konfiguration: Das Herzstück von DRBD
Die Konfiguration von DRBD erfolgt über Konfigurationsdateien. Früher war dies oft eine einzelne /etc/drbd.conf. Heutzutage ist es üblicher, Ressourcen in separaten Dateien unter /etc/drbd.d/ zu definieren. Das macht es übersichtlicher. Wir erstellen eine neue Konfigurationsdatei für unsere Ressource.
Auf beiden Servern die Datei /etc/drbd.d/r0.res erstellen oder bearbeiten:
sudo nano /etc/drbd.d/r0.res
Fügen Sie den folgenden Inhalt ein (passen Sie die Hostnamen, IPs und Gerätenamen an Ihre Umgebung an):
resource r0 {
protocol C; # Synchrone Replikation: Keine Datenverluste
on node-a.example.com {
device /dev/drbd0;
disk /dev/sdb1; # Das physikalische Block-Gerät auf Node A
address 192.168.1.10:7788; # IP und Port von Node A
meta-disk internal; # Metadaten werden auf /dev/sdb1 gespeichert
}
on node-b.example.com {
device /dev/drbd0;
disk /dev/sdb1; # Das physikalische Block-Gerät auf Node B
address 192.168.1.11:7788; # IP und Port von Node B
meta-disk internal;
}
handlers {
# Optional: Skripte, die bei bestimmten Ereignissen ausgeführt werden
# z.B. bei Split-Brain, Connection-Loss etc.
}
disk {
# Optional: Optionen für das zugrundeliegende Block-Gerät
# z.B. no-disk-flushes;
}
net {
# Optional: Netzwerk-spezifische Optionen
# z.B. allow-two-primaries; (Vorsicht! Nur mit Quorum-Manager)
}
syncer {
# Optional: Optionen für die Synchronisation
# rate 100M; # Max. Bandbreite für Synchronisation
}
}
Erklärung der wichtigsten Parameter:
resource r0: Definiert eine DRBD-Ressource mit dem Namenr0. Sie können mehrere Ressourcen haben.protocol C: Dies ist der Standard und die empfohlene Einstellung für synchrone Replikation. Jede Schreiboperation wird erst als erfolgreich gemeldet, wenn sie auf beiden Knoten bestätigt wurde.on [hostname]: Definiert die Einstellungen für den jeweiligen Host.device /dev/drbd0: Dies ist das virtuelle DRBD-Gerät, das erstellt wird. Es ist der Name, den Sie später für Dateisysteme verwenden.disk /dev/sdb1: Dies ist das physikalische Block-Gerät auf dem jeweiligen Server, das von DRBD genutzt wird.address [IP]:[Port]: Die IP-Adresse des jeweiligen Servers und der Port, über den DRBD kommuniziert. Standard ist 7788.meta-disk internal: Die Metadaten von DRBD (wo die Daten zuletzt geschrieben wurden, DRBD-Status etc.) werden am Ende der physikalischen Partition gespeichert. Alternativ kann manexternalnutzen, wenn man eine separate kleine Partition für Metadaten verwenden möchte (oft 128 MB). Für den Anfang istinternalvöllig ausreichend.
Stellen Sie sicher, dass die Hostnamen in der Konfiguration exakt mit den Ausgaben von hostname -f (Fully Qualified Domain Name) oder hostname -s (Short Name) übereinstimmen, je nachdem, welche Sie in Ihrer DRBD-Konfiguration verwendet haben.
DRBD initialisieren und synchronisieren
Nachdem die Konfigurationsdatei auf beiden Servern identisch ist, können wir DRBD zum Leben erwecken.
Auf beiden Servern ausführen:
sudo drbdadm create-md r0
Dieser Befehl initialisiert die Metadaten auf den physikalischen Block-Geräten. Bestätigen Sie die Frage mit yes. Tun Sie dies *nicht*, wenn sich bereits wichtige Daten auf dem Gerät befinden! Der Befehl überschreibt Teile des Geräts!
Auf beiden Servern ausführen:
sudo drbdadm up r0
Dieser Befehl aktiviert die Ressource r0. Die Server versuchen nun, eine Verbindung herzustellen.
Sie können den Status überprüfen mit:
sudo drbdadm status r0 # oder allgemeiner cat /proc/drbd
In der Ausgabe sollte etwas wie WFConnection oder Connected erscheinen. Einer der Knoten wird den Status Secondary/Unknown haben, der andere Secondary/Secondary.
Jetzt müssen wir einen Knoten zum Primärsystem erklären, damit die Erstsynchronisation stattfindet. Dies muss nur auf *einem* der beiden Server geschehen, vorzugsweise auf demjenigen, der eventuell bereits Daten enthält (wenn Sie Daten migrieren möchten) oder der, den Sie als „original” betrachten.
Nur auf dem Server, der der Primär werden soll (z.B. node-a):
sudo drbdadm primary --force r0
Der --force-Parameter ist bei der Erstinitialisierung notwendig, da DRBD sonst nicht weiß, welche Seite die „Gültige” ist. Nach der ersten Zuweisung ist er nicht mehr nötig.
Überprüfen Sie den Status erneut:
sudo drbdadm status r0 # oder cat /proc/drbd
Sie sollten sehen, dass node-a jetzt den Status Primary/Secondary hat und node-b den Status Secondary/Primary. Ein wichtiger Indikator ist die Synchronisation: UpToDate/Cutsync oder UpToDate/Inconsistent am Anfang und dann UpToDate/UpToDate, sobald die Synchronisation abgeschlossen ist.
Die Synchronisation kann je nach Größe des Geräts und Netzwerkgeschwindigkeit eine Weile dauern. Der Fortschritt wird ebenfalls in /proc/drbd angezeigt.
Das DRBD-Gerät nutzen: Dateisystem erstellen
Sobald die Synchronisation abgeschlossen ist und beide Knoten den Status UpToDate/UpToDate anzeigen, können Sie das DRBD-Gerät nutzen.
Wichtig: Dateisysteme dürfen immer nur auf dem *Primär*-Knoten erstellt und gemountet werden! Niemals auf einem Sekundär-Knoten versuchen zu mounten (es sei denn, Sie haben allow-two-primaries konfiguriert, was aber spezielle Cluster-Software und erweiterte Kenntnisse erfordert!).
Nur auf dem Primärserver (z.B. node-a):
sudo mkfs.ext4 /dev/drbd0
Jetzt können Sie einen Mount-Punkt erstellen und das Dateisystem mounten:
sudo mkdir /mnt/data sudo mount /dev/drbd0 /mnt/data
Sie können nun Daten in /mnt/data schreiben. Diese Daten werden synchron auf node-b repliziert.
Um einen manuellen Failover zu testen (was bei DRBD bedeutet, die Rollen zu wechseln):
Auf node-a (Primär):
sudo umount /mnt/data sudo drbdadm secondary r0
Auf node-b (Sekundär):
sudo drbdadm primary r0 sudo mount /dev/drbd0 /mnt/data
Herzlichen Glückwunsch! Sie haben erfolgreich einen manuellen Failover durchgeführt. Die Daten, die Sie zuvor auf node-a geschrieben haben, sollten jetzt auf node-b unter /mnt/data sichtbar sein.
Wichtige DRBD-Befehle im Überblick
Hier sind einige weitere nützliche Befehle für den täglichen Umgang mit DRBD:
sudo drbdadm status [r0]: Zeigt den aktuellen Status einer oder aller DRBD-Ressourcen.sudo drbdadm down r0: Deaktiviert die Ressourcer0. Trennt die Verbindung und nimmt das virtuelle Gerät vom Netz.sudo drbdadm disconnect r0: Trennt die Netzwerkverbindung, hält aber das Gerät lokal aktiv.sudo drbdadm connect r0: Versucht, die Verbindung nach einemdisconnectwiederherzustellen.sudo drbdadm adjust r0: Wendet Änderungen an der Konfigurationsdatei an, ohne die Ressource komplett herunterzufahren und wieder zu starten.
Häufige Stolpersteine und Tipps aus der Praxis
DRBD ist robust, aber es gibt ein paar Dinge, auf die man achten sollte:
- Netzwerk: Eine stabile, schnelle und latenzarme Netzwerkverbindung ist das A und O. Probleme hier führen zu Leistungseinbußen oder Verbindungsabbrüchen. Firewalls müssen den DRBD-Port immer zulassen!
- Split-Brain: Dies ist das Worst-Case-Szenario. Es tritt auf, wenn beide Knoten glauben, Primärsystem zu sein, weil die Netzwerkverbindung zwischen ihnen unterbrochen wurde und sie sich nicht mehr synchronisieren konnten. DRBD erkennt dies und trennt die Verbindung, um Datenkorruption zu verhindern. Die Lösung erfordert manuelles Eingreifen (Entscheidung, welche Seite die „gültige” ist und Synchronisation von dieser Seite aus erzwingen). Im produktiven Einsatz wird dies durch einen Cluster-Manager (z.B. Pacemaker/Corosync) verhindert, der Mechanismen wie Fencing (automatisches Abschalten eines Knotens bei Netzwerkproblemen) implementiert. Für die ersten Schritte ist es wichtig, den Begriff zu kennen und die Gefahr zu verstehen.
- Metadaten: Die DRBD-Metadaten sind entscheidend. Beschädigen Sie diese nicht. Vermeiden Sie es, Partitionen, die von DRBD genutzt werden, manuell zu manipulieren oder zu formatieren.
- Testen, Testen, Testen: Simulieren Sie Ausfälle regelmäßig. Ziehen Sie Netzwerkkabel, fahren Sie einen Server hart herunter. Nur so stellen Sie sicher, dass Ihr Setup wirklich funktioniert.
- Monitoring: Überwachen Sie den DRBD-Status (
cat /proc/drbdoderdrbdadm status) und die Systemressourcen (Plattenplatz, CPU, RAM, Netzwerk).
DRBD und High Availability – Der nächste Schritt
Was wir hier gelernt haben, ist die Basis. DRBD selbst bietet keine automatische Failover-Funktionalität. Es repliziert lediglich die Daten. Wenn der Primärserver ausfällt, müssen Sie manuell eingreifen, um den Sekundärserver zum Primär zu machen und das Dateisystem zu mounten.
Für eine vollautomatische Hochverfügbarkeit benötigen Sie zusätzlich einen Cluster-Manager wie Pacemaker und Corosync. Pacemaker überwacht den Zustand Ihrer DRBD-Ressourcen, des Primärservers und der Dienste, die auf DRBD basieren. Im Falle eines Ausfalls kann Pacemaker automatisch den Sekundärserver zum Primär heraufstufen, das Dateisystem mounten und die Anwendung starten. Dies ist das übliche Setup für Produktionsumgebungen, aber ein Thema für einen weiteren detaillierten Artikel.
Fazit
DRBD ist eine mächtige und vielseitige Lösung, um Ihre Speichersysteme hochverfügbar zu machen. Die ersten Schritte, wie wir sie hier durchlaufen haben, sind grundlegend und bieten einen soliden Einblick in die Funktionsweise. Mit einer verständlichen Installation und Konfiguration haben Sie jetzt eine redundante Speicherschicht geschaffen, die Ihnen ein hohes Maß an Datensicherheit bietet.
Zögern Sie nicht, mit DRBD zu experimentieren. Bauen Sie sich ein kleines Testlabor auf, folgen Sie den Schritten in diesem Artikel und sehen Sie selbst, wie zuverlässig diese Technologie ist. Die Welt der hochverfügbaren Systeme mag komplex erscheinen, aber mit Tools wie DRBD ist der Einstieg leichter als gedacht. Viel Erfolg beim Meistern Ihrer hochverfügbaren Infrastruktur!