HDD Storage Verwaltung Strategie

[crally]

Hallo zusammen,

ich habe vor ca. 2 Jahren meinen ersten Proxmox Server aufgesetzt um zu lernen. Mittlerweile ist er gewachsen und ich mache so ziemlich alles mit dem Server.
D.h. auch alle meine Daten sind dort abgelegt und können von jedem Gerät genutzt werden.
Ich denke aber, dass ich das nicht so clever gemacht habe bzw. zu umständlich und mir dadurch auch Bremsen eingebaut habe.
Da ich nun einen neuen Server bekomme, will ich nochmal von Grund auf alles neu machen und dann hoffentlich ein paar Jahre damit zufrieden sein. Dabei brauch ich Hilfe bei der Entscheidung wie ich meine Datenfestplatten verwalte.

Aktuell ist es so:
2x 500GB im Hardware Raid 1 für Proxmox OS und VM's/CT's
6x 1TB am Raid-Controller im JBOD Mode direkt an Proxmox. Proxmox macht daraus ein RAIDZ bestehend aus 3 Gruppen zu je 2 Platten. Effektiv also ca. 2,7TB Speicher. Habe damals irgendwo gelesen, dass das so die "sicherste" Methode sei.
Jedenfalls werden diese 2,7TB komplett einer OMV VM zugewiesen. Im OMV hab ich das dann als Ext4 formatiert und von dort dann Gruppenberechtigungen und SMB Freigaben erstellt. Auch der Nextcloud Container bindet dann den Datenspeicher via SMB vom OMV ein.
Irgendwie wirkt das aber z.T. alles sehr träge.

Im neuen Server werden 2x4TB HDD als Datenspeicher verbaut werden. Jetzt frage ich mich nur, wie ich das am besten anlege. Am liebsten hätte ich natürlich, dass der Datenspeicher von allen anderen VM's und CT's genutzt werden kann, aber auch von allen PC's/Handys im Netzwerk.
Allerdings hab ich jetzt viel gelesen, dass von einer virtualisierten NAS wie OMV oder TrueNAS eilt. abgeraten wird. Dort habe ich allerdings eine schöne Oberfläche um Rechte zu vergeben.

Was wäre da wohl die beste Methode?
Platten komplett durchreichen und alles von der VM managen?
Platten von Proxmox managen lassen und irgendeine Management-Software direkt auf dem Host installieren?

Was wäre da ein guter "Way to Go"?

Bin für alles dankbar

Edit:
Backup der Daten habe ich dann auch bisher via OMV und einer USB-HDD gemacht. Für das Backup der VM's/CT's habe ich wiederum in Proxmox den Speicher vom OMV via SMB eingebunden. Also ein ziemliches hin und Her....

 

[foxpalace]

Hi - zuerst - hoffentlich verwendest du im neuen Server kein RAID mehr und nutzt einen HBA - das dankt dir dann das ZFS - desweiteren what the hell is OMV - mach eine normale VM und lerne Samba

 

[crally]

Danke für die Antwort,

OMV wäre OpenMediaVault. Das nutze ich derzeit aufgrund des GUI. Das macht es einfach Übersichtlicher.

Für Proxmox und die VM's werde ich zwei Intel DC S3710 400GB Platten nutzen. Die wollte ich dann auch mit ZFS nutzen. Denke, die sollten dann gut mit der hohen Schreiblast fertig werden.

Ich habe halt irgendwie Bauchschmerzen, wenn ich direkt auf dem Host-System die Datenplatten anlege und von dort aus meine Freigaben erstelle.
Deshalb wollte ich ja auch eine VM nutzen. Der Einfachheit wegen, dann halt eine Software mit GUI, mit der ich dann gleich noch ein paar Dienste/Protokolle mehr verwalten kann.
Wie auch immer...

Also dein Rat wäre, die Datenplatten mit Proxmox in ein Mirrored ZFS zu packen und das daraus entstehende Storage an eine VM weiterzureichen und von dort aus die Freigaben zu erstellen?
So habe ich es ja quasi aktuell.

 

