Die Qual der Wahl: Neue Festplatten für das NAS

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:

Deskstar 5K3000 Deskstar NAS Ultrastar 7K6000
Größen 1,5-3 TB 3-6 TB 2-6 TB
Ausgewähltes Modell [tooltip text=“HDS5C3020ALA632″ trigger=“hover“]2 TB[/tooltip] [tooltip text=“H3IKNAS600012872SE“ trigger=“hover“]6 TB[/tooltip] [tooltip text=“HUS726040ALE610″ trigger=“hover“]4 TB[/tooltip]
RPM Coolspin (~5.400) 7.200
Cache 32 MB 128 MB
Geschwindigkeit (avg) 97 MB/s 198 MB/s 208 MB/s
Zugriffszeit (avg) 8,2 ms 8,2 ms 7,8 ms
Stromverbrauch (Leerlauf/Zugriff) 4,4 Watt / 6,4 Watt 6,9 Watt / 8,9 Watt 7,1 Watt / 9,1 Watt
24/7 Nein Ja
MTBF 1 Million 1 Million 2 Millionen
Garantie 3 Jahre 3 Jahre 5 Jahre
Preis 110 € (2012) ~240 € ~250 €

 

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:

Deskstar 5K3000 Deskstar NAS Deskstar 7K4000
Größen 1,5-3 TB 3-6 TB 2-4 TB
Ausgewähltes Modell [tooltip text=“HDS5C3020ALA632″ trigger=“hover“]2 TB[/tooltip] [tooltip text=“H3IKNAS40003272SE“ trigger=“hover“]4 TB[/tooltip] [tooltip text=“H3IK40003272SE“ trigger=“hover“]4 TB[/tooltip]
RPM Coolspin (~5.400) 7.200
Cache 32 MB 64 MB
Geschwindigkeit (avg) 97 MB/s 160 MB/s 182 MB/s
Zugriffszeit (avg) 8,2 ms 8,2 ms 8,9 ms
Stromverbrauch (Leerlauf/Zugriff) 4,4 Watt / 6,4 Watt 6,9 Watt / 8,9 Watt 6,7 Watt / 8,9 Watt
24/7 Nein Ja Nein
MTBF 1 Million
Garantie 3 Jahre
Preis 110 € (2012) ~145 € ~140 €

 

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:

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

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

# 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:

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

unused devices: <none>

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

# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/md0

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Anschließend kann der LUKS-Container aktiviert werden:

# cryptsetup luksOpen storage

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

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

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

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

Analog dazu, um das Konstrukt sauber auszuhängen:

#!/bin/sh
umount /dev/mapper/vg_storage-lv_storage
lvchange -a n vg_storage
cryptsetup 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. 🙂

Sharing is caring


Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInShare on XingShare on RedditPrint this pageEmail this to someone

