NAS Box / File Server: Storage Spaces vs FakeRAID

[StefanDinslaken]

Das schöne an FreeNAS ist, dass es quasi eine Appliance ist. Du kannst (und sollst) im BSD also gar nicht viel ändern. Für das Management gibt es eine Web-UI, die Doku dazu ist recht ausführlich und das Forum ist auch klasse.

Das ist auch etwas, das ich an meinem QNAP sehr schätze - es hat ne schöne GUI, mit der man alles machen kann. Dafür ist man bzgl. Software schon eingeschränkt. Da geht unter Windows deutlich mehr, wenn man nicht auf der Kommandozeile rumhaken will. Man muss hier wirklich abwägen, was einem wichtig ist.

ECC ist jetzt gar nicht so teuer. Die Pentium haben schon ECC-Support, alternativ Intel Avoton (C2550, C2750) als AiO-Plattform. ECC-RAM selbst ist auch nicht so teuer. Den Löwenanteil nehmen die Festplatten ein

Danke für den Tipp, ich schaue mir die genannte Intel Plattform mal an! Auch fehlt mir hier noch Wissen zu ECC, inwiefern das die Stabilität von so einem Storage Pool unter ReFS verbessert. Wenns jemand weiss, nur her damit, sonst muss ich das mal recherchieren.

 

[d4nY]

ECC ist insofern wichtig, wenn es um die Checksummen geht. Ich rede jetzt hier einfach mal von ZFS, aber ich denke bei ReFS ist es ähnlich:

Jedesmal wenn eine Datei geschrieben/geändert wird, wird eine Checksum gebildet, die wird mit den Meta-Informationen abgelegt. Jetzt gibt es bei ZFS die sog. Scrubs, die laufen in regelmäßigen Intervallen und prüfen, ob die geschrieben Daten mit den Checksummen übereinstimmen. Falls ja ist alles gut, falls nicht wird versucht die Daten mit Hilfe der Paritätsinformationen (Spiegelung, RAID5,6) wiederherzustellen.
Jede dieser Aktionen findet im RAM statt, ergo kann (mit expliziter Betonung auf KANN) es sein, dass sich ein Bit dreht und die Checksumme falsch eingelesen wird und ZFS die Datei auf der Festplatte für fehlerhaft hält und die eigentlich korrekten Daten könnten dann durch fehlerhafte Daten überschrieben werden

Ist insgesamt ein sehr theoretisches Problem
Wenn du mal nach "zfs ecc ram" googlest findest du haufenweise Blogs und Posts und alles mögliche dazu, wieso ECC RAM unumgänglich ist oder wieso es nicht ist
Man kann, wenn man sich der Risiken bewusst ist, auch auf ECC verzichten (man sollte ja so oder so ein Backup haben). Empfohlen wird es aber natürlich immer, weil man einfach auf Nummer sicher geht.

Wie auch ein Entwickler von ZFS sagt: ECC ist für ZFS nicht wichtiger als für jedes andere Dateisystem auch. Ich bin lange Zeit ohne ECC gefahren (gab nie Probleme), hab mir dann aber einen i3, sowie ein Board mit IPMI zugelegt und da war ECC dann quasi auch mit dabei

Zur Flexibilität: FreeNAS bzw. FreeBSD unterstützt Jails, so eine Art VM (hab mich damit aber auch noch nicht wirklich beschäftigt). In Zukunft gibt's dann auch Unterstützung für einen "echten" Hypervisor (bhyve)

 

[StefanDinslaken]

Danke für die Erläuterungen zu ECC, jetzt habe ich das einigermaßen verstanden.

Die Schreibperformance bei Storage Spaces ist ohne SSDs als Write Back Cache recht bescheiden, mehr als 40MB/s bekommst du da nicht hin.

Was ist hier eigentlich das Nadelöhr? Die CPU oder die HDD?

Des Weiteren frage ich mich, welche Platten man hier einsetzen sollte. Bei klassischem RAID rät man ja zu speziellen Platten wie WD Red. Ist dies bei Storage Pools auch der Fall, oder kann man hier alles rein werfen?

 

[Wilhelm14]

ECC und ZFS sollten z.B. fertige Server wie der Dell T20 haben (135 € durch Cashback ohne Laufwerke). FreeNAS.

Im Idealfall ist die Verfügbarkeit nicht unterbrochen. Gibt's denn einen Vorteil bei der Variante mit zwei Backups statt Redundanz im Server?

Das kommt natürlich ganz auf den persönlichen Geschmack an. Bei einem RAID 5 hast du trotz Plattenausfall durchgehende Verfügbarkeit und du musst nur die defekte HDD tauschen. Bei Backups musst du warten, bis das Backup wieder eingespielt ist. Rein mit Backups hat man außerdem nur den Datenstand des letzten Backups. Wenn man täglich, wöchentlich oder monatlich Backups macht, können im schlimmsten Fall Daten eines Tages, einer Woche oder eines Monats weg sein. Das ist dir aber alles bekannt.

