Schneller, günstiger und trotzdem verlässlicher Fileserver?

[Klokopf]

Letzten Monat hab ich mein Netzwerk auf 10 Gbit umgestellt und habe somit neue Anforderungen an meinen Mediaserver/NAS.
Derzeit verwende ich unRAID auf einem i3-6300 System mit 16GB ECC RAM. unRAID hat aber starke Einschränkungen in Sachen Geschwindigkeit. Ein Cachepool hilft zwar mit dem writespeed, der readspeed allerdings wird nie schneller als der der angesprochenen Festplatte (Prinzip bedingt).
In einem 1 Gbit Netzwerk stört das nicht weiter da hier viele HDDs schon an ihre Grenzen stoßen, da der Flaschenhals jetzt aber weg ist würde ich ganz gerne etwas mehr Performance rauskitzeln.
Folgendes ist mir dabei aber sehr wichtig:

1. Datenintegrität (Bitrot Protektion, Hardwareausfalltoleranz, UE-Reparatur)
2. Möglichst geringer Datenverlust bei Ausfall über das Toleranzlevel
3. Für Privatanwender sinnvoll erweiterbar
4. Möglichkeit für möglichst einfache Backups

Wenn man den ersten Punkt liest fällt einem ja sofort ZFS ein. Meiner Meinung nach ist das Dateisystem für Privatanwender (gerade wenn der Speicherplatzbedarf recht schnell steigt) ziemlich ungeeignet da es sich nicht sinnvoll erweitern lässt und nur Sinn macht wenn man seinen Bedarf planen kann. Zudem verliert man alle Daten beim Überschreiten der Ausfalltoleranz.

Ich hatte dazu eine recht wacklige Idee und wollte mal wissen was ihr so davon haltet. Es geht in Richtung Raid-Nesting ist aber etwas mehr um die Ecke gedacht
Konkret hatte ich vor immer zwei (gleich große) HDDs in einem btrfs RAID 0 zusammenzufassen, was mir in den meisten Fällen doppelte Leistung bringen sollte. Da btrfs einen Softwareraid integriert hat kann man auch mit reinem Gewissen ohne Hardware-Raid an die Sache rangehen
Über die einzelnen RAID 0 Gruppen spannt man dann sowas wie SnapRAID oder flexRAID. Die Programme stellen sicher dass die Dateien nicht beschädigt werden, außerdem kann man durch diese seine Ausfalltoleranz (Redundanz) aufbauen. Mir persönlich reicht die Zeitversetzte Parity von SnapRAID da ich für „work in progress“ Dateien normalerweise einen eigenen Share habe.

Ich rate dazu mindestens 2 Gruppen verlieren zu können, was bei meinem Raid 0 Aufbau 2 HDDs bedeutet (außer zwei in der gleiche Gruppe fallen aus, in dem Fall kann man sogar 4 verlieren)
Meine erste Idee war das Ganze einfach in Ubuntu zu realisieren, hab dann aber festgestellt das OMV mittlerweile auch btrfs unterstützt, was alles etwas einfacher machen würde.
Ich hab bisher nur mit Enterprise RAID Systemen gearbeitet, hab also keine Ahnung wie sich meine Idee im Consumer Bereich so macht.

Gibt es vielleicht eine weniger umständliche Lösung die ich nur noch nicht gefunden hab?
Bin gespannt auf eure Meinungen und Anregungen

 

[conf_t]

Du kannst auch ein RAID 6 bauen. Je mehr Disks desto schneller. Ich hatte seiner Zeit (anno 2008) mit einem Raid 5 aus 4 Disks ~ 250 MB/s schreibend und 290 MB/s lesend. ECC Ran hast du ja schon. Ich weiß jA nicht welche Geschwindigkeiteb angepeilt werden.... Aber mit RAID 6 und sagen wir 6 HDDs mit 7200 rpm sollte da schon was gehen. Ein guter Hardware Controller kann helfen, wenn der CPU beim XOR die Puste ausgehen sollte.

Noch frisst das aber auch alles Strom ohne Ende. Alleine die meisten 10 G Karten haben einen Kühlkörper. Aktuell halte ich es bei den Betriebskosten 10 G für Soho noch unangebracht. Aber jedem sein Hobby .

 

[Candy_Cloud]

Punkt 1: Kein Raid das es gibt ist ein Backup und garantiert dir irgendwie eine Sicherheit. Das ist alles Augenwischerei.
Punkt 2: Wenn man Zeit hat, kann man sich mit fast jeder Hardware mit einem schlanken Linux (ich bevorzuge Debian) einen richtig guten Fileserver aufbauen unter Verwendung von Samba. Dazu ein Webfrontend damit man den Server besser aus der Ferne erreichen kann.

Mit Debian + Samba erreiche ich auf meiner Laborratte gut das Maximum des verbauten S-ATA 3G Controllers via einer SSD. Ich nutze es jedoch ohne Bedarf an Ausfallsicherheit. Rein zum üben wie sich das handhabt.

