Upgrade 10+ Jahre altes unRaid system

[kysriel]

Hallo zusammen,

 

nachdem mein unRaid System jetzt mehr als 5 Jahre lang ausgeschalten in der Ecke stand, kam der Moment an dem ich es wieder aktivieren wollte. Leider merke ich, dass das System inzwischen schon ziemlich an seine Grenzen kommt.

 

Lian-Li PC-Q25

i5-2400 (nachgerüstet)

ASRock P8H77-I m-ITX

8GB RAM

250GB Samsung 870 evo (nachgerüstet)

insgesamt 11TB nutzbares Array aus 2 und 3TB WD RED Platten

LSI 6gb/s SAS HBA Karte auf IT mode geflashed

 

Außerdem läuft bei mir noch ein Lenovo Tiny thin client mit

i5-8400T

16GB RAM

250GB SSD

 

Auf dem Thin Client läuft Proxmox mit Home Assistant als VM und 7-8 LXC Container derzeit ohne Probleme.

 

Auf unRaid möchte ich nun vor allem meine Medien verwalten. D.h.

*Arrs

Tdarr um h265 platzsparend konvertieren zu können (low Prio)

Sabnzbd

Jellyfish

Immich

und ich würde mich gerne an einer VM für Proxmox Backup Server versuchen.

 

Ich hätte da jetzt an ein System auf Basis eines i3-12100 gedacht mit vorerst 16GB RAM aber dabei sind ein paar Fragen aufgetaucht. Als ersten Schritt habe ich mal 2x 16TB Seagate Exos besorgt, die mein Speicherproblem mal beheben.

 

Das LianLi Gehäuse limitiert mich leider auf m-ITX, könnt ihr mir ein geeignetes Mainboard empfehlen?

 

Die Thematik Cache und Pool überfordert mich derzeit und ich bin mir nicht sicher, was ich davon wirklich brauche. Ich denke 2 SSDs für die Docker und VM Daten wären gut, würde mir da eine zweite 250gb Platte reichen? 500gb SSD sind zwar schon erschwinglich, aber ich müsste halt zwei davon kaufen.

 

Wie kann ich am besten des Entpacken und Kopieren von SABnzbd beschleunigen? NVMe Pool? Wie groß sollte der sein? Zur Zeit denke ich, dass ich hier den größten Flaschenhals habe. Eingerichtet habe ich derzeit alles so gut es geht nach den Trash Guides.

 

Ich hoffe ich habe alles verständlich erklären können und freue mich auf eure Vorschläge

 

 

 

 

Edited March 10 by kysriel

[EliteGroup]

1 hour ago, kysriel said:

Tdarr um h265 platzsparend konvertieren zu können (low Prio)

Sicher das du jetzt noch auf H265 setzten möchtest?
Die Zukunft ist AV1 in Punkto:
- Kompression
- Video Quallität
- Lizenzfrei

Aktuell starten alle großen Dienste durch mit AV1. Von YouTube bis nVidia.
Es ist zu diesen Zeitpunkt ein schwieriges Thema bezüglich verfügbare Hardware Encoding/Decodig von AV1 und das kommende aussterben von H265/HEVC...
Das Problem hier ist das AV1 iGPUs erst ende des Jahres kommen werden, aktuell gibt es keine für 1700 Socket.
Es gibt (aktuell) nur AMD AM5 CPUs mit iGPU die AV1 encoding/decoding unterstützt. Bei Intel gibt es die PCIe Intel ARC A380 mit AV1
Wenn du allerdings bei HEVC bleiben möchtest spielt alles von der CPU wahl keine Rolle...
Da du scheinbar aber Systeme für viele Jahre haltest, wäre ein Bibliothek mit HEVC echt schade. Ich warte extra seit 1 Jahr auf neue Hardware sonst hätte ich bereits von H264 zu HEVC begonnen. Nur für Streaming besonders als Datengrab und sogar Remote Streaming gewinnt AV1 eindeutig in allen Punkten.
Nicht flasch Verstehen: HEVC wird auch in Zukunft unterstützt auf allen Geräten.
Die Videoquallität ist aber leider nur "mittel". Sollte man nur machen wenn das platzsparen wichtiger ist als die Videoquallität.
Möchte man sich ein großes Datengrab aufbauen sollte man bei H264 bleiben oder AV1 sich langsam überlegen.
Bei Serien setzte ich gerne auf HEVC. Bei Filme eher weniger.
 

