OpenSolaris als Fileserver
Dank eines sehr schnellen SMB/CIFS-Servers und den Möglichkeiten des modernen Dateisystems ZFS ist OpenSolaris eine gute Wahl zum Aufbau eines Dateiservers fürs LAN.
Ein leistungsfähiger Dateiserver fürs Heimnetz im Eigenbau ist kein Hexenwerk: Ein nicht zu lahmer Prozessor, ein bis zwei GByte RAM, Gigabit-Netzwerk, ein SMB/CIFS-Server für Windows-, Linux- und MacOS-Clients, ein paar Platten, zu einem RAID-5 zusammengefasst. Das ist schon für 400 bis 500 Euro zu haben und verspricht mehr Datensicherheit und vor allem eine deutlich höhere Performance als eine simple Netzwerkfestplatte (siehe c't 26/08, ab 8.12. am Kiosk).
Performance ist (neben der höheren Flexibilität) auch das schlagende Argumente gegenüber besseren NAS-Filern (Network Attached Storage) mit mehreren Platten: In den Tests bei c't erreichten auch Geräte mit Preisen deutlich über 500 Euro lediglich Datenraten zwischen 10 und 50 MByte/s und blieben damit weit hinter dem in einem Gigabit-Netz Möglichen zurück.
Um die Kosten niedrig zu halten, empfiehlt sich eines der freien Betriebssysteme, die alle auch als SMB-Server arbeiten können. Von Linux und FreeBSD existieren sogar spezielle Varianten für den NAS-Einsatz (siehe c't 26/08, ab 8.12. am Kiosk). Aber warum nicht OpenSolaris? Immerhin ist Solaris ein bewährtes Server-Betriebssystem, das mit ZFS eine moderne Storage-Lösung mitbringt, die RAID-Funktionen und einen Logical Volume Manager mit einem modernen Dateisystem kombiniert.
Solaris-Hersteller Sun setzt ZFS und OpenSolaris in seinen neuen Open-Storage-Servern ein, die auf x86-Hardware bis zu 576 TByte Massenspeicher via NFS, SMB/CIFS, FTP und iSCSI bereitstellen. Das dort verwendete "Fishworks Appliance Kit with OpenSolaris", ein speziell auf den Storage-Betrieb angepasstes OpenSolaris mit einer komfortablen Management-Oberfläche, ist zwar noch nicht zur Installation auf eigener Hardware verfügbar; aber auch das frei verfügbare OpenSolaris enthält alle für einen Dateiserver notwendigen Komponenten – wenn auch nicht ganz so komfortabel verpackt wie in Suns Open-Storage-Servern zu Preisen ab 10.000 Euro.
Dass OpenSolaris für diese Aufgabe taugt, haben wir im Vergleich mit anderen Betriebssystemen gesehen: Mit einer Leserate von 111 MByte/s und einer Schreibrate von 86 MByte/s ließ das Sun-Unix alle anderen freien Systeme hinter sich, lag gleichauf mit dem Windows Server 2008 und erreichte Werte nahe dem in einem Gigabit-Netz maximal möglichen Datendurchsatz.
ZFS
Der größte Vorteil von OpenSolaris für einen Fileserver ist das Dateisystem ZFS, das die Verwaltung der Massenspeicher enorm vereinfacht. Das Zusammenfassen mehrerer Platten zu einem RAID-5-Array samt Anlegen eines Dateisystems und dauerhaftem Einbinden in den Verzeichnisbaum erfordert lediglich einen einzigen Befehl auf der Kommandozeile -- kein Hantieren mit Partitionen, physischen und logischen Volumes, fdisk, Dateisystem- und RAID-Tools, Konfigurationsdateien und Skripten. Weitere Dateisysteme in dem Speicherpool lassen sich im Handumdrehen anlegen und ins System einbinden; fügt man eine Platte hinzu, steht der neue Speicherplatz sofort allen Dateisystemen zur Verfügung. Integrierte Funktionen zum Anlegen von speichersparenden Snapshots und Images sorgen für Datensicherheit.
Checksummen sichern die Datenintegrität vom Betriebssystem bis zum physischen Speicher, Fehler werden erkannt und automatisch korrigiert – egal, ob auf dem SATA-Kabel gelegentlich ein paar Bits kippen oder eine Platte zickt. Als 128-Bit-Dateisystem wird ZFS auf absehbare Zeit an keine praktisch relevanten Grenzen stoßen: Die maximale Größe für Dateien und Dateisysteme liegt bei 16 Exabyte (16 Millionen Terabyte). Ein Speicherpool, der physische Speichergeräte zu einer virtuellen Platte zusammenfasst, kann bis zu 256 Zettabyte verwalten – IDC schätzt den weltweit verfügbaren Speicherplatz im Jahr 2007 auf rund 250 Exabyte, also ein Tausendstel davon.
ZFS arbeitet mit copy-on-write: Geänderte Daten werden auf der Platte nicht überschrieben, sondern in neuen, freien Blöcken auf der Platte abgelegt. Das garantiert zum einen ein jederzeit konsistentes Dateisystem, da man auf die alten Daten zugreifen kann, bis die neuen Daten vollständig geschrieben sind. Zum anderen erlaubt es das einfache Anlegen von Snapshots: Hebt man die alten Datenblöcke auf, statt sie nach Abschluss der Schreiboperation freizugeben, kann man jederzeit zu einem älteren Stand einer Datei zurückkehren – so ist das ressourcensparende Anlegen von Snapshots möglich.
Installation
Wir haben sowohl die ältere Version 2008/05 als auch das aktuelle OpenSolaris 2008/11 auf der Hardware unseres Selbstbau-NAS installiert (siehe c't 26/08, ab 8.12. am Kiosk): AMD Athlon64 X2, 2 GByte RAM, Intel-Gigabit-LAN, vier SATA-Platten à 250 GByte, eine 4-GByte-SSD als Bootgerät. Die OpenSolaris-Live-CD erkannte sämtliche Hardware; die Installation aus dem Live-System heraus ist mit wenigen Mausklicks erledigt.
OpenSolaris enthält zwei SMB/CIFS-Server: das aus der Linux-Welt bekannte Samba und den Sun-eigenen SMB-Server. Letzterer ist besser ins System und in das ZFS integriert und bietet neben der Anbindung des Solaris-Servers an ein Active Directory verschiedene Optionen, Windows- und Solaris-Benutzer aufeinander abzubilden und die Zugriffsrechte auf Freigaben zu regeln. Alle Feinheiten beschreibt der Solaris CIFS Administration Guide – im Folgenden wollen wir lediglich einen Leitfaden geben, wie man einen OpenSolaris-Rechner in einen einfachen File-Server für ein kleines LAN verwandelt.
Der Sun-SMB-Server muss in OpenSolaris nachinstalliert werden. Er steckt in den Softwarepaketen SUNWsmbs und SUNWsmbskr, die man über den grafischen Paket-Manager, zu finden im Menü Systemverwaltung, einspielt. Um den SMB-Server im System registrieren, bootet man das System anschließend einfach neu; um ihn ohne Reboot in Betrieb zu nehmen, sind einige Klimmzüge nötig.
Netzwerk, RAID
Netzwerk
Nun muss man sich auf die Kommandozeile begeben, wo man sich mit
su -
Root-Rechte verschafft. Der Befehl
svcadm enable -r smb/server
startet den SMB-Server;
svcs smb/server
gibt anschließend als Status des Dienstes "online" aus.
Das Programm svcadm (service administration) muss man in OpenSolaris 2008/05 auch bemühen, falls der OpenSolaris-Rechner eine feste Netzwerkadresse kriegen soll (was für den Betrieb als Fileserver aber nicht unbedingt erforderlich ist): Die Befehle
svcadm disable network/physical:nwam
svcadm enable network/physical:default
schalten die "Network Auto-Magic" ab, die standardmäßig eine IP-Adresse via DHCP bezieht, und erlauben stattdessen die Konfiguration einer festen Adresse. Am bequemsten geht das mit dem in der Systemverwaltung zu findenden GUI-Tool zur Netzwerkkonfiguration. Im aktuellen OpenSolaris 2008/11 kümmert sich das Netzwerktool selbst darum, die Network Automagic abzuschalten, wenn man eine feste IP-Adresse einstellen möchte.
RAID
Anschließend geht es an das Einrichten des RAID-5-Arrays. Der Befehl
format
zeigt die Namen der Platten im System an; er kann mit Strg-C abgebrochen werden. Anschließend fasst
zpool create daten raidz1 c4t0d0 c4t1d0 c4t2d0 c4t3d0
die vier Platten unseres Selbstbau-Fileservers – die jeweils ersten Platten (d0) an den Target Devices 0 bis 3 des fünften Massenspeicher-Controllers im System (c4, der SATA-Controller; c0 bis c3 sind die IDE-Controller) – zu einem RAID-5-Speicherpool (RAID-Z1 in der ZFS-Terminologie) namens daten zusammen, der gleich mit einem Dateisystem versehen und unter /daten eingebunden wird.
Wer es eine Nummer kleiner will und sich mit zwei Platten zufrieden gibt, die sich gegenseitig spiegeln (RAID-1), verwendet stattdessen den Befehl
zpool create daten mirror c4t0d0 c4t1d0
Beim Anlegen eines RAID-Arrays können auch gleich hot spares mit angegeben werden, Platten, die das System automatisch verwendet, wenn eine der Platten im RAID nicht mehr funktioniert. Mehr dazu verraten die man-page zu zpool und der Artikel Speichermeister in c't 21/08.
Der Befehl
zpool list
zeigt eine Übersicht der Speicherpools samt ihrer Belegung an;
zpool iostat
gibt Auskunft über Lese- und Schreiboperationen – mit der Option -v auch für die einzelnen Devices im Pool.
Kontrolle
Wichtiger für einen Fileserver ist allerdings der Zustand der Platten:
zpool status
verrät, ob es den Platten im Array gut geht und ob Checksummenfehler beim Lesen von Dateien aufgetreten sind. Falls das Tool bei einer Platte Fehler meldet, gibt
zpool status -v
genauere Auskunft. Mit
zpool scrub daten
liest das System alle Blöcke des Speicherpools ein und gleicht ihren Inhalt gegen die Checksumme ab. Das Scrubbing erfolgt im Hintergrund, erzeugt allerdings eine recht hohe I/O-Last. Sun empfiehlt, das Scrubbing bei Desktopplatten ein Mal pro Woche, bei Serverplatten ein Mal im Monat durchzuführen.
Bei Ausfall einer Platte wechselt ein RAID-Array von "online" in den Zustand "degraded", zudem schreibt der Fault Manager Daemon fmd einen entsprechenden Eintrag ("drive offline") nach /var/adm/messages. Daten lassen sich noch immer lesen und schreiben, jetzt freilich ohne redundante Speicherung. Daher will man in diesem Fall schnellstmöglich für Ersatz sorgen:
zpool replace daten c4t1d0 c4t2d0
ersetzt die ausgefallene oder auszutauschende Platte c4t1d0 durch c4t2d0. ZFS spiegelt dabei die Daten der verbliebenen Platte automatisch auf die neue Platte, was je nach Datenmenge einige Minuten bis Stunden dauern kann. Nach Abschluss dieses "Resilvering", währenddessen der Zugriff auf die Daten weiterhin möglich ist, ist das RAID-Array wieder voll funktionstüchtig.
Freigaben, Benutzer
Freigaben
Auf dem Speicherpool kann man nun ein weiteres Dateisystem speziell zur Freigabe via SMB anlegen:
zfs create -o casesensitivity=mixed daten/public
zfs set sharesmb=on daten/public
Mit der Option "casesensitivity=mixed" emuliert OpenSolaris beim Zugriff via SMB das Verhalten von Windows beim Umgang mit Dateinamen: Sie dürfen zwar Groß- und Kleinbuchstaben enthalten, beim Zugriff auf eine Datei unterscheidet das System aber nicht nach Groß- und Kleinschreibung. Solaris würde sich ansonsten wie jedes andere Unix verhalten und foo, Foo und FOO als drei verschiedene Dateien betrachten, die alle im gleichen Verzeichnis liegen dürfen.
Die Dateisystemeigenschaft "sharesmb" sorgt dafür, dass das lokal unter /daten/public eingebundene Dateisystem via SMB freigegeben wird – auch nach dem nächsten Reboot, ohne dass dazu Einträge in irgendwelchen Konfigurationsdateien nötig wären: Die Freigabe über SMB ist eine Eigenschaft des Dateisystems, ebenso wie der Mount-Point.
Ebenfalls eine Eigenschaft des Dateisystems ist der Name der Freigabe. Einen anderen Namen als die Voreinstellung "daten_public", etwa "Alle", setzt man mit
zfs set sharesmb=name=Alle daten/public
Die etwas krude wirkende Syntax mit den zwei Gleichheitszeichen ist tatsächlich korrekt so.
Weitere Freigaben lassen sich nach dem gleichen Muster einrichten; der Befehl
sharemgr show -vp
zeigt die bestehenden Freigaben an. Das Tool "Gemeinsame Ordner" in der Systemverwaltung kann man übrigens nicht zur Freigabe nutzen: Es unterstützt lediglich Samba, nicht aber den Sun-SMB-Server.
Soll der OpenSolaris-Server in einer anderen Arbeitsgruppe als der Vorgabe WORKGROUP auftauchen, lässt sich auch das konfigurieren:
smbadm join -w Workgroup-Name
Benutzer
Der Zugriff auf eine Freigabe erfordert immer die Angabe von Benutzername und Passwort eines unter OpenSolaris angelegten Benutzers, "anonyme" Freigaben oder einen "guest"-Account gibt es nicht.
Um OpenSolaris-Benutzern den Zugriff via SMB zu erlauben, muss man die Datei /etc/pam.conf um die Zeile
other password required pam_smb_passwd.so.1 nowarn
ergänzen. Wer sich nicht mit vi herumschlagen will, öffnet die Datei als der bei der Installation angelegte Hauptbenutzer mit dem Befehl
pfexec gedit /etc/pam.conf
in einem GUI-Editor. Anschließend ist jedem über die grafische Benutzerverwaltung (zu finden im Menü Systemverwaltung) neu angelegten Benutzer der Zugriff via SMB erlaubt. Bei bereits bestehenden Accounts muss man das Passwort einmal mit dem Befehl passwd ändern. Ein neuer Benutzer "smb" mit gleichlautendem Passwort kann für den Zugriff auf die öffentliche Freigabe dienen; für jeden Benutzer, der ein eigenes Verzeichnis auf dem Fileserver erhalten soll, ist ein eigener Account anzulegen.
Wer auf eine Freigabe unter einem bestimmten Benutzernamen zugreift, hat dort genau die Rechte, die derselbe Benutzer bei einer lokalen Anmeldung im System hätte. Man muss also auf der OpenSolaris-Maschine mit den Befehlen chmod (ändert die Zugriffsrechte) und chown (ändert den Besitzer) für die passenden Zugriffsrechte sorgen. So erhalten mit
chmod a+rwx /daten/public
alle Benutzer Lese- und Schreibrechte für das ZFS-Dateisystem daten/public und damit auch für diese Freigabe (Details zu chmod verrät man chmod).
Will man neben dieser für alle Benutzer les- und beschreibbaren Freigabe benutzerspezifische Freigaben einrichten, legt man mit dem Tool "Benutzer und Gruppen" im Systemverwaltungsmenü für jeden Benutzer einen eigenen Account an. Dabei erhält der neue Benutzer ein Homeverzeichnis mit dem Namen des Benutzers in /export/home. /export/home ist der Mountpoint eines eigenen Dateisystems rpool/export/home – der Befehl
zfs list
zeigt alle Dateisysteme an.
Freigaben
Umzug
Nun könnte man einfach die Home-Verzeichnisse en bloc freigeben:
zfs set sharesmb=on rpool/export/home
Auf unserem Selbstbau-NAS ist das allerdings nicht sehr sinnvoll: Der bei Speicherpool rpool, der die Systemdaten und die Home-Verzeichnisse in verschiedenen Dateisystemen enthält, wurde bei der Installation auf der 4-GByte-SSD angelegt – viel Platz zum Speichern ist dort also nicht.
Aber der Inhalt eines ZFS-Dateisystems lässt sich problemlos in einen anderen Speicherpool verlagern. Dazu benötigt man zunächst eine Momentaufnahme (einen Snapshot) des aktuellen Zustands des zu übertragenden Dateisystems:
zfs snapshot -r rpool/export/home@transfer
Damit kann man jetzt ein anderes Dateisystem befüllen, das dabei gleich angelegt wird:
zfs send rpool/export/home@transfer | zfs receive daten/home
Der send-Befehl des zfs-Tools erzeugt hier ein Image des Snapshots transfer des Dateisystems rpool/export/home, das auf die Standardausgabe geschrieben wird (und sich mit einer Output-Umleitung auch in einer Datei speichern lässt). zfs receive nimmt das Image entgegen und erzeugt daraus das neue Dateisystem daten/public/home.
Das Gleiche ist noch für das Home-Verzeichnis des bei der Installation angelegten Hauptbenutzers nötig, der bei OpenSolaris 2008/11 ein eigenes Dateisystem für sein Home-Verzeichnis erhält. Die Option -r beim Anlegen des Snapshots von rpool/export/home hat bereits dafür gesorgt, dass der Snapshot existiert:
zfs send rpool/export/home/test@transfer | zfs receive daten/public/home/test
Um das alte Home-Verzeichnis durch das neue zu ersetzen, muss man das alte zunächst unmounten; dabei sollten keine Anwendungen laufen, die Dateien geöffnet halten:
zfs umount -f rpool/export/home/test
zfs umount -f rpool/export/home
Nun setzt man für die beiden neu angelegten Verzeichnisse die richtigen Mountpoints mit
zfs set mountpoint=/export/home daten/public/home
zfs set mountpoint=/export/home/test daten/public/home/test
und löscht das alte Home-Verzeichnis mit
zfs destroy -r rpool/export/home
Auto-Freigaben
Der CIFS/SMB-Server von OpenSolaris unterstützt ein nützliches Feature namens "autohome": Legt man in /etc eine Datei smbautohome mit dem Eintrag
* /export/home/&
an, erhält jeder Benutzer beim Zugriff via SMB auf sein Homeverzeichnis – so lange, bis er sich wieder abmeldet. Die Home-Verzeichnisse auf dem Server sind damit nur dann erreichbar, wenn sie wirklich gebraucht werden. Der Nachteil: Sie werden in der Netzwerkumgebung nicht angezeigt.
Eine komfortablere Lösung ist es daher, mit
zfs set sharesmb=name=Home daten/home
einfach das komplette Dateisystem mit allen Home-Verzeichnissen freizugeben. Standardmäßig sind die Zugriffsrechte unter OpenSolaris so gesetzt, dass jeder Benutzer den Inhalt aller Home-Verzeichnisse lesen, allerdings nicht darin schreiben darf. Möchte man den Inhalt der Home-Verzeichnisse vor den anderen Benutzern verbergen, nimmt
chmod go-r /export/home/*
die Leserechte für alle Anwender außer dem Besitzer des jeweiligen Verzeichnisses.
Will man verhindern, dass einzelne Benutzer den gesamten Speicherplatz des Speicherpools aufbrauchen, kann man Quotas setzen:
zfs set quota=600GB daten/home zfs set quota=600GB daten/public
sorgt dafür, dass keines der beiden im RAID-Array angelegten Dateisysteme mehr als 600 GByte belegen kann.
Der Lohn der Mühe
Zum Schluss noch ein paar Tipps, was mit OpenSolaris und ZFS noch möglich ist. Regelmäßige Snapshots sorgen dafür, dass sich versehentlich gelöschte oder überschriebene Dateien mit wenigen Handgriffen wiederherstellen lassen. Ein solcher Snapshot ist in Sekundenbruchteilen angelegt und braucht erst einmal nahezu keine Ressourcen: Er füllt sich erst, wenn Dateien geändert oder gelöscht werden. Der Befehl
zfs list -t snapshot
zeigt die bestehenden Snapshots an; der Befehl
zfs rollback daten@snapshot
versetzt das Dateisystem wieder in den Zustand, in dem es beim Anlegen des Snapshots war. Eleganter ist es allerdings, mit
zfs set snapdir=visible daten
die Snapshots und alle Dateien darin über das Unterverzeichnis /daten/.zfs zugänglich zu machen. OpenSolaris 2008/11 bringt einen Dienst mit, der automatisch regelmäßige Snapshots erstellt und über das Tool "Einrichtung des Zeit-Schiebereglers" aktiviert wird.
Mit dem bereits erwähnten Scrubbing kann man in regelmäßigen Abständen den Gesundheitszustand der Hardware überprüfen.
Wer Linux- und Unix-Clients im LAN hat, möchte für sie vielleicht einen NFS-Server aufsetzen; dazu genügt ein
zfs set sharenfs=on daten
Siehe dazu auch: (odi)
