von Max Lessel

Viele Einsatzszenarien von NAS-Server erlauben keine oder nur minimale Ausfälle. Der übliche Standalone-Fileserver verfügt jedoch über keine Hochverfügbarkeits-Funktionen. Linux kann auf einige vergleichsweise simple Funktionen zurückgreifen, die sowohl die Verfügbarkeit als auch die Performance eines NFS- oder CIFS-Fileservers wesentlich verbessern. Dem Anwender stehen dabei zwei Optionen offen: Ein simpler Aktiv/Passiv-Spiegel oder der komplexere Cluster-Betrieb. In diesem Workshop stellt speicherguide.de beide Verfahren vor, dabei jedoch nicht komplett in die Konfigurationsdetails der Lösungen abtauchen, Das würde für jeden Ansatz einen eigenen, mehrteiligen Workshop erfordern. Im Anhang des Artikels weisen Links auf ausführliche How-to-Dokumente im Internet.

Gespiegelte Server

Die einfache Hochverfügbarkeitslösung für Linux-Fileserver offeriert Ausfallsicherheit aber keine Verbesserung der Performance. Dabei kommen zwei Server mit lokalen Platten zum Einsatz, wobei einer als passiver Standby-Node nur dann den Betrieb aufnimmt, wenn der primäre Node ausfällt. Die Grundlage für diesen Modus ist das »Distributed Replicated Block Device« (DRDB). Dieser Kernel-Treiber klinkt sich zwischen das Dateisystem und eine Partition oder ein LVM-Volume. Alle Schreibzugriffe auf dem primären Server fängt DRDB ab und spiegelt diese synchron auf den sekundären Rechner. Das gespiegelte Dateisystem ist dort im regulären Betrieb erst einmal nicht gemounted.

Beide Server verfügen über eine eigene IP-Adresse für Konfiguration und Administration. Der eigentliche CIFS- oder NFS-Server nutzt jedoch eine virtuelle IP-Adresse. Bei einem Failover übernimmt der sekundäre Server diese IP. Zudem sind beide Maschinen über eine private Datenverbindung miteinander gekoppelt. Das könnte sowohl ein serieller Nullmodem-Link, als auch ein zweiter LAN-Adapter mit einer Punkt-zu-Punkt-Verbindung sein. Diese Verbindung nutzt das Linux-HA-Software-Paket »Heartbeat«.

Kann der Heartbeat-Service auf dem passiven Node keine Verbindung mehr zum primären Node aufbauen, startet er das Failover-Skript. Dieses pausiert den DRDB-Dienst, mounted das gespiegelte Volume, aktiviert die virtuelle IP-Adresse auf dem LAN-Adapter und fährt den NFS oder CIFS-Dienst hoch. Zudem sorgt Hearbeat für einen kontrollierten Failback. Kehrt der primäre Server zurück, dreht Heartbeat den DRDB-Betrieb um und spiegelt die zwischenzeitlichen Änderungen des Dateisystems auf den primären Node zurück. Dann erfolgt die Übergabe der Dienste.

Die Kombination DRDB und Heartbeat arbeitet relativ unabhängig vom verwendeten Service. Das Spiegel-Setup lässt sich nicht nur für Fileserver, sondern auch für Web- Datenbank- oder Mailserver verwenden. DRDB kennt zudem einen asynchronen Spiegelmodus für langsamere Verbindungen und lässt sich daher auch für WAN-Replikationen von Filialen zu Zentralen verwenden.

Fileserver im Cluster

Komplexer stellt sich ein Cluster-Szenario dar. Hierbei liegen die eigentlichen Daten auf einem SAN-Laufwerk mit FC- oder iSCSI-Anbindung. Darauf arbeitet ein Cluster-Dateisystem wie GPFS (IBM), GFS2 (Redhat), Lustre (Sun) oder OCFS2 (Oracle). Das Cluster-Dateisystem liefert den Record- und Block-Locking-Mechanismus, damit mehrere Server parallel auf ein Dateisystem schreiben können, ohne sich gegenseitig die Dateien zu zerschießen. Mehrere NFS/CIFS-Nodes greifen simultan auf das Cluster-Dateisystem zu. Alle Nodes verwenden eine virtuelle IP-Adresse und übernehmen im Round-Robin-Verfahren abwechselnd eingehende Verbindungen.

Im Klartext bedeutet das, dass eine einzelne Client-Server-Verbindung nicht schneller als bei einem Einzelserver arbeitet jedoch die Last vieler NFS/CIFS-Clients sich auf die vorhandenen Nodes verteilt und damit die kumulierte Performance aller Verbindungen steigt. Zudem kann ein einzelner Cluster-Node ausfallen, ohne dass Daten verloren gehen. Abgebrochene Verbindungen landen nach einem Reconnect dann auf einem anderen Server.

Anders als bei der DRDB-Spiegelung setzt der Cluster-Betrieb jedoch voraus, dass der verwendete Dienst (NFS oder CIFS) selbst Clusterfähig arbeitet. Der Samba-Service nutzt im Standalone-Betrieb das »Trivial Database System« (TDB) ein, um verbindungsorientierte Livedaten wie Blockzugriffe, Benutzerdaten und ähnliches zu sichern. TDB arbeitet nur sehr mäßig im Cluster und muss daher gegen das CTDB (Clustered Trivial Database System) getauscht werden. Auch andere Dateidienste wie NFS und FTP nutzen TDB und lassen sich mit CTDB für den Clusterbetreib verwenden.

Fazit

Der DRDB-Spiegel eignet sich aufgrund der relativ simplen Konfiguration für viele Einsatzgebiete. Die beliebte Spiegelung vom Haupt-Rechenzentrum in einen separaten Brandabschnitt oder ein Nachbargebäude liefert dabei sogar die Disaster-Toleranz. Windows-Fileserver müssen für vergleichbare Funktionen auf kostenpflichtige Zusatzprogramme wie von Double-Take zurückgreifen.

Für den NFS/CIFS-Betrieb im Multi-Node-Cluster gibt es aktuell kein Windows-Pendant. Dafür gestaltet sich die Cluster-Konfiguration auch entsprechend komplexer. Ein Cluster-Setup kommt bei regulären Backoffice-Installationen jedoch eher selten vor. Nur wer dutzende oder eher hunderte von CIFS/NFS-Clients betreibt oder viele Diskless-Linux-Workstations mit Root-Dateisystem auf NFS einsetzt, wird sich diesem Setup stellen müssen.