1 hour ago, kysriel said:

Die Thematik Cache und Pool überfordert mich derzeit und ich bin mir nicht sicher, was ich davon wirklich brauche. Ich denke 2 SSDs für die Docker und VM Daten wären gut, würde mir da eine zweite 250gb Platte reichen? 500gb SSD sind zwar schon erschwinglich, aber ich müsste halt zwei davon kaufen.

Theoretisch würde ein Pool aus 2x SSD für Sicherheit und Cache reichen.
Wenn du allerding SABnzbd + *Arrs und Transcoding verwenden willst kann ich dir nur dringend Empfehlen eine eigene Single Cache SSD für das Array... Das wird dir das Leben leichten machen und den verschleiß deiner Appdata minimieren.
Du könntest Theoretisch:
1. POOL (Cache)
1x SSD (500GB bis 2TB jenachdem wie hoch die bearbeitende Downloadsumme ist und wie oft "geschoben" wird), eine zweite SSD für *arr Systeme wird nicht benötigt da diese im schlimmstenfall die letzten Daten erneut runtergeladen werden können.

2. POOL (Data)
Hier kannst du auch nur 1x SSD verwenden.. Wenn du regelmäßig Backup machst von Appdata (was einige leute so machen) und ein Verlust bei Datenträger schaden dir egal ist..
Ansonst wenn es um Sicherheit geht wäre 2x SSD als Spiegel besser. Als ZFS Pool würde das sogar einen kleinen Performance schub geben als wie eine Single SSD.
Die entscheidung ob ungesichert und kosten sparen mit 1x oder Ausfallsicherheit mit 2x SSD liegt bei dir.
Alleine für Docker als Appdata würden dir 250GB SSD bestimmt reichen... (Solang du großzügig deinen Cache betreibst oder du wählst weniger Cache dafür Tägliche verwendung vom Mover zum Array)

 

1 hour ago, kysriel said:

Wie kann ich am besten des Entpacken und Kopieren von SABnzbd beschleunigen? NVMe Pool? Wie groß sollte der sein? Zur Zeit denke ich, dass ich hier den größten Flaschenhals habe. Eingerichtet habe ich derzeit alles so gut es geht nach den Trash Guides.

Cache POOL.
Du legst einen Share der NUR auf dem Cache ist, ich verwende den Namen "Tmp", das steht für Temporäre Datein, ein unterordner mit SABnzbd.
Am Ende arbeitet Tdarr auch ausschließlich im Cachepool, der muss garnicht wissen was sich am Array befindet (Wenn die vorhanden Datein mal alle Umgewandelt sind).
Dann kommen die Radarr / Sonarr und was du sonst noch verwendest. Die verwenden den "User" Share von Array.
Der sieht und schiebt neue Inhalte nur auf den Cache, der UNRAID Mover schiebt von Cache auf Array und Radarr/Sonarr verwaltet diese per USER Fuse mount.
Also SABnzbd arbeitet ausschließlich auf /mnt/cache und nicht auf /mnt/user

Die Performance kannst du mit SABnzbd steigern indem du "Direkt Entpacken" aktivierst. Dann wird bereits wärend des Downloads die Archive entpackt und die entpackung ist fast direkt nach Download Ende fertig entpackt ohne wartezeit.

Wichtig für das ganze Arbeiten mit einen vollständigen *arr System ist eine saubere Ordnerstruktur und die richtige verwendung von Freigaben.
Wie schon erwähnt wichtig erstelle einen eigenen Share mit dem Namen "Tmp" und dort werden Temporäre Datein bearbeitet, wie SABnzbd und Tdarr

Edited March 10 by EliteGroup

