Welche Möglichkeiten einen RAID aufzusetzen gibt es bei Proxmox?

[Renegade33]

Moin,
da mein Hauptpost anscheinend zu umfangreich ist, mal nur eine Teilfrage:
Welche Arten von RAID gibt es unter Proxmox und was sind die Vor-Nachteile des jeweiligen?

Explizit habe ich ein GIGABYTE C246M-WU4. Auf diesem sind 2 Western Digital Red SN700 NVMe NAS SSD - 1DWPD 1TB, M.2 (WDS100T1R0C) installiert und 8 SATA Ports.

Es sollen 2-3 VMs drauf laufen. Meine Idee war, die M2-SSD in einen RAID1 zu packen und dort die VMs laufen zu lassen. Die SATA-Platten sollen als NAS fungieren. Dazu hätte ich eine VM mit passender SW (unraid, Nextcloud,...) aufgesetzt und die Platten dann an die VM durchgereicht, damit die mit diesen ein RAID5 als NAS aufbaut.

Oder habe ich da eine völlig sinnfreie Konfiguration im Kopf?

mfG
Rene?

 

[cwt]

Die NVME sind dann sowohl für PVE OS als auch VMs? Bitte (wie immer) beachten, dass man mit solchen Laufwerken nicht viel Freude hat (beim Einsatz von ZFS). Consumer drives ohne PLP und wenig cache sterben recht schnell und die Performance geht in den Keller. Ob Du a) alle 8 S-ATA ports beim Einsatz von 2x NVME nutzen kannst, müsstest Du nachlesen. Und b) kann es gut sein, dass Du diese nicht direkt durchreichen kannst, wenn der storage controller für NVME & S-ATA identisch ist (meistens bei solchen Boards der Fall). Prinzipiell kannst Du das so machen.

 

[Renegade33]

Was wäre denn eine Alternative zu ZFS? Darum hab ich ja hier nach den verschiedenen Möglichkeiten für RAID gefragt.
also zu a). Das geht. Es sind alle 8 SATA-Ports nutzbar.
zu b) Woran seh ich das? Laut Anleitung ist mir das nicht ganz klar. Da steht folgendes dabei.


Ich könnte auch eine SATA-SSD mit reinhängen, auf welcher ich das OS laufen lasse. Es müssen nicht alle 8 SATA Ports für das NAS hergenommen werden. Da reichen mir 6 Stück für.

PLP wäre jetzt nicht so das Problem. Der Server hängt direkt an einer USV.

 

[UdoB]

Was wäre denn eine Alternative zu ZFS?

Bcachefs. Aber leider erst in einigen Jahren.

Ernsthaft: sofern man Grundregeln (Redundanz, ECC) beachtet liefert ZFS: 100% Datenintegrität = keine "kaputten" Daten, niemals!; integrierte Kompression (bei mir im Schnitt Faktor 1.58); beliebig viele und technisch "billige" Snapshots; integre Replikation; mit einigem Zusatzaufwand integrierte Verschlüsselung; und einiges mehr. (Auswendige Liste, da fehlt bestimmt etwas.)

Mir bekannte Alternativen bieten jeweils nur manches davon.

Allein der erste Punkt (Integrität) und kontinuierliche Verfügbarkeit ist für mich das Wichtigste. Natürlich gibt es je nach konkret vorhandenen Gegebenheiten auch Nachteile. Für mich sind die alle nebensächlich.


Choose your Poison ;-)

PS: sagte ich schon, dass ich ein ZFS-Fan bin?

 

[Renegade33]

@UdoB ich hab bis jetzt auch viel gutes über ZFS gehört und bei Unraid zum Beispiel, wünscht es sich die Community seid Jahren.
Allerdings habe ich jetzt auch schon öfters gehört, wie ja @cwt schreibt, dass ZFS Probleme mit Consumer-Platten macht, wegen des zu geringen Caches.

Meine Prioritäten liegen auf Verfügbarkeit/Integrität(gehört für mich zusammen, da ohne Integrität die korrekten Daten auch nicht verfügbar sind) und Geschwindigkeit, da ein lahmer NAS Speicher oder DC/LDAP Server einfach schrecklich anstrengend ist zum Arbeiten im Netz.

Darum ja meine Frage, wie es am besten ist, die Platten aufzuteilen.
Beide M2 als RAID1 für OS und VM oder nur eine und die andere als Cache einbinden oder OS und VM auf verschiedene Platten,...