Mir persönlich reichen in meinem Privatbereich reine Backups. Ich habe keine Lust, Jahre oder gar Jahrzehnte lang mehrere Festplatten im RAID laufen zu lassen um irgendwann mal in den Genuss des Vorteils zu kommen. Mir ist der Nutzen zum Aufwand nicht hoch genug. Lärm, Wärme, Strom, Mehrkosten für HDD Anzahl. Ich nutze z.B. aktuell ein 1-Bay NAS von Synology. Hier spreche ich nur für mich. Das muss jeder für sich selbst abwägen. Und ja, für andere Bereiche würde ich auch Soft-RAIDs oder Storage-Pools nehmen. Du schreibst, dass du den Server für die Arbeit brauchst.

PS: Ich würde wegen des Dauerbetriebes weiterhin WD Red nehmen. Und Storage Pools sind SoftRAIDs, sollten also die Platten ähnlich "belasten".

 

[Masamune2]

Ich glaub das Risiko könnte ich verkraften. Vermutlich lässt mich Microsoft aber nicht, korrekt?

Korrekt

Was ist hier eigentlich das Nadelöhr? Die CPU oder die HDD?

Die Latenz der Platten ist das Problem. Ohne Schreibcache werden Daten erst als geschrieben gemeldet wenn das Stripeset eingelesen, die Daten verändert, die Parität berechnet, das Stripeset wieder geschrieben und dazu noch die Meta infos geschrieben wurden. Das erfordert viele Kopfbewegungen und macht die Geschichte langsam.
Mit Schreibcache wird erst mal alles in SSDs abgelegt die sehr viel schneller sind (besonders die Latenz) und wenn ein komplettes Stripeset zusammen ist kann er direkt auf die Platten geschrieben werden ohne vorher das alte zu lesen und zu verändern. Das sorgt für die massive Beschleunigung mit aktiviertem Schreibcache. Gilt genauso auch für Hardware Raid Contoller mit (Battery/Flash Backed) Write Cache.

 

[StefanDinslaken]

Mit Schreibcache wird erst mal alles in SSDs abgelegt die sehr viel schneller sind (besonders die Latenz) und wenn ein komplettes Stripeset zusammen ist kann er direkt auf die Platten geschrieben werden ohne vorher das alte zu lesen und zu verändern. Das sorgt für die massive Beschleunigung mit aktiviertem Schreibcache.

Ah, okay. Wie realisiert man sowas denn? Du schriebst oben von 2x 10 GB SSDs, aber gibts so kleine SSDs heute überhaupt noch? Oder kann man da einfach USB3 Sticks nehmen? Die sind ja eig. für sowas nicht gedacht.

 

[Masamune2]

So kleine SSDs gibts natürlich nicht und auch alte SSDs mit SLC Zellen machen kaum noch Sinn. Zwar halten die sehr viel aus, sind aber auch relativ langsam.
Ich würde zwei günstige Consumer SSDs nehmen und den Wear-Level Counter im Auge behalten. Solange du nicht jeden Tag viel auf den Server schreibst dürften die lange halten, zumal du ja immer viele leere Zellen hast wenn von einer 128GB SSD nur 10GB aktiv genutzt werden.

USB Sticks eigenen sich erst mal nicht da sie als Wechseldatenträger erkannt werden. Windows-to-Go Sticks die sich als Festplatte ausgeben dürften auch nicht funktionieren.

 

[d4nY]

Bei USB-Sticks würde ich auch aufpassen, weil die sich an vielen kleinen Schreibvorgängen schon auch mal zu Tode schreiben können (wenn billig)

Du kannst dir mal die Samsung SM863 anschauen, die bietet eine gute Leistung, ist nicht teuer, hat 770 TBW und eine Powerloss-Protection. Ist also ideal als Schreib-Cache geeignet

 

[StefanDinslaken]

Danke nochmal für eure vielen Hinweise, das hilft wirklich sehr. Ich habe gestern Abend mal in einer virtuellen Umgebung das ganze mal ausprobiert, was man machen kann, wie es sich verhält, wenn man HDDs entfernt, usw. Bei der Konfiguration des Pool kann man hierbei zwischen zwei Optionen wählen. Parity und 2-Way Mirror. Erlich gesagt, habe ich den Unterschied hier nicht ganz verstanden. So wie ich das sehe, arbeiten beide ab 3 Festplatten als RAID5. Zusätzlich funktioniert 2-Way Mirror auch als RAID1 mit zwei Disks. Dann sehe ich aber keinen Unterschied ab 3 Festplatten. Was habe ich hier verpasst?

 

[Masamune2]