[foxpalace]

jupp - hier ein samba Fileserver - die SSDs sind lokal am Proxmox

 

[crally]

so sieht das bei mir aktuell auch aus.
Du verwaltest die Freigaben dann rein über die Konsole, korrekt?
Hast du da nen Tip für eine gute GUI-Alternative?
Hatte da mal was von webmin o.ä. gehört, aber das hat dann wohl auch direkt root-rechte und soll nicht so sicher sein.

 

[Dunuin]

OMV kannst du auch gut mit lokalem ZFS Storage benutzen. Musst du halt ein OMV LXC statt einer VM machen. Dann kannst du den Mountpoint eines ZFS Pools/Datasets per bind-mount in den LXC durchreichen und dort dann die WebUI von OMV nutzen um diesen durchgereichten Ordner dann als NFS/SMB Share bereitzustellen.

So wie das foxpalace macht sollte es mehr Overhead geben:
Physisches Laufwerke -> ZFS -> Dataset -> Imagedatei -> qcow2 -> virtio Virtualisierung -> Dateisystem -> Dateien

Anstatt da einfach das Dataset per bind-mount in den OMV LXC zu nutzen:
Phyische Laufwerke -> ZFS -> Dataset -> Dateien

 

[foxpalace]

ich nutze ja kein OMV - ich habe dort ein Samba am Start und verwalte über Konsole - jupp

 

[Dunuin]

Ging ja auch nicht um das OMV sondern wie du deine Daten zum SMB Server bringst. Jeder Zwischenschritt steigert exponentiell den Overhead. Das mit doppeltem CoW über zusätzliches qcow2, zusätzliches Dateisystem (ext4 oder NTFS oder was du da nimmst) und zusätzliche Virtualisierung wäre vermeidbar und ein simpler Samba Server würde auch ohne all das dazwischen prima funktionieren.

 

[Aquator]

OMV kannst du auch gut mit lokalem ZFS Storage benutzen. Musst du halt ein OMV LXC statt einer VM machen. Dann kannst du den Mountpoint eines ZFS Pools/Datasets per bind-mount in den LXC durchreichen und dort dann die WebUI von OMV nutzen um diesen durchgereichten Ordner dann als NFS/SMB Share bereitzustellen.

Das würde mich auch interessiere. Also wie man OMV in einem LXC erstellt und wie man Dataset direkt durchreicht.
Habe es bisher auch nur so, dass OMV als VM läuft und ich eine zweite VM-Disk für den Storage eingehangen habe die ich dann unter OMV als NFS freigebe.

 

[Dunuin]

Für den OMV LXC nimmt man einfach den normalen Debian 10 LXC und lässt dort das OMV Install Script drüberlaufen. Schon hat man ein OMV LXC. Ist jetzt mit PVE7 nur etwas nervig, weil man mit Debian 11 ja nun immer das Nesting-Feature aktivieren sollte und man Nesting wegen der Sicherheit eigentlich nicht nutzen möchte, wenn der LXC privilegiert ist. Dann sollte man also den OMV LXC als unprivilegierten LXC mit Nesting erstellen, aber dann muss man sich mit dem User-Remapping herumschlagen, damit man Lese/Schreibrechte auf den durchgereichten bind-mount bekommt. Sonst hat ja nicht mal root im LXC die Rechte auf den durchgereichten Ordner zugreifen zu dürfen, da der root im LXC ja nicht der echte root ist, sondern nur ein weiterer unprivilegierter Nutzer.

 

[Aquator]

Ok danke. Werde ich mal ausprobieren.

 

[foxpalace]

Ging ja auch nicht um das OMV sondern wie du deine Daten zum SMB Server bringst. Jeder Zwischenschritt steigert exponentiell den Overhead. Das mit doppeltem CoW über zusätzliches qcow2, zusätzliches Dateisystem (ext4 oder NTFS oder was du da nimmst) und zusätzliche Virtualisierung wäre vermeidbar und ein simpler Samba Server würde auch ohne all das dazwischen prima funktionieren.

