Nachdem ich meinem Homeserver vor einiger Zeit ein neues Herz eingepflanzt habe, war nun ein Upgrade der Festplatten notwendig. Aber zuerst ein bisschen Historie…

Als ich den Server aufgebaut habe, habe ich mir natürlich auch gründlich überlegt, wieviele Platten ich brauche und in welcher Konfiguration ich diese verwende. Dabei spielten u.a. die Faktoren Preis, Zuverlässigkeit, Energie- und Platzbedarf mit:

Preis: Der Server läuft zwar 24×7 und die Platten werden nicht in den Standby-Modus gefahren. Aber für Dauerbetrieb ausgelegte Festplatten kosten gerne mal doppelt soviel wie normale Desktop-Versionen. Bei einer geschätzten Nutzungsdauer von 1,5 Jahren greife ich zur günstigeren Variante.

Zuverlässigkeit: Um eventuellen Defekten vorzubeugen, setze ich auf doppelte Parity (RAID6 oder raidz2 bei Solaris ZFS). So können zwei beliebige Festplatten gleichzeitig ausfallen, ohne die Datenkonsistenz zu gefährden.

Energiebedarf: Ich brauche kein Maximum an Performance, daher sind energiesparende Festplatten mit ~5400 Umdrehungen pro Minute sinnvoller als die schnelleren Modelle mit 7200 UPM. Nebenbei sind sie leiser und werden nicht so warm.

Platzbedarf: Mein “alter” Linux-Server hatte etwa 2,5 TB Kapazität, also kalkuliere ich für den neuen Server erst mal mit 3 TB Nettokapazität. Ich gehe davon aus, dass mein Platzbedarf langsamer wächst als die Datendichte bei Festplatten zunimmt. Mit der Zeit werde ich die Festplatten durch Modelle mit höherer Kapazität ersetzen, aber die Zahl der Platten bleibt konstant.

Ich neige dazu, Hardware nur genau dann und in der Menge zu kaufen wie ich sie brauche, ohne dabei allzu sehr auf “Zukunftssicherheit” zu achten. Viele Jahre Erfahrung haben mich gelehrt, dass sich derartige Investitionen nicht auszahlen, da die als zukunftssicher geglaubten Standards doch schneller abgelöst werden als einem lieb ist.

Zum Zeitpunkt der Anschaffung lag der “sweet spot” für 3,5”-SATA-Festplatten bei 1,5 TB – genau passend für meinen Bedarf. 2 TB waren auch schon gut verfügbar, aber noch etwas teuer. Also habe ich 4 x 1,5 TB von Samsung (EcoGreen F2 HD154UI, Stückpreis rund 63 EUR) bestellt und verbaut. Meine Erwartungen wurden erfüllt: Die Platten arbeiten günstig, leise und energiesparend – und es gab keine Ausfälle. Hinzu kamen noch zwei 2,5”-Platten für das Betriebssystem, diese habe ich vom alten Server recyclet.

Anscheinend habe ich aber die Wachstumsgeschwindigkeit meiner Datenhalde etwas unterschätzt, denn wenig mehr als 6 Monate später ist die Kapazität nahezu erschöpft. Also müssen neue Platten her! Diesmal habe ich mich für 2 TB Hitachi 5K3000 entschieden, diese sind erfreulicherweise für 24×7-Betrieb spezifiziert und kosten kaum mehr als die Samsungs (68 EUR das Stück).

Das eigentliche Ersetzen der Platten ist unspektakulär:

• Rechner ausschalten
• Neue Festplatte anschliessen (dabei entweder die alte Festplatte ersetzen oder die neue Festplatte an einen freien SATA-Port anschliessen)
• Rechner einschalten
• zpool replace <Name des zpools> <altes Device> <neues Device>
• Warten (die Daten werden nun rekonstruiert, das dauert in meinem Fall etwa 8 Stunden)

Dies wiederholt man nun nach und nach für jede Festplatte. Ob die Platte nun in-place ersetzt wird oder erst zusätzlich angeschlossen wird, hängt wohl v.a. von den freien SATA- und Stromanschlüssen ab. Das “zpool replace” braucht in beiden Fällen gleich lange. Wenn genügend freie SATA-Ports vorhanden sind, kann man auch mehrere Platten auf einmal ersetzen; bei zwei Platten dauerte das Rebuild bei mir ca. 10 Stunden, ging also deutlich schneller als 2 x 8 Stunden.

Sofern man beim zpool das Attribut “autoexpand” auf “on” gesetzt hat, wird der Pool automatisch vergrößert, sobald auf allen Devices freier Speicherplatz zur Verfügung steht. Der zusätzliche Platz steht dann sofort zur Verfügung.

All diese Operationen sind dabei im laufenden Betrieb möglich, aus Anwendungs-/Betriebssicht spürt man höchstens die durch das Rebuild beeinträchtige, geringere Performance. Sofern man hot-swappable Hardware nutzt, entfällt sogar das Aus- und Einschalten beim Plattenwechsel.