Beim 3-War Mirror wird einfach analog zum Raid 1 auf drei Platten geschrieben (also eine Datenplatte und zwei Spiegel). Beim Parity Layout wird analog zum Raid 5 reihum ein Paritätsblock geschrieben.
Wichtigster Unterschied für den User: Bei drei Platten hast du beim 3-Way Mirror die Kapazität einer Platte zur Verfügung, bei Parity die von zweien.

 

[d4nY]

Meine Vermutung wäre jetzt gewesen, dass du beim Mirror alle Disks spiegelst. Also bei 3 Disks hast du dann 2 Duplikate. Bei Parity dann eben immer eine Festplatte als Parity

Hast du mal ausprobiert was passiert, wenn du beim 2-Way Mirror 2 HHDs entfernst?

 

[StefanDinslaken]

Beim 3-War Mirror wird einfach analog zum Raid 1 auf drei Platten geschrieben (also eine Datenplatte und zwei Spiegel). Beim Parity Layout wird analog zum Raid 5 reihum ein Paritätsblock geschrieben.
Wichtigster Unterschied für den User: Bei drei Platten hast du beim 3-Way Mirror die Kapazität einer Platte zur Verfügung, bei Parity die von zweien.

Jau, bei 3-Way Mirror wird einfach auf drei Platten das gleiche geschrieben, so dass zwei ausfallen können. Aber wie siehts bei 2-Way Mirror aus?

Ergänzung (21. Juni 2016)

Meine Vermutung wäre jetzt gewesen, dass du beim Mirror alle Disks spiegelst. Also bei 3 Disks hast du dann 2 Duplikate. Bei Parity dann eben immer eine Festplatte als Parity. Hast du mal ausprobiert was passiert, wenn du beim 2-Way Mirror 2 HHDs entfernst?

Wenn ich aus drei Platten ein 2-Way Mirror mache, dann bleibts online, solange ich nur eine Platte entferne. Danach ists offline. So wie ich das jetzt verstanden habe, ist die Kapazität auch n-1.

 

[Masamune2]

Bei einem 2-Way Mirror gibt es nur eine Kopie der Daten. hat man drei Platten in einem Pool bedeutet das die Kopie wird reihum geschrieben: Ein Chunk auf Platte 1 und 2; ein Chunk auf Platte 2 und 3; ein Chunk auf Platte 3 und 1.
Du kannst damit auch eine Platte verlieren und hast effektiv immer noch nur den halben Platz nutzbar, dafür ist es schneller als Parity.

 

[StefanDinslaken]

Bei einem 2-Way Mirror gibt es nur eine Kopie der Daten. hat man drei Platten in einem Pool bedeutet das die Kopie wird reihum geschrieben: Ein Chunk auf Platte 1 und 2; ein Chunk auf Platte 2 und 3; ein Chunk auf Platte 3 und 1.
Du kannst damit auch eine Platte verlieren und hast effektiv immer noch nur den halben Platz nutzbar, dafür ist es schneller als Parity.

Ah, ich glaube ich verstehe. Das heißt bei Parity hat man ganz klassisch ein RAID5, sodass einem bei 3 Platten die Kapazität von Zweien zur Verfügung steht. Beim 2-Way Mirror hat man immer genau 50% der Kapazität. Es handelt sich also um ein RAID1, was lustigerweise auch mit ungeraden Mengen an Platten klappt.

 

[Masamune2]

Da das "Raid" hier nicht auf Ebene der physikalischen Platten aufgebaut wird sondern auf Ebene der logischen Volumes die man anlegt geht sowas. Daher ist der Begriff Raid im klassischen Sinne hier nicht mehr ganz korrekt und wird so auch nicht verwendet.
Ein weiterer Vorteil ist das man in einem Pool von X Platten mehrere Volumes anlegen kann die unterschiedliche Raidlevel haben.

z.B. vier Platten mit jeweils 4TB in einen Speicherpool ergeben 16TB Kapazität des Pools. Innerhalb dieses Pools lege ich jetzt ein Volume mit 200GB und 2-Way Mirror an (belegt dann effektiv 400GB) und ein weiteres Volume mit 1TB und Parity (belegt dann effektiv 1,33TB)
Damit bleiben dem Pool noch 14,27 TB für weitere Volumes.

Diese Form der Speichervirtualisierung ist heute eigentlich üblich.

 

[StefanDinslaken]

Hmm, ich muss ja sagen, so übermäßig begeistert bin ich ja nicht von der Performance. Ich habe jetzt mal folgendes gemacht in Virtual Box:

- OS auf virtuelle SSD installiert, die VHD liegt tatsächlich auch auf einer SSD
- 3x virtuelle HDD, zusammengefasst mit Parity, alle VHDs liegen auf einer gemeinsamen, echten HDD

