Hochverfügbarkeit klingt gut und teuer. Unter Linux reichen aber auch bereits Standardkomponenten für ein ausfallsicheres Speichersystem aus vernetzten, räumlich verteilten Blockdevices.

Wenn eine Serverkomponente ausfällt, ist es in einem von zwei Fällen eine Festplatte. Die Hardware ist meist für ein paar hundert Euro ersetzbar, aber schon bei kleinen Unternehmen sind die gespeicherten Daten im Schnitt Hunderttausende wert[1]. Gegen deren Verlust schützt ein Backup. Das rettet die Daten, kostet aber Zeit fürs Recovery und auch der damit verbundene Stillstand kann hohe Kosten verursachen.

Deshalb beugen hochverfügbare Systeme auch dem Zeitverlust vor. Eine ihrer Maximen ist: Der Ausfall eines Teils muss für das Ganze folgenlos bleiben. Ein Speichersystem nach diesem Grundsatz kann unter Linux aus relativ preiswerten Standardkomponenten aufgebaut werden. Das Schlüsselwort dafür heißt ENBD.

Netz-Disks

ENBD ist das Kürzel für Enhanced Network Block Device[2] und bezeichnet eine Erweiterung des Network Block Device[3] von Pavel Machek, das seit der Version 2.1.101 in den Linux-Kernel integriert ist. Beiden gemeinsam ist das Prinzip, Platten (oder nur Partitionen, ja selbst einzelne Dateien) von entfernten, jedoch via Ethernet erreichbaren Rechnern so zu mounten, dass sie wie lokale Disks erscheinen.

Anders als zum Beispiel NFS exportiert ENBD ein Device, kein Filesystem. Das Besondere daran ist, dass sich diese virtuellen Platten wie physikalisch vorhandene auch zu Raid-Gruppen unterschiedlicher Level zusammenfassen lassen. Das Attribut "enhanced" bezieht sich unter anderem auch auf die zusätzliche Fähigkeit von ENBD, eine unterbrochene Verbindung zwischen Client und Server selbstständig wiederherzustellen.

Mit dieser Technik sind Fileserver möglich, die gar keine eigenen Platten haben und stattdessen ihre Disks über voneinander unabhängige Netzwerkverbindungen von verschiedenen Rechnern als ENBD-Laufwerke importieren. Auf diese Weise verteilt sich der Server über mehrere Räume oder Gebäude. Ein solcher Aufbau könnte überleben, selbst wenn durch einen Brand oder Wassereinbruch ein Teil total zerstört würde.

Der ENBD-Server, zuständig für den Export des Device, läuft als normaler Prozess im Userspace. Er kommuniziert über einen frei wählbaren Port mit einem ENBD-Client, der von verschiedenen Seiten solche Devices importiert. Der Datenverkehr lässt sich mit SSL verschlüsseln. Im ENBD-Client teilen sich ein Kernelmodul »enbd.o« und ein Daemon den Job (siehe Abbildung 1). Der Grund dafür ist, dass dem Modul allein nur 1 GByte Speicher zur Verfügung stünde, während sein Kompanion den gesamten physikalisch vorhandenen Speicher benutzen kann.

Abbildung 1: Schematische Darstellung der ENBD-Architektur.

Doppelt gesichert

Im hier vorgestellten Beispiel gibt es drei Backend-Rechner mit jeweils sechs 200- GByte-Disks, von denen fünf zu einer Raid-5-Gruppe zusammengeschlossen sind, während die sechste als Hot-Spare-Platte dient. Beim Ausfall einer Platte aus der Raid-Gruppe springt sie automatisch ein. Der eigentliche Fileserver - das Frontend - mountet diese drei Raid-Gruppen (netto jeweils knapp 800 GByte) und schließt sie seinerseits in einem Raid 5 zusammen.

So wird doppelte Redundanz erreicht: In jedem Backend-System darf eine Platte und im Gesamtverbund ein komplettes Backend-System ausfallen, ohne dass der Betrieb unterbrochen würde oder gar Daten verloren gingen. Um die gleiche Zuverlässigkeit wie bei Geräten von etablierten Herstellern zu erreichen, musste das Projekt allerdings ein eigenes USB-Zusatzgerät entwickeln. Es basiert auf einem Mikroprozessor und einer LCD-Anzeige. Der Mikrokontroller überwacht die Drehzahlen aller Lüfter sowie die Temperaturen an sechs verschiedenen Stellen im Gehäuse.

Das Gerät wird anstelle des Diskettenlaufwerks eingebaut. Sein Display zeigt Daten wie IP-Adresse, Speichernutzung, Hostname und Ähnliches an. Bei Überhitzung, Plattendefekt oder Ausfall eines Lüfters wird der Administrator durch Mail, Syslog oder Ausgabe auf dem Display informiert. Schlimmstenfalls fährt der Rechner herunter, um weiteren Schaden möglichst zu vermeiden.

Zusätzlich ist es möglich, das plattenlose Frontend mehrfach auszu-legen und über einen Heartbeat-Cluster zu sichern (Hinweise unter[4] und[5]). Der Preis für die auf diese Weise erreichbare hohe Fehlertoleranz besteht einerseits in der für Hot Spares und Raid-Gruppen erforderlichen Speicherkapazität: Von 3,6 TByte bleiben nur noch 1,6 TByte (44 Prozent) für Nutzdaten übrig. (Wer zum Beispiel statt drei Backends sechs einsetzt, verbessert das Verhältnis auf rund 70 Prozent.) Der zweite Nachteil: Die doppelte Berechnung der Raid-5-Paritäten kostet Zeit, sprich Performance beim Schreiben.

Die Installation eines derartigen Speichersystems ist nicht übermäßig kompliziert. Der Quellcode der ENBD-Software ist unter[6] erhältlich. Vor dem Übersetzen ist lediglich im Makefile der Pfad zu den Kernelquellen zu aktualisieren und bei Bedarf das SMP-Flag zu setzen. Für Kernelversion 2.6 ist bereits ein Patch verfügbar.

Hochverfügbarkeit klingt gut und teuer. Unter Linux reichen aber auch bereits Standardkomponenten für ein ausfallsicheres Speichersystem aus vernetzten, räumlich verteilten Blockdevices.