Home > IT-Infrastruktur, Netzwerke > Homeserver mit Opensolaris (Erfahrungsbericht)

Homeserver mit Opensolaris (Erfahrungsbericht)

March 3rd, 2009

Ein alter, ungenutzter Rechner kann als Homeserver umfunktioniert werden, um beispielsweise wichtige Daten darauf zu sichern. In meinem Fall benutze ich einen AMD Duron mit 1000 MHz und 512 MB RAM.
Ein Dateiserver sollte besonders robust sein und das Risiko für Datenverluste minimieren. Um sich beispielsweise gegen den Ausfall einer Festplatte abzusichern, sollten die Daten auf einer zweiten Festplatte gespiegelt werden. Und um sich vor versehentlichem Löschen zu schützen, sollten inkrementelle Backups erstellt werden, so dass alte Zustände der Daten wiederhergestellt werden können. Das (und noch mehr) kann relativ einfach mit dem innovativen Dateisystem ZFS erreicht werden.
Für die Spiegelung werden zwei baugleiche Festplatten benötigt. In diesem Fall kommen zwei USB-2.0-Festplatten mit jeweils 1000 GB Kapazität zum Einsatz. Als Betriebssystem wird Opensolaris verwendet (Distribution: Nexenta Core Platform 2 Beta2).



Warum USB?
USB hat einen Nachteil: die Geschwindigkeit. In meinem Fall hat das Netzwerk eine Geschwindigkeit von 1000 MBit/s. Das bedeutet, dass USB 2.0 mit seinen 480 MBit/s den Flaschenhals darstellt. Es sollte aber ausreichen, wenn nicht ständig riesige Datenmengen über das Netzwerk transferiert werden.

Constantin Gonzalez erläutert die Vorteile von USB-Festplatten. Zum einen ist der Preis ein Argument. Außerdem lassen sich die USB-Platten bequem an einen anderen Rechner anschließen und die Kapazität lässt sich leicht ausbauen, wenn die Platten voll sind.

Warum Opensolaris und nicht Linux?
Wie schon erwähnt, soll ZFS als Dateisystem eingesetzt werden, welches die Spiegelung und Snapshots sehr einfach gestaltet. In der Linuxwelt gibt es (noch) nichts vergleichbares (in der Entwicklung befindet sich Btrfs).
Zwar gibt es auch die Möglichkeit, ZFS auf Linux einzusetzen (ZFS on FUSE), aber Solaris erscheint mir hier die sauberere Lösung für den Server zu sein, weil ZFS einfach nativ dabei ist und “Out-Of-The-Box” funktioniert.

Wahl der Distribution
Näher untersucht wurden “OpenSolaris 2008.11″ von SUN Microsystems und die Nexenta-Distribution.
OpenSolaris 2008.11 ist eine reine Distribution für Desktop-Systeme, ohne irgendwelche Konfigurationsmöglichkeiten bei der Installation. Für einen Server also ungeeignet, obwohl man natürlich überflüssige Komponenten (wie beispielsweise die grafische Oberfläche) nachträglich wieder entfernen könnte.
Der bessere Ansatz wäre es, mit einer Basisinstallation zu starten und erforderliche Komponenten gegebenenfalls nachinstallieren zu können. Und genau das bietet NexentaCore. Es wird nur ein minimales System installiert. Außerdem kombiniert es den Solaris Kernel mit dem “Ubuntu-Userland”, was mir entgegen kommt, da ich Ubuntu auf dem Desktop und Debian auf auf meinem vServer einsetze. Nexenta bedeutet für mich somit einen reduzierten Umgewöhnungsaufwand, also ein zusätzlicher Pluspunkt.

Installation
Dazu gibt es nicht viel zu sagen. CD reinschieben, von CD booten und die Installation starten. Ich hatte wahrscheinlich Glück, dass alle benötigten Komponenten erkannt wurden und funktionieren. Opensolaris 2008.11 fand keinen Treiber für meine Netzwerkkarte, aber mit Nexenta funktioniert sie ohne Probleme.

Konfiguration
Falls bei der Installation noch nicht richtig eingerichtet, muss die Netzwerkverbindung konfiguriert werden. Um Zugriff auf die Ubuntu-Repositories (für Updates und Paketinstallationen) zu erhalten, muss zusätzlich eine Internetverbindung eingerichtet werden.
Der Server soll über SSH erreichbar sein, also muss auch ein SSH-Daemon installiert werden (“sudo aptitude install sunwsshdu”). Sobald der Zugriff über das Netzwerk per SSH funktioniert, kann man die lokale Sitzung beenden und Monitor und Tastatur abstöpseln. Ab sofort läuft der gesamte Zugriff auf den Server nur noch über das Netzwerk.