Da hier drei virtuelle Disks in auf einer echten HDD liegen, ist die Performance natürlich der letzte Dreck. Aber da ist was interessantes, das man beobachten kann. Wenn man jetzt über SMB was auf den Pool schiebt, ist die Performance erstmal sehr gut. Windows cacht wie man im Screenshot sehen kann die Daten in den RAM, bis ein gewisses Level erreicht ist. Dann sackt die Übrtragungsrate stark ein. Ist die Übertragung abgeschlossen, geht die RAM Nutzung wieder zurück, jetzt wandern die Daten aus dem RAM-Cache in den Pool.



Das ist ja eigentlich ein ganz schönes Verhalten. Kann man hier irgendwie Windows dazu bringen, den RAM hier (fast) komplett auszunutzen? Dann hätte man ja letztendlich einen Write-Cache; zwar nicht auf SSD, sondern im RAM, aber macht ja nix.

 

[d4nY]

zwar nicht auf SSD, sondern im RAM, aber macht ja nix.

Doch, weil RAM flüchtig ist. Wenn dir jetzt während der Datenübertragung der PC ausgeht (Bluescreen, Stromausfall) dann hast du einen inkonsistenten Datenbestand. Das ist insofern vernachlässigbar, wenn du das nur als Fileablage nutzt, da du ja idR weißt wann du etwas darauf schreibst. Sobald du die Storage Spaces aber als Shared Storage für VMs oder Datenbanken nutzt kann sowas zu riesengroßen Problemen führen

​Aus dem Grund verwendet man für Schreibcaches eben auch SSDs im RAID-1 mit einer Powerloss Protection

Ich würde Windows den RAM-Cache verwaltet lassen und nichts großartig daran ändern. Wenn du genug RAM hast kannst du aber bspw. eine RAM-Disk erstellen und die dann dem Pool als SSD zuweisen (natürlich mit den selben Problem wie oben beschrieben)

 

[StefanDinslaken]

Doch, weil RAM flüchtig ist. Wenn dir jetzt während der Datenübertragung der PC ausgeht (Bluescreen, Stromausfall) dann hast du einen inkonsistenten Datenbestand. Das ist insofern vernachlässigbar, wenn du das nur als Fileablage nutzt, da du ja idR weißt wann du etwas darauf schreibst.

Ahjo, stimmt. Für letzteren Fall könnte man dann einen zweiten Storage Space anlegen und da das Caching abschalten. AFAIK geht das ganz einfach über den Geräte Manager.

Für den ersten Fall allerdings, wäre es ja schön, die RAM Nutzung zu maximieren. Vllt. kann man ja Windows sogar dazu überreden hier die Auslagerungsdatei auf der SSD zusätzlich zu verwenden.

Ergänzung (21. Juni 2016)

BTW, jetzt musste ich auch noch feststellen, dass Windows bei Konfiguration als Parity nur NTFS und nicht ReFS kann...

 

[Masamune2]

Da hier drei virtuelle Disks in auf einer echten HDD liegen, ist die Performance natürlich der letzte Dreck.

Korrekt, der Test ist so nicht wirklich hilfreich.

Wenn man jetzt über SMB was auf den Pool schiebt, ist die Performance erstmal sehr gut. Windows cacht wie man im Screenshot sehen kann die Daten in den RAM

Dieser Cache entspricht immer der Hälfte des eingebauten RAMs und kann meines Wissens nach auch nicht verändert werden. Er ist aber wie schon angemerkt nicht geschützt und daher eigentlich nutzlos.

Für den ersten Fall allerdings, wäre es ja schön, die RAM Nutzung zu maximieren. Vllt. kann man ja Windows sogar dazu überreden hier die Auslagerungsdatei auf der SSD zusätzlich zu verwenden.

Versuch es nicht, denn es bringt dir nichts. Der große Vorteil durch einen geschützten Schreibcache, nämlich das zusammenfassen von Schreiboperationen hast du mit dieser Methode nicht. Der Cache im RAM sorgt nur für "falsche" Werte beim Kopieren von Daten, der Storage Pool wird dadurch nicht schneller.

BTW, jetzt musste ich auch noch feststellen, dass Windows bei Konfiguration als Parity nur NTFS und nicht ReFS kann...

Das betrifft aktuell nur die TP von Server 2016 und Windows 10. Unter 2012 R2 geht das. Unter 2016 wird gerade noch an den Storage Spaces und an ReFS geschraubt, daher wär ich hier vorsichtig das schon "produktiv" einzusetzen.
Versuch mal über cmd bzw. diskpart das Volume zu formatieren.

 

[StefanDinslaken]

Hach, sehr unbefriedigend das ganze. Das muss ich alles nochmal überdenken, was mir hier wie wichtig ist.

Wie schafft es denn eig. QNAP ohne ECC-RAM und SSD Caches ein schnelles Software RAID 5 zu bauen? Die schaffen es ja das Gigabit Netzwerk auszulasten.