Beratung für unRAID-Build

[ArdNsc]

Hallo,
ich will meinen ersten selbstbau Dateiserver/NAS mit unRAID aufbauen, um ein altes Synology NAS loszuwerden und einen Raspi zu ersetzen, der einige kleinere Dinge via Docker ausführt. Das Gerät soll hauptsächlich Speicher für mein Netzwerk bereitstellen und in der Lage sein, Dinge wie Pihole, Nextcloud, Sabnzbd über Docker auszuführen. Mediendateien würden auch auf dem neuen Gerät gespeichert, aber Videocodierung/-decodierung ist nicht erforderlich, da auf einem anderen Gerät im Netzwerk Kodi ausgeführt wird. Ich habe auch nicht vor, VMs auszuführen, nur Docker-Container.

Bereits vorhanden sind 4 Festplatten (6,8,10,10TB) und zwei SSDs (250GB), die in den Server kommen würden. Ich möchte natürlich die Möglichkeit haben, das Speicherarray und den Cache später durch Hinzufügen zusätzlicher Laufwerke zu erweitern, bevor ich die alten entfernen/ersetzen muss.

Könnt ihr mir helfen, die Hardware, die ich ausgesucht habe, danach zu beurteilen, ob sie zu dem skizzierten Use-Szenario passt?

• Gehäuse: Silverstone DS380
• Stromversorgung: Chieftec Compact CSN-450C 450W SFX12V
• Hauptplatine: Gigabyte C246N-WU2
• Prozessor: Intel Core i3-9100F
• RAM: Kingston Server Premier DIMM 8 GB, DDR4-2400 CL17-17-17, EWG
• Lüfter: 3x Noctua NF-S12A PWM für das Gehäuse und Noctua NH-L9i für den Prozessor

Einige Gedanken / Fragen:

• Das Mainboard listet nur Windows als unterstütztes Betriebssystem auf, kein Linux. Wird das ein Problem sein?
• Ich möchte in der Lage sein, irgendwann in der Zukunft 2,5 Gbit/s oder 10 Gbit/s Ethernet hinzuzufügen, wenn mein Netzwerk / andere Geräte davon profitieren können. Dafür würde ich den freien PCIe-Port benötigen.
• Ist es überhaupt möglich, einen Prozessor ohne iGPU auszuwählen, wenn ich keine dedizierte GPU integrieren möchte?
• Werde ich in Bezug auf die Datenzuverlässigkeit von ECC RAM profitieren?
• Ich möchte, dass das System für seine Aufgaben gut dimensioniert ist. Würde ich von einem schnelleren Prozessor / mehr RAM profitieren? Oder ist meine Wahl schon eine Art Overkill? Ich möchte auch mindestens einige der Datenlaufwerke verschlüsseln (LUKS), das System müsste also dazu in der Lage sein, das ohne große Geschwindigkeitseinbußen bei der Netzwerkdatenübertragung zu bewerkstelligen.
• Bei einem zukünftigen Upgrade auf ein schnelleres Ethernet wäre es schön, wenn die (aktuelle) 1-Gbit/s-Verbindung der "Engpass" für die Geschwindigkeit der Netzwerkdatenübertragung (SMB, NFS) wäre, und nicht das System selbst.

Ich freue mich auf eure Meinung und eure Tipps. Da ich auch im ComputerBase-Forum neu bin: Ich hoffe, meine Fragen sind in Ordnung und rechtfertigen das Öffnen eines neuen Themas. Wenn ihr weitere Infos braucht, sagt einfach bescheid.

 

[alturismo]

• Mainboard sollte kein Thema sein, auch wenn nur windows dran steht
• Netzwerk ist klar mit PCIe
• ohne iGPU geht, ist dann headless, ich würde mir das nur wirklich gut überlegen ... da die iGPU im Falle von Transcoding im Docker das übernehmen würde ... Bsp. Plex, Emby, .... extern vom Handy auf deine Medien zugreifen, macht mit hw transcoding schon mehr Sinn ... ist dann auch headless aber hast dann wenigstens die Möglichkeit ...
• ob der Ram was bringt kann ich nicht beurteilen
• mehr CPU, mehr RAM, ... wird sich zeigen was du wirklich machen wirst, mein Unraid System war auch klein am Anfang, jedoch dann kamen die Spielereien dazu

- Wichtig, ein schnelles cache drive .... als Puffer, mind. SSD ... und als /appdata Laufwerk für die Docker.

allgemein, unraid bietet eine Verschlüsselung an und auch Sicherheit (parity), Sicherheit bedeutet, du brauchst 1 Festplatte die mind. die Größe deiner größten Datenplatte ist als Parity Laufwerk, in diner aktuellen Konstellation wäre das 1 x 10tb Platte als Parity (Sicherung).

wenn VM mit GPU zum Thema wird, dann gäbe es noch mehr zu beachten, aber das steht ja nicht zur Debatte.

aktuell läuft das bei mir

core i7 8700
64 GB Ram
iGPU UHD630 (unraid Docker, plex, emby, tvheadend, ... hw transcoding)
PCIe Karten
Nvidia 1030 (Arbeits PC)
Nvidia 1070 (Media/Gaming PC)
10G Netzwerkkarte
USB 3 Karte (Media/Gaming PC, 4 Ports)
usw usw ...

