2016 scheint für mich das Jahr der neuen Hardware-Renewals zu sein - nachdem schon meine komplette virtuelle Infrastruktur ausgetauscht wurde, benötigte das NAS nach knapp 4 Jahren neue Festplatten.

NAS, DAS, was?

Seit zahlreichen Jahren verwende ich stets selbst zusammengestellte NAS, um meine Daten und eine Medienbibliothek an einer zentraler Stelle zu sammeln. Nachdem ich zwischenzeitlich immer mal wieder die Hardware-Plattform gewechselt habe, kommt hierfür aktuell wieder ein HP MicroServer Gen8 mit vier 2 TB Festplatten (Details weiter unten!) zum Einsatz. Einmal in der Woche werden Backups ausgeführt, die letztendlich auch den gesamten Datenbestand auf ein externes Festplatten-Gehäuse, einem Onnto DataTale mit ebenfalls vier 2 TB Festplatten, synchronisieren. Beide Systeme binden die Festplatten in einem RAID-5 Verbund an. So mancher mag das als paranoid bezeichnen - mir hat die Vergangenheit jedoch gezeigt, dass es nicht schaden kann, auf "Nummer sicher" zu gehen ("Better safe than sorry"). 🙂

Aktuell stört mich vor allem der eher mäßige Datendurchsatz meines NAS, was der damaligen Planung geschuldet ist. Entgegen meiner ursprünglichen Planung dient das NAS nämlich nicht nur als "Datengrab", sondern auch als Shared Storage meiner VMware vSphere-Umgebung. Bezüglich der Stabilität kann ich mich keineswegs über meine damalige Entscheidung beschweren - die HGST-Festplatten laufen (obwohl sie nicht dafür konzipiert sind) im Dauerbetrieb und haben mich bisher noch nie im Stich gelassen. Speicherkapazität ist weniger ein Problem. Ich entferne regelmäßig nicht mehr benötigte Daten und habe derzeit noch ca. 1 TB frei - also habe ich vor 4 Jahren ein durchaus realistisches Wachstum eingeplant. 🙂

Festplatten-Auswahl

Bei der Auswahl der Festplatten war mir eine feste Drehzahl wichtig. Variable Drehzahlen aufgrund erkannter Zugriffsmuster (à la Coolspin, IntelliPower™) machen bei meinem Setup wenig Sinn. Im Internet habe ich mehrfach (z. B. hier) gelesen, dass diese Techniken unter Linux die Lebenszeit der Festplatten verkürzen können, da hier offensichtlich unnötige Spin-Down/-Up Kommandos ausgeführt werden. Seagate wäre eine denkbare Alternative, die jedoch aufgrund persönlicher Erfahrungen ausscheidet. Ich will hier ganz sicher kein Bashing betreiben - Produktionsfehler gibt es bei jeder Marke und sicherlich auch jedem Produkt. Ich für meinen Teil hatte zu viel Defekte bei Seagate-Festplatten und habe keine Lust auf weitere Experimente - zumindest nicht bei meinem NAS, welches für mich wichtige Daten enthält. 😉

Letztendlich habe ich mir die aktuelle Deskstar NAS und Ultrastar-Serie von HGST angeschaut. Die letzten Jahre hatte ich bereits 8 Festplatten von HGST im Einsatz und war äußerst zufrieden. Die folgende Tabelle vergleicht meine aktuellen Festplatten mit zwei potenziellen Nachfolge-Produkten:

Das Hauptmanko meiner aktuellen Lösung ist der Datendurchsatz, weswegen mir ein großer Cache von 128 MB wichtig war. Die Deskstar NAS- und Ultrastar-Serie unterscheiden sich hier geringfügig im Datendurchsatz. Bezüglich der Garantie und der mittleren Betriebszeit zwischen Ausfällen (MTBF, Mean Time Between Failures) gibt es jedoch große Unterschiede - hier glänzt die Ultrastar mit längerer Garantie und einer doppelt so hohen Zeitspanne. Beide Festplatten sind für den 24 Stunden-Einsatz freigegeben, was bei meinen aktuellen Festplatten nicht der Fall ist. Der Preisunterschied zwischen den beiden Produkten ist nicht sehr groß, was mir die Entscheidung nicht gerade erleichterte.

Wie bereits erwähnt, ist die Datenmenge nicht das Problem - weswegen das Upgrade auf 6 TB-Festplatten nicht allzu verlockend war. Mit einem Wechsel auf 4 TB-Festplatten könnte ich die Anzahl der verwendeten Festplatten von vier auf drei verringern und hätte trotzdem noch mehr Speicherplatz (8 TB statt 6 TB im RAID-5 Verbund). Das käme auch dem höheren Stromverbrauch der Ultrastar-Festplatten entgegen. Sollte der Speicherplatz knapp werden, könnte ich noch eine weitere Festplatte hinzufügen, da der MicroServer über vier Festplatteneinschübe verfügt.

Bei meinem externen Gehäuse müssen mittelfristig auch Festplatten ersetzt werden, sobald die Speicherauslastung auf dem NAS steigt. Hier müssen es jedoch nicht unbedingt besonders schnelle Festplatten sein, da ich die DataTale lediglich einmal in der Woche zu Backup-Zwecken anschalte. Anbei wieder ein Vergleich:

