UnRAID vs FreeNAS Corral - Umsteigen?

[KingBeike]

Hallo,

derzeit nutze ich UnRAID 6.3.3 für mein Heimnetzwerk und bin eigentlich sehr zufrieden. Dennoch bin ich besorgt, denn ich speichere einige für mich sensible Daten auf meinem Server und wenn man über die Datensicherheit von ZFS liest und nach einigen Einbrüchen in der Umgebung wird man da schon nachdenklich.

Deshalb wollte ich mal eure Erfahrungen hören und ob ihr mir ebenfalls einen OS Wechel nahe legen würdet?

Situation aktuell:

UnRAID Server mit 3x3 TB WD Red und einer 4TB WD Red Parity. 250GB Cache SSD. Intel core i3 Haswell und 16GB Ram.
Hierdrauf laufen einige Docker (Nextcloud, Plex etc.) und einige VM's (Ubuntu, Windows)

Nächtliches Backup auf einen weiteren UnRAID Server über rtc wake und ein kleines eigenes skript mit rsync.



Docker, VM's usw unterstützen beide OS. Ich denke FreeNAS bietet gegenüber UnRAID aber noch einige, vor allem professionelle, Funktionen mehr. Zumindest out of the Box.

Gründe die mich zu einem möglichen Wechsel bewegen könnten:

1. Verschlüsselung des gesamten Pools, das ist für mich das Hauptargument !
2. ZFS
3. SnapShots
4. Replikation auf einen weiteren FreeNAS Server - Sehr einfach, vor allem auch in Zukunft mit Offside Backup mit eigenem drittem Server.

Negative Punkte:

1. Teure Erweiterung des Speichers
2. Verlust der gesamten Daten wenn Volume beschädigt über die Redundanz hinaus (Bei Unraid bleiben die Daten auf den gesunden Platten weiter verfügbar, egal wieviele Platten einen Defekt erleiden.)
3. Neue Hardware (ECC mit ryzen z.B.)


Lohnt sich ein Wechsel für mich? Oder sollte ich es so laufen lassen?

Wenn ja, ist es sinnvoller auf Raid-Z zu setzen oder lieber Mirrored vdevs? Mirror sollte ja eigentlich günstiger bei der Erweiterung sein, aber verschlingt natürlich 50% Storage...

Lösungen wie EncFS scheinen nur bis Unraid 6.2 zu funktionieren, aktuell wohl nicht mehr. Sonst wäre das auch eine mögliche Lösung gewesen.

Danke schonmal für mögliche Anregungen :-)

 

[HominiLupus]

Für ZFS brauchst du ECC RAM aka einen Xeon Prozessor und Mainboard.
Es ist nicht zwingend notwendig, aber ohne ist ZFS bissel ein Roulettspiel.

Ryzen ist derzeit noch nicht 100% wie funktionierend das ECC ist. Auch brauchst du keine so potente Hardware ausser für Dinge wie Dedup.

 

[KingBeike]

Ja ich weiß, das war ja bei Punkt 3 bei den negativen Punkten. Ich brauche neue Hardware mit ECC.

Plex mit Transcoding ist auch relativ Hardware intensiv, vor allem im kommenden 4k Zeitalter.

 

[snaxilian]

Naja, die Antwort hast du dir doch eigentlich schon selbst gegeben. Wenn du Verschlüsselung willst, dann bleibt dir nur eine Migration von unraid weg zu etwas, dass dieses Feature unterstützt.

Das kann Freenas sein oder ein Linux mit luks als Disk Encryption. Entweder komplett auf der Shell oder so etwas wie OpenMediaVault, das kann afaik LUKS mit Plugin.

Wenn Freenas: mirrored vdev, davon kannst dann mehrere zu einem zpool zusammen fassen. Ja, du opferst zwar 50% aber die Vorteile überwiegen: schnellere Wiederherstellung bei Ausfall einer Platte, Platten unterschiedlicher Größe mischen, einfachere Erweiterung.

Recht gut erklärt findest du dies auch nochmal hier

 

[d4nY]

Wenn Freenas: mirrored vdev, davon kannst dann mehrere zu einem zpool zusammen fassen. Ja, du opferst zwar 50% aber die Vorteile überwiegen: schnellere Wiederherstellung bei Ausfall einer Platte, Platten unterschiedlicher Größe mischen, einfachere Erweiterung.