also, am Ende kommt es darauf an was du machen wirst und was der "Spieltrieb" bringt
für das Datenmanagement wäre meine Empfehlung eine nvme ssd zu nutzen, das wäre noch wichtig ...

ich nutze 2 hierfür

die erste (cache) für /appdata (dockers) und als Puffer für Medien
die zweite ist für meine VM's und GAME Share (wo die aktuellen Spiele liegen)

 

[Eyestea]

Falls für dich auch gebrauchte Komponenten in Fragen kommen, kann ich dir die Website serverbuilds.net (auch auf reddit / discord) ans Herz legen.
Ich hatte ähnliche Anforderungen wie du und habe mir während der Pandemie einen unraid Server in Anlehnung an den NAS Killer 4.0 build zusammengebaut und bin sehr zufrieden!

 

[snaxilian]

@alturismo Der TE schreibt doch eindeutig, dass der kein transcoding benötigt, warum willst du es ihm dann einreden?

@ArdNsc Ungeachtet der Transcoding Thematik: Nicht jedes (Consumer) Board bzw. dessen BIOS/UEFI startet unbedingt komplett headless wenn keinerlei GPU verbaut ist. Da würde ich mich vorher schlau machen ob das Board ohne GPU läuft. Falls Händler oder Hersteller dies nicht beantworten will oder kann: Bestellen, testen und ggf. zurück schicken und einen Plan B haben, alternativ eine CPU mit iGPU...

Ebenso ist die reine Aussage "Docker Container" schwer einzuschätzen bei der CPU. Die Frage lautet viel mehr: Wie viele Container und was soll da drin laufen? 5 Container mit irgendwelchen vergleichsweise kleinen Aufgaben: Da reicht der i3 locker. Ein Dutzend Webseiten mit SQL-Backend, einem Cache wie memcached oder redis mit hunderten parallelen Zugriffen, dazu noch ein transcodierender Plex etc: Dann reicht die CPU nicht mehr.
Als Beispiele:
Ich betreibe z.B. u.a. einen vServer mit 2 dedizierten vCPUs und 6 GB RAM und da laufen ca 20 Container drauf, u.a. eine Nextcloud-Instanz für 5 Leute, ein Mailserver, ein VPN-Endpunkt, ein Reverse Proxy als TLS Endpunkt und abgespeckter WAF und noch 1-2 kleinere Projekte. Die CPU Last liegt im Schnitt bei 25% Auslastung pro Kern und das System nimmt sich 3 GB Ram.
Ebenso hab ich ein FreeNAS hier stehen mit einem Pentium G4600 und mit einem Pool aus HDDs und einem Pool mit SSDs. Ersterer stellt nur stumpf SMB-Shares zur Verfügung auf letzterem laufen zwei VMs, je ein Webserver und ein mariaDB/mysql Server und ein kleines iSCSI Laufwerk. CPU liegt hier im Schnitt bei 40% da v.a. der Webserver regelmäßig zu tun hat und da diverse Skripte laufen die entweder $Dinge überwachen oder automatisiert steuern.
Ob die gewählte CPU ausreichend ist oder zu klein dimensioniert ist oder jetzt schon völlig überdimensioniert ist können wir aktuell nur schwer beantworten. Bei geringer Last wird sie sich sowieso herunter takten und vergleichsweise wenig Strom ziehen. Aber wenn du absehen kannst, dass du die Leistung nie benötigen wirst kannst das Geld auch besser einsparen...

Muss es das DS380 sein? Je nach zukünfig genutzter PCIe Karte kannst du einen der HDD-Slots nicht nutzen und es wird echt kuschelig in dem Case mit allen Kabeln. Wenn es der Platz her gibt würde ich eine Nummer größer wählen wie z.B. das CS380.

ECC Ram bringt nur sinnvoll etwas wenn auch ein Dateisystem verwendet wird, dass schleichende Bit-Fehler erkennen und beheben kann. Im Fall von unraid wäre dies dann BTRFS.

Solange der gewählte Prozessor AES-NI beherrscht solltest du keinen großen Unterschied spüren was die Verschlüsselung angeht. Unraid bietet dafür ganz klassisch das allgemein unter Linux übliche LUKS an.

Da unraid die Laufwerke einzeln anspricht wird zumindest bei lesendem Zugriff der Flaschenhals immer die Leistung der einzelnen HDDs sein, sowohl was Latenz beim Zugriff als auch jegliche lesende Operationen angeht. Die SSD Cache Funktionalität bezieht sich bei unraid afaik immer nur auf Schreibzugriffe sofern nicht die Daten direkt und explizit auf der SSD abgelegt werden aber dann ist die SSD halt kein Cache mehr sondern ein beliebiges Array Laufwerk.
Beim lesen/betrachten/kopieren einer Datei vom NAS zum PC wirst daher ins Limit der HDD laufen. Bei aktuellen NAS-Platten wird das irgendwo zwischen 150 und im allerbesten Fall bei bis zu 250 MB/s. Kopierst du zwei Dateien vom NAS zum PC und die Dateien liegen auf unterschiedlichen HDDs bekommst in Summe 300 bis eben im besten Fall bis zu ~500 MB/s. Von daher JA: Wenn wir über das sequenzielle lesen oder ggf. auch schreiben von Daten reden ist aktuell das 1GBit/s Ethernet der Flaschenhals. Sobald aber random I/O gefragt sind oder du mehrere Daten von der gleichen HDD lesen willst ist diese der Flaschenhals. Ein simples und einfaches JA oder NEIN gibt es auf die Frage nicht sondern immer ein "es kommt drauf an" welchen Use-Case du betrachtest.

 

