FreeBSD - GEOM_GATE oder iSCSI oder HAST ... [Update 3 - 06.05.2012]


Netzwerk-RAID - Die administrative Hölle auf Erden


Von Thorsten Geppert am 20.05.2010, geändert 06.05.2012.

Bitte auch die Updates weiter unten lesen.

FreeBSD, meine eigentliche Liebe, wenn es sowas überhaupt in dem Bereich gibt, erwidert sie anscheinend in einem ganz bestimmten Punkt nicht: Software-RAID-Erstellung über ein Netzwerk.

Obgleich das Betriebssystem gleich mehrere Möglichkeiten mitbringt, deren Konfigurationen sehr einfach sind, sind entweder alle extrem fehlerbehaftet oder ich bin viel zu dumm. Es endet immer in Kernel-Panics oder dem Abschalten des Hardware-RAID-Controllers.

Ich habe alle drei Dinge auf verschiedenen Hardware- sowie virtuellen Servern (VirtualBox) getestet.

HAST

HAST ist bereits nach Stable geMFCd. Es ist einfach zu konfigurieren. Das Erstellen ein und der selben Datei auf Master und Slave (HAST kann nur zwei Geräte abgleichen) geht schnell von der Hand und ist recht verständlich. Auf dem Master sowie auf dem Slave "kreiert" man dann die HAST-Resource, startet den HAST-Daemon (hastd) und kann dann dem Master und dem Slave seine Rollen zuweisen. Es kommen die unterschiedlichsten Meldungen. Einen Abgleich habe ich im stundenlangen Konfigurieren und Recherchieren einmalig hinbekommen. Der Erfolg war nicht mehr reproduzierbar.

→ Mein Foreneintrag auf bsdforen.de

iSCSI

Auch iSCSI ist sehr einfach zu administrieren. Die Geschwindigkeit ist mittelmäßig, eher schlecht. Obgleich sich das jeweilige exportierte Device mühelos mit dem iSCSI-Initiator einhängen lässt, endet jedes längere Schreiben auf dem Device in einem Kernel-Panic. Schade.

→ Mein Foreneintrag auf bsdforen.de

GEOM_GATE alias ggate

Die meiner Meinung einfachste Konfiguration hat ggate. Auf dem Rechner, auf dem die Devices exportiert werden sollen, genügt es, die Datei "/etc/gg.exports" mit dem Inhalt "ip RW|RO /dev/device" zu erstellen, ggated zu starten und auf dem, der die Devices nutzen soll, via "ggatec create server|ip /dev/device" das Device einzubinden. Das funktioniert hervorragend. Allerdings im Verbund mit gmirror (GEOM_MIRROR) ist die Sache alles andere als stabil, wenn man beispielsweise ein Device aus dem Mirror entfernt. Panic oder Abschaltung des RAID-Controllers. Auch, wenn man beispielsweise Devices aus dem Mirror deaktiviert und das in anscheinend für gmirror einer falschen Reihenfolge macht: Panic. Wirklich brauchbar ist das nicht.
Benutzt man statt gmirror ZFS im ZPOOL mit Mirroring, gibt's direkt beim Zugriff via NFS auf den freigegebenen Mount eine Panic. Mit UFS2 scheint es eher zu gehen.

Fazit

Mit "nbd" und "GlusterFS" auf Linux funktioniert die ganze Sache besser. Ich forsche derzeit noch an einer Lösung. Ob ich eine finde, kann ich derzeit noch nicht sagen.

[Update 1 - 04.06.2010]

Ich habe ja tüchtig um mich herumgeschlagen, aber möchte mich mal an der Stelle ein wenig korrigieren, da neue Ergebnisse vorliegen. Thomas Krenn, unser Serverlieferant, hat uns, obgleich der Bitte, dass die Maschinen vollständig unter FreeBSD laufen müssen, Geräte mit Adaptec-Controllern verkauft, die eine alte und kaputte Firmware haben. Diese Firmware bringt den Controller bei hoher Last unter Linux und FreeBSD zum Absturz. Flashed man die Controller mit der Version 17899, dann scheint ein Teil der Probleme behoben zu sein.

Bisher habe ich nur GEOM_GATE in Kombination mit GEOM_MIRROR getestet. Das lief mit all meinen Tests jetzt recht stabil und performant. iSCSI habe ich auf den Maschinen noch nicht getestet.

HAST habe ich mir in der Version FreeBSD 8.1 Beta angesehen. Da funktioniert es überhaupt nicht.

[Update 2 - 16.10.2010]

Jetzt läuft seit gut einem Monat ein FreeBSD 8.1 mit iSCSI und sechs Freigaben, die permanent benutzt werden, ohne jede Störung. Die einzelnen Platten sind mit GELI verschlüsselt und im raidz-Verbund zu einem Volume zusammengeschlossen. Darauf sind Dateien, die über iSCSI freigegeben sind. Eine Windows Server 2008 R2 sowie fünf Macs mit TimeMachine sind angeschlossen. Bisher keine Zwischenfälle.

[Update 3 - 06.05.2012]

Wir setzen HAST inkl. CARP mittlerweile seit ein paar Monaten erfolgreich ein. Es funktioniert nicht nur gut, sondern hervorragend. Keine Kernelpanics, die Daten sind immer gut synchron und auch Tests mit ZFS haben gute Resultate gezeigt. Das alles auf FreeBSD 9.0 Stable.

[zurück]