ZFS
Um einen Pool mit den zwei Festplatten aufzusetzen, braucht man im Prinzip nur eine Zeile:

zpool create mpool mirror c2t0d0 c3t0d0

Damit wird der Pool “mpool” erstellt (“create”), der die beiden Platten c2t0d0p0 und c3t0d0p0 spiegelt (“mirror”) und als “/mpool” in das Dateisystem eingehängt wird. Damit ist das Grundlegende erledigt und man kann nun bereits anfangen, die Platten zu benutzen. Natürlich lohnt es sich, sich genauer mit ZFS zu beschäftigen, um die Möglichkeiten auch voll zu nutzen.
Meine Empfehlungen: Das OpenSolaris ZFS Dateisystem und Solaris ZFS Administration Guide.

Die Bezeichner der Festplatten lassen sich herausfinden, indem man als root den Befehl “format” ausführt (beenden mit strg-d).

Ich habe meinen Pool in zwei Bereiche untergliedert:
In “current” werden aktuelle Arbeitsdaten, E-Mails, etc. von meinem Laptop gesichert, die mittels rsync auf den Fileserver übertragen werden.
Das Verzeichnis “archive” wird als Netzlaufwerk in mein Dateisystem eingebunden und dort werden Daten abgelegt, die ich nicht auf meinem Laptop benötige bzw. keinen Platz finden.

Energieverbrauch
Der Server frisst im Leerlauf etwa 90 Watt (PC: 70 Watt, USB-Festplatten: jeweils 10 Watt). Das halte ich für den Rund-um-die-Uhr-Betrieb untragbar. Bei 20 Cent pro Kilowattstunde würden die Kosten durchschnittlich 13,14 € im Monat betragen. Und wenn das alle Menschen in Deutschland machen würden, müssten acht neue Kernkraftwerke gebaut werden. (Gerechnet mit 80 Millionen Einwohnern und 8000 GWh pro Kernkraftwerk im Jahr)

Also wird der Server bei Bedarf ein- und ausgeschaltet.
Deshalb hier noch eine einfache Möglichkeit, um beim Booten ein paar Sekunden einzusparen:
Die Wartezeit des Bootloaders auf Benutzereingaben auf Null setzen. Dazu einfach in der Datei “/boot/grub/menu.lst” den Eintrag “timeout 10″ zu “timeout 0″ abändern.

Probleme
Manchmal ist der komplette Pool unlesbar und sämtliche ZFS-Kommandos bleiben hängen. Dann hilft nur noch ein Neustart des Servers. Siehe ZFS-8000-HC. Die Ursache dafür ist mir noch völlig schleierhaft, jedenfalls tauchen die Probleme immer dann auf, wenn ich den Pool mit sshfs auf meinen Linux-Laptop einbinde.

Fazit
Die Einrichtung des Systems gestaltet sich recht einfach. Das Konzept von Nexenta und Opensolaris und vor allem von ZFS ist genial. Der einzige Makel an der Sache ist die Instabilität, den ich einfach damit erkläre, dass NexentaCore 2 noch in der Betaphase steckt. Eventuell werden die Fehler aber auch durch meinen Linux-Client verursacht. Es muss abgewartet werden, wie sich das entwickelt. Ich werde vorerst mit der unstabilen Version ausharren und auf die Updates hoffen. :-)

Wahrscheinlich wäre für ein Produktivsystem die stabile Nexenta Version vorzuziehen, die aber nur eine Betaversion des Opensolaris-Kernels verwendet, was auch nicht gerade für Stabilität spricht.

Ausblick

  • Herausfinden, warum der Pool ständig unlesbar wird.
  • Es fehlen noch die automatischen Snapshots und das automatische Überprüfen der Datenintegrität.
  • Geschwindigkeit verbessern, z.B. könnte man im lokalen Netzwerk auf den kryptographischen Overhead verzichten, d.h. man könnte unverschlüsselte Protokolle einsetzen.
  • Ich suche noch nach Alternativen für eine energieeffiziente und praktikable Lösung. “Wake on LAN” funktioniert, dazu müsste das System aber im Standbybetrieb bleiben, was immer noch über 20 Watt benötigt. Sobald der Strom einmal abgeschaltet wurde, funktioniert das Aufwecken über das Netzwerk nicht mehr?!
  • CD-ROM, Diskettenlaufwerk und weitere nicht benötigte Komponenten könnten entfernt werden.
  • Ein schnellerer Bootvorgang wäre toll.
  • Ein zusätzlicher Mechanismus zur Langzeitarchivierung wäre wünschenswert, d.h. hin und wieder sollten Backups auf lang haltbare Speichermedien übertragen werden.
Comments are closed.