Umstieg von Synology auf Proxmox - Verständnisfrage

[boexler]

Hallo miteinander,

nach rund 6 Jahren darf meine DS918+ (16GB RAM / 4x12TB HDD / 2x1TB SSD Cache) nun in den Ruhestand und soll durch einen etwas professionelleren Server ersetzt werden:

• be quiet! Straight Power 12 1200W ATX 3.1
• ASUS Pro WS W680-ACE IPMI
• Lenovo DCG ThinkSystem 430-16i SAS 12Gb/s, PCIe 3.0 x8
• Kingston Server Premier UDIMM 48GB, DDR5-5600, CL46-45-45, 2RX8, ECC
• Intel Core i5-14600K, 6C+8c/20T, 3.50-5.30GHz
• Kingston FURY Renegade SSD 2TB, M.2 2280 / M-Key / PCIe 4.0 x4 - RAID1 für VMs (Windows)
• Dell 0DX4NF Intel EMC Optane P4800X 750GB U.2 NVMe PCIe 3.0 x4 Solid State Drive - RAID1 für VM/LXC Docker Host
• NVIDIA Quadro K4200

Aktuell bin ich dabei meine Daten der Synology auf mehrere kleine Festplatten zu sichern, damit ich die 4x12TB dann ebenso in den Server einbauen kann und mit der eigentlichen "Migration" beginnen kann.

Folgendes Szenario stelle ich mir vor. Auf den Optane Festplatten möchte ich zwei Docker Hosts (docker-backbone, docker-media) laufen lassen:
docker-backbone (Auszug gekürzt):

• Adguard
• Traefik
• HomeAssistant
• Paperless
• ..

docker-media (transcoding support):

• Plex
• Arr*

Auf den Optanes habe ich bereits einen ZFS-Pool vmdocker erzeugt und darin ein Dataset vmdocker/docker-backbone.
Im ZFS-Pool liegt nun der LXC-Container und mittels mp0 habe ich den docker-backbone Ordner gemapped. Dort sollen alle Daten, die der Docker-Host oder interne Docker-Container erzeugen, gespeichert werden.
Nun stellt sich mir noch die Frage, wie ich genau die 4x12TB einbinde und dann auch bequem in die verschiedenen LXC/VM mounte. Dort liegen später Filme, Fotos und die Paperless Dokumente.

In der Synology hatte ich dafür drei verschiede Ordner, die ich jeweils in den entsprechenden Docker-Container gemapped hatte.

Muss ich den "Umweg" gehen und eine VM/LXC Container mit Unraid/TrueNAS erstellen, meine 4x12TB dort initialisieren und dann per NFS mounte oder gibt es dafür einen eleganteren Weg?

Irgendwie habe ich noch einen Knoten im Kopf und finde aber auch keine passende Lösung im Netz was hier das "Best Practise" ist. NFS soll man nach meinem Verständnis vermeiden (Perfomance und ZFS wird ausgehebelt?)? Gleichzeitig möchte ich aber, dass mehrere LXCs/VMs auf die drei verschiedenen Ordner auf den 4x12TB zugreifen können.

Danke im Voraus,
bin für sämtliche Infos dankbar!

Grüße

 

[FrankList80]

Subjektive 2-cent // Apologies - aus vielen jahren "Schmerz und Tränen" kann ich nur davon abraten Storage und Compute auf einem Stück-Hardware zu betreiben. Mein Tipp: HW-Refresh des "Filers" (z.B. X86 mit OMV und 2tes Netzteil auf Cold Standby) und Compute, Compute sein lassen. 2tes Physikalisches PBS, ggf. ein zweites (off) PBS mit weekly Sync o.ä.. Viel Strom, ja, aber so sind die Files da auch wenn Compute down :/

---

[Virtualization Support for SME and NGOs | DLI Solutions ]

 

[6equj5]

Muss ich den "Umweg" gehen und eine VM/LXC Container mit Unraid/TrueNAS erstellen, meine 4x12TB dort initialisieren und dann per NFS mounte oder gibt es dafür einen eleganteren Weg?

PVE kann Kernel-NFS. Eleganter geht's net.

NFS soll man nach meinem Verständnis vermeiden (Perfomance und ZFS wird ausgehebelt)?

Manchmal hilft die Praxis. Hab diverse Tests dazu gemacht. Bind mount auf den LXC oder NFS mount im LXC macht ziemlich genau 0 Unterschied. Ist mir auch nicht klar, wo der herkommen soll.

 