Sorry, aber das ist quatsch

Wie man seine vdev's aufbaut hängt davon ab welche Anforderungen man hat. RaidZ bei nem klassischen Datengrab und mirrored wenns schnell(er) sein soll. Man kann vdev's nicht erweitern, egal ob mirrored oder mit parity, man kann nur einen Pool erweitern und auch wenn es nicht empfohlen ist, kann man verschiedene vdev's unterschiedlicher Größe mischen. Ob RaidZ oder mirrored spielt für die "Einfachheit" keine Rolle (dem Pool ist das egal). Ebenso kann man natürlich auch bei RaidZ unterschiedliche Plattengröße nutzen, die kleinste HDD ist dann (wie beim mirror) die Größe an die sich die anderen Platten anpassen
Bei den Wiederherstellungszeiten kann man drüber reden, aber da ZFS sowieso nur genutzte Bytes schreibt und eine aktuelle CPU keine Probleme hat die parity zu berechnen behaupte ich dass sich die Zeitunterschiede in Grenzen halten

In dem Fall würde ich aber auch sagen nimm mirrored vdev's, da du ja anscheinend VMs und Container nutzt. In der Konstellation wäre auch ein SLOG überlegenswert (welche SSD hast du genau?)
Kommt halt auf deinen Use Case draufan

E: ein Haswell i3 kann auch mit ECC umgehen, du bräuchtest also nur den RAM und ein Board mit nem C Chipsatz

 

[KingBeike]

Den i3 würde ich ungern nochmal "aufrüsten", da nehme ich lieber etwas mit mehr Power ;-).

Wenn ich den Pool mit einem Raid-Z2 beginne, kann ich den auch mit mirrored vdevs erweitern? Das war doch glaube ich etwas, wovon dringend abgeraten wurde, oder?

Erweitern geht ja nur mit einem neuem vdev oder alle platten eines vdevs durch größere ersetzen und immer rebuild.

 

[snaxilian]

Sorry, aber das ist quatsch [...]

Dann lies doch bitte mal den von mir verlinkten Artikel.

Beispiel mit 4x 1 TB Platten, je 2 zu einem mirrored vdev und dann ein zpool über beide mirror. Nennen wir die Platten mal:
hdd_1_1, hdd_1_2, _2_1 und 2_2

Mein Pool wäre somit 2 TB groß

Natürlich kann ich dann _1_1 und _2_1 gegen z.B. 4 TBs tauschen, resilvern, dann _1_2 und _2_2 gegen 4 TBs tauschen, erneut resilvern und dann ist mein Pool 8 TB groß.

Vorteil: Beim resilvern muss keine parity neu berechnet werden sondern nur von einer Platte gelesen werden und nicht von allen.

 

[d4nY]

Hab ich gelesen und mir missfallen Artikel die pauschal behaupten ich muss dieses oder jenes tun

Wieso sollte ich einen Pool aus mirrored vdev's aufbauen, wenn mir Kapazität wichtiger ist als Performance? Für meine Mediathek ist mir Kapazität und Ausfallsicherheit wichtig, die CPU langweilt sich sowieso und mein Gigabit-Netzwerk wird von einem RaidZ egal in welcher Konstellation verfrühstückt

Mein NAS besteht auch 6x3 TB im RaidZ2, sprich 12 TB Nutzkapazität. Die gleiche Konstellation mit mirrored vdev's bringt mir aber nur 9 TB. Wieso sollte ich die 3 TB verschwenden wenn mir die Performance relativ egal ist?

Ein anderes NAS, auf dem VMs liegen, habe ich dafür mit mirrored vdev's eingerichtet, weil mir die Performance und Ausfallsicherheit wichtiger war als die Kapazität. Da wäre es auch nicht sinnvoll ein RaidZ draus zu machen

Zum resilvern: Die Platte von der gelesen wird ist aber trotzdem Teil des Pools und muss somit auch bei quasi allen Dateioperationen angefasst werden. Die anderen vdev's sind zwar nicht betroffen, bringt mir aber nichts wenn ich trotzdem auf die eine Platte warten muss. Das einzige was man sich spart ist die Berechnung der parity und die ist auf modernen Prozessoren nicht der Rede wert

 