ja, da hast du recht, aber ich prügel mich nicht mehr weiter durch die Container, da nehme ich lieber bissl Overhead in kauf und dafür sauberes VM. Altbacken, ich weiß, aber angenehm zu verwalten. Dementsprechend passe ich die Hardware an. Container sind immer suspekt!

 

[crally]

@Dunuin
Vielen Dank für die ausführlichen Antworten. Klingt jedenfalls plausibel für mich.

Was spricht für/gegen eine VM, an die die HDD's durchgereicht werden und? Also das ZFS von der VM managen zu lassen....

 

[Dunuin]

@Dunuin
Vielen Dank für die ausführlichen Antworten. Klingt jedenfalls plausibel für mich.

Was spricht für/gegen eine VM, an die die HDD's durchgereicht werden und? Also das ZFS von der VM managen zu lassen....

Ein Problem ist meist schon einmal das Durchreichen selbst. Richtiges physisches Durchreichen geht nur bei NVMe SSDs. Oder man müsste den kompletten SAS/SATA Controller per PCI Passthrough an die VM durchreichen. Meist hat man da aber nur einen davon auf dem Board der dann alle 4, 6 oder 8 SATA Ports bedient. Wenn dann aber all diese SATA Ports gemeinsam in die VM durchgereicht wären, dann hat man meist keine Möglichkeiten mehr an dem Mainboard noch seine System-Platten oder Laufwerke für den VM Storage anzuschließen (außer man nimmt USB, NVMe oder kauft gleich einen zusätzlichen PCIe HBA).
Dann gibt es noch Möchtegern-Durchreichen per qm set oder USB Passthrough, wo man aber in der VM nicht mit der echten physischen Hardware arbeitet, sondern da Emulierung/Virtualisierung dazwischen ist. Diese verursacht dann Overhead (und macht alles langsamer, besonders bei USB), sorgt mit Pech für zusätzliche Probleme und man kann nicht mehr alle Features nutzen (z.B. gibt es kein SMART im Gast und es werden standardmäßig im Gast 512B statt 4K Blockgröße genutzt, da es ja keine echte HDD/SSD ist, selbst wenn die physischen Disks mit 4K Blockgröße arbeiten).

Einer der Hauptnachteile wäre noch, dass man sich da den Speicherplatz für das NAS nicht direkt mit dem Host teilen kann. Hätte ich eine HDD im Host könnte ich da problemlos gemeinsam die Platte als VM Storage für meine VMs sowie als Dataset für meine SMB/NFS-Daten im NAS LXC nutzen. Das klappt dann alles direkt und lokal. Bei einer durchgereichten HDD in eine VM müsste ich dann erst über einen NFS/SMB Share den Speicherplatz wieder zum Host bringen. Und SMB/NFS ist echt langsam, gerade wenn man IOPS braucht.

Also richtiges Durchreichen per PCI Passthrough ist eine feine Sache. Pseudo-Durchreichen per "qm set" geht zur Not auch noch, wenn man keinen PCIe Slot mehr frei hat um einen neuen HBA anzuschließen.
Was man aber meist lassen sollte ist einfach virtuelle Disks für eine NAS VM zu verwenden. Das macht nur in wenigen Fällen Sinn, z.B. wenn man sein NAS hochverfügbar haben möchte und dann immer das ganze NAS inkl. allen Daten automatisch zwischen den Hosts migriert werden soll. Aber für sowas würde dann CEPH wohl eh mehr Sinn machen als da ständig TBs an virtuellen Disks hin und her zu migrieren.

Denn je mehr Dateisysteme und Abstraktionsebenen man da verschachtelt, desto übler wird der Overhead. Sagen wir z.B. mal ich habe eine physische 10TB HDD im Host. Aus dieser erstelle ich einen ZFS pool. Dann erstelle ich eine VM mit einer virtuellen Disk, was dann auf dem ZFS pool ein Zvol erzeugt. In dem Gast installiere ich mir dann ein TrueNAS was die virtuelle Disk benutzt um noch einen ZFS Pool zu erstellen. Auf diesem zweiten Pool erstelle ich mir dann noch ein Zvol was ich mit ext4 formatiere. Sieht dann also so aus:
physische 10TB HDD -> ZFS -> Zvol -> virtio -> virtuelle disk -> ZFS -> Zvol -> ext4 -> Dateien