Bei meinem bisherigem Windoof System war halt 2 Platten im RAID1 für OS und VM und die HDD waren über ein HW RAID5 als Netzlaufwerke eingebunden. Und 1x wöchentlich hab ich ein Backup der wichtigen Laufwerke dann aufs Band gezogen.
So kenn ich es halt, aber heißt ja noch lang nicht, dass es eine gute Lösung war.

 

[UdoB]

Viele Wege führen nach Bielefeld.

Ich würde zwei hochwertige M.2 NVMe nehmen (deine beiden will ich jetzt nicht recherchieren), spiegeln, und dann sowohl das OS UND auch die VMs dort ablegen.

Die Blechplatten können dann ein beliebig langsames RaidZx bilden oder eben auch komplett zu einer VM delegiert werden. Dies wiederum würde ich aber nur dann machen, wenn der Controller per PCI-Passthrough zu greifen ist und durchgreicht werden kann. (Ich persönlich habe bisher vom Passthrough die Finger gelassen - es verkompliziert die ganze Konstruktion in jedem Fall und erzeugt neue potentielle Fehlerquellen. Viele Nutzer haben gute Erfahrungen damit gemacht - andere nicht.)

Und die 8 SATA Ports führen fast immer zur Frage der Topologie. Was ist dir wichtiger: Performance oder Platzverlust? Wenn du Performance haben willst kommen nur striped Mirrors in Frage. Wenn der Platzverlust minimiert werden soll, kommt RaidZ1/2/3 in Frage. (Z1 ist aber definitiv nicht empfehlenswert, nicht bei diesen Größen.)

Vier gespiegelte Paare liefern vierfache IOPS (im Vergleich zu einer einzelnen Platte). Ein RaidZ2 mit 8 Platten nur einfache IOPS.

Have fun!

 

[UdoB]

Noch 'ne Idee: opfere zwei der 8 Blechplatten und ersetze sie durch hochwertige ("Enterprise"-) SSDs mit PLP (Power Loss Protection). Als Größe sollten einige hundert GB genügen. Nutze diese beiden als "Special Device" in dem Blechpool. Dort landen dann alle Metadaten und auch (sehr) kleine "echte" Daten.

Das ist meist nützlicher als ein (readonly-) Cache-Device und/oder ein (SYNC-write-only) SLOG dranzuflanschen.

Wie gesagt: es gibt viele Möglichkeiten...

 

[cwt]

Thema Datenintegrität: dann ist ZFS immer die 1. Wahl. Allerdings empfiehlt sich dann nicht nur der Einsatz von Enterprise SSDs/NVME (alleine wegen der Langlebigkeit, ZFS schreibt wesentlich mehr als andere Systeme), sondern auch ECC RAM. Mittlerweile gibt es erschwingliche (kleinere) Boards, die Consumer/Desktop CPUs mit ECC RAM unterstützen. Und preislich tut sich das jetzt nicht sooo viel.

Das Thema SSD/NVME mit PLP hat nicht nur etwas mit Datenverlust bei Stromausfall zu tun. Der Cache dieser Laufwerke ist wesentlich größer als bei Consumer Laufwerken. Insbesondere bei ZFS merkt man den Unterschied bei Last dann deutlich. Der Cache der Consumer Laufwerke läuft dann schnell voll und die Performance dropped.

Wenn man PVE nur als „Spielwiese“ zum Testen nutzt, kann man auch Consumer Hardware nehmen. Aber wenn einem Datenintegrität wichtig ist (auch im Bereich SOHO), sollte man zu „guter“ Hardware greifen. HDDs als Datengrab mit wenig Zugriffen sind ok, nur nicht als OS oder bspw. Datenbankspeicher. Wie @UdoB schon schrieb: 2 anständige SSDs als Cache drive (mirrored) schaffen nochmal Performance.

 

[Renegade33]

Für ECC bräuchte ich eine andere CPU und neuen RAM. Es soll ja immer noch ein System im privaten Umfeld sein. Darum habe ich mich gegen den ECC entschieden. Da wäre mir der Preis um einige hundert Euro nach oben gegangen. Also die M2 haben einen Cache von 1GB/TB und sind ja extra für NAS bzw. vielschreib Operationen ausgelegt. Die Frage ist nur, reichen Sie für ZFS oder sollte ich eher auf ein anderes RAID-System zurückgreifen mit meiner Hardware.

 

[UdoB]

Wie @UdoB schon schrieb: 2 anständige SSDs als Cache drive (mirrored) schaffen nochmal Performance.