[kysriel]

Vielen Dank für die ausführlichen Infos!

 

2 hours ago, EliteGroup said:

Sicher das du jetzt noch auf H265 setzten möchtest?
Die Zukunft ist AV1 in Punkto:
- Kompression
- Video Quallität
- Lizenzfrei

 

Da sieht man mal, dass ich die letzten Jahre in der Senke war

 

2 hours ago, EliteGroup said:

Das Problem hier ist das AV1 iGPUs erst ende des Jahres kommen werden, aktuell gibt es keine für 1700 Socket.
Es gibt (aktuell) nur AMD AM5 CPUs mit iGPU die AV1 encoding/decoding unterstützt. Bei Intel gibt es die PCIe Intel ARC A380 mit AV1

 

Viel zum Nachdenken, mal sehen wie lange das alte System noch mitmacht. Hatte natürlich gehofft jetzt gleich eine vorhandene Lösung zu finden. Das scheint derzeit auch auf mITX Format schwer machbar zu sein, wenn schon eine HBA Karte einen Slot braucht.

 

2 hours ago, EliteGroup said:

Theoretisch würde ein Pool aus 2x SSD für Sicherheit und Cache reichen.
Wenn du allerding SABnzbd + *Arrs und Transcoding verwenden willst kann ich dir nur dringend Empfehlen eine eigene Single Cache SSD für das Array... Das wird dir das Leben leichten machen und den verschleiß deiner Appdata minimieren.
Du könntest Theoretisch:
1. POOL (Cache)
1x SSD (500GB bis 2TB jenachdem wie hoch die bearbeitende Downloadsumme ist und wie oft "geschoben" wird), eine zweite SSD für *arr Systeme wird nicht benötigt da diese im schlimmstenfall die letzten Daten erneut runtergeladen werden können.

2. POOL (Data)
Hier kannst du auch nur 1x SSD verwenden.. Wenn du regelmäßig Backup machst von Appdata (was einige leute so machen) und ein Verlust bei Datenträger schaden dir egal ist..
Ansonst wenn es um Sicherheit geht wäre 2x SSD als Spiegel besser. Als ZFS Pool würde das sogar einen kleinen Performance schub geben als wie eine Single SSD.
Die entscheidung ob ungesichert und kosten sparen mit 1x oder Ausfallsicherheit mit 2x SSD liegt bei dir.
Alleine für Docker als Appdata würden dir 250GB SSD bestimmt reichen... (Solang du großzügig deinen Cache betreibst oder du wählst weniger Cache dafür Tägliche verwendung vom Mover zum Array)

 

Wenn ich das richtig verstanden habe, wäre eine zweite SSD derzeit wohl das beste Upgrade (und auch weiter verwendbar).

Ich hatte teilweise das Gefühl, dass SABnzbd beim Entdecken dem Prozessor viel abverlangt (deswegen habe ich derzeit "direkt entdecken" deaktiviert), aber das könnte evtl auch sein, weil ich derzeit nur das Array als Speicher für das ganze Setup verwende.

Da ich regelmäßig Backups von Appdata mache, würde ich mir einfach eine 500gb SATA SSD für einen eigenen Cache Share zulegen.

Edited March 10 by kysriel

[EliteGroup]

34 minutes ago, kysriel said:

Ich hatte teilweise das Gefühl, dass SABnzbd beim Entdecken dem Prozessor viel abverlangt (deswegen habe ich derzeit "direkt entdecken" deaktiviert), aber das könnte evtl auch sein, weil ich derzeit nur das Array als Speicher für das ganze Setup verwende.

Ich hatte auch mal das Problem...
Es könnte wirklich daran liegen.
Mit aktueller CPU und direktes arbeiten am SSD Cache geht meine CPU kaum noch hoch. Das Arbeiten im /mnt/user "könnte" das Problem sein das beim entpacken nicht SABnubd die CPU hoch reißt sondern Unraid-FUSE. Deshalb die empfehlung: Arbeite mit Temporäre Dateien nur auf dem Cache /mnt/cache
Seit dem habe ich auch mit direkt entpacken keine probleme mehr.
 

38 minutes ago, kysriel said:

Da ich regelmäßig Backups von Appdata mache, würde ich mir einfach eine 500gb SATA SSD für einen eigenen Cache Share zulegen.

Ja also 1. Pool Cache mit 1 SSD und 2. Pool Data mit 1 SSD ist durchaus möglich mit einem hauch vertrauen und regelmäßig Backups. Kein Problem.

Zu der Hardware:
Hier gebe es sehr viele möglichkeiten...
Mal so ein gedanken Spiel: Wie wäre beide deiner System zusammen zu führen in einem guten effizienten Unraid Server?
Nachdem was ich von dir gelesen habe würde ein Intel N100 reichen von der CPU, der auch Transkodierung unterstützt nebenbei...
Aktuell geht ein Hype auf das Mainboard
ASRock N100M
Die Leistung wäre zugegeben etwas schwächer als deine 2 Systeme zusammen, aber der Intel N100 hat nur 6 Watt TDP!
Richtig guter kleiner Stromspar Server mit dampf unter der Haube.
Der ist stark genug für alle Docker die du dir wünscht + Transkodierung und 1 oder 2 VMs sind auch kein Problem.
Zudem kostet das Mainboard + CPU "nur" 125€ was jetzt nicht die Welt für einen Server dieser Leistung ist.

Der Nachteil ist klar nur 2x SATA OnBoard. Ich weis jetzt nicht genau wieviele HDDs verwendest du aktiv?
Aber Upgrade per PCIe ist ja möglich. Wobei du von deiner LSI Karte schreibst, die frisst wieder Strom im Vergleich zu SATA ASM1166 Controller. Ein ASM1166 bringt dir +6 SATA Slots fürs Array, OnBoard ist dazu noch ein M.2 Slot. Der zb für Data Pool verwendet werden kann.
Deine Stromkosten würden massiv sinken. Aktuell betreibst du eine 95 Watt + 35 Watt CPU.
Wobei man sagen muss der 8400T ist keine schlechte CPU / Server. Der könnte komplett als Unraid Server dienen, benötigt aber ein anderes Gehäuse wenn das möglich wäre? Oder sind überhaupt PCIe Slots vorhanden oder ist das so ein Mini-PC? Dann sind die vorraussetzungen leider schlecht trotz guter CPU

[kysriel]

Ja die N100 Boards hab ich auch schon gesehen. Mich stört da bisschen die Modularität. Wäre ich mit einem LGA1700 Board bereit für eine CPU mit iGPU die dann später mal AV1 unterstützt? Dann würde ich bevorzugen im schlimmsten Fall nur die CPU zu tauschen.

 

Alles in einem System zusammenzufassen hatte ich auch schon überlegt. Der 8400T ist leider in einem MiniPC, den würde ich dann wohl eher verkaufen.

 

Meine derzeitige HDD Situation ist

Array

1x 16TB Parity

1x 16TB Data

1x 4TB falls der Platz eng wird als reserve

 

Pools

1x 250GB SATA SSD (aktuell AppData) -> würde ich im neuen System gegen 500GB/1TB NVME für Cache Pool ersetzen

1x 500GB SATA SSD gerade für Cache Pool bestellt, würde ich dann für AppData benutzen

bzw. ist es besser eine NVMe für AppData oder lieber Cache Pool zu verwenden?

Ich rechne jetzt mal mit nur einem m.2 slot bei den mITX Boards und die PCIe Karte würde dann vorraussichtlich für einen ASM1166 controller verwendet werden.

 

Also wären mindestens 4x Sata schon gut zu haben.

 

Wäre ein Wechsel von der LSI Karte zu einem ASM1166 Controller auch jetzt schon als nächster Schritt zu empfehlen um in der Zukunft Strom zu sparen? Das würde mich generell bei der Auswahl der Mainboards für mITX flexibler machen.

[DataCollector]

Thema AV1 in iGPU:

AV1 CPU kommen erst noch. ich weiß nicht ob die aver für S1700 erscheinen werden.

https://videocardz.com/newz/intel-confirms-meteor-lake-has-av1-video-encoding-and-decoding-support

Wenn ich diese Webseite als Grundlage nehme, wird das erst mit meteor Lake mit dem neuen Sockel-1851  etwas werden.

In so fern ist es egal, wenn Du jejt upgraden willst, kann weder N100 oder ein S1700 AV1 in der iGPU untertützen.

 

250GB SATA für Appdata: Solange Du nicht viele VM anlegst reicht die, da Du den Array Cache ja auf einem anderen pool handhabst.

500GB SATA Für Array Pool(Cache) Wenn Du weiterhin nicht viel im Array machst reicht das.

Ich hätet aber lieber zu etwas größerem gegriffen, udn wenn sowieso die Harwdareplattform geändert wird (oder man per PCIe -Adpaterkarte einen Slot nutzen kann) direkt NVME SSD.

 

gute NVMe SSD sind erheblich flotter als SATA SSD.

Ein EInsatz einer NVMe eignet sich dort, wo man eben viele Zugriffe schnell evrarbeiten will.

Wnen bisher eien SATA SD reicht, reicht die auch in naher Zukunft. Aber wenn man heutzutage eine SSD (<= 4TB) neu kauft und die möglicheit hat es einzusetzen, würde ich zu NVMe schauen.

 

Wenn es uATX sein dürfte (passendes gehäuse vorausgesetzt/doch beschafft) sind auch 2 oder sogar 3x M:2 PCIe möglich oder eben auch im PCIe per Adapterkarte.

 

Wechsel LSi zu ASM1166 jetzt schon: wenn es technich machbar ist: ja. Dein Stromverrbauch wird etwas sinken.

[kysriel]

Es ist mir inzwischen einiges klarer, auch was ich brauche/will. 

Ein paar Fragezeichen habe ich noch bei den Geschwindigkeiten.

SATA 3.0 mit 6Gb/s sollte ja für alle HDDs und SSDs ausreichen.

Für M.2 Speicher gibt es ja sowohl NVMe als auch SATA. Hab ich es richtig verstanden, dass M.2 SATA eigtl nicht schneller sind als normale SATA SSDs?

Wie sieht das mit PCIe 3.0 4x vs PCIe 4.0 4x aus? Gibt es da einen merkbaren Unterschied in meinem usecase? Würden evt. sogar PCIe 3.0 2x reichen? Das ASRock N100D hat ja z.b. einen PCIe 3.0 2x NVMe Slot.

[EliteGroup]

38 minutes ago, kysriel said:

Für M.2 Speicher gibt es ja sowohl NVMe als auch SATA. Hab ich es richtig verstanden, dass M.2 SATA eigtl nicht schneller sind als normale SATA SSDs?

Das ist korrekt. M.2 Sata nimmt man heute üblicherweise nicht mehr wenn der M.2 Slot PCIe fähig ist..
 

39 minutes ago, kysriel said:

Wie sieht das mit PCIe 3.0 4x vs PCIe 4.0 4x aus? Gibt es da einen merkbaren Unterschied in meinem usecase? Würden evt. sogar PCIe 3.0 2x reichen? Das ASRock N100D hat ja z.b. einen PCIe 3.0 2x NVMe Slot.

PCIe 4.0 ist klar um einiges schneller. Aber bemerkt man kaum. PCIe 4.0 verbraucht mehr Strom sogar als 3.0, im Server wäre es die bessere Wahl.
Wenn dein Mainboard max 3.0 unterstützt, macht es auch keinen Sinn eine 4.0 SSD zu kaufen auch wenn es Technisch möglich ist sie zu verwenden, nur sind diese meist teurer.

Es gibt nur eines was wichtig ist bei SSDs in Unraid:
TBW!
Umso höher umso besser. Der Rest ist unwichtig.

[DataCollector]

5 hours ago, kysriel said:

SATA 3.0 mit 6Gb/s sollte ja für alle HDDs und SSDs ausreichen.

 

Sofern es keine NVMe/PCIe SSD sind: ja.  😁

 

5 hours ago, kysriel said:

Für M.2 Speicher gibt es ja sowohl NVMe als auch SATA.

 

M.2 ist nur eien Schnittstelle und da gibt es sogar noch mehr wie USB und CNVi.

Aber bei den 2280er Slots, die man für SSDs gerne sieht sind M-Ke mit NVMe/PCIe flotter und zu bevorzugen.

SATA in einem M.2 macht (in meinen Augen) nur Sinn, wenn das Board nichts anderes dort kann, man eine solche SSD kostenlos noch rumfliegen hat/einsetzen will oder es PCIe-Lane-Probleme auf dem Mainboard gibt.

Wenn es unbedingt SATA sein soll, bevorzuge ich die an einem SATA Standardanschluß zu betreuben und einen M.2 der auch PCIe beherrscht eben für 'höherwertige Aufgaben' zu nutzen.

 

5 hours ago, kysriel said:

Hab ich es richtig verstanden, dass M.2 SATA eigtl nicht schneller sind als normale SATA SSDs?

 

Korrekt. maximum ca. 6GBit/s = ca. 600MByte/s

 

5 hours ago, kysriel said:

Wie sieht das mit PCIe 3.0 4x vs PCIe 4.0 4x aus?

 

PCIe 4.0 ist doppelt so flott bei meist erheblich höherem Strombedarf/Wärmeentwicklung.

 

5 hours ago, kysriel said:

Gibt es da einen merkbaren Unterschied in meinem usecase?

 

Ich sehe keinen wirklich relevanten Unterschied (außer ggf. aufwändigere Kühlung einer energieintensiveren PCIe 4.0 SSD die auch mit PCIe 4.0 betrieben wird).

Aber man kann bei vielen Mainboards auch dei PCIe Einstellungen ändern, so daß eine PCIe 4.0 SSD auch auf PCIe 3.0 gedrosselt laufen kann (Unter Dauerlast schreiben SSDs sowieso eher nicht an den Spitzenwerten, die gerne in den Datenblättern angegeben werden.

 

5 hours ago, kysriel said:

Würden evt. sogar PCIe 3.0 2x reichen? Das ASRock N100D hat ja z.b. einen PCIe 3.0 2x NVMe Slot.

 

Ja. Damit wären immer noch rund 2GByte/s möglich und das ist immer noch sehr flott (mehr als 3mal so schnell wie eine SATA SSD sein kann).

 

Aber man sollte nicht verschweigen. auch NVMe/PCIe SSD können nicht zaubern. Es gibt auf dem Markt viele günstige Modelle, die aber unter Dauerlast dann auch auf Werte einer SATA SSD einbrechen.

Wenn man also (so wie ich) oft viel und schnell am Stück auf die SSD schreiben will, ist eine NVMe SSD, die dann auf 80MBYte/s einbricht sogar enttäuschnder als viele Festplatten.

NVME/PCIe ist also keine magische Formel, die dafür sorgt, daß alle SSD mit dieser technik wirklich in allen belangen einer guten SATA SSD oder gar einer Festplatte überlegen sind.

 

Und ganz zum Schluß: ich verwend eeinige PCIe4.0 fähige SSDs, aber die im PCIe 3.0 Betrieb, weil ich festgestellt habe, daß die Exemplare, die ich getestet habe, ziemlich gut für meinen Wunsch eine hoher Schreubfestigkeit zu haben (also wenig Einbrüche bei dem oben beschriebenen schnellen Schreiben großer Mengen).

In meinen Tests bin ich aber auch auf einige PCIe3.0 und auch 4.0 SSDs gestoßen, die eben (wie erwähnt) massiv bei meiner Nutzung eingebrochen sind.

In so fern spreche ich mich nicht gegen PCIe 4.0 SSD generell aus, nur betreibe ich sie eben auch nur mit PCIe 3.0, weil das bei mir vollkommen ausreicht.

Edited March 13 by DataCollector