OpenSolaris-Datenhalde mit NFSv4
February 7, 2010

Letztes Jahr habe ich mir neue Hardware angeschafft, um einen, auf OpenSolaris basierenden, Fileserver zu bauen. Nun habe ich es endlich mal geschafft diesen auch zu installieren, zu konfigurieren und alle Daten aufzuspielen. Der Rechner soll seinen Datenbestand dann per NFSv4 an meinen Linux-Desktop, mein Linux-Notebook und mein NetBSD-Notebook exportieren. Dabei traten einige kleine Probleme auf, von denen ich das wichtigste weiter unten noch erläutere. Aber vorerst noch ein Wort zur Hardware. Augenmerk liegt natürlich auf geringer Geräuschentwicklung, guter Energieeffizienz und redundant gespeicherten Daten.

Hardware:

Gehäuse und Netzteil sind schon vorhanden gewesen, ebenso wie eine 1000-MBit-Intel-Netzwerkkarte (PCI).

<li>Bei dem Gehäuse handelt es sich um ein Chieftec-Server-Gehäuse im E-ATX-Format. Neupreis (2003) war ca. 50€.</li>
<li>Das Netzteil ist ein Enermax-300-Watt-Netzteil (ATX 1.2) mit zwei Lüftern. Sehr zuverlässig und leise (Enermax-Netzteile boten auch damals schon einen relativ hohen Wirkungsgrad). Neupreis (2003) war ca. 50€.</li>

Neukauf:

• Mainboard: Asus MicroATX mit AM2+ Sockel und Onboard-Grafik (auch Sound und GB-LAN)
• AMD Athlon 4850e AM2 mit 2x 2500 MHz und 45 Watt TDP (Der Prozessortakt für K8-basierende Prozessoren kann leider nicht durch OpenSolaris geregelt werden. Zum Kaufzeitpunkt gab es allerdings noch keine K10-Prozessoren mit weniger als 65 Watt TDP. K10-Prozessoren können geregelt werden, daher lautet meine heutige Kaufempfehlung: AMD Athlon II X2 240e)
• 8 GiB DDR2-800 Kingston Value-RAM (4x2GiB) - Auf ECC habe ich verzichtet
• 2x 1500 MByte Seagate SATA2-Festplatte mit 5900 U/min

Das System:

<li>Betriebssystem: OpenSolaris snv_132</li>

<li>Dateisystem: ZFS v22 MIRROR mit deduplication, SHA-256 und auf einigen Dateisystemen auch gzip-9 Komprimierung.</li>

NFSv4

Beispiel:

Ich exportiere das Dateisystem rpool/share (mit all seinen Subdateisystemen) für den Rechner lee mit Schreibrechten. Die Option sec=sys wird automatisch hinzugefügt, ihr Einfluss kann in nfssec(5) nachgelesen werden.

root@milten:~# zfs set sharenfs=rw=lee rpool/share
root@milten:~# exportfs
-@rpool/share   /share   sec=sys,rw=lee   ""
-@rpool/share   /share/Bilder   sec=sys,rw=lee   ""
...

Nun kann der Client lee den Export vom Solaris-Server mounten:

lee:~# mount -t nfs4 -o rw milten:/share /mnt/Server/


uschy@lee:/mnt/Server/Share$ ls -lha
drwxr-xr-x 13 4294967294 4294967294 13  7. Feb 03:15 .

Allerdings funktioniert das Mapping von uid und gid noch nicht ganz. Auf dem jeweiligen Dateisystem stimmen die ids allerdings überein. Daher muss auf jedem Rechner ein Mapping-Daemon laufen, unter GNU/Linux ist es der idmapd (gehört zum NFS-Client- und -Server-Daemon) und unter Solaris der mapid (svc:/network/nfs/mapid:default).

Diese Dienste laufen auch standardmäßig, allerdings muss man beiden noch eine korrekte NFSv4-Domäne zuweisen.

OpenSolaris:

In der Datei /etc/default/nfs muss folgende Einstellung vorgenommen werden:

NFSMAPID_DOMAIN=local

und die davon abhängigen Dienste müssen neu gestartet werden:

root@milten:~# svcadm restart svc:/network/nfs/server:default
root@milten:~# svcadm restart svc:/network/nfs/mapid:default

Unter GNU/Linux genau das gleiche (hier Debian):

In der Datei /etc/idmapd.conf folgende Zeile anpassen:

Domain = local

und den NFS-Client neu starten:

lee:~# /etc/init.d/nfs-common restart
Stopping NFS common utilities: idmapd statd.
Starting NFS common utilities: statd idmapd.

Nun stimmen die Mappings überein:

uschy@lee:/mnt/Server/Share$ ls -lha
drwxr-xr-x 13 uschy root  13  7. Feb 03:15 .
..