Auch hier ist der preisliche Unterschied zwischen den beiden Produkten wieder nicht sehr groß. Da das Gehäuse nur sporadisch genutzt wird, ist es nicht notwendig, für den Dauerbetrieb zertifizierte Festplatten einzusetzen. Anhand der Modellbezeichnungen der beiden Festplatten zeigt sich, dass die Deskstar NAS-Festplatten den herkömmlichen Deskstar-Festplatten sehr ähneln (H3IKNAS40003272SE, H3IK40003272SE). Folglich dürften die Unterschiede sehr gering ausfallen - böse Zungen im Internet behaupten sogar, es gäbe keine technischen, sondern lediglich Marketing-Unterschiede. 😉

Fazit

Letztendlich habe ich mich für das NAS für die HGST Ultrastar 7K6000 entschieden. Da der Speicherplatz der DataTale derzeit noch ausreicht, habe ich hierfür noch keine neuen Festplatten gekauft. Wenn das der Fall ist, werde ich vermutlich auf die HGST Deskstar 7K4000 setzen.

Benchmark

Die Festplatten wirken sehr hochwertig, sie sind im Vergleich zu herkömmlichen Consumer-Festplatten deutlich schwerer. Die Lautstärke hält sich in Grenzen, lediglich unter Volllast sind sie deutlich hörbar. Für ein leises NAS sind die Festplatten also nicht unbedingt zu empfehlen.

Bevor ich Festplatten in Betrieb nehme, unterziehe ich sie gewöhnlich einem ausgiebigen Test auf fehlerhafte Sektoren. Mit HD Tune lassen sich auch Performance-Benchmarks ausführen - eine gute Gelegenheit, um zu schauen, ob die Festplatte auch hält, was sie verspricht.

Mit durchschnittlich 180 MB/s lesend und schreibend kommt sie den beworbenen 208 MB/s schon ziemlich nahe.

Implementation

Für meine selbstgebauten NAS-Systeme verwende ich seit geraumer Zeit mdadm, LUKS und LVM. Ich verwende bewusst kein Hardware-RAID - im Falle eines Defekts müsste nämlich der gleiche Controller erneut beschafft werden, was nach einigen Jahren durchaus problematisch sein kann. Darüber hinaus finden Hardware RAID-Controller vor allem dort Verwendung, wo die Host-CPU andere Dinge als das Verwalten des RAIDs erledigen soll - im Falle eines NAS ist das also überflüssig. Die Migration von Software RAID-Volumes unter Linux ist sehr komfortabel - es genügt, die Festplatten in ein anderes Linux-System zu verbauen und das Volume einzuhängen. 🙂

Nachdem die Festplatten verbaut wurden, habe ich diese erstmal mit einem GPT-Label versehen und Software RAID-Partitionen erstellt:

1# parted /dev/sd{a,b,d} mklabel gpt
2# parted -a optimal -- /dev/sd{a,b,d} mkpart primary 0% 100%
3# parted /dev/sd{a,b,d} set 1 raid on

Anschließend habe ich das RAID-5 Volume mit mdadm erstellt:

1# mdadm --create /dev/md0 --auto md --level=5 --raid-devices=3 /dev/sda1 /dev/sdb1 /dev/sdd1

Der Fortschritt der initialen Datensynchronisation kann über die Datei /proc/mdstat eingesehen werden:

1# cat /proc/mdstat
2md0 : active raid5 sdd1[3] sdb1[1] sda1[0]
3      7813771264 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
4      [>....................]  recovers =  3.8% (151748612/3906885632) finish=331.3min speed=188880K/sec
5      bitmap 0/30 pages [0KB], 65536KB chunk
6
7unused devices: <none>

Nach der Fertigstellung kann der verschlüsselte LUKS-Container über das RAID-Volume erstellt werden.

 1# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/md0
 2
 3WARNING!
 4========
 5This will overwrite data on /dev/md0 irrevocably.
 6
 7Are you sure? (Type uppercase yes): YES
 8Enter LUKS passphrase:
 9Verify passphrase:
10Command successful.

Anschließend kann der LUKS-Container aktiviert werden:

1# cryptsetup luksOpen storage

Abschließend fehlen noch das LVM-Konstrukt, bestehend aus physischem Volume, Volumengruppe und logischem Volume und ein Dateisystem:

1# pvcreate /dev/mapper/storage
2# vgcreate vg_storage /dev/mapper/storage
3# lvcreate --name lv_storage --extents 100%FREE
4# mkfs.ext4 /dev/mapper/vg_storage-lv_storage
5# mkdir /mnt/storage

Zum Einhängen des verschlüsselten Konstrukts verwende ich ein kleines Skript:

1#!/bin/sh
2cryptsetup luksOpen /dev/md0 storage
3vgscan
4lvchange -a y vg_storage
5mount /dev/mapper/vg_storage-lv_storage /mnt/storage

Analog dazu, um das Konstrukt sauber auszuhängen:

1#!/bin/sh
2umount /dev/mapper/vg_storage-lv_storage
3lvchange -a n vg_storage
4cryptsetup luksClose storage

Im Benchmark erreicht der verschlüsselte Container lesend ca. 300 MB/s - ein Wert, der sich durchaus sehen lassen kann. Das vorherige Volume war deutlich langsamer. Nach einigen Wochen bin ich immer noch sehr zufrieden mit dem Setup. 🙂