Ich denke die richtige Kombination aus Hardware und Software ist entscheidend. Dazu eine saubere Spiegelung die sich jede Nacht erstellt.

 

[Klokopf]

@ Candy_Cloud
das ein Raid kein Backup ist ist mir schon klar, ich hab auch ein richtiges Backup und werde das auch weiterhin machen
Mir gehts bei der Ausfallsicherung einfach darum nicht alle Daten neu aufspielen zu müssen nur weil eine Platte kaputt geht.
Debian ist weniger mein Fall, ich komm von Windows Servern, wenn man das gewohnt ist kommt einem Linux im allgemeinen sehr minimal vor Debian da ein harter Kontrast, daher tendiere ich eher zu Ubuntu

@ Nicht ich
ein klassisches Raid 6 lässt sich aber wieder nicht erweitern, auserdem ist das array bei überschreiten der Ausfalltolleranz nutzlos... Vom prinzip her wärs aber cool

 

[conf_t]

Heutzutage lassen sich die RAID 5 und RAID 6 Implementierungen durchaus erweitern, ob durch größere oder zusätzliche Disks.
Und bei den Klimmzügen (im Prinzip ein RAID 10 mit unterschiedlichen RAID-Systemen), die du oben beschreibst und von denen ich dringend abrate, planst du auch nur einer Toleranz von 2 defekten Disks ein. Das verkraftet auch ein RAID 6.

 

[Klokopf]

naja eher ein Raid 06 (raid 0 mit aufgesetzter dual parity). Die erweiterbarkeit von Raid 6 ist mir neu, scheint aber ne Möglichkeit zu sein, mal schauen was ich da so finde, danke für die Info

Mein, zugegeben recht wackliger aufbau, hat aber den vorteil das ich nicht das ganze Array verliere wenn mehr als 2 Platen ausfallen. Ich sollte vlt noch anmerken das ich derzeit 10 Datenplatten + eine Parity Platte verwende. Für meinen plan müsste ich noch mind. eine HDD kaufen und hätte dann 5 Raid 0 Verbände, sollten 2 Ausfallen hab ich immer noch die Daten auf den anderen 3.
Ein Ausfall ist natürlich kein Weltuntergang da ich ja ein volles seperates Backup habe, allerdings ist es mehr arbeit

Außerdem hab ich noch kein Raid 6 gesehen das mit Bitrot zurecht kommt...

Aber mein vorhaben ist schon sehr wacklig, da muss ich dir recht geben
Ich hab aus Hardware die ich noch rumliegen hab mal einen testserver gebaut und werd einfach mal testen ob was schief geht
Ich hoffe immer noch über irgendwas zu stolpern das genau meine Anforderungen entspricht, wage aber zu bezweifeln das sowas existiert...

Ergänzung (8. September 2016)

Also nach 20 Stunden heavy testing hällt noch alles Die Performance ist wie erwartet und zumindest bei meinem Testaufbau mit gerade mal 140 GB pro Raid 0 dauert auch das berechnen der Parity nicht lange.
Als nächstes werde ich mal versuchen sowas wie einen Festplatten ausfall inszenieren und ein paar Daten korrupieren

 

[conf_t]

Dann mal frohes weiter testen

 

[Klokopf]

Also ich bin jetzt durch mit meinen Tests In über 6 TB Daten (gemischt aus RAW Fotos und kleinen JPEGs) geschriebenen Daten ging nichts schief. Auch absichtlicher bitrot wurde im hintergrund korrigiert ohne das es zu hängern oder wartezeiten kahm.

Beim Simulieren eines Plattenausfalls gabs aber ein Problem: Der rebuild einer 70 GB Partition dauerte 21 Stunden. Ich bin mir nicht sicher woran das lag... Wenn man das auf 4TB HDDs hochrechnet vergehen ja Jahre.

Ich hab 4*15k RPM 2,5" SAS HDDs mit 146GB in jeweils 2 70 GB partitionen aufgeteilt und immer 2 Partitionen auf verschiedenen Festplatten in ein Raid 0 gepackt. Für die Parity hab ich genau das gleiche mit den 2 übrigen HDDs gemacht. Die Testmaschine hat einen Quadcore Xeon mit 2,2 GHz (schon recht alt) und 8 GB ECC RAM. Der SAS Controller lief im HBA Modus an einem PCIe x8 Slot.
Ich hoffe ehrlich gesagt das der lange rebiuld auf das alter des Systems zu schieben ist...

 

[Klokopf]

Ich hab mich mal an die SnapRAID community gewendet und meinen aufbau dargelegt. Anscheinend kommt die schlechte rebuild rate vom Raid Controller den ich verwended habe, man kann leider weder das caching noch die anderen RAID funktionen abschalten... (selbst im JBOD Modus).
Ich hab ne ganze Reihe Benchmarks bekommen die schnellere Rebuilds zeigen und das auf vergleichbarer Hardware