Ich bin da mal etwas penibel: ich bevorzuge ein "Special Device" welches Metadaten und kleine Dateien aufnimmt. Das ist kein Cache. Ein Cache-Device bringt insbesondere bei einem Datengrab rein gar nix: die Daten müssen ja erstmal in den Cache geladen werden = ein Beschleunigungseffekt tritt nur beim mehrfachen und zeitnahem lesen ein.

Ähnliche Spitzfindigkeiten gelten für das oft falsch als "Schreibcache" betitelte SLOG: dieses wird NUR bei synchronen Schreibvorgängen verwendet. Wenn man nicht gerade mit spezieller Software oder Datenbanken arbeitet, sind aber 95 % der Schreibvorgänge asynchron!

Ja, ich bin ein Erbsenzähler, aber solche Unterschiede sind durchaus relevant...

Viele Grüße

 

[UdoB]

Für ECC bräuchte ich eine andere CPU und neuen RAM.

ECC ist empfehlenswert, aber nicht zwingend erforderlich. Mit ECC ist "nur" eine weitere Fehlerquelle ausgeschlossen und bei ein-Bit-Fehlern kann zunächst einfach weitergearbeitet werden. (Wie bei einem degraded Raid.)

@home hatte ich jahrelang Xeon-Systeme mit ECC Ram. Aus Kostengründen bin ich nun auf Miniatursysteme umgestiegen, die nur wenig Leistung verbraten und... kein ECC unterstützen. Schade und ärgerlich, aber je nach eigener Einschätzung tolerierbar.

Beruflich kommen aber nur "richtige" Server zum Einsatz und dann ist ein Verzicht auf ECC einfach kein Thema.

((
Ich bin seit Jahrzehnten im Rechnerbereich aktiv. Ich habe etliche Platten sterben sehen, viele schleichend. Das bedeutet, dass Daten, die vor Jahren geschrieben wurden, einfach "heute" nicht mehr lesbar waren. Das kann mit ZFS, etwas Redundanz plus gelegentlichem Scrubbing einfach nicht mehr passieren.
Natürlich hat auch Arbeitsspeicher (ohne ECC) schon versagt. Aber dann stürzte meist der Rechner einfach ab. Ich kann für mich selber keinen Fall belegen, in dem Daten beim Wegschreiben wegen eines Ramfehlers beschädigt wurden, ohne das dies auf dem Bildschirm ebenfalls erkennbar war.
Man sollte an dieser Stelle vielleicht auch nochmal erwähnen, dass normaler Arbeitsspeicher ohne ECC üblicherweise eine Single-Bit-Errorerkennung pro Byte hat, realisiert als einfaches Parity-Bit. Nur korrigieren kann dieser Mechanismus halt nix: das Bios registriert dies zwar, kann aber nix tun außer einen Reset auszulösen.
))

Viele Grüße

 

[Renegade33]

ECC ist empfehlenswert, aber nicht zwingend erforderlich. Mit ECC ist "nur" eine weitere Fehlerquelle ausgeschlossen und bei ein-Bit-Fehlern kann zunächst einfach weitergearbeitet werden. (Wie bei einem degraded Raid.)

@home hatte ich jahrelang Xeon-Systeme mit ECC Ram. Aus Kostengründen bin ich nun auf Miniatursysteme umgestiegen, die nur wenig Leistung verbraten und... kein ECC unterstützen. Schade und ärgerlich, aber je nach eigener Einschätzung tolerierbar.

Beruflich kommen aber nur "richtige" Server zum Einsatz und dann ist ein Verzicht auf ECC einfach kein Thema.

Sehe ich genauso. ECC hab ich im alten System, aber für privat eigentlich nicht notwendig. Vor allem, wenn du das meiste im Datengrab hältst.

Will eben jetzt auch auf ein Minisystem runter, um eben Strom zu sparen. 30-40W gegen 150W machen bei 24/7 doch was aus auf Dauer.

Geschäftlich würde ich auch keinesfalls auf ECC verzichten. Und falls mal irgendwann ein gutes Angebot steht, rüste ich auch Privat um, aber da sehe ich es eher als "nice to have" an.

Ich bin seit Jahrzehnten im Rechnerbereich aktiv. Ich habe etliche Platten sterben sehen, viele schleichend. Das bedeutet, dass Daten, die vor Jahren geschrieben wurden, einfach "heute" nicht mehr lesbar waren. Das kann mit ZFS, etwas Redundanz plus gelegentlichem Scrubbing einfach nicht mehr passieren.