[KingBeike]

Danke für eure Beiträge .

Wäre ein Raid-Z aus euerer Sicht dann um ein anderes Raid-z..also einmal z1 und einmal z2 oder sogar um mirrored vdevs erweiterbar, oder sollte man das tunlichst lassen?


Habt ihr Erfahrungen mit den Replications unter Corral? Ich würde gerne einen verschlüsselten Snapshot auf meinem dann Unraid Backup server parken..

 

[d4nY]

Theoretisch kannst du verschiedene vdev's (sprich RaidZ 1/2/3 oder mirrored oder single disk) unterschiedlicher Größen mischen, empfohlen wird aber die gleiche Art von vdev mit gleicher Anzahl Festplatten und gleicher Kapazität

​Bei den Replications muss ich passen

 

[KingBeike]

Okay, dann wäre ja auch für die Erweiterung ein mirrored vdev pool am sinnvollsten.

 

[snaxilian]

@d4nY: Da stimme ich dir zu, wenn einem Kapazität über alles geht, dann ist ein RAIDZ bzw RAIDZ2 sinnvoller ggü mirrored VDEVs unter der Voraussetzung, dass man seine benötigte Kapazität langfristig geplant hat.

Bitte korrigiere mich aber wenn du ein RAID7 vergrößern willst, musst du erste Platte gegen eine größere tauschen, resilvern, dann die nächste usw. bis alle durch sind und erst dann kann der Pool wachsen, oder? Bei einem Pool aus zwei mirrored VDEVs muss ich zwar auch einen kompletten Mirror nacheinander tauschen, kann aber theoretisch in beiden Mirror je eine Platte tauschen, resilver, dann je die zweite tauschen und bin durch.

Aber ja grundsätzlich wenn Performance dann mirrored VDEVs und für Hauptsache Kapazität dann ein RAIDZ(2)

 

[d4nY]

Bitte korrigiere mich aber wenn du ein RAID7 vergrößern willst, musst du erste Platte gegen eine größere tauschen, resilvern, dann die nächste usw. bis alle durch sind und erst dann kann der Pool wachsen, oder?

Stimmt, da hast du Recht, prinzipbedingt lässt sich ein mirrored vdev leichter/schneller durch neue Festplatten ersetzen. Insofern hast du auch Recht, dass sich ein mirrored vdev doch leichter vergrößern lässt (Ich bin davon ausgegangen, dass du mit "erweitern" einfach das hinzufügen eines neuen vdev meinst )
Es wird aber glaube ich auch empfohlen, dass man nicht allzu viele HDDs in ein vdev packen soll, sondern lieber mehrere vdev's erstellt

 

[snaxilian]

Daher ja pro vdev immer nur 2 Platten. Über diese vielen "Raid 1" packt man dann seinen zpool

Klar kann man idR anfangs sein Storage durch hinzustecken weiterer Platten erweitern aber irgendwann hat man entweder keine Ports mehr frei oder das Gehäuse ist voll. Spätestens dann will man ja die alten Platten gegen neue und größere tauschen

 

[KingBeike]

Das ist derzeit wohl auch der Plan.

So muss ich nachher beim Erweitern nur 2 Platten dazu stecken oder 2 durch 2 neue ersetzen.

Bei einem Raid-Z müsste ich bei einem Raid-Z2 schon 4 Platten kaufen....

 

[d4nY]

Ein Z2 mit 4 Platten macht man ja auch nicht

Du hättest dann nämlich 2 Platten mit Nutzkapazität und 2 Platten mit Parity -> 50% Verlust und das ist dann nichts anderes als ein unnötig aufwändiger mirrored vdev Pool (oder hab ich da jetzt grad was falsch verstanden?)

Aber da du sowieso VMs auf dem Storage betreibst kommt eigentlich nichts anderes in Frage außer mirrored vdev's und wie schon erwähnt vielleicht noch ein SLOG-Device

 

[KingBeike]

Ja da hast du natürlich recht :-D Ich denke es werden mirrored vdevs. Ich muss mir nur noch etwas für den backup Server überlegen...

Da wäre UnRAID perfekt, aber ich glaube da wird es dann auch mit den verschlüsselten Backups schwierig.