[ArdNsc]

Danke für eure Antworten. Ich gehe mal der Reihe nach auf ein paar Punkte ein:

Falls für dich auch gebrauchte Komponenten in Fragen kommen, kann ich dir die Website serverbuilds.net (auch auf reddit / discord) ans Herz legen. Ich hatte ähnliche Anforderungen wie du und habe mir während der Pandemie einen unraid Server in Anlehnung an den NAS Killer 4.0 build zusammengebaut und bin sehr zufrieden!

Danke für den Tipp! Ich schließe gebrauchte Komponenten nicht grundsätzlich aus. Aber erst einmal brauche ich ja eine bessere Vorstellung davon, welche Komponenten ich für meine Zwecke überhaupt benötige.

Zu SSD/Cache:

für das Datenmanagement wäre meine Empfehlung eine nvme ssd zu nutzen, das wäre noch wichtig ...
ich nutze 2 hierfür ... die erste (cache) für /appdata (dockers) und als Puffer für Medien
die zweite ist für meine VM's und GAME Share (wo die aktuellen Spiele liegen)

Ich hatte geplant, zwei vorhandene Sata-SSDs mit btrfs Raid 1 als Cache-Array einzusetzen. Warum käme es auf nvme an?

Die SSD Cache Funktionalität bezieht sich bei unraid afaik immer nur auf Schreibzugriffe sofern nicht die Daten direkt und explizit auf der SSD abgelegt werden aber dann ist die SSD halt kein Cache mehr sondern ein beliebiges Array

Hatte ich auch so verstanden. Das hieße doch, für Dockerkram würde sich die Verwendung einer dritten SSD als separates Array empfehlen?

Zu den Aufgaben und Docker:

Ebenso ist die reine Aussage "Docker Container" schwer einzuschätzen bei der CPU. Die Frage lautet viel mehr: Wie viele Container und was soll da drin laufen? 5 Container mit irgendwelchen vergleichsweise kleinen Aufgaben: Da reicht der i3 locker. Ein Dutzend Webseiten mit SQL-Backend, einem Cache wie memcached oder redis mit hunderten parallelen Zugriffen, dazu noch ein transcodierender Plex etc: Dann reicht die CPU nicht mehr.

Konkret ginge es um: Nextcloud (2 tägliche und 4 sporadische User), ggfs. eine zweite Nextcloud-Instanz, Pihole, Sabnzbd, Sonarr, Radarr, Lidarr, Bazarr, SubSync.

Zur GPU/CPU:

Ungeachtet der Transcoding Thematik: Nicht jedes (Consumer) Board bzw. dessen BIOS/UEFI startet unbedingt komplett headless wenn keinerlei GPU verbaut ist. Da würde ich mich vorher schlau machen ob das Board ohne GPU läuft. Falls Händler oder Hersteller dies nicht beantworten will oder kann: Bestellen, testen und ggf. zurück schicken und einen Plan B haben, alternativ eine CPU mit iGPU...

Ich hatte jetzt überlegt, mir diesen Stress zu ersparen und dann doch einfach eine CPU mit iGPU zu verwenden. Zwar kommt, wie gesagt, Transcoding nicht in Betracht, aber schaden würde es ja auch nicht, wenn das Setup es dann im Zweifelsfall doch auch beherrschen würde.

Solange der gewählte Prozessor AES-NI beherrscht solltest du keinen großen Unterschied spüren was die Verschlüsselung angeht. Unraid bietet dafür ganz klassisch das allgemein unter Linux übliche LUKS an.

Ich bin jetzt auf den Pentium Gold G5400 gekommen. Der hat eine iGPU und beherrscht AES-NI. Wie würdest du/würdet ihr den in Bezug auf die o.g. Docker-Anforderungen beurteilen?


Zum Gehäuse:

Muss es das DS380 sein? Je nach zukünfig genutzter PCIe Karte kannst du einen der HDD-Slots nicht nutzen und es wird echt kuschelig in dem Case mit allen Kabeln. Wenn es der Platz her gibt würde ich eine Nummer größer wählen wie z.B. das CS380.

Ich würde das Gerät gerne an einem bestimmten Platz aufstellen und bin aufgrund dessen Begrenzung (maximal 35x35x40) auf das Gehäuse gekommen. Ich sehe, dass mich diese Auswahl auch aufgrund des MB-Formfaktors ziemlich einschränkt: Es gibt kaum mini-itx-Boards, die ECC unterstüzten. Ich habe aber innerhalb dieser Größenbeschränkung keine brauchbaren Alternativen gefunden.

Zu ECC/btrfs:

ECC Ram bringt nur sinnvoll etwas wenn auch ein Dateisystem verwendet wird, dass schleichende Bit-Fehler erkennen und beheben kann. Im Fall von unraid wäre dies dann BTRFS.

