Bester Weg für Fileserver (samba)

[Tobi26]

Hi,
ich bin recht neu in Proxmox unterwegs und bräuchte mal euren Rat.
Möchte ein ZFS-Mirror an eine VM oder lcx weitergaben um darauf über Samba-Freigaben für Windows-Rechner zu erstellen.
Das ZFS Mirror errstellen habe ich soweit, ist ja kein Hexenwerk.
Der grundlegende Samba-Teil ist auch kein Problem.
Mein erster Versuch das mit einem unpreviligierten lcx zu lösen (debian + samba) scheint aber nicht ganz optimal wil ich wohl ein User-Mapping mit selben IDs auf Proxmox machen muss. Sinnvoll?
Was ändert an der Situation ein priveligierter Container?
Ist es cleverer das ganze in ein VM laufen zu lassen und auf dem ZFS-Mirror eine neue VM-Disk dafür anzulegen?

Vielleicht kann mir einer von euch da etwas Licht ins dunkel bringen was der sinnvollste Weg ist.

Danke und Grüße

 

[Impact]

Du brauchst das ID Mapping nur wenn du ein Bind Mount mit einem unprivilegierten Container benutzt. Du kannst deinem CT aber auch einen ganz normalen Mount Point geben. So mache ich es zumindestens. Wie sieht denn pct config CTID aus?

 

[Tobi26]

Hier meine config:

arch: amd64
cores: 1
features: keyctl=1,nesting=1
hostname: samba
memory: 512
mp0: rpool-data:subvol-103-disk-0,mp=/data,backup=1,size=20G
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:D8:6A:0F,ip=dhcp,type=veth
ostype: debian
rootfs: local-zfs:subvol-103-disk-0,size=8G
swap: 512
unprivileged: 1

Ich glaube mein Fehler ist, dass ich dachte "direkt" auf /rpool-data arbeiten zu können, bzw. das versucht habe...
Ich habe im ersten Versuch das so gemappt und versucht damit zu arbeiten:
mp0: /rpool-data,mp=/data

 

[micneu]

Ich persönlich würde ein NAS nicht produktiv als VM betreiben. In meinem Netzwerk setze ich dafür immer auf ein Bare-Metal-System.

 

[Tobi26]

Ich persönlich würde ein NAS nicht produktiv als VM betreiben. In meinem Netzwerk setze ich dafür immer auf ein Bare-Metal-System.

Aus welchen Gründen denn?
Ich nutze es nur zu rein privaten Zwecken. Da möchte ich nicht 5 Maschinen da stehen haben...

 

[Treptower]

nachvollziehbarer Ansatz und läuft hier seit langer Zeit (sowohl für NVMes und drehende HDDs) sehr zuverlässig - bei mir sieht der Container und der Mountpoint wie folgt aus:

arch: amd64
cmode: console
cores: 2
features: nesting=1
hostname: zfs30w
memory: 4096
mp0: /dreizig/data,mp=/mnt/data
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:37:F9:A2,ip=dhcp,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-zfs:subvol-200-disk-0,size=8G
swap: 512
tags: NAS

 

[woma]

So mache ich das im Prinzip auch.

Mit je einem ZFS-Dataset pro späterem Samba Share kann man ZFS Features ggf. sinnvoller nutzen als mit der "alles in einen Topf" Taktik.
Getrennte Snapshots von Shares, Quotas, Abfrage tatsächlich belegter Speicherplatz pro Share etc.

Der Aufwand für mehrere Mountpoints in der LXC-Konfiguration ist überschaubar.

mp1: /zfspool/eis/public,mp=/mnt/zfs4eis/public,mountoptions=noatime
mp2: /zfspool/eis/trash,mp=/mnt/zfs4eis/trash,mountoptions=noatime
mp3: /zfspool/eis/pve,mp=/mnt/zfs4eis/pve,mountoptions=noatime

root@pve-i5:~# zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zfspool             2.53T  1015G   144K  /zfspool
zfspool/eis         2.53T  1015G   139K  /zfspool/eis
zfspool/eis/public  2.14T  1015G  2.14T  /zfspool/eis/public
zfspool/eis/pve     83.5G  1015G  83.5G  /zfspool/eis/pve
zfspool/eis/trash    312G  1015G   312G  /zfspool/eis/trash