[Johannes S]

Bind mount auf den LXC oder NFS mount im LXC macht ziemlich genau 0 Unterschied

Das ist so nicht ganz korrekt: Direktes mounten in einen LXC setzt voraus, dass es ein priviligerter Container ist und die will man aus Securitygründen eigentlich vermeiden:

Unprivileged Containers
Unprivileged containers use a new kernel feature called user namespaces. The root UID 0 inside the container is mapped to an unprivileged user outside the container. This means that most security issues (container escape, resource abuse, etc.) in these containers will affect a random unprivileged user, and would be a generic kernel security bug rather than an LXC issue. The LXC team thinks unprivileged containers are safe by design.

This is the default option when creating a new container.

Note If the container uses systemd as an init system, please be aware the systemd version running inside the container should be equal to or greater than 220.
Privileged Containers
Security in containers is achieved by using mandatory access control AppArmor restrictions, seccomp filters and Linux kernel namespaces. The LXC team considers this kind of container as unsafe, and they will not consider new container escape exploits to be security issues worthy of a CVE and quick fix. That’s why privileged containers should only be used in trusted environments.

https://pve.proxmox.com/wiki/Linux_Container#_security_considerations

bind mounts funktionieren dagegen auch mit unpriviligierten lxcs.

 

[boexler]

Subjektive 2-cent // Apologies - aus vielen jahren "Schmerz und Tränen" kann ich nur davon abraten Storage und Compute auf einem Stück-Hardware zu betreiben. Mein Tipp: HW-Refresh des "Filers" (z.B. X86 mit OMV und 2tes Netzteil auf Cold Standby) und Compute, Compute sein lassen. 2tes Physikalisches PBS, ggf. ein zweites (off) PBS mit weekly Sync o.ä.. Viel Strom, ja, aber so sind die Files da auch wenn Compute down :/

---

[Virtualization Support for SME and NGOs | DLI Solutions ]

Leider sind meine Resourcen endlich ;o)
Ich hatte unter Anderem geplant, die StorageBox von Hetzner für meine Backups zu verwenden. Dort könnte ich meine Dokumente und Bilder zugänglich ablegen und hätte im Fall der Fälle noch Zugriff auf meine Daten.

PVE kann Kernel-NFS. Eleganter geht's net.

Nutzt ihr dafür noch zusätzliche administrative Tools oder macht ihr alles über die "etc/exports"? Gleiches gilt für das SMB Protokoll.

Manchmal hilft die Praxis. Hab diverse Tests dazu gemacht. Bind mount auf den LXC oder NFS mount im LXC macht ziemlich genau 0 Unterschied. Ist mir auch nicht klar, wo der herkommen soll.

Hab meine ZFS-Datasets nun direkt gemounted und bin damit sehr happy.

Das ist so nicht ganz korrekt: Direktes mounten in einen LXC setzt voraus, dass es ein priviligerter Container ist und die will man aus Securitygründen eigentlich vermeiden:

Sind direktes mounten und bind mount nicht zwei verschiedene Dinge?

 

[6equj5]

Das ist so nicht ganz korrekt

Doch, schon. Ich bezog mich ja auf die immer wieder behaupteten Performanceunterschiede, welche ich nicht reproduzieren kann.

Security ist 'ne andere Baustelle. Bisher ist mir das im Homelab eher nicht so wichtig, wenn es mich behindert, was eigentlich immer der Fall ist.
Der LXC ist mit Template von Proxmox erzeugt und dann ein PBS drin installiert. Wenn da Malware drin wäre, hätte nicht nur ich ein Problem.

bind mounts funktionieren dagegen auch mit unpriviligierten lxcs.

Das geht aber nicht quer durchs Netzwerk, sondern nur vom Host aus, oder. Aber man könnte wohl den NFS-Mount auf dem Host machen und dann an den LXC weiterreichen...?

Nutzt ihr dafür noch zusätzliche administrative Tools oder macht ihr alles über die "etc/exports"? Gleiches gilt für das SMB Protokoll.

Hab fast überall Webmin drin, das macht vieles übersichtlicher. Und mausbedienbarer, ich hasse es, zu tippen.

 

[Johannes S]

Doch, schon. Ich bezog mich ja auf die immer wieder behaupteten Performanceunterschiede, welche ich nicht reproduzieren kann.

