OCFS und DRDB (Teil I) - Neue Funktionen in DRBD 8.0:

Keine Angst vor Split-Brain!

Die elegante Open Source Lösung DRBD hilft, kostengünstig Shared Storage zur Verfügung zu stellen. In diesem Artikel stellen wir einige neue und nützliche Funktionen der aktuellen Version 8.0 vor.

global {
usage-count yes;
}

resource data1 {

net {
allow-two-primaries;
cram-hmac-alg "sha1";
shared-secret "SuperStrengGeheim";
after-sb-0pri disconnect;
}

  on suse1 {
    device     /dev/drbd0;
    disk       /dev/xvdb2;
    address    10.1.1.1:7788;
    meta-disk  /dev/xvdb1[0];
}
  on suse2 {
    device    /dev/drbd0;
    disk      /dev/xvdb2;
    address   10.1.1.2:7788;
    meta-disk /dev/xvdb1[0];
}
}

Befehle, Quellcode

disconnect

discard-younger-primary

discard-older-primary

discard-least-changes

discard-node-Knotenname

In vielen Netzwerkumgebungen stellt sich die Frage nach gemeinsam genutztem Storage. Implementiert man die Speicherhaltung lokal auf einem System, hat man bei einem Systemausfall das Problem, die Daten erst mühselig aus dem Backup auf ein anderes System zu übertragen. Nutzt man Lösungen wie SAN oder InfiniBand, muss man ziemlich tief in den Geldbeutel greifen. Die Open Source Lösung DRBD hilft, kostengünstig gemeinsam genutzten Speicher zur Verfügung zu stellen.

In diesem Artikel stellen wir Ihnen einige neue und nützliche Funktionen der aktuellen Version 8.0 vor. In einer der kommenden Ausgaben wird dann die Funktion des "Dual Primary Mode" in Verbindung mit Cluster-Dateisystemen weiter vertieft. Abbildung 1 gibt einen Überblick darüber, was sich eigentlich hinter DRBD verbirgt.

DRBD - Quantensprung und der Weg in den Kernel

Um DRBD nutzen zu können, werden ein Kernel-Modul und Verwaltungsbefehle benötigt. DRBD ist aktuell noch nicht im Vanilla-Linux-Kernel enthalten, aber einige Hersteller liefern ihre Distribution mit DRBD-Implementierung aus. Nutzt man ein SuSE Linux, ist DRBD schon enthalten, unter einem Red Hat Enterprise Server ist DRBD noch nicht enthalten. DRBD, ursprünglich als Diplomarbeit des Österreichers Philipp Reisner entwickelt, wird mittlerweile von seiner Firma LINBIT [1] weiterentwickelt. Auch eine kommerzielle Variante namens DRBD+ mit speziellen Funktionen ist verfügbar. Die DRBD-Entwickler baten vor kurzem um die Aufnahme in den offiziellen Linux-Kernel und wurden, sofern einige Änderungen am Programmierstil gemacht würden, auf später vertröstet. Etwas gewöhnungsbedürftig ist auch die Versionsbezeichnung: Auf Version 0.7 folgte die Version 8.0, in der vor allem Administratoren der alten Versionen mit geänderten Einstellungen zu kämpfen haben, gleichzeitig aber auch mit sinnvollen neuen Funktionen belohnt werden.

Usage - Wir wissen Bescheid

Eine der ersten, auffälligen Funktionen der Version 8.0 ist der Eintrag usage-count yes (siehe Abbildung 2) in den globalen Einstellungen der Konfigurationsdatei von DRBD /etc/drbd.conf. Dieser Eintrag kann die Einstellungen yes, no oder ask annehmen. Legt man ein neues DRBD an, wird je nach Einstellung dieses Eintrags gefragt, ob Informationen über dieses Blockdevice bei LINBIT registriert werden sollen. Hiermit möchten die Entwickler die Anzahl der Benutzer, die DRBD nutzen, erfassen. Auf der Internetseite des Projekts [2] kann man sich die Statistiken ansehen. Aktuell werden pro Tag über 100 DRBD-Installationen vorgenommen und registriert. Auch ist zu sehen, dass die Größe der DRBD-Devices zunimmt. Aktuell gibt es schon Größenordnungen zwischen 10 und 20 Terabyte. Unbekannt ist die Dunkelziffer der nicht registrierten Installationen.

Auf "Nummer sicher"