Das geht jetzt über die Fragen zum HW-Build hinaus, aber in diesem Zusammenhang bin ich noch unsicher, weil unRAID btrfs für das HDD-Array zwar anbietet, aber nicht empfiehlt. Ich wollte einen Schutz gegen "Bit-Rot" haben und war so überhaupt auf btrfs in Verbindung mit ECC gekommen. Wenn ich btrfs gar nicht einsetzen kann/sollte für das Haupt-Array, macht ECC dann überhaupt einen Sinn? Umgekehrt: Warum sollte man btrfs nicht für das Haupt-Array einsetzen?

Zum "Flaschenhals":

Wenn wir über das sequenzielle lesen oder ggf. auch schreiben von Daten reden ist aktuell das 1GBit/s Ethernet der Flaschenhals. Sobald aber random I/O gefragt sind oder du mehrere Daten von der gleichen HDD lesen willst ist diese der Flaschenhals.

So war die Frage gemeint, ja. Und letzteres ist klar. Ich hatte gefragt, weil ich mal irgendwo gelesen habe, dass unRAID aufgrund der Parität und dem fehlenden Striping Schreibgeschwindigkeiten von ungefähr 40mb/s hinbekommt, was ja schon arg wenig wäre. Ich wollte mich vergewissern, dass ich mit unRAID inkl. eines SSD-Caches am Ende nicht schlechter dastehe als im Moment mit meiner Diskstation, wo ich bei unverschlüsselten Shares ins Limit der Ethernet-Verbindung laufe, sondern noch "Luft nach oben" habe.

 

[alturismo]

warum nvme als Empfehlung, da über die caches der meiste Verkehr läuft, jetzt mal egal ob Docker, VM, Daten ...

Szenario hier, nvme als /cache

hier liege die appdata files aller Docker und hier ist auch der "Puffer" (cache) der Daten, Übergang zum Thema Geschwindigkeit mit parity, da der normale aktuelle "Datenverkehr" über den cache läuft (hier zumindest) ist die Schreibgeschwindigkeit deines cache drives das limit (mit overhead natürlich usw).

der Mover im Hintergrund schiebt dann nach Bedarf auf das array und da kommen dann die hdd's bzw. parity zum Einsatz mit reduzierter Schreibgeschwindigkeit.

Und zu deiner Anmerkung warum das array nicht mit btrfs läuft, gute Frage ... nur soviel dazu meinerseits, wie du in meinen screens siehst nutze ich die caches als single drive in xfs da mir btrfs schon abgeschmiert ist und alles futsch war ... daher habe ich sogar meine cache drives in xfs neu eingesetzt (geht jedoch nur als single drive caches, pool mit mehreren ist nur mit btrfs machbar).

Anwendungsszenario

ich habe eine Share namens /Media/TV wo meine Aufnahmen (von tvheadend) liegen.

Die ist erstmal immer physikalisch im cache und wird dann nach Füllrate per mover ins array geschoben

---

Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present. This setting also affects mover behavior.

No prohibits new files and subdirectories from being written onto the Cache disk/pool. Mover will take no action so any existing files for this share that are on the cache are left there.

Yes indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the Cache disk/pool and onto the array.

Only indicates that all new files and subdirectories must be writen to the Cache disk/pool. If there is insufficient free space on the Cache disk/pool, create operations will fail with out of space status. Mover will take no action so any existing files for this share that are on the array are left there.

Prefer indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the array and onto the Cache disk/pool.

NOTE: Mover will never move any files that are currently in use. This means if you want to move files associated with system services such as Docker or VMs then you need to disable these services while mover is running.

---
wie du hier siehst bedeutet das

/Media -- steht auf yes (Platz nach Bedarf, erst cache, dann array)
/appdata -- steht auf only (NUR auf cache)