Naja, nfs ist halt ein Layer mehr zwischen dem Host und den Gästen. VMs kann man ja z.B. entweder als raw-Image in Blockspeicher (etwa zfs zvols oder lvm thick) oder auf einen Dateisystem (Directory, nfs, cifs). In beiden Fällen muss man noch für das Gastsystem ein Dateisystem erstellen, aber bei nfs/cifs/Directory hat man dann ein Dateisystem in einen Dateisystem, das kann sich in der Performance schon bemerktbar machen (hier wurde berichtet, dass auf Datenbankservern das zwischen 20% und 40% Performanceunterschied ausmachen kann). Und auch bei lxcs macht das einen Unterschied:
Reiche ich das Dataset per bind mount durch habe ich direkt den Zugriff über das Dateisystem (duh), mit nfs geht damit noch ein weiterer Layer (der Netzwerkkram von NFS) einher, den es auf einen lokalen System gar nicht braucht. Man mag das im Alltag (da eh alles auf den gleichen Host läuft) nicht unbedingt bemerken, aber ganz beiseite schieben würde ich das nicht

Mit anderen Worten: Wenn alles auf den selben Host läuft, ist NFS schlicht überflüssig für das Sharen von Dateien zwischen den lxcs, da kann man genauso gut einen gemeinsamen Ordner auf Hostebene einrichten und per bind mounts an die Container durchreichen. Bei VMs ist es etwas komplizierter, weil virtiofs (was grundsätzlich ähnliches ermöglicht wie die bind mounts bei containern) in Vergleich zu nfs oder cifs nicht sehr performant ist. Aber auch da: Kann durchaus sein, dass es im Alltag reicht.

Security ist 'ne andere Baustelle. Bisher ist mir das im Homelab eher nicht so wichtig, wenn es mich behindert, was eigentlich immer der Fall ist.

Inwieweit "behindert" dich Security? Ich finde es ja eigentlich ganz gut, dass ein potentieller Angreifer bei einen Ausbruch aus einen unpriviligierten Container nicht direkt root-Rechte hat.

Der LXC ist mit Template von Proxmox erzeugt und dann ein PBS drin installiert. Wenn da Malware drin wäre, hätte nicht nur ich ein Problem.

Gerade wenn auch andere Leute davon abhängig sind, spricht das doch für eine Installation als unprivilgierter Container oder (noch besser isoliert) als VM. Wobei man PBS eigentlich eh auf dezidierter Hardware betreiben sollte, eine VM-PBS oder LXC-PBS sehe ich höchstens als Zwischenstation (so mache ich es selbst) wo der Kram tagsüber gesichert wird, um dann nachts auf dem nur dafür eingeschalteten eigentlichen PBS gesynct zu werden.

Das geht aber nicht quer durchs Netzwerk, sondern nur vom Host aus, oder. Aber man könnte wohl den NFS-Mount auf dem Host machen und dann an den LXC weiterreichen...?

Exakt das ist best practice bei containern. Wenn man darauf plus das Gefrickel mit subuids keine Lust hat, muss man halt eine VM erstellen, die muss ja auch nicht unbedingt viel RAM fressen (meine kleinsten Debian VMs haben zwischen 512MB und 2GB RAM zugewiesen). Gerade Alpine oder ein minimales Debian sind sehr genügsam.

Hab fast überall Webmin drin, das macht vieles übersichtlicher. Und mausbedienbarer, ich hasse es, zu tippen.

Nichts für ungut, aber dann bist du bei Linuxservern falsch Und seitdem MS die powershell stärker pusht auch zunehmend unter Windows (was in meinen Augen eine gute Sache ist, Shells lassen sich nun mal besser automatisieren als das Mausgeschubse)

 

[6equj5]

Shells lassen sich nun mal besser automatisieren

Es gibt immer mehr Tools (Docker, LXC), die auch Tasks automatisieren. Find ich alles deutlich lustiger.

Wenn alles auf den selben Host läuft, ist NFS schlicht überflüssig für das Sharen von Dateien zwischen den lxcs

Das ist schon klar, hier ging es ja auch zunächst um einen Netzwerkmount in den PBS-LXC. Dann kam irgendwer von wegen Performance. Ich kann das nie nachvollziehen, ich find NFS genial. Simpel und schnell.

da kann man genauso gut einen gemeinsamen Ordner auf Hostebene einrichten und per bind mounts an die Container durchreichen.