12 Kommentare Schreibe einen Kommentar

  1. Ich kann noch empfehlen zwei SSDs über bcache oder lvmcache hinzuzuschalten. Das bringt nochmal einen ernomen Schub, vor allem bei sync-writes.

    • Hey Andreas,
      da war ich ein wenig skeptisch, weil die Meinungen im Internet so weit auseinander gehen.

      Hast Du das bei dir am Laufen? Wie zeichnet sich das in einem Benchmark aus?

      Beste Grüße!

      • Ich habe mit bcache und ZFS sehr gute Erfahrungen (= gute Performance) gemacht, verwende es aber nicht mehr produktiv, da der Aufbau schon etwas viel ‚Gewuschdel‘ ist. Ich hatte auch mehr als ein Jahr flashcache im Einsatz, was auch gut funktioniert hatte. Beide Methoden waren technisch gesehen ein einfachsten und auch auf unterster Schicht angesiedelt, die die Verwendung ähnlich luks funktioniert und über den device mapper das finale Gerät zur Verfügung stellt. Integration ins OS war leider nur manuell möglich was ggf. bei einem Update auch in die Hose gehen kann.

        Daher verwende ich jetzt nur noch lvmcache, da die Integration in aktuelle Betriebssysteme wesentlich einfacher möglich ist (auch wenn das heißt, dass man dann überall LVM benötigt, was bei ZFS eher hinderlich ist).

        Aber generell ist der Geschwindigkeitsvorteil schon enorm wenn man hier write-back verwenden möchte – sollte man dann eigentlich immer nur mit 2 SSDs machen.

        Was den Benchmark angeht:
        Ich selbst teste aber eigentlich nie Durchsatz, sondern immer nur random IO und der wird deutlich besser dadurch. Ob das synchrone Schreiben besser wird ist natürlich sehr von der verwendeten SSD abhängig, da hier Consumer SSDs nicht wirklich gut sind. Für eine Liste guter SSD kann ich dir folgende Seite empfehlen:
        http://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is-suitable-as-a-journal-device/

        Hier mal noch ein sehr subjektiver Eindruck, aber wenn man z.B. mehrere Tage an einer VM öfters arbeiten muss (inkl. hoch- und runterfahren) und somit die meisten Blöcke in den Cache wandern wird die VM schon sehr schnell. Mein Eindruck ist aber eher für einen Laptop im Dauereinsatz, für Serverumgebungen kann ich zu Eigenbau Storage-Tiering nicht viel sagen, da käuft man sich das ja meistens ein (oder man hat ZFS mit L2ARC, und da ist es ein No-Brainer).

        Für deinen nächsten ‚Build‘ kannst du ja auch mal an ZFS denken. Ich habe mein NAS nun komplett darauf umgestellt (nach einigen anderen Projekten in dem Umfeld) und bin damit natürlich langsamer als mit LVM und Software-RAID, habe aber super schnelle inkrementelle Backups, Snapshots und Kompression. Mit der geeigneten Virtualisierungsumgebung ist das dann echt super (CoW, Snapshots, Backups, etc).

      • Danke für die interessanten Anregungen! 🙂

        ZFS ist ein sehr cooles Dateisystem – mich stört nur sehr stark, dass es nicht offiziell im Linux-Kernel gewartet wird. Daher würde ich vermutlich eher auf Illumos/nexentaStor setzen, als auf ein Linux-basiertes NAS. Teste das immer mal wieder in VMs, aber wirklich repräsentativ ist das natürlich nicht..

        Welches Betriebssystem setzt du auf deinem ZFS-NAS ein?

        Beste Grüße!

  2. Pingback: Stankowic development – D-Link DGS-1510-28X – günstiger 10G-Switch

    • Hey Matthias,
      gute Frage – die 300 MB/s beziehen sich auf das, was ich mit bmon bei VM-Migrationen bzw. hdparm ohne Cache sehe:
      # hdparm -t /dev/md0
      /dev/md0:
      Timing buffered disk reads: 1096 MB in 3.00 seconds = 365.11 MB/sec
      # hdparm -t /dev/md0
      /dev/md0:
      Timing buffered disk reads: 1076 MB in 3.01 seconds = 357.62 MB/sec
      # hdparm -t /dev/md0
      /dev/md0:
      Timing buffered disk reads: 1098 MB in 3.00 seconds = 365.69 MB/sec

      Eine einzelne Festplatte kommt auf knapp 200 MB/s, was vermutlich dem großen internen Cache von 128 MB geschuldet ist:

      # hdparm -t /dev/sda
      /dev/sda:
      Timing buffered disk reads: 578 MB in 3.00 seconds = 192.54 MB/sec

      Von daher scheinen die 300 MB/s für das gesamte RAID 5-Volume mit 3 Festplatten durchaus realistisch zu sein. 😀

      • Unverschlüsselt sind die 300 MB/s schon realistisch, aber mit dem Celeron und deiner cryptsetup Konfiguration wirst du keine 300 MB/s erreichen. Ich habe auch den HP MicroServer mit Celeron und habe das vor einiger Zeit mal ausgiebig mit dd getestet:
        http://www.directupload.net/file/d/4400/jlvjbh29_png.htm

        Jetzt läuft es schon eine Weile produktiv mit Debian und LUKS+ZFS.

      • Sehr schöner Graph, Matthias! Hast Du denn manuell erstellt? Oder gibt es dafür eine passende Software?

        In der Tat unterstützt der G1016T keine AES-NI (Intel® Advanced Encryption Standard Instructions). In einem Benchmark gestern habe ich gesehen, dass die CPU ordentlich mit der Ver-/Entschlüsselung zu kämpfen hat, wenn ich IO-Benchmarks auf den VMs starte und parallel noch über Samba Dateien kopiere. Ich sollte mal nach einer anderen CPU schauen..

        Beste Grüße!

  3. Ich verwende für alles Debian, da ist ZFS seit kurzem ja integriert. Früher habe ich Proxmox als ZFS-basis verwendet (und dann natürlich auch gleich die Virtualisierungsoftware dazu verwendet)

    Sag mal, bin ich nur zu doof oder wo ist bei den weiteren Kommentaren der Antworten-Knopf? Ich sehe ihn beim Hovern über meinem ersten Kommentar und deinem ersten, aber danach sehe ich kein „antworten“ mehr.

    • Wenn ich mich recht entsinne, kann man lediglich direkt auf Kommentare der ersten beiden Ebenen antworten. Ab einer Verzweigung des dritten Grades kann man nicht mehr direkt antworten, um das Design der Seite nicht zu zerschießen. 😀

  4. @Christian: Das Diagramm lässt sich leider nicht automatisch erstellen. Das sind mehrfache dd-Durchläufe (1 Ergebnis im Diagramm = Durchschnitt aus 10 Durchläufen mit 40GiB pro Test) gewesen, die ich dann mit (Apple) Numbers bisschen übersichtlicher dargestellt habe.

Schreibe einen Kommentar