Jedes Dateisystem hat Overhead. Bei ext4 habe ich bei 4K Sync Writes z.B. eine Write Amplification von Faktor 5 gemessen. Für jeden 1GB den ich auf eine ext4-Partition schreibe werden dann 5GB (5*1GB) geschrieben. Danach haben wir das ZFS im Gast. Sagen wir mal ZFS sorgt für eine Write Amplification von Faktor 10. Dann werden die 5GB vom ext4-Dateisystem zu 50GB (10*5*1GB) die auf die virtuelle Disk geschrieben werden müssen. Dann hat die Virtio Virtualisierung aber auch noch Overhead. Sagen wir mal das wären Faktor 1,1. Dann wären es schon 55GB (1,1*10*5*1GB). Dann haben wir nochmal das ZFS auf dem Host selbst mit wieder Faktor 10 Write Amplification. Dann sind es schon 550GB (10*1,1*10*5*1GB) die auf die physische HDD geschrieben werden müssen, nur weil man 1GB auf die ext4-Partition im Gast schreiben will. Die HDD kann nicht zaubern und hat ihre Limits wie schnell sie Lesen/Schreiben kann. Wenn sie also 550x so viel schreiben muss, dann geht sie auch 550x so schnell kaputt und schafft nur 1/550-stel der Performance.
Das üble hierbei ist das sich die Write Amplification multipliziert und nicht addiert. Man hat also ein exponentielles Wachstum und kleine unnötige zusätzliche Schritte können sich massiv am Endergebnis auswirken.

Hätte ich mein NAS einfach in einem LXC mit lokalem Dataset gehabt hätte es so ausgesehen:
physische 10TB HDD -> ZFS -> Dataset -> Bind-mount nach LXC -> Daten

Dann hätte ich einfach nur einmal die Faktor 10 Write Amplification von ZFS gehabt. Dann würde 1GB schreiben nur 10GB und nicht 550GB an Writes erzeugen und das NAS wäre 55x schneller.

Sind jetzt etwas extreme Beispiele mit 4K Sync Writes, weil die so eine extrem hohe Write Amplification erzeugen, aber das sollte dann gut darstellen, warum man unnötige Umwege vermeiden und keine Dateisysteme verschachteln sollte.

Und bei verschachtelten ZFSs darf man den RAM nicht vergessen. Faustformel ist ja 4GB + 1GB RAM je 1 TB Rohkapazität. Bei einer 10TB HDD sollte man dem ZFS also 14GB RAM geben. Jetzt hat man aber 10TB ZFS auf dem Host und die selben 10TB nochmal im ZFS im Gast. Beide haben ihren eigenen ARC also muss ich dem Host 14GB RAM für ZFS resiervieren und ich muss der VM zusätzliche 14GB RAM zuteilen. Dann verliere ich also 28 statt 14GB RAM um die 10TB HDD nutzen zu können.
Und dann sollte man ja einen ZFS Pool wegen CoW nie mehr als 80% füllen, da er sonst fragmentiert und langsam wird. Von den 10TB auf dem Host wären dann für den Gast nur 8TB nutzbar. Macht man im Gast nochmal ZFS würden von den 8TB dann wieder 20% wegfallen und man hätte nur noch 6,4 TB über. Also kurz...besser kein ZFS verschachteln.

 

[Aquator]

Hätte ich mein NAS einfach in einem LXC mit lokalem Dataset gehabt hätte es so ausgesehen:
physische 10TB HDD -> ZFS -> Dataset -> Bind-mount nach LXC -> Daten

Ist das Dataset dann sowas wie das Dateisystem? Also ext4 oder z.B. in meinem Fall ein Raidz?
Dieses kann man an den LXC direkt durchreichen und dann kann das Gastsystem aus dem LXC die Daten direkt auf diesem ablegen?
Habe ich das richtig verstanden?