Zum Abschluss noch eine kleine aber feine Beobachtung. Im Laufe dieses ganzen Procederes hatte ich bei einer der Platten im Pool den Stromstecker nicht richtig drauf, sodass dem zpool auf einmal Laufwerk fehlte. Er lief natürlich, war aber im “degraded” Zustand – was eine erneute Synchronisation des Mediums erforderlich macht. Also, Rechner wieder aus, Kabel überprüft, Rechner wieder an, Platte da. Ich ärgerte mich schon darüber, erneut 8 Stunden warten zu dürfen. Aber siehe da: ZFS erkannte, dass die Platte wieder verfügbar war, synchronisierte neu und war bereits nach wenigen Megabyte fertig! Dabei wurde nur der Teil der Daten synchronisiert, bei dem es seit dem letzten Vorhandensein des Laufwerks Änderungen gegeben hatte. Mit Linux/mdadm wäre an dieser Stelle eine komplettes Rebuild des RAID-Arrays fällig gewesen. ZFS FTW! Linux sollte man an der Stelle aber auch Zugute halten, dass die Anzahl der Laufwerke in einem RAID variiert werden kann. So kann ein RAID6 z.B. durch das Hinzufügen einer weiteren Platte on-the-fly vergrößert werden. Dieses “reshaping” hat ZFS bis heute nicht gelernt.

Fazit: ZFS ist ein wirklich geniales Filesystem, das alltägliche Wartungsarbeiten einfach macht. Wieviel Intelligenz dahinter steckt, scheint nur hier und da durch. Im nächsten Artikel werde ich berichten, was es beim Austausch der Boot-Platte zu beachten gilt.

Mein gestern umgerüsteter Homeserver läuft noch immer – so weit, so erfreulich. Beim Schmökern in der c’t geriet ich aber ein wenig ins Grübeln. Ich laß einen Testbericht aktueller Mainboards, in dem unter anderem auf die teils mangelhaft vorkonfigurierten BIOS-Einstellungen hingewiesen wurde, insbesondere in Sachen SATA-Controller. Ich hatte gestern zwar ins BIOS geschaut und einige Einstellungen angepasst, aber über den Betriebsmodus des SATA-Controllers bin ich dabei nicht gestolpert.

Also kontrollierte ich dies heute, und wie befürchtet lief der SATA-Controller im IDE-Kompatibilitätsmodus. Das führt unter anderem dazu, dass NCQ (Native Command Queuing) nicht genutzt werden kann und so einiges an Performance verschenkt wird. Also flugs die Einstellung auf den nativen SATA-Betrieb umgestellt (AHCI) und neu gebootet.

Es kam wie es kommen musste, die Diva Solaris weigerte sich zu starten (dabei ist sie übrigens in guter Gesellschaft, auch Windows kann es überhaupt nicht leiden, wenn man den SATA-Controller umkonfiguriert, an den die Boot-Platte angeschlossen ist). Ich wollte schon das gestern beschriebene Hardware-Rekonfigurationsprocedere erneut durchführen, googelte aber noch kurz und siehe da: Die Lösung Veröffentlicht unter bits + bytes | Verschlagwortet mit Homeserver, Solaris | Leave a reply

Wie vor einigen Tagen berichtet stand bei meinem Homeserver ein Hardwareupgrade an. Dem habe ich mich heute gewidmet, allerdings erst einmal nur provisorisch. Man weiss ja nie, ob die neue Hardware auch so funktioniert wie man sich das vorstellt. So schaut’s derzeit unter’m Schreibtisch aus:

Soweit läuft die Maschine wieder, allerdings war dafür bei Solaris ein wenig mehr Handarbeit von Nöten als ich dies von Linux gewohnt bin.

Als Vorbereitung habe ich erst einmal ein neues Boot Environment angelegt, um ggf. einfach wieder zur alten Konfiguration zurück zu können. ZFS und Snapshots machen’s möglich:

beadm create solarisexpress11-new

Nun galt’s, die neue Hardware anzuschliessen und von einer Live-CD zu booten, um das System mit der neuen Hardware vertraut zu machen. Dabei war dieser Bug Report sehr hilfreich. Zuerst muss das root-Filesystem eingebunden sowie das Boot Environment gemountet werden, danach wird die Hardwarekonfiguration erneuert und zuletzt das Boot Archive (eine Art initramfs) aktualisiert:
# Passwort der Live-CD lautet “solaris”
pfexec su -

# -f ist erforderlich, da das Filesystem zuletzt auf einer anderen
# Maschine gemountet war und nicht exportiert wurde
zfs import -f rpool

# Boot Environment einbinden
mkdir /x
beadm mount solarisexpress11-new /x

# Device Tree neu erstellen
mv /x/etc/path_to_inst /x/etc/path_to_inst.orig
touch /x/etc/path_to_inst
devfsadm -C -r /x
devfsadm -r /x

# reconfigure beim nächsten Start erzwingen
touch /x/reconfigure

# Boot Archive aktualisieren
bootadm update-archive -R /x

# Filesystem synchronisieren und Boot Environment aushängen
cd /
sync
beadm unmount solarisexpress11-new
Das war’s. Beim nächsten Neustart erkennt Solaris die neue Hardware, richtet sie ein und die Kiste läuft wieder.

Erfreulicherweise scheint sich das Upgrade auch gelohnt zu haben. Aus Sicherheitsgründen mache ich einmal pro Woche einen vollständigen Integritätstest des Filesystems, einen sogenannten scrub. Man will ja wissen, wann die Platten anfangen Daten zu verlieren. Beim Daten-Pools dauerte das zuletzt 12 Stunden und 17 Minuten. Der aktuelle Durchgang ist bei etwa der Hälfte, die geschätzte Gesamtdauer liegt bei unter 8 Stunden. Sehr schön!