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 erwarten 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 natürlich kaum. Ich bevorzuge allerdings OMV in einer VM. Hat auch ein recht intuitives Web-Interface und bietet eben noch Dienste wie z.B. rsync ootb.

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. Sonst habe ich womöglich Probleme mit Kernel A auf Host A und mit Kernel B auf Host B zu tun.

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 eine ZweitopenwrtVM mit Verweis auf das FailoverGW gestartet.
Das Modem selbst lässt sich kaum elegant virtualisieren. Leider gibt es stumpfe Modems so gut wie gar nicht mehr. Sind alles nur noch Router, die man in einen Modemmodus versetzen kann und trotzdem sinnlos Strom verballern.

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. Dann ist natürlich eher kostspieliges direktes Failover zwischen Internetzugängen statt Schnell&Schmutzig-Lösungen netzwerkintern nötig. Anektdote am Rande: Telekom vermietet solche "Lösungen" seit zig Jahren, aber ich habe bis Heute noch nie eine zufriedenstellend funktionierende Lösung von denen geliefert bekommen.

 

[Johannes S]

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

Da gelten halt die gleichen Einwände wie bei TrueNAS. Ich nehme halt einen LXC, weil ich darüber ZFS auf Proxmox-Ebene für die Verwaltung nutzen kann und die Datasets dann an den samba-Server durchreichen.

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 eine ZweitopenwrtVM mit Verweis auf das FailoverGW gestartet.

Und beide können das gleiche Modem nutzen? Wie? Kein Trollen, ernsthaftes Interesse, weil ich auch am Überlegen bin, ob und wie ich die Firewall hochverfügbar kriege, aktuell tendiere ich zur Perspektive "ist die sense down, habe ich eh kein Internet, dann ist der Rest auch egal"

 

[TErxleben]

Da gelten halt die gleichen Einwände wie bei TrueNAS. Ich nehme halt einen LXC, weil ich darüber ZFS auf Proxmox-Ebene für die Verwaltung nutzen kann und die Datasets dann an den samba-Server durchreichen.

Sozusagen ZFS innerhalb eines Containers auf ext4 Basis des PVE?

Und beide können das gleiche Modem nutzen? Wie? Kein Trollen, ernsthaftes Interesse, weil ich auch am Überlegen bin, ob und wie ich die Firewall hochverfügbar kriege, aktuell tendiere ich zur Perspektive "ist die sense down, habe ich eh kein Internet, dann ist der Rest auch egal"

Tun sie ja nicht. Zwei physische GWs. Zwei OpenWRTs mit gleicher IP, die nie gleichzeitig aktiv sind, und nur auf unterschiedlich GWs verweisen. Fällt der StandardWRT aus, wird die VM deaktiviert und die andere OpenWRT-VM gestartet. Schon kriegen alle Clients gar nicht mehr mit, wer nun eigentlich die Daten weiterleitet. Im schlechtesten Fall gibt es eine Minute Humpelei.

 

[Johannes S]

Sozusagen ZFS innerhalb eines Containers auf ext4 Basis des PVE?

Nein, ich nutze im Host bereits zfs.

Tun sie ja nicht. Zwei physische GWs. Zwei OpenWRTs mit gleicher IP, die nie gleichzeitig aktiv sind, und nur auf unterschiedlich GWs verweisen. Fällt der StandardWRT aus, wird die VM deaktiviert und die andere OpenWRT-VM gestartet. Schon kriegen alle Clients gar nicht mehr mit, wer nun eigentlich die Daten weiterleitet. Im schlechtesten Fall gibt es eine Minute Humpelei.

Ok, so macht es Sinn, danke Müsste man da nicht sogar mit keepalived oder carp ( für opnsense ) die Minute wegoptimieren können?

 

[TErxleben]

Nein, ich nutze im Host bereits zfs.

Ist in meinen Augen auch die vernünftigste Lösung. Allerdings hast du den ZFS-Overhead in jeder VM und jedem Container. In VMs, in denen explizit ZFS angelegt wird, sogar doppelt. Darum habe ich bei ZFS immer noch leichte Bauchschmerzen.

Ok, so macht es Sinn, danke Müsste man da nicht sogar mit keepalived oder carp ( für opnsense ) die Minute wegoptimieren können?

Kann man, dann leidet man aber irgendwann unter "flapping". In meinen Umgebungen lohnt der zusätzliche nicht unerhebliche Aufwand aber nicht. Nahtloses Failover bekommt ja selbst ein Provider innerhalb seines eigenen Netzes nicht hin (siehe mein Beispiel Telekom). Da bin ich sehr pessimistisch, wie es z.B. bei Hauptprovider Telekom mit Failoverprovider Vodafone funktionieren soll. Dann ist im Zweifel ein Telefongespräch eben unterbrochen.
Um providerübergreifen mit Telefonie arbeiten zu können, musst du mindestens einen dritten Anbieter ins Boot holen, der deine SIP-Accounts hostet.

 

[Tobi26]

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

Dein Mountpoint läuft ja auch nicht in einer subdisk sondern direkt auf einem Verzeichnis/Dataset oder?
Bekommt man so nicht die Themen mit den Zugriffsrechten und dem ID-Mapping?

Grüße

 

[Tobi26]

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.

Das sieht nach dem aus was ich machen sollte/wollte


Ich hab jetzt mal testweise auf meinem ZFS-Pool rpool-data mit "zfs create rpool-data/media" ein Dataset erstellt.
Aber wie gehts von da an weiter?
Sorry ich hab leider beim suchen nix vernünftiges gefunden...
Danke schonmal