Dumme Frage, was ist Scrubbing?
Ich dachte mir halt RAID plus Backup sollte sicher genug sein für privat.

Ich sag mal Datentechnich sind wichtig ein paar Dokumente (xlsx, docx, pdf,...) und für meine Damen noch ihre Fotos. Alles, was Video, Musik,... ist, überleb ich, wenn es doch mal korrupte Daten gibt.

Also würdest du mir raten, die 2 M2 als ZFS RAID1 zu betreiben, 2 SSD als "Special Device" und 6 HDD als Datengrab anzulegen?

 

[UdoB]

Dumme Frage, was ist Scrubbing?

Das ist keine dumme Frage. Beim Scrubbing werden alle belegten Blöcke eines ZFS Pools eingelesen, deren Checksumme neu berechnet und mit der alten, auf den Platten gespeicherten, verglichen. Natürlich müssen diese Checksummen unverändert identisch sein.

Falls die Platte beim Lesen andere Daten geliefert hat (ohne(!) eine Fehlermeldung zu generieren), dann nennt man das "Bitrot". Ohne extensives Checksumming gibt es keine Möglichkeit, so etwas zu erkennen. Dann ist die Worddatei oder das gelandene Foto "irgendwie kaputt", ohne dass die Ursache klar ist. ZFS verhindert das wirksam.

Also würdest du mir raten, die 2 M2 als ZFS RAID1 zu betreiben, 2 SSD als "Special Device" und 6 HDD als Datengrab anzulegen?

Korrekt. "Raid1" nennt man hier "Mirror". (Manchmal ist die Nomenklatur wichtig, hier nicht unbedingt.) Und der zweite Halbsatz bildet einen Pool mit zwei vdevs: einmal das Special Device als Mirror und zweitens die Blechplatten in einem RaidZ2-vdev. Zum Besispiel...

Viele Grüße

 

[Renegade33]

@UdoB also bei der Installation kann man ja schon ZFS Raidz 0-3 auswählen. Da dann erstmal Raidz1 wählen und die beiden M2 Platten reinpacken. Dann kann ich ja schonmal den pve installieren und eine VM. Läuft ja alles auf dem Raidz1. Die anderen Platten kann ich ja nachträglich dazu packen oder?
Welches Programm würdest du denn für SMB Freigaben mit AD Berechtigungen wählen? Ursprünglich war da bei mir Unraid geplant, weil dies alle nicht benötigten Platten abschalten kann. Somit doch ein merklicher Stromsparfaktor.

 

[UdoB]

Da dann erstmal Raidz1 wählen und die beiden M2 Platten reinpacken.

MIRROR!

Die anderen Platten kann ich ja nachträglich dazu packen oder?

Ja, sicher. Das soll ja auch ein separater Pool werden.

Welches Programm würdest du denn für SMB Freigaben mit AD Berechtigungen wählen?

https://github.com/bashclub/zamba-lxc-toolbox --> "zmb-standalone"

Samba AD, inkl. ZFS-Snapshots, die als "Vorherige Versionen" (heißt das noch so?) im Windows File Explorer greifbar sind; als LXC = ohne Tricks wie "pass-through" in eine VM hinein. Die Verwaltung klappt dann auch per klassischen RSAT bzw. den üblichen Windows Tools.

Die Autoren sitzen in Deutschland.

Viel Erfolg

Disclaimer: auch für einen Samba-Fileserver gibt es etliche brauchbare Lösungen...

 

[news]

Als neuen Pool kann man einfach einen ZFS RaidZ1 mit 3 Platten und Ausfall von max 1 Platte anlegen.
Hat man 4 oder mehr Platten, dann können die als ZFS RaidZ2 angelegt werden.
ZFS RaidZ2 mit 4x HDD
Und immer an das Special Device denken!
2x - 3x SSD über eine ZFS Mirror bringt mehr, als keine Special Device.

Man merkt das besonders beim ls -la . oder tree .

Aber das Special Device kann nicht mehr entfernt werden, aber z.B. als ZFS Mirror mit 2x SSDs angelegt werden und anschließend kann man noch eine weitere SSD attachen. Dann erhält man z.B. ZFS Mirror mit 3x SSDs.
Die Lesezugriffe werden auch dann intelligent über alle SSDs verteilt.

 

[Renegade33]

@UdoB also wenn ich das richtig verstehe ist die LXC toolbox eine script Sammlung mit vorgefertigten scripten, welche mir einen Container erstellt in dem der Server läuft, der mir die Freigabe shared, aber die Daten eigentlich plain auf dem node liegt oder?

Kann das Tool auch mehrere shares in einem Container anlegen? Dazu hab ich jetzt leider nichts gefunden.
Wie läuft das dann mit der Abschaltung der Platten bei Nichtbenutzung?

Der DC läuft aber extra. Da hätte ich eine UCS Domain überlegt. (Bin auch gerne für andere Ideen offen. Nur die Domain würde ich gerne über eine grafische Oberfläche verwalten können.

 

[UdoB]

also wenn ich das richtig verstehe ist die LXC toolbox eine script Sammlung mit vorgefertigten scripten, welche mir einen Container erstellt in dem der Server läuft, der mir die Freigabe shared, aber die Daten eigentlich plain auf dem node liegt oder?

Korrekt.

Kann das Tool auch mehrere shares in einem Container anlegen?

Ich habe das Script genau einmal genutzt, und das ist mindestens drei Jahre her. Ich habe weitere Shares in separaten Datasets einfach parallel so eingehängt, wie es die initial eingerichtete Freigabe zeigte. Das Script ist wertvoll weil es einen guten Rahmen liefert und man sich die Details der smb.conf nicht aus den Fingern saugen muss. Das mit ZFS-Snapshot --> Windows: "Vorgängerversionen wiederherstellen" hatte ich jedenfalls irgendwann schonmal erfolglos versucht, zu konfigurieren. Damals war ich gescheitert. Mit diesem Script funktionierte das einfach...

Der DC läuft aber extra. Da hätte ich eine UCS Domain überlegt.

Gute Idee. Ist bei mir @home genau so

(Ich habe da noch ein Problem mit Zugriffsrechten bestimmter Dateien des Thunderbird unter Linux, die ich nicht begreife, aber das ist eher ein punktuelles Problem.)

Auch wenn ich mich wiederhole: es gibt etliche gute Varianten, so etwas zu konstruieren. Einfach mal probieren..., sofern man keinen Support kauft, kostet es ja nix

Viel Erfolg!

 

[Renegade33]

Ich habe das Script genau einmal genutzt, und das ist mindestens drei Jahre her. Ich habe weitere Shares in separaten Datasets einfach parallel so eingehängt, wie es die initial eingerichtete Freigabe zeigte. Das Script ist wertvoll weil es einen guten Rahmen liefert und man sich die Details der smb.conf nicht aus den Fingern saugen muss. Das mit ZFS-Snapshot --> Windows: "Vorgängerversionen wiederherstellen" hatte ich jedenfalls irgendwann schonmal erfolglos versucht, zu konfigurieren. Damals war ich gescheitert. Mit diesem Script funktionierte das einfach...

Also hast du mehrere Container mit dem Script kreiert?

Gute Idee. Ist bei mir @home genau so

Verwaltest du die AD vom ucs direkt über die Webgui oder über ein Windows-Tool?

Wie funktioniert das Special Device genau? Ist das dann ein Teil des HDD Verbundes im Raidz2 oder etwas eigenes? Müssen beim Raidz und Special Device alle Platten jeweils gleich grioß sein oder gehen da auch unterschiedliche?

 

[UdoB]

Also hast du mehrere Container mit dem Script kreiert?

Nein. (Nicht in diesem Kontext.)

Ich habe einfach weitere Datasets/Mountpoints für den Container angelegt. Und danach manuell die smb.conf editiert.

Verwaltest du die AD vom ucs direkt über die Webgui oder über ein Windows-Tool?

Ich verwende das WebGui des UCS. Windows verwende ich ziemlich selten.

Wie funktioniert das Special Device genau?

Das ist bestimmt schon an irgendeiner anderen Stelle besser dokumeniert als ich das hier wiederholen könnte. Grundsätzlich landen Metadaten und sehr kleine Dateien auf diesem vdev.

Ist das dann ein Teil des HDD Verbundes im Raidz2

Ja! Im Gegensatz zu CACHE/SLOG kann man ein Special Device NICHT wieder entfernen.

Müssen beim Raidz und Special Device alle Platten jeweils gleich grioß sein oder gehen da auch unterschiedliche?

Vollkommen egal. Sinnvollerweise sind die Platten innerhalb eines vdevs gleich groß: wenn sie unterschiedlich groß sind, "wirkt" die kleinere Größe Empfehlungen für die Größe eines Special Device kann ich nicht belegen. (Mein einziges ist wesentlich kleiner als 5% vom Blechvolumen.)

Viele Grüße