Bare-Metal TrueNAS hatte ich auch schon am Laufen als die Energiekosten noch überschaubar waren. Aber die benötigten Funktionen lassen sich auch mit ZFS auf PVE Host + Samba in LXC abbilden und es läuft dann ein Gerät weniger 24/7.

Nachteil ist, dass bei einem Backup von PVE zu "NAS Storage" die Backups von VM/CT das System nicht verlassen. Es Ist also nur ein lokales Backup auf andere Datenträger im Rechner selbst, das muss man bei der Backupstrategie bedenken.

Stichwort andere Datenträger ... NAS ist etwas langfristiges und die Daten sollen auch eine PVE-Neuinstallation überdauern. Daher für ein NAS LXC keine Mountpoints verwenden, welche die Daten dann doch wieder auf der Bootdisk von PVE abspeichern.
Ausnahme sind nur kleine virtuelle PVE Disks, die man langfristig im Backup halten kann. Diese würden beim Restore aller Gäste nach Neuinstallation wieder hergestellt, ebenso wie die i. d. R. kleinen Bootdisks der Gäste. Eine 2TB virtuelle DIsk, die ich aus dem Backupvorgang aus Platzmangel irgendwann mal ausschließen musste, ist nach dieser Prozedur futsch.
"Die einen haben es schon hinter sich und die anderen vor sich ... " Sag man in der Fliegerei über das Landen ohne ausgefahrenes Fahrwerk. So ist es auch mit dem Datenverlust bei nicht im Backup enthaltener Disk bei einem Restore.

 

[micneu]

Aus welchen Gründen denn?
Ich nutze es nur zu rein privaten Zwecken. Da möchte ich nicht 5 Maschinen da stehen haben...

Ich möchte jederzeit Zugriff auf mein NAS haben und dabei nicht von Proxmox abhängig sein.
In meiner produktiven Umgebung virtualisiere ich daher weder die Firewall noch das NAS - Testsysteme hingegen können gerne virtualisiert werden.

 

[TErxleben]

Ich möchte jederzeit Zugriff auf mein NAS haben und dabei nicht von Proxmox abhängig sein.
In meiner produktiven Umgebung virtualisiere ich daher weder die Firewall noch das NAS - Testsysteme hingegen können gerne virtualisiert werden.

Naja... Ich virtualisiere praktisch alles und habe lieber einen zweiten PVE als Failover im Einsatz, Wichtige Dienst-VMs werden so vollautomatisch bei Ausfall eines Master-Dienstes binnen 60s vom Failover-PVE zur Verfügung gestellt. Lediglich VMs deren Daten Inkonsistenzen erzeugen können, möchte ich bewusst manuell starten. So habe ich keine Probleme mit einem zusätzlichen SPOF wie NAS. Lediglich Dinge, die sich nicht sinnvoll virtualisieren lassen (Gateways, Switche, Accesspoints) sind auf Einzelgeräten redundant vorhanden.

 

[Johannes S]

Naja... Ich virtualisiere praktisch alles und habe lieber einen zweiten PVE als Failover im Einsatz, Wichtige Dienst-VMs werden so vollautomatisch bei Ausfall eines Master-Dienstes binnen 60s vom Failover-PVE zur Verfügung gestellt. Lediglich VMs deren Daten Inkonsistenzen erzeugen können, möchte ich bewusst manuell starten. So habe ich keine Probleme mit einem zusätzlichen SPOF wie NAS. Lediglich Dinge, die sich nicht sinnvoll virtualisieren lassen (Gateways, Switche, Accesspoints) sind auf Einzelgeräten redundant vorhanden.