DRBD nutzt nur eine einzige Leitung für die Replikation der Daten und die Datenkommunikation. In der Praxis wird hier eine private Leitung (Crossover-Kabel) zwischen den beiden Knoten genutzt. Da der Weg dieser Leitung oft über mehrere Switches und Router geht, besteht Gefahr durch ein Eindringen von Außen in das private DRBD-Netzwerk. Durch Emulieren des DRBD-Netzwerkprotokolls könnte nun der Datenverkehr zwischen den DRBD-Knoten gestört oder sogar verändert werden.

Abhilfe schafft hier der neue Eintrag shared-secret (siehe Abbildung 2), der bis zu 64 Zeichen lang sein kann. Hier kann eine Passphrase eingestellt werden, mit der die übertragenen Pakete zwischen den DRBD-Knoten authentifiziert werden. Mit dem Schalter cram-hmac-alg kann der Hash-Algorithmus gewählt werden. Mögliche Werte sind z. B. md5, sha1, sha256, sha512, wp256, wp384, wp512. Will man nicht nur gegenseitige Authentifizierung, sondern auch eine Verschlüsselung der übertragenen Daten, muss dies weiterhin mit Linux-Bordmitteln, wie IPSEC oder OpenVPN, implementiert werden.

Split-Brain - Schizophrenie des Clusters

Eine der am meisten gefürchteten Situationen bei DRBD ist eine Split-Brain-Situation. Diese kommt zustande, wenn die private Leitung zwischen den beiden DRBD-Knoten unterbrochen ist, diese den jeweiligen Status des anderen nicht mehr erfragen und auch keine Daten mehr schreiben können. Nun besteht die Gefahr, plötzlich zwei primäre DRBD-Devices zu haben und diese entweder manuell oder per Cluster-Software zu mounten.

Wenn jetzt die private Leitung wieder verfügbar ist, stellt sich die Frage, wie DRBD die Situation auflöst. Unter der Version 0.7 gab es die Funktion "Automatic split brain recovery". Hierbei wurden automatisch alle Daten des jüngeren DRBD-Devices verworfen. Dieses Verhalten konnte auch nicht geändert werden. In der Version 8.0 kann jetzt ganz individuell entschieden werden, was nun passieren soll. Hierzu gibt es den neuen Eintrag after-sb-0pri (siehe Abbildung 2). Die möglichen Werte hierfür finden Sie in Abbildung 3.

Dual Primary Mode

Bei DRBD hatte man in den alten Versionen die Problematik, dass das DRBD-Device immer nur auf einem der beiden Knoten eingebunden werden konnte, nämlich auf der Primärseite. Auf dem Secondary schlug jeder Versuch fehl. Noch nicht einmal ein Read Only Mount war möglich.

Gerade wenn man DRBD in Verbindung mit einem Active/Active-Cluster einsetzen will, ist dies ein Problem, da nicht auf beiden Clusterhälften auf die Dateisysteme zugegriffen werden kann. Dies ändert nun in der Version 8.0 der neue Eintrag allow-two-primaries in der Konfigurationsdatei (siehe Abbildung 2). Ist dieser Eintrag in der Konfigurationsdatei der beiden DRBD-Knoten enthalten, kann nun auf beiden Knoten die Ressource data1 mit dem Befehl drbdadm primary data1 zum Primary gemacht werden. Zu beachten ist hierbei, dass man nicht einfach irgendein beliebiges Dateisystem auf dem DRBD erstellt. Wichtig ist, dass dieses Dateisystem auch clusterfähig ist. Mögliche Dateisysteme wären hier OCFS2 oder GFS2.

Fazit

In diesem Artikel haben wir einige der neuen Funktionen der Version 8.0 vorgestellt. Schaut man auf der Projekt-Webseite [2] oder in die aktuellen Manual Pages, wird man feststellen, dass sich in der Version 8.0 noch einiges mehr verändert hat. Die Aufnahme in den offiziellen Linux-Kernel lässt erwarten, dass sich DRBD vor allem auch über die Teichgrenzen hinweg weiter verbreiten wird. Für die Version 9 von DRBD ist die Unterstützung von mehr als zwei Knoten geplant. Auch der Blick auf die kommerzielle Version lohnt sich allemal, da hier noch einige zusätzliche Funktionen implementiert wurden, die vor allem für große Firmenumgebungen nützlich sind, wie z. B. das Backup auf einen dritten Knoten. In einer der nächsten ORDIX News berichten wir über die Nutzung von Cluster-Dateisystemen in Verbindung mit dem Dual Primary Mode.

Christian Fertsch (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen