Unraid (?) Servervorschlag inkl. Docker/VMs

[flowershop]

Hallo zusammen,

derzeit betreibe ich einen Freebsd Server mit zwei ZFS data pools. In erster Linie Plex, ein paar kleinere Datenbanken, Dinge wie Solaranzeige, Fotoarchiv, Unifi etc.. Ich liebe ZFS aber sehe ein, dass mein Use-Case mittlerweile schlicht ein anderer ist. Bei vielen TB an Daten, die eher im Archiv liegen und ggf. alle paar Monate mal genutzt werden, denke ich über einen Switch zu unraid nach. Klar ist es kein FreeBSD mit ZFS, aber für meinen Use-Case könnte ich damit erreichen, dass ich viel leichter einzelne Platten nachstecken kann und die Platten 99% der Zeit im Spindown/Idle sind, was ja bzgl. Umwelt auch netter ist.

Aktuell ist es ein Supermicro Gehäuse mit 12*3,5“ Platten und einem X9DRD-7LN4F. Dazu ein LSI für die internen Platten. 2*E5-2650 v2 2.6Ghz und 64GB ECC RAM (4* Samsung M393B2G70DB0-YK0). Auf dem FreeBSD laufen einige JAILs (Nextcloud, Plex, Datenbanken). Und eine vm-bhyve mit Ubuntu für ein paar Docker.

Dazu noch ein Supermicro JBOD mit 16 bays über SAS angeschlossen.

Plan wäre das ganze wie folgt zu verschlanken:

• 1 Gehäuse mit 24-36 bays (um in den nächsten Jahren wenn notwendig nach und nach einzelne Platten nachzustecken)
• 2 CPUs mit gutem Preis/Leistungsverhältnis
• 2 NVMe als Unraid Cache-Pool
• 8*20 TB (6*Data + 2 * parity)
• 64GB+ Memory
• 10 GB Ethernet Anbindung (plus VLANs)

Als Basis wie gesagt unraid. Großteil der Apps (wie plex&unifi&co) als Docker auf dem Unraid, eine KVM Windows Server VM und eine KVM FreeBSD (für alles, was ich nicht sinnvoll mit Dockern hinbekomme).

Meine Hoffnung: Durch den Wegfall des externen (extrem lauten) JBODs spare ich schon einmal 2 Netzteile und den dadurch gezogenen Strom. Der Wechsel von ZFS (und derzeit 8-17 Spinning Disks) auf unraid (mit nahezu immer idling disks) sollte ebenfalls helfen. Mit 2TB NVMes kriege ich schon einiges in den VMs und Docker abgefackelt und bin zumindest bzgl. IOPS deutlich fixer als bisher (bisheriges ZROOT 2 TB Spinning SATA).

Habt ihr eine gute Empfehlung für Gehäuse und Board? Meine Schraubmotivation ist nicht gerade wahnsinnig hoch. Daher dachte ich an etwas von serverschmiede. Z.B.

• Supermicro CSE-847 X10DRI-T4+.
• 2 * Intel E5-2667V3
• 4*16 GB ECC RAM (in der Hoffnung, dass ich dann die 4*16GB aus dem alten Server nach der Migration rüberziehen kann)
• LSI SAS9300-8i mit IT Firmware (Frage: Bringt mir der 16i hier etwas)?
• 4*X540 10GB ist ja onboard
• 2*Supermicro 1280W 80 Platinum PSU

Bei den NVMe bin ich unschlüssig (komme aus de S-ATA Welt). GGf. ein AOC-SLG3-2M2 Adapter und dann zwei „normale“ 2TB NVMes rein? Spricht da was gegen Samsung 970/980/990 (gibts da Empfehlungen)? Es sind keine Enterprise SSDs aber sie würde im Unraid ja im BTRFS Raid-1 Pool (oder im neuesten unraid ZFS mirror) laufen und wenn mir eine flöhten geht, ist die fix ersetzt. Vermutlich alle 2-3 Jahre eine neue NVMe kaufen fühlt sich günstiger an als jetzt eine mega teure Enterprise SSD zu nehmen. Aber genau deswegen bin ich ja hier, um Eure Meinung zu hören. Brauchen die Samsungs extra Kühlkörper?

Setzt hier jemand etwas ansatzweise Ähnliches mit Unraid (bin Unraid Neuling) ein? Gibts Pferdefüße? Dinge wie Performanceunterschiede zwischen UnRaid und ZFS sind mir klar. Aber 95% von dem, was ich auf dem Server mach eist long-time-storage von großen Dateien. Write Once, Read seldom.

Nach dem was ich gelesen habe, kann ich ja zahlreiche VLANs in Unraid nutzen und an die Docker Container oder die VMs geben. Damit sollte ich alle Szenarien hinbekommen. Falls ich dann noch ein Plex Transcoding Thema haben sollte, kann ich ja noch eine Nvidia GPU für Hardware Transcoding reinwerfen.

Das Board hat laut Webseite:

• 2x PCIe 3.0 (x16) Low Profile
• 3x PCIe 3.0 (x8) Low Profile

Wenn ich mich nicht verzählt habe würde der LSI einen (x16?) belegen. Der NVMe zweifach Adapter (der hoffentlich die beiden NVMes als zwei Devices auswirft) den zweiten. Bliebe noch einer für z.B. die GPU.


Bin gespannt auf Eure Meinungen und auf was ich nicht geachtet habe.

 

[hominidae]

Bei den NVMe bin ich unschlüssig (komme aus de S-ATA Welt). GGf. ein AOC-SLG3-2M2 Adapter und dann zwei „normale“ 2TB NVMes rein? Spricht da was gegen Samsung 970/980/990 (gibts da Empfehlungen)? Es sind keine Enterprise SSDs aber sie würde im Unraid ja im BTRFS Raid-1 Pool (oder im neuesten unraid ZFS mirror) laufen und wenn mir eine flöhten geht, ist die fix ersetzt. Vermutlich alle 2-3 Jahre eine neue NVMe kaufen fühlt sich günstiger an als jetzt eine mega teure Enterprise SSD zu nehmen. Aber genau deswegen bin ich ja hier, um Eure Meinung zu hören. Brauchen die Samsungs extra Kühlkörper?

Setzt hier jemand etwas ansatzweise Ähnliches mit Unraid (bin Unraid Neuling) ein? Gibts Pferdefüße? Dinge wie Performanceunterschiede zwischen UnRaid und ZFS sind mir klar. Aber 95% von dem, was ich auf dem Server mach eist long-time-storage von großen Dateien. Write Once, Read seldom.

...nur als Info...ZFS gibt es auch in unraid...ab der v6.12 schon drin nativ ,...aktuell gibt es Release-Candidates....ich nutze das schon ein paar Monate.
Hinweis: das Cold/Storage Konzept (Array) in unraid bleibt, auch bei ZFS...jede Disk im Array ist/bleibt allein formatiert.
Damit gibt es natürlich bei einem Fehler keinen "heilenden" Vorteil einen CoW FS (BTRFS, ZFS) auf dem Array....dafür ist/sind die Parity-Disk(s) da.
Aber auf einem unraid Pool kannst Du auch ZFS einsetzen, hier dann mit allen "normalen" Raid-Modi wie für zfs-pools möglich.

 

[flowershop]

Danke Dir. Habe ich gesehen. Auf den einzelnen Disks im Pool sehe ich da keinen Vorteil (oder habe ich was verpasst) gegenüber XFS. Beim cache-pool würde ich wahnsinnig gerne gleich ZFS aufsetzen. Ich scheue mich nur vor der 6.12er Beta. Da steht dann beim rc gerne mal "wenn sie den Pool mit einer vorherigen Version angelegt haben, müssen sie den neu anlegen" und dann musste ja erst alles aufs Array bringen und dann wieder zurück. Da fehlt mir die Muße. Oder ist das nur eine Warnung, die man geflissentlich ignorieren kann?

 

[hominidae]

Ich scheue mich nur vor der 6.12er Beta. Da steht dann beim rc gerne mal "wenn sie den Pool mit einer vorherigen Version angelegt haben, müssen sie den neu anlegen" und dann musste ja erst alles aufs Array bringen und dann wieder zurück. Da fehlt mir die Muße. Oder ist das nur eine Warnung, die man geflissentlich ignorieren kann?

Ja, Du verwechselst Beta mit RC.
Das "Problem" gab es allein mit ZFS Pools, die vor der beta5 angelegt wurden...inzwischen kamen viele weitere Betas und nun Release Candidates...RCs sind public, das sollte safe sein.

Auf den einzelnen Disks im Pool sehe ich da keinen Vorteil (oder habe ich was verpasst) gegenüber XFS.

natürlcih wird bei ZFS der Fehler detektiert und Du weisst auf welcher Disk er ist.
Ausserdem kannst Du dann auch mit dem Array ZFS Features nutzen, zB snaps und replication (send/receive) machen.

Beim cache-pool würde ich wahnsinnig gerne gleich ZFS aufsetzen.

Das geht...Vorteil hier wäre, die Disks müssen nicht formatiert werden (anders als im Array) und Du könntest, weil Du schon auf ZFS bist, den zpool in einen unraid-pool auf Basis ZFS importieren.
Im unraid-pool können die Disks übrigens auch schlafen gehen...mein altes unraid Medien-Datengrab hatte letztens einen defekt...ich habe das Ding daher einfach komplett ausser Betrieb genommen, da die 3TB Disks da drin eh alt waren und langsam voll wurden... und den Platz verdoppelt, indem ich in meinen 24x7-unraid einen zpool Mirror aus 2x18TB +2x20TB eingebaut habe
Sieht bei mir so aus, inkl. einem Cache-Pool aus 2x 1TB NVMe.

~# zpool list -v
NAME            SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
cache           928G  30.5G   898G        -         -     1%     3%  1.00x    ONLINE  -
  mirror-0      928G  30.5G   898G        -         -     1%  3.28%      -    ONLINE
    nvme0n1p1   932G      -      -        -         -      -      -      -    ONLINE
    nvme1n1p1   932G      -      -        -         -      -      -      -    ONLINE
media          34.5T  14.8T  19.7T        -         -     0%    42%  1.00x    ONLINE  -
  mirror-0     16.4T  6.60T  9.76T        -         -     0%  40.3%      -    ONLINE
    sdd1       16.4T      -      -        -         -      -      -      -    ONLINE
    sdg1       16.4T      -      -        -         -      -      -      -    ONLINE
  mirror-1     18.2T  8.22T  9.97T        -         -     0%  45.2%      -    ONLINE
    sdc1       18.2T      -      -        -         -      -      -      -    ONLINE
    sdf1       18.2T      -      -        -         -      -      -      -    ONLINE

...wenn kein Media-Player läuft, geht der zpool "media" mit allen Disks schlafen. bei Zugriff gehen halt alle Disk im zpool an, anders als im Array.

 

[flowershop]

natürlcih wird bei ZFS der Fehler detektiert und Du weisst auf welcher Disk er ist.
Ausserdem kannst Du dann auch mit dem Array ZFS Features nutzen, zB snaps und replication (send/receive) machen.

Touché. Aber wirklich reparieren kannst Du ihn dann bei einzelnen ZFS Disks auch nicht und müsstest im Zweifel die gesamte Platte herstellen korrekt?

Ja, Du verwechselst Beta mit RC.
Das "Problem" gab es allein mit ZFS Pools, die vor der beta5 angelegt wurden...inzwischen kamen viele weitere Betas und nun Release Candidates...RCs sind public, das sollte safe sein.

Wer lesen kann ist klar im Vorteil. Danke Dir!

indem ich in meinen 24x7-unraid einen zpool Mirror aus 2x16TB +2x18TB eingebaut habe

Ja da können die auch schlafen gehen, klar. Habe ich im FreeBSD jetzt auch so konfiguriert. Aber wenn Du auf etwas aus dem pool zugreifst, müssen alle Disks hochfahren. Im native unraid müsste ja nur die Platte hochfahren, auf der die Datei liegt. Oder bin ich jetzt komplett schief gewickelt? Und wenn der Pool voll wird (bzw. langsam bei 90-95% plus Belegung) haue ich im unraid array eine einzelne Platte rein. Beim ZFS müsste ich ja wieder ein komplettes vdev bauen. Genau daher will ich ja für diesen Datengrab Anwendungszweck davon runter.

bei Zugriff gehen halt alle Disk im zpool an, anders als im Array.

Ah. Da schreist Du es ja selber. Danke! Gut. Schreit also viel nach rc nehmen, ZFS für den pool für die VMs, appdata und array-cache und dann native unraid array mit einzelnen Platten (plus 2 Parity). Ob dann ZFS auf die einzelnen Platen oder XFS muss ich noch ausknobeln. Klar: Snapshots etc. wären dann da. Das stimmt.

 