Das Problem ist halt, dass viele Leute sich so Sachen wie TrueNAS, UnRaid oder OMV als VM aufsetzen, weil sie halt gerne eine GUI für das Einrichten ihrer Netzwerkfreigaben haben wollen, diese Systeme aber eigentlich davon ausgehen und erarten direkten Zugriff auf die Hardware zu kriegen ( siehe hier: https://www.truenas.com/community/r...guide-to-not-completely-losing-your-data.212/)

Naheliegender wäre natürlich sich eine VM oder Container mit einen Standardlinux und irgendeiner GUI (Webmin, Cockpit) als Webinterface zur Verwaltung hinzustellen, das wird aber in den einschlägigen clickbait-Videos und Blogs halt nicht empfohlen

Wenn man aber TrueNAS und CO einsetzen möchte, dann bin ich auch mittlerweile (als jemand der lange TrueNAS virtualisiert betrieben hat, bevor er zu einen Samba-Server im Container gewechselt ist) der Meinung, dass man das dann bitte auf dezidierter Hardware machen soll mit einer zweiten NAS; wo dann die Daten für den fail-over-Fall hingesynct werden.
Zum Thema "nicht sinnvoll virtualisierbar": Da würde ich im Heimnetz auch die Firewall (also pfsense/opnsense/openwrt und co) dazu zählen. Normalerweise (siehe https://forum.opnsense.org/index.php?topic=39556.0 ) will man die Firewall ja direkt am Internet (über Glasfaser- oder DSL-modem) betreiben, das beißt sich bei üblichen Heimsetups aber mit der Redundanz. Außer man macht nested-NAT, wovon ja aufgrund der damit einhergehenden größeren Komplexität eher abgeraten wird.

In einen Firmennetzwerk, wo auch der Internet-Uplink redundant ist, mag das anders aussehen

 

[TErxleben]

Das Problem ist halt, dass viele Leute sich so Sachen wie TrueNAS, UnRaid oder OMV als VM aufsetzen, weil sie halt gerne eine GUI für das Einrichten ihrer Netzwerkfreigaben haben wollen, diese Systeme aber eigentlich davon ausgehen und erarten direkten Zugriff auf die Hardware zu kriegen ( siehe hier: https://www.truenas.com/community/r...guide-to-not-completely-losing-your-data.212/)

Da frage ich mich immer warum? Performancegewinn auf Kosten von viel schwererer Kapselung? Wenn ich das letzte Yota Performance brauche, bleibt nur Baremetal. Dann will ich Netzwerkverkehr aber schon mal aussen vor lassen.

Naheliegender wäre natürlich sich eine VM oder Container mit einen Standardlinux und irgendeiner GUI (Webmin, Cockpit) als Webinterface zur Verwaltung hinzustellen, das wird aber in den einschlägigen clickbait-Videos und Blogs halt nicht empfohlen

Minimalistischer geht es kaum. Ich bevorzuge dafür OMV in einer VM. Hat auch ein recht intuitives Web-Interface.

Wenn man aber TrueNAS und CO einsetzen möchte, dann bin ich auch mittlerweile (als jemand der lange TrueNAS virtualisiert betrieben hat, bevor er zu einen Samba-Server im Container gewechselt ist) der Meinung, dass man das dann bitte auf dezidierter Hardware machen soll mit einer zweiten NAS; wo dann die Daten für den fail-over-Fall hingesynct werden.

Sehe ich auch so. Darum benutze ich eben ein NAS innerhalb einer VM statt "in" einem Container.

Zum Thema "nicht sinnvoll virtualisierbar": Da würde ich im Heimnetz auch die Firewall (also pfsense/opnsense/openwrt und co) dazu zählen. Normalerweise (siehe https://forum.opnsense.org/index.php?topic=39556.0 ) will man die Firewall ja direkt am Internet (über Glasfaser- oder DSL-modem) betreiben, das beißt sich bei üblichen Heimsetups aber mit der Redundanz. Außer man macht nested-NAT, wovon ja aufgrund der damit einhergehenden größeren Komplexität eher abgeraten wird.

OpenWRT setzte ich auch virtualisiert ein. Dieses sogar in zweifacher Ausführung, die sich mit gleicher internen IP nur durch das eingetragen GW unterscheiden. Ist GW A platt, dann wird ein ZweitopenwrtVM mit Verweis auf das FailoverGW gestartet.
Das Modem selbst lässt sich nicht virtualisieren. Leider gibt es stumpfe Modems so gut wie gar nicht mehr. Sind alles nur noch Router, die man in einen Modemmodus versetzen kann.

In einen Firmennetzwerk, wo auch der Internet-Uplink redundant ist, mag das anders aussehen

Das ist natürlich noch ein ganz anderer Koffer, der erstmal gestemmt werden will.