Platz da: Wie man einen Solaris zpool durch Ersetzen der Festplatten vergrößert

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.