Man verliert mit den bind mounts leider die Möglichkeit zu Snapshots. Was wirklich lästig ist, denn beim Backup macht's der PVE ja auch:

INFO: including mount point rootfs ('/') in backup
INFO: excluding bind mount point mp0 ('/mnt/mn5hd.data') from backup (not a volume)
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'

Inwieweit "behindert" dich Security?

Man kann halt vieles nicht so hopplahopp mal eben machen ohne root.

Wobei man PBS eigentlich eh auf dezidierter Hardware betreiben sollte, eine VM-PBS oder LXC-PBS sehe ich höchstens als Zwischenstation

Na ja ... das geniale an der Virtualisierung ist ja, daß man so VMs / Container ganz simpel komplett irgendwohin sichern kann und auch ebenso simpel wieder herholt. Wo soll den der Vorteil von einem Bare Metal PBS sein? Daß man den in einem Panzerschrank verschließen kann? Ich bin hier im Home Lab und wichtige Daten sind sowieso irgendwo in der Cloud noch mal.

 

[Johannes S]

Es gibt immer mehr Tools (Docker, LXC), die auch Tasks automatisieren. Find ich alles deutlich lustiger.

Die wiederum auf CLI-Tools basieren, außerdem frage ich mich gerade, wie du mit docker oder lxc Tasks automatisiert, die sind ja eher ein Deploymentmechanismus. Tools wie puppet oder ansible greifen da schon eher, aber auch die rufen am Ende des Tages nur Shellbefehle auf.

Das ist schon klar, hier ging es ja auch zunächst um einen Netzwerkmount in den PBS-LXC.

Nee, ursprünglich ging es jemanden darum, wie er seine Snyology durch einen PVE-Server ersetzt, also ein Szenario wo sämtliche Daten und Dienste auf der gleichen Kiste laufen. Da braucht es keine Netzwerkfreigaben für Container, da man die Verzeichnisse eben direkt durchreichen kann.

Man verliert mit den bind mounts leider die Möglichkeit zu Snapshots. Was wirklich lästig ist, denn beim Backup macht's der PVE ja auch:

Naja (siehe https://forum.proxmox.com/threads/why-do-bind-mounts-prevent-snapshots.85495/ ) die Entwickler argumentieren halt, dass sie vermeiden möchten, dass User sich darüber wundern, dass "stillschweigend" bestimmte in der Konfiguration erwähnte mounts nicht mitgesnapshotet werden. Kann man bewerten wie man will, als workaround kann man aber auch händisch (also ohne den PVE-eigenen Mechanismus) die mounts durchreichen, dann stört das beim Snapshoten nicht. Oder (da ja lxcs typischerweise sehr schnell gestoppt und gestartet sind) man macht die lxc-Backups direkt im stop-Modus. VMs haben das Problem übrigens nicht.

Man kann halt vieles nicht so hopplahopp mal eben machen ohne root.

Das ist ja auch der Sinn der Sache, damit man eben nicht als normaler User sich Sachen kaputt macht, bzw. ein freidrehender Dienst einen nicht das ganze System kaputt macht. "Behindern" würde ich das nicht nennen, vor allem weil der Defaultuser bei PVE ja eh root ist.

Ich kann das nie nachvollziehen, ich find NFS genial. Simpel und schnell.

Naja, simpel ist es nur, wenn man ignoriert, dass es trivial hackbar ist, sofern man nicht Kerberos aktiviert. Mit Kerberos ist es dann nicht mehr simpel:
https://talks.mrmcd.net/2024/talk/7RR38D/

Nicht falsch verstehen: Ich nutze NFS selbst ohne Kerberos, aber man sollte sich halt bewusst machen, dass eine NFS-Freigabe im Grunde für alle Geräte im Netz ohne weiteres les- und schreibbar ist, solange man kein Kerberos nutzt.

Na ja ... das geniale an der Virtualisierung ist ja, daß man so VMs / Container ganz simpel komplett irgendwohin sichern kann und auch ebenso simpel wieder herholt. Wo soll den der Vorteil von einem Bare Metal PBS sein? Daß man den in einem Panzerschrank verschließen kann? Ich bin hier im Home Lab und wichtige Daten sind sowieso irgendwo in der Cloud noch mal.

Dass man für die Wiederherstellung nicht erst einen laufenden PVE braucht und dass die Backups nicht auf der gleichen Kiste sind wie die Produktionsdaten. Im Worstcase sind bei einen Schaden dann nämlich beide weg.