[hominidae]

Aber wirklich reparieren kannst Du ihn dann bei einzelnen ZFS Disks auch nicht und müsstest im Zweifel die gesamte Platte herstellen korrekt?

Korrekt, die Disks wird von der Parity-Disk im Array emuliert, bis Du sie austauschst. Des wegen "un-Raid".

Aber wenn Du auf etwas aus dem pool zugreifst, müssen alle Disks hochfahren. Im native unraid müsste ja nur die Platte hochfahren, auf der die Datei liegt. Oder bin ich jetzt komplett schief gewickelt?

Nein, das ist korrekt...beim lesendem Zugriff...bei schreibendem Zugriff auch die Parity Disk(s)
Es kommt auf das Einsatz-Szenario an... bei meinem medien-Pool, der eh nur 1-3h in der Woche mal in Benutzung ist, brauche ich das Array nicht und bei den nun grossen Disks ist es mir egal, ob da 1-2 oder alle 4 Disks laufen....immer noch sparsamer als im alten Filer, der ja noch NT-Verluste und MB, CPU, RAM in Arbeit extra hatte (der lief im suspend mode, und wurde per WoL geweckt).

Und wenn der Pool voll wird (bzw. langsam bei 90-95% plus Belegung) haue ich im unraid array eine einzelne Platte rein.

Ja, genau...
Wir war nicht so ganz klar, ob Du nur von Deinem JBOD weg willst oder eben auch diese Möglichkeiten des unraid Array Konzepts nutzen willst.
Da die Disks fürs Array aber neu formatiert werden müssen, wäre es evtl. trotzdem eine Idee für die Daten-Migration von / via (lokalem) zpool auf Array (egal ob dort XFS oder ZFS genutzt wird).
Ich würde das übrigens zunächst nur mit Daten-Disks machen und die Parity zuletzt einbauen, wenn alle Daten auf dem Array sind...ist dann schneller.

Schreit also viel nach rc nehmen, ZFS für den pool für die VMs, appdata und array-cache und dann native unraid array mit einzelnen Platten (plus 2 Parity). Ob dann ZFS auf die einzelnen Platen oder XFS muss ich noch ausknobeln. Klar: Snapshots etc. wären dann da. Das stimmt.

Ja, klingt vernünftig.
ZFS in unraid kommt übrigens über 2 Releases verteilt (v6.12 und v6.13)...in v6.12 wird noch nicht alles über die UI integriert sein (snaps, send/receicve).
Das es mit ZFS jetzt ja auch "pools" (zpools) gibt und einen ZFS-Cache (ARC) wurde das Konzept etwas umformuliert ...unraid-Cache/-Pool und -Array heissen jetzt "Primary und Secondary Storage, bleibt aber technisch gleich. Mit v6.13 soll aber das Konzept aber wohl nochmal erweitert werden...Array und Pool soll flexibler werden...dann könnte man zB auch für einen unraid-pool einen anderen unraid-pool als Primary (Cache-Pool) verwenden.

 

[flowershop]

Wir war nicht so ganz klar, ob Du nur von Deinem JBOD weg willst oder eben auch diese Möglichkeiten des unraid Array Konzepts nutzen willst.

In der Tat beides. Und vom bhyve->Ubuntu->Docker Zeugs auch. Da können die Docker gleich im unraid laufen.

Hast Du eine Idee bzgl. der NVMe Devices? Passen da die "normalen" Samsung Pros wenn die Nutzung in erster Linie appdata ist? Ich würde mir wirklich gerne Enterprise-SSDs sparen.

 

[hominidae]

Hast Du eine Idee bzgl. der NVMe Devices? Passen da die "normalen" Samsung Pros wenn die Nutzung in erster Linie appdata ist?

Ja, die laufen gut und stabil.
Siehe auch hier: https://forums.unraid.net/topic/103012-wo-gibt-es-günstige-hdd-ssd/?do=findComment&comment=1264181
Wenn Du die gross genug holst, werden die lange halten.
Ich habe zwei Corsair Force MP600 (R1)...die sind auch schnell und haben eine höhere TBW als die Samsung.