Open-Source-Tools helfen Administratoren

Linux-Cluster in der Praxis

30.06.2008
Von  und Thomas Steudten
Oliver Häußler arbeitet als freier Journalist und Moderator in der IT- und Telekommunikationsbranche. Seine journalistischen, wirtschaftlichen und technischen Erfahrungen sammelte der Kommunikationswissenschaftler während seiner über 20 Jahre langen Tätigkeit als Chefredakteur von renommierten Fachzeitschriften wie der Funkschau, FunkschauHandel, NetworkWorld und als Moderator von Kongressen, Webcasts und zahlreichen Podiumsdiskussionen.

Anwendungen für DRBD

Mit DRBD lässt sich beispielsweise der Zugriff auf eine Datenbank an einer Firmenaußenstelle optimieren, indem eine Kopie der Daten vor Ort gehalten wird. Kopie heißt in diesem Fall kein Zugriff, so lange die originale Datenbank, das heißt das Blockdevice, im Status "primary" aktiv ist. Im Fehlerfall würde die Datenbank diese gespiegelten Daten nutzen und so den Service aufrechterhalten können.

Ein Webserver in Amerika kann seine Daten auf einen Webserver in Europa spiegeln und so den Zugriff im Fehlerfall auf den europäischen Server umlegen. Eine re-dundante Datenhaltung ist in den meisten Clustern eine Grundvoraussetzung.

Ohne DRBD wird dies in Form von so genannten shared Storages realisiert, also gemeinsam genutztem Speicher (SAN). Dieser Speicher muss, da nur einmal vorhanden, im Storage-System (SAN) gespiegelt werden (Raid 1, Raid 5), um redundant vorhanden zu sein.

Mit DRBD lässt sich diese doppelte oder dreifache (DRBD+) Datenhaltung im Gegensatz zu einem hochverfügbaren Storage Area Network auch mit preiswerten Standard-Festplatten realisieren.

Funktionsweise in der Praxis

DRBD arbeitet bis Version 0.7 nach dem Primary-Secondary-Prinzip (analog Master-Slave) und kopiert Blöcke immer vom primären zum sekundären System, wobei die Rollenverteilung dynamisch verändert werden kann. In der Regel kommt ein Blockdevice ("/dev/sdXy"), also eine Partition der Festplatte oder gar die ganze Festplatte zum Einsatz.

In den meisten Linux-Distributionen ist DRBD bereits in den Kernel integriert (als Modul "drbd"). Wird das Modul in den Kernel geladen, stehen die Device-Knoten "/dev/drbdX" zur Verfügung – je nach Einstellung in der Konfigurationsdatei "/etc/drbd.conf" (siehe Kasten "Device-Knoten" auf der nächsten Seite). Hier ist das Modul "drbd” in den Kernel geladen, es sind zwei DRBD-Devices angelegt und die Kernel-Prozesse sind gestartet.

Damit sind die wesentlichen Voraussetzungen für die Funktion bereits gegeben. Je nachdem, welches DRBD-Device in der Konfiguratiosdatei zugeordnet wurde, sind pro Device die drei Prozesse aktiv:
• zdrbdX_receiver
• zdrbdX_asender
• zdrbdX_worker X:0..n