im "real life" scenario wirst du die array Geschwindigkeit nie merken außer du schreibst direkt NUR auf das array,
ich bevorzuge "aktuelle" Medien, Daten .... schnell und leise (keine spinups der hdd's) greifbar zu haben und nur bei Bedarf auf das array zuzugreifen ... Bespiel, ich schaue mir einen alten Film an

@snaxilian und zur iGPU, ich will dazu niemanden "überreden", nur anmerken was er jetzt evtl. nicht in Betracht zieht, ... da geht ja noch mehr wenn man sich dann einarbeitet und merkt ...
Beispiel, anstelle einer VM einen Docker mit ubuntu, xrdp, igpu für docker freigeben, einbinden und auch Vorteile haben ... nennen wir es mal eine "Not VM" für kleines Office, remote browser, was auch immer, geht auch ohne igpu, nur mit ist es sicherlich kein Schaden ... egal, ich lasse das Thema jetzt

 

[snaxilian]

Sabnzbd, Sonarr, Radarr, Lidarr, Bazarr, SubSync

Pentium Gold G5400 gekommen. Der hat eine iGPU und beherrscht AES-NI. Wie würdest du/würdet ihr den in Bezug auf die o.g. Docker-Anforderungen beurteilen?

Weder kenne noch nutze ich die ganzen *arr oder nzbd Dienste aber hier nutzt das jemand auf einem ~8 Jahre alten HP Microserver N54L. Ich wage also mal zu behaupten, dass der Pentium damit klar kommen sollte...

weil unRAID btrfs für das HDD-Array zwar anbietet, aber nicht empfiehlt. Ich wollte einen Schutz gegen "Bit-Rot" haben und war so überhaupt auf btrfs in Verbindung mit ECC gekommen. Wenn ich btrfs gar nicht einsetzen kann/sollte für das Haupt-Array, macht ECC dann überhaupt einen Sinn? Umgekehrt: Warum sollte man btrfs nicht für das Haupt-Array einsetzen?

Mir sind genau drei Dateisysteme bekannt, die vor bit-rot schützen: ZFS, BTRFS und ReFS. Wenn du dieses Feature haben willst und unraid nutzen möchtest ist die Entscheidung somit gefallen.
Du solltest lernen, Dokumentation und Wikis genauer zu lesen. Ja, XFS ist "abgehangener" und ja btrfs hat noch seine "Kinderkrankheiten" in gewissen Konstellationen wie z.B. die integrierte Raid5/6 Funktionalität. Bei standalone oder Raid1 ziemlich stabil sonst würde es z.B. SLES nicht verwenden. Ja, RHEL hat es "raus geschmissen" aber fairerweise sollte man sagen, dass RHEL parallel an Stratis arbeitet
Ich habe unraid nie verwendet aber ich würde, soweit ich es richtig verstanden habe, die Data Array Disks einzeln mit btrfs formatieren und die Cache SSDs ebenso mit btrfs. Wenn du diese im Raid 1 verwenden willst hast zumindest bei den SSDs keine andere Wahl.
Ansonsten wirst du ja natürlich auch das Thema Backup nicht vernachlässigt haben nehme ich an denn Fehler passieren. Sei es durch Layer 8 oder einen Bug in der Software oder Hardware-Ausfall. Warum dann also nicht das Restrisiko des vermeintlich jüngeren und je nach Einsatzszenario instabilerem Btrfs eingehen und von den Vorteilen profitieren?

Zum ECC: Stell dir dein PC wie ein Auto vor. Das fehler-korrigierende Dateisystem ist der Anschnallgurt und ECC der Airbag (oder umgedreht, mir egal).
Beide zusammen: Sehr gute Schutzwirkung, beide agieren Hand-in-Hand.
Nur eins von beiden: Naja immer noch besser als nix aber wirst trotzdem mehr Blessuren davon tragen.
ECC schützt dich halt vor kippenden Bits im RAM aber eben nicht vor "bit-rot" auf den HDDs.

@alturismo Good Point mit der iGPU. Wenn der Aufpreis minimal ist klar warum dann nicht mitnehmen und man umgeht das Problem mit einem ggf. nicht startenden Mainboard.

da mir btrfs schon abgeschmiert ist und alles futsch war

Hat man dafür nicht Backups?^^

 

[alturismo]

Hat man dafür nicht Backups?^^

ja, hat man nur einmal nicht mehr weil ich dachte das backup läuft eh nächstes Wochenende und ich räume mal auf ... Kopfschuss, passiert auch nie wieder System war halt bisher immer zu stabil, bis auf cache und btrfs, das ist mir übrigens 2 x passiert, einmal schadlos (da backup), einmal nicht (da Vollidiot) daher Umstieg auf xfs, das läuft einfach ... aber btrfs hat natürlich seine Vorzüge, wie du es treffend formuliertest, Anwendungsszenario ...

 

[ArdNsc]

@snaxilian Es wird dann wohl auf den Pentium Gold G5400 hinauslaufen. Danke für die Hilfe.

@alturismo Ich verstehe das doch richtig, dass ich dann mit einem Raid 1 Cache Array für verschiedene Shares unterschiedliches Verhalten (no, yes, only usw.) konfigurieren kann, d.h. ich brauche keine dritte SSD für Docker, sondern stelle die entsprechenden Ordner einfach anders ein als den Rest, für den der Writecache z.B. Nachts ins Array geschrieben und geleert werden soll... ja?

An euch beide noch eine Rückfrage zu btrfs: Klar habe ich auch Backups. Aber der Sinn dieses NAS (ggü. einer Ansammlung von Festplatten) mit Parität, Korrektur von Bitfehlern usw. soll schon darin bestehen, dass die Daten möglichst zuverlässig verfügbar sind und bleieben und auf ein Backup nur im absoluten Notfall zurückgegriffen werden muss. Von btrfs hätte ich mir einen Beitrag zu diesem Ziel versprochen und nicht das Gegenteil, weshalb man dann halt auf Backups zurückgreifen muss. Könnt ihr die Risiken vielleicht spezifizieren oder du, @alturismo einfach mal erzählen, weshalb dir das btrfs-array 2x abgeschmiert ist?

Ist euch (oder anderen) an der sonstigen Hardwarewahl noch irgendetwas aufgefallen? Vor dem DS380 wird teilweise wegen Temperaturproblemen der Platten gewarnt und man muss wohl auf eine Bastellösung zurückgreifen, um überhaupt einen nennenswerten Airflow im Festplattenkäfig zu erreichen... aber ich sehe aufgrund der Platzbeschränkung bei mir zu dem Gehäuse keine Alternative. Das CS380 ist zu groß, das CS381 würde vielleicht noch gehen, aber das ist mir offen gesagt auch einfach zu teuer.

 

[alturismo]

zu deiner Frage, klar, docker braucht keine extra ssd, nur sollte auf jeden Fall eine SSD (oder mehrere) da sein
für den cache, ich hatte bei deinem ersten post das so verstanden daß diese erst später folgen sollen, davon
würde ich abraten, cache (SSD oder schneller) ist ein Muss

tja, warum ist mir 2 x der btrfs pool abgeraucht, gute Frage die ich nicht beantworten kann.

beim ersten Mal war es ein Pool (die 2 nvme drives zusammen), da dachte ich mir ok, kann passieren ...
beim zweiten Mal war es dann jedoch ein single drive setup (die 2. hatte ich dann als unassigned device für
die VM's drin), das war dann mein Fiasko ohne Backup ...

Erklären kann das keiner, das FS war halt nicht mehr erreichbar, nur noch lesen ... nach einem reboot dann
komplett weg und auch per allen möglichen Versuchen was zu retten ... ging halt nichts mehr.

Daher leider schwer zu sagen was der Grund war ... ich weiß nur das ich nicht der einzige bin der bereits
seinen btrfs cache verloren hat ... man liest das die docker aktuell unheimlich viele Schreibvorgänge
verursachen und das scheint mit der neuesten 6.9 build im Zusammenspiel mit der neuen docker version
erledigt zu sein, wir werden sehen ... vielleicht hat das bei dem ein oder anderen dazu geführt ...

Aber das sind nur Vermutungen, da ja per Standard btrfs für den cache genommen wird und der Großteil
daran nichts ändert ... und das nicht jedem 2. passiert ... würde ich sagen das ist schon recht zuverlässig,
waren nur meine persönlichen Erfahrungen und fahre daher gut mit dem o.g. Setup, xfs single drive cache's.

und als backup des caches, da kann man definieren was einem wichtig ist, ich muss nicht den gesamten
cache als backup haben, die /appdata sind mir wichtig, die Vorlagen der Docker sind mir wichtig ...
das Dockerimage (30G) brauche ich nicht als backup, das ist schnelll und ohne Aufwand wieder da.

Und wenn ein paar Serien oder Filme im cache über die Wupper gehen ... na dann ... auch schnell erl.

 

[snaxilian]

Aber der Sinn dieses NAS (ggü. einer Ansammlung von Festplatten) mit Parität, Korrektur von Bitfehlern usw. soll schon darin bestehen, dass die Daten möglichst zuverlässig verfügbar sind und bleiben und auf ein Backup nur im absoluten Notfall zurückgegriffen werden muss. Von btrfs hätte ich mir einen Beitrag zu diesem Ziel versprochen und nicht das Gegenteil, weshalb man dann halt auf Backups zurückgreifen muss

Puh, da weiß ich gar nicht wie viele neins ich da schreiben und wo ich anfangen soll. Du würfelst hier blind alle möglichen Begrifflichkeiten zusammen und machst Annahmen, die so einfach nicht stimmen.

NAS - Ein NAS ist erst einmal nichts anderes als ein Network Attached Storage, also ein im Netzwerk verfügbarer Speicher für Daten. Ein Raspi mit nem USB-Stick kann mittels samba- oder nfs-Serverdienst bereits ein NAS sein. Genau so gut jedes Fertigsystem-NAS oder auch dein geplantes unraid oder freenas oder auch eine NetApp AFF All-Flash kein ein NAS sein, dann nur ein ziemlich teures^^

Paritäten (oder auch allgemeiner Raids und artverwandte Lösungen) - Hier wird lediglich die Verfügbarkeit erhöht damit die Daten eben auch verfügbar sind wenn ein Bauteil ausfällt. Da es sich hier bei HDDs um bewegliche Bauteile handelt ist da eine gewisse Redundanz sinnvoll. Gleichzeitig ist es mit das einfachste Mittel Redundanzen zur Verfügung zu stellen im Bereich der privaten Konsumenten denn Hand aufs Herz: Lüfter im Gehäuse oder die CPU oder auch im Netzteil sind bewegliche Teile und das Stromnetz auch in Teilen anfällig. Dies sind aber Bereiche wo man im Endkundensegment so gut wie keine Redundanzen schaffen kann oder es preislich nicht attraktiv ist. Hinzu kommt bei größeren/professionelleren Storages die Anbindung über zwei Controller was dann aber idR Dualport-SAS-Festplatten erfordert aber ich schweife ab.
So oder so: Ein Raid was Redundanzen aufbaut und/oder Paritätsinformationen beinhaltet kann ich genau so gut in einem einzelnen PC betreiben. Da Daten auf einem einzelnen PC aber in der Regel nur für den einen Anwender wichtig sind spart man sich diesen Aufwand aber bei Serversystemen, denn nichts anderes ist ein NAS, werden oft genug Daten abgelegt die für mehrere Personen wichtig sind. Daher ist es auch in gewisser Weise relevant, dass die Daten mit einer höheren Verfügbarkeit vorhanden sind.

Erkennung/Korrektur von Bitfehlern - Als man merkte, dass Bitfehler entstehen können musste man Abhilfe schaffen. Entweder müsste man alle Daten in Dateiformate abspeichern, die Korrekturdaten beinhalten (rar Files beispielsweise) aber das ist aufwendig oder man müsste selbst für alle Daten mehrere Kopien anlegen und diese regelmäßig vergleichen aber das ist teuer aufgrund des ganzen Speicherplatzes oder man bildet über die gespeicherten Daten Checksummen aus denen man die ursprünglichen Daten wiederherstellen kann und prüft regelmäßig. Letzteres ist die Funktionsweise von btrfs, zfs oder ReFS mit den regelmäßigen Scrubs.
Fun Fact am Rande: Genau mit diesem Prinzip arbeitet z.B. unraid bei den Paritäten oder fest jedes beliebige Raid. Der gravierende Unterschied ist: Diese Lösungen nehmen nur die Blöcke und können im Fehlerfall nicht prüfen. Wenn dir also mit einem Raid 5 oder unraid mit einfacher anstatt doppelter Parität eine HDD ausfällt dann wird stumpf aus den Paritätsinformationen alles wieder hergestellt. Ist durch "bit-rot" ein Fehler entstanden wird halt die fehlerhafte Datei wiederhergestellt oder noch schlimmer: Hast du nicht nur bit-rot sondern einen nicht mehr lesbaren Sektor scheitert die Wiederherstellung und zwar nicht nur von der "Datei" sondern vom gesamten Laufwerk. Ein Raid (oder vergleichbares Paritätssystem) kennt nur das gesamte Gebilde.
Lösungen wie btrfs/zfs/refs vereinen Raidfunktionen und Dateisystemfunktionen und können dies daher besser lösen. Kippt mir da nach einem Scrub ein Bit habe ich trotzdem verloren daher sollte man diese Scrubs regelmäßig machen. Bei sich selten ändernden Daten wie z.B. einem Medienarchiv monatlich aber bei einem VM-Storage würde ich dies mindestens einmal die Woche erledigen lassen.

Backups - Ich habe keine Ahnung woher im allgemeinen dieses "ohoho Backups nur im Notfall mimimi" von allen möglichen Leuten kommt aber ich verstehe es einfach nicht. Ein Backup tut nicht weh und brauche ich es öfters bin ich vor allem routinierter in der Wiederherstellung als wenn ich es alle 5+ Jahre brauche und dann zwar weiß dass irgendwo und irgendwie meine Daten auf dem Backupdatenträger/-system liegen ich aber keine Ahnung habe wie ich da jetzt dran komme.
Btrfs bringt einem da gerade eine Erleichterung und Automatisierung durch die Snapshot-Funktion. Du könntest z.B. bei sich häufig ändernden Daten stündlich einen Snapshot anlegen lassen aber nur einmal täglich den dann aktuellsten Snapshot auf ein Backupsystem replizieren lassen und dort so lange aufbewahren wie du es möchtest. Der lokale Snapshot ist dann nix anderes oder vergleichbar mit den unter Windows bekannten Shadow Copies / Schattenkopien.
Datei aus Versehen gelöscht? > Kein Problem, letzten bekannten Snapshot mit der Datei eben gemountet, Datei da raus kopiert, Snapshot entmountet (kennt da jemand eine bessere eingedeutschte Version für??).
HDD ausgefallen? > Ersatz beschaffen und letzten Snapshot vom Backup zurück replizieren, live nehmen, fertig.
Komplettes Storage ausgefallen? > Ersatz beschaffen, Vorgehen siehe einzelne HDDs.

Wie ich schon erwähnte: Unterschiedliche Anwendungsfälle erfordern unterschiedliche Maßnahmen und Lösungen. Lösungen wie btrfs/zfs/refs bieten den Vorteil, dass ich den Anteil der unterschiedlichen Maßnahmen reduzieren kann weil ich dadurch unterschiedliche Anforderungen abdecken kann. Wichtig hierbei: Keines der genannten Lösungen ist eine Allroundlösungen und alle haben ihre Schwächen und Stärken.

 

[ArdNsc]

Ich weiß, was ein NAS ist und ich weiß auch, dass Raid kein Backup ersetzt. Ich meinte die Zwecke, die ich mit meinem Neubau (den habe ich kurzerhand als "dieses NAS" bezeichnet) verfolge: Da will ich die Zuverlässigkeit erhöhen und werde deswegen hellhörig, wenn mir zu einem Dateisystem, das dazu ein Beitrag sein soll, gesagt wird, wenns kaputt geht ist doch egal, hast ja sicher ein Backup... Womit du allerdings recht hast, ist, dass ich von btrfs keine Ahnung habe, deshalb stelle ich ja hier die ganzen Fragen. Ich könnte wahrscheinlich gezielter nachfragen, wenn ich mich damit mehr auseinandergesetzt habe, stimmt schon...

 

[snaxilian]

Dann musst du dies auch so klar und eindeutig schreiben. Keiner hier kann erahnen was du meinst sagen zu wollen und niemand kann deine unausgesprochenen Gedanken nachvollziehen.

Spoiler: Disclaimer

Wie vermutlich schon aufgefallen unterscheide ich nicht explizit zwischen "klassischen" Raid-Lösungen oder den Methoden von btrfs/zfs oder herstellerspezifischen Lösungen wie beispielsweise unraid, snapraid oder sonstigen. Raid verwende ich hier als Synonym für die Möglichkeit die Verfügbarkeit zu erhöhen durch Verteilung von Daten über mehrere Laufwerke. Nicht betrachtet werden andere Eigenschaften von teils anderen Raid-Funktionen und -Leveln zur Erhöhung der Leistungsparameter (lesen, schreiben, random IOPS, etc) oder die zur Bereitstellung eines Speicherbereichs der größer ist als die einzelner Laufwerke.

Welche konkrete Zuverlässigkeit willst du denn genau erhöhen? Willst du die Verfügbarkeit erhöhen, sprich sollen die Daten auch bei Ausfall einzelner Komponenten verfügbar sein? Dann musst du Redundanzen verwenden, die simpelste sind wie bereits erwähnt die Verwendung von Raids oder vergleichbaren Paritätslösungen. Streng genommen ist dies aber auch keine Verfügbarkeit sondern eher eine Hochverfügbarkeit denn auch mit einem Backup sind Daten verfügbar wenn auch nicht sofort innerhalb von 2 Sekunden.
Aber auch diese sind kein Allheilmittel: Why raid 5 stops working in 2009 und Why raid 6 stops working in 2019. Das erklärt recht gut die Zusammenhänge und Limitierungen bei Raid und Consumerplatten. Wenn du HDDs auswählst mit einer besseren URE kannst du die Wahrscheinlichkeit(!) verbessern aber niemals eliminieren. Durch btrfs/zfs/refs mit den inkludierten Metadaten und Checksummen und regelmäßigen Scrubs kannst du diese Fehler entdecken bevor es zu einem Problem wird aber auch hier kannst du es nie komplett eliminieren.
Diese Funktionen (Checksummen, redundante Metadaten, Scrubs) haben aber weniger mit der Verfügbarkeit zu tun sondern stellen eine gewisse Integrität der Daten sicher.

Alles bisher genannte erhöht also den Schutz deiner Daten aber es kann dich nicht schützen vor:

• menschlichem Versagen wie z.B. versehentliches löschen von Daten
• Schadsoftware/Ransomware
• Beschädigung durch Elementarschäden (Feuer, Wasser, Blitzschlag, etc)
• Verlust der Daten durch Diebstahl
• physikalische Beschädigung (NAS beim Umzug fallen gelassen)

Um nur ein paar der häufigsten Ursachen zu nennen die mir spontan einfallen. Vor diesen Gefahren schützt dich aber ein Backup (naja streng genommen ein Backupkonzept was oft mehr als ein Backup beinhaltet...).

Deine Grundannahme "unraid + btrfs schützt meine Daten" ist somit schlicht falsch bzw. viel zu undifferenziert. Du musst stets definieren: Wovor soll ich geschützt sein bzw. was ist die Bedrohung und welche Gegenmaßnahmen kann ich dazu verwenden.
Ja, ein Dateisystem dass Bitfehler erkennen und korrigieren kann erhöht den Schutz deiner Daten und erhöht die Zuverlässigkeit da es dich vor genau diesen Bitfehlern schützt. Es schützt dich aber nicht vor den ganzen anderen potentiellen Fehlerquellen. Ein XFS mag da in den Grundfunktionen ggf. ausgereifter sein da schon länger in Nutzung als Btrfs aber auch XFS wird nach wie vor weiter entwickelt und bekommt neue Features und auch diese können Fehler beinhalten. Aber keine Ahnung ob unraid diese Features ebenfalls überhaupt verwendet oder nicht.

 

[ArdNsc]

Ich glaube nicht, dass ich mich so unklar ausdrücke. Ich hätte vielleicht schreiben sollen: Ich will nicht mit der Wahl von btrfs (ggü. xfs) die Datenintegrität erhöhen, wenn das auf Kosten eines gesteigerten Risikos für einen Totalausfall des Arrays geht. Das hast du immerhin suggeriert. Aber zu der Frage, weshalb btrfs hier ein Risiko darstellen könnte, ist außer Mutmaßungen ja nichts gekommen. Stattdessen erzählst du mir, dass mich das nicht vor Diebstahl und Wasserschäden schützt. Also lassen wir das jetzt.

 

[alturismo]

@ArdNsc ich denke du verwechselst evtl. hier gerade etwas, ich hatte bei btrfs gesagt .... @snaxilian ist da glaube ich nicht dabei, er hat anderes dokumentiert (und das ganze auch sehr sauber fachlich(.

Also, zusammengefasst, dein unraid System wird sicherlich deine Bedürfnisse erfüllen. Wir sind uns alle klar
darüber das alles seine Grenzen hat und Du kein Rechenzentrum bist

Bzgl. cpu und igpu wurde auch etwas geschrieben, das liegt an Dir (und auch hier der EInwand das manche MB NUR mit GPU starten berücksichtigen)

Und der Rest passt, zur Info auch, die unraid comunity ist auch sehr hilfreich ... und es gibt mittlerweile sogar einen deutschen Bereich falls von Nöten