@crally
Ich hoffe ist ok wenn ich mit dazwischen frage

 

[Dunuin]

Ist das Dataset dann sowas wie das Dateisystem? Also ext4 oder z.B. in meinem Fall ein Raidz?

Ja. ZFS kennt 2 Dinge:
1.) Zvols: Das sind Blockdevices und die werden für alle virtuellen Disks von VMs benutzt. Diese zvols muss man sich dann erst noch partitionieren und mit einem Dateisystem der Wahl formatieren wenn man dort Dateien drauf speichern will.
2.) Datasets: Jedes Dataset ist sein eigenständiges Dateisystem und auf die schreibt man dann direkt seine Dateien. LXCs nutzen normal Datasets und keine Zvols.

Ein weitere Vorteil von Datasets ist die Blockgröße. Ein Zvol nutzt eine feste Volblocksize. Wenn man die Volblocksize z.B. auf 64K stellt, dann wird alles in 64K Blöcken geschrieben, egal wie groß oder klein die Datei ist die man speichern möchte. Will ich eine 1KB Datei auf so ein Zvol mit 64K Volblocksize speichern, dann wird diese 1KB Datei immer die vollen 64K belegen. Will ich eine 80kb Dateispeichern, dann muss ein Zvol 2x 64K speichern und nutzt dann 128K um 80kb zu speichern.
Datasets nutzen hingegen die Recordsize und diese ist nicht statisch. Nehme ich eine Recodsize von 128K dann kann ZFS seine Daten als 4K bis 128K Records schreiben. Das speichern einer 1kb Datei würde dann nur ein 4K Record speichern. Eine 80kb Datei würde ein 128K Record schreiben. Bei Datasets kann sich also ZFS an die Größe der jeweiligen Daten anpassen und verschwendet so unter Umständen weniger Platz oder wird schneller.

Dieses kann man an den LXC direkt durchreichen und dann kann das Gastsystem aus dem LXC die Daten direkt auf diesem ablegen?

Genau. Keine Virtualisierung dazwischen, kein zusätzliches Dateisystem wie ext4. Der Gast schreibt die Dateien einfach direkt ohne was dazwischen in das ZFS Dataset.

 

[Aquator]

Das klingt gut.
Wenn ich das richtig gelesen habe muss der LXC dann aber previlegiert sein, oder? Sonst kann dieser nicht auf das Dataset zugreifen?

Das Dataset wird dann ja über die configdatei des Containers als Mountpoint eingebunden.
Kann ich da aus verschiedenen Containern drauf zugreifen?

 

[Dunuin]

Das klingt gut.
Wenn ich das richtig gelesen habe muss der LXC dann aber previlegiert sein, oder? Sonst kann dieser nicht auf das Dataset zugreifen?

Es geht auch mit unprivilegierten LXCs, aber dann wird es recht nutzerunfreundlich weil man sich mehr mit den Sicherheitsfeatures (wie User-Remapping) herumschlagen bzw die teilweise manuell aushebeln muss.

Das Dataset wird dann ja über die configdatei des Containers als Mountpoint eingebunden.
Kann ich da aus verschiedenen Containern drauf zugreifen?

Genau. Ich denke das sollte eigentlich gehen. Bind-mounts machen ja Zugriff auf Dateiebene und nicht auf Blockebene und dann sollte sich das Dateisystem eigentlich darum kümmern, wer wann wie wodrauf zugreifen kann. Ist dann ja nichts anderes wie wenn sich z.B. mehrere User die gleiche formatierte Partition teilen. Statt mehreren Users hast du dann halt mehrere LXCs.

 

[Aquator]

Ok. Das klingt so als will es am Wochenende ausprobiert werden ;-)
Danke für deine Klasse erklärunge.
Ich hoffe dem Erstelle des Themas ist ebenso geholfen.

 

[foxpalace]

@Dunuin - wir reden aber hier nur von Containern, oder?