Proxmox -> TrueNAS datasets einbinden sowie Link Aggregation

[ShadowDragon]

Hallo,

mich würde interessieren wie ich am besten TrueNAS datasets (SMB shares) in Proxmox einbinde. Aktuell binde ich den share "proxmox-backup" auf Datacenter-Ebene ein, um dort entsprechend die Backups meiner Container zu definieren. Da dies bedeutet, das Backups auf LXC Container Ebene stattfinden, bin ich hier natürlich auch nicht so ganz zufrieden mit, wenn ich denn nun einen Docker-Container (innerhalb des LXC-Containers) updaten muss und im Falle eines Fehlers dadurch alle anderen Docker-Container auch wiederherstellen muss indem der ganze LXC-Container wiederhergestellt wird.

Dann habe ich auf Ebene von meiner einen Proxmox-Node in deren /etc/fstab Datei weitere SMB-Shares eingebunden, welche dann via bindmounts an den LXC-Container und von da via bindmount in den docker-Container gehen.

Das Problem des gesamten Setups ist allerdings, egal ob die Shares via /etc/fstab oder die shares via dem Datacenter in der WebUI:
Sobald TrueNAS wegen z.B. Updates neustarten muss, sind diese in Proxmox nicht mehr erreichbar, bis ich Proxmox auch neustarte.
Was ich eigentlich will ist, dass ich TrueNAS aktualisieren kann ohne auch meine Proxmox-Instanz neustarten zu müssen.

----

Unabhängig davon hätte ich noch eine weitere Frage: Wie lässt sich bei Proxmox Link Aggregation mit LACP einrichten, so dass die Bandbreite zwischen allen LXC-Containern shared ist. Wenn aktuell mehrere Clients den selben LXC-Container zeitgleich anfragen, bekommen alle nur eine Verbindung von 1 Gbit/Anzahl der Clients pro Sekunde, obwohl der Server 2x1Gbit-LAN hat.
Bei TrueNAS bekommt dagegen bei 2 Clients jeder exakt 1 Gbit via Link Aggregation mit LACP.

 

[martinallnet]

Samba ist hier auch sicher nicht das richtige Protokoll, zum Einbinden unter Linux in z. B. Proxmox würde ich eher iSCSI (auf Blockebene) oder NFS vorziehen.

 

[0x8100]

Wie lässt sich bei Proxmox Link Aggregation mit LACP einrichten, so dass die Bandbreite zwischen allen LXC-Containern shared ist.

auto bond0
iface bond0 inet manual
        bond-slaves eno12399np0 eno12409np1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
        mtu 9000

damit wird der traffic nicht nur anhand der mac auf einen der links im bond verteilt sondern auch anhand von informationen aus layer 3+4. siehe z.b. https://www.thomas-krenn.com/de/wiki/Link_Aggregation_Lastverteilungs-Algorithmen#layer3.2B4

 

[ShadowDragon]

Samba ist hier auch sicher nicht das richtige Protokoll, zum Einbinden unter Linux in z. B. Proxmox würde ich eher iSCSI (auf Blockebene) oder NFS vorziehen.

Ich hatte mich damals für Samba entschieden, weil ich auf einigen Geräten noch Windows installiert hatte und somit der Zugriff auf einige der Shares leichter war, wenn ich z.B. zusätzliche Daten für die Anwendungen rüber schieben will.
Zusätzlich dazu kam noch der Sicherheitsaspekt hinzu. Da ich damals keine VLAN fähiges Gerät (mittlerweile ist mein Switch VLAN-fähig) im Haus hatte, erschien mir Samba wesentlich simpler, indem es einfach via Passwort vor unbefugtem Zugriff geschützt ist statt sich mit Dingen wie Kerberos rumzuschlagen.

Wenn es natürlich irgendwelche signifikaten Vorteile hat und ich das ganze vor unbefugten Zugriff absichern kann, kann ich dies natürlich ändern. Von iSCSI habe ich aber soweit noch nichts gehört. Nur von NFS/Samba.

auto bond0
iface bond0 inet manual
        bond-slaves eno12399np0 eno12409np1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
        mtu 9000

damit wird der traffic nicht nur anhand der mac auf einen der links im bond verteilt sondern auch anhand von informationen aus layer 3+4. siehe z.b. https://www.thomas-krenn.com/de/wiki/Link_Aggregation_Lastverteilungs-Algorithmen#layer3.2B4

Also mit dieser Konfiguration von layer3+4 zeigt mir iperf immer noch an, das bei 2 Clients jeder die halbe Bandbreite von einem Interface bekommt.

 

[martinallnet]

Von iSCSI habe ich aber soweit noch nichts gehört. Nur von NFS/Samba.

Da kann man eher ganze Felstplattenimages oder Datenträger einbinden, das arbeitet auf Blockebene, nicht auf File-Ebene.
Der Client kann sich den Datenträger somit auch selbst partitionieren und formatieren.

 

[ShadowDragon]

Da kann man eher ganze Felstplattenimages oder Datenträger einbinden, das arbeitet auf Blockebene, nicht auf File-Ebene.
Der Client kann sich den Datenträger somit auch selbst partitionieren und formatieren.

Ah. Ja, so viel braucht Proxmox dann doch nicht, vor allem da auf der Festplatte noch andere Datasets drauf sind, wie private und so.

 

[snaxilian]

Sobald TrueNAS wegen z.B. Updates neustarten muss, sind diese in Proxmox nicht mehr erreichbar, bis ich Proxmox auch neustarte.

Hach immer diese Windows-Denke, dass man irgendwelche Server neustarten muss^^
Ursache des Problems ist: Solche gemounteten Freigaben werden als verfügbar angesehen, es erfolgt also keine automatische Verfügbarkeitsprüfung die ggf. die Shares (erneut) einbindet.
Ein "mount -a" oder "mount -o remount $source $mountpoint" sollte ausreichen.

Was ich eigentlich will ist, dass ich TrueNAS aktualisieren kann ohne auch meine Proxmox-Instanz neustarten zu müssen.

Dann musst du die Shares hochverfügbar bereit stellen, sodass ein Reboot keine Serviceunterbrechung zur Folge hat.
Alternativ kannst dir auch ein Script zurecht fummeln was die Verfügbarkeit der Shares prüft und wenn diese weg waren und dann wieder da sind, ein erneutes einbinden triggert.

da auf der Festplatte noch andere Datasets drauf sind, wie private und so.

Verständnisfehler. Du gibst bei iSCSI nicht ganze Festplatten des Storage-Servers frei sondern du kannst auf dem Storage-Server ein virtuelles Laufwerk erzeugen und dieses bekommt dann ein anderer Server (Proxmox in dem Fall) zur Verfügung gestellt. Für den konsumierenden Server sieht das dann aus wie eine lokale Festplatte die man partitionieren kann.

Also mit dieser Konfiguration von layer3+4 zeigt mir iperf immer noch an, das bei 2 Clients jeder die halbe Bandbreite von einem Interface bekommt.

Unterstützt denn auch dein Switch die verwendeten hash algorithms auf Layer3+4? Welche Parameter bei iperf verwendest du? Bisher ist es schwer, dein genaues Setup nachzuvollziehen, da zu viele Unbekannte im Spiel sind.

Wenn aktuell mehrere Clients den selben LXC-Container zeitgleich anfragen, bekommen alle nur eine Verbindung von 1 Gbit/Anzahl der Clients pro Sekunde, obwohl der Server 2x1Gbit-LAN hat.

Die Bridge an der die LXCs hängen, hat nach außen aber schon das bond-interface und nicht ggf. noch eins der einzelnen 1 GBit/s NICs?

 

[ShadowDragon]

Ursache des Problems ist: Solche gemounteten Freigaben werden als verfügbar angesehen, es erfolgt also keine automatische Verfügbarkeitsprüfung die ggf. die Shares (erneut) einbindet.

Das ist eigentlich das, was ich bei Network-Shares erwartet hatte, dass der die automatisch auf Verfügbarkeit prüft und dann entsprechend mountet.

Ein "mount -a" oder "mount -o remount $source $mountpoint" sollte ausreichen.

Interessant. Diese Befehle waren mir unbekannt (es ist aber auch ultra selten das ich mal was via terminal mounte). Leider reichen diese Befehle nicht aus.

Weder mit "mount -a" noch mit folgendem Befehl

mount -o remount //XXX.XXX.XXX.XXX/app-data /mnt/pve/app-data

sind die Daten wieder für die Anwendung verfügbar.
Diese Shares sind via /etc/fstab auf der Proxmox-Node selbst gemounted.

//XXX.XXX.XXX.XXX/app-data /mnt/pve/app-data cifs ro,relatime,vers=3.0,cache=strict,_netdev,nofail,credentials=/etc/samba/credentials/share,uid=101000,noforceuid,gid=101000,file_mode=0755,dir_mode=0755,nounix 0 0

In den LXC Container sind diese dann anschließend via einem Mount-Point im Webinterface gemountet und von dort aus unter "volumes" in einer docker-compose file.

Zusätzlich dazu gibt es noch einen Share für Backups, welcher im Webinterface auf der Datacenter gemountet ist. (Das tolle Datacenter aus 1 Node ^^)

Dann musst du die Shares hochverfügbar bereit stellen, sodass ein Reboot keine Serviceunterbrechung zur Folge hat.

Dies dürfte mit exakt einem TrueNAS System recht schwierig umsetzbar sein, da TrueNAS nach Updates automatisch neustartet (genauso wie Proxmox nach Updates vom Kernel auch nen reboot will). Generell habe ich halt nur 1 TrueNAS System und 1 Proxmox-System. Weitere Server gibt es nicht.

Verständnisfehler. Du gibst bei iSCSI nicht ganze Festplatten des Storage-Servers frei sondern du kannst auf dem Storage-Server ein virtuelles Laufwerk erzeugen

Ah, das hört sich interessant an. Aber ich denke mal, es wäre dann nicht möglich mal eben Daten vom PC auf den Server zu schieben? Aktuell mounte ich hin und wieder die datasets vom NAS, um Daten rüberzuschieben. Da die selben datasets auch in Proxmox gemountet sind, erhält der Server somit direkt die neuen Daten.

Unterstützt denn auch dein Switch die verwendeten hash algorithms auf Layer3+4?

Das ist eine gute Frage. Ich weiß, dass dieser Link-Aggregation beherrscht. Der TP-Link JetStream TL-SG2218 - V1 versorgt hier alle LAN-Geräte (inklusive Server) mit Internet.

Welche Parameter bei iperf verwendest du?

Das wären die folgenden zwei Befehle (Server / Client):

iperf -s
iperf -c XXX.XXX.XXX.XXX -p 5001 -P -t 60
iperf -c XXX.XXX.XXX.XXX -p 5001 -P -t 60

Mit diesen Befehlen habe ich das ganze sowohl unter TrueNAS (wo es geklappt hat) als auch unter Proxmox getestet. Dabei habe ich mit 2 Clients versucht auf den Server zuzugreifen.

Bisher ist es schwer, dein genaues Setup nachzuvollziehen, da zu viele Unbekannte im Spiel sind.

Welche Infos werden noch benötigt?

 

[snaxilian]

Das ist eigentlich das, was ich bei Network-Shares erwartet hatte, dass der die automatisch auf Verfügbarkeit prüft und dann entsprechend mountet.

Irrglaube wie du jetzt gelernt hast. Leute tendieren dazu, an viel zu vielen Stellen irgendwelche Selbstheilungskräfte und Automatismen zu vermuten. Wichtigste Lektion die du jetzt mitnehmen solltest: Stelle keine Vermutungen an sondern überprüfe deine Annahmen. Entweder lesen der Doku, Manpages, etc. oder durch ausprobieren.

Zum erneuten einbinden: Du warst aber schon per SSH auf dem Proxmox-Node angemeldet und hast die Befehle entweder per voran gestelltem sudo oder als root ausgeführt, oder?

LXC Container sind diese dann anschließend via einem Mount-Point im Webinterface gemountet und von dort aus unter "volumes" in einer docker-compose file.

Von hinten durch die Brust ins Auge... Überlege doch mal, ob du da nicht noch mehr Komplexität rein bringen kannst.</ironie>
Also warum so dermaßen kompliziert? Komplexität ist der Feind ist die zweite Lektion.
Du kannst direkt SMB Shares bzw. Verzeichnisse auf SMB Shares als Volume bei Docker verwenden: https://docs.docker.com/storage/volumes/#create-cifssamba-volumes

Weitere Server gibt es nicht.

Ja dann musst du halt die Tatsache akzeptieren, dass du Dienste eben nicht hochverfügbar haben kannst.

Aber ich denke mal, es wäre dann nicht möglich mal eben Daten vom PC auf den Server zu schieben?

Technisch ist das zwar möglich aber iSCSI ist hier nicht sinnvoll bei deinen Anforderungen. Bleib bei SMB oder NFS wenn du von mehreren Systemen parallel auf die Daten zugreifen willst.

iperf -c XXX.XXX.XXX.XXX -p 5001 -P -t 60

Hinter -P müsste noch eine Zahl für die Anzahl der parallelen Verbindungen, zumindest laut Doku.

Noch etwas: Die eingestellte bond-xmit-hash-policy bedeutet wie Daten übertragen werden sollen, also ausgehend vom jeweiligen System. Eingehende Verteilung macht der Switch, die Daten fließen im iperf Test ja von den Clients zum Switch und weiter zum Server.
LACP kann zwar die Verbindungen verteilen aber das Zauberwort lautet "kann", es ist keine Garantie.

 

[ShadowDragon]

Zum erneuten einbinden: Du warst aber schon per SSH auf dem Proxmox-Node angemeldet und hast die Befehle entweder per voran gestelltem sudo oder als root ausgeführt, oder?

Jo, via root.

Du kannst direkt SMB Shares bzw. Verzeichnisse auf SMB Shares als Volume bei Docker verwenden: https://docs.docker.com/storage/volumes/#create-cifssamba-volumes

Oh, interessant. Das ist mir neu. Das komplizierte Setup entstand auch daher, weil ich dies nicht wusste.

LACP kann zwar die Verbindungen verteilen aber das Zauberwort lautet "kann", es ist keine Garantie.

Ich war hier davon ausgegangen, wenn ich 2 Clients nutze und dann mit iperf eine Verbindung zum selben Server starte, dass LACP dann die Verbindung teilen wird, damit beide Clients die maximale Datenrate erhalten. Und bei TrueNAS, wo ich LACP als erstes eingerichtet habe, hat es auch funktioniert (und funktioniert immer noch). Also bei TrueNAS wird der iperf traffic gesplittet.

 

[snaxilian]

Das komplizierte Setup entstand auch daher, weil ich dies nicht wusste.

Ja.. so ist das wenn man blind drauf los frickelt und nicht in die Doku schaut. Aber keine Sorge, das geht auch Leuten so, die so einen Kram beruflich machen und sich für kompetent halten und ja, trifft mich genauso.

Ich war hier davon ausgegangen [...]

Wichtigste Lektion die du jetzt mitnehmen solltest: Stelle keine Vermutungen an sondern überprüfe deine Annahmen.

Die Funktionsweise von LACP und der xmit_hash_policy ist ausreichend im Internet erklärt und basiert in der Regel auf diversen XORs, Hashberechnungen und Modulos aber das bedeutet eben auch, dass mehrere parallele Verbindungen im schlechtesten Fall dennoch über das gleiche physikalische Interface gehen.

Du kannst theoretisch noch andere bonding modes durchprobieren. Manche erfordern passende Switch-Config (so wie bei 802.3ad/LACP) und nicht jeder Switch unterstützt alle Modi.
Oder du gehst weg von Redundanz per Layer 2/3 und machst dies per Applikation. SMB kann ab v3 Multichannel und auch NFS kann ab v4 mit parallelNFS über mehrere NICs skalieren. Setzt voraus, dass dies bei den Clients UND dem Server korrekt implementiert wurde und entsprechend vom Admin, also dir, konfiguriert wurde.
Aber: Diese Mechanismen wurden nicht für so kleine Umgebungen konzipiert wie sie manche Menschen zuhause haben sondern eher im klassischen Server- bzw. Datacenterbereich. Da haben Server dann 2+ 10G Interfaces und es greifen eine zweistellige Anzahl anderer Server oder Clients auf Dienste zu und da spielt es dann eine untergeordnete Rolle wenn zwei Clients über das gleiche Interface rein kommen weil im Schnitt trotzdem ausreichend gut die Last verteilt wird.

 

[ShadowDragon]

Zum erneuten einbinden: Du warst aber schon per SSH auf dem Proxmox-Node angemeldet und hast die Befehle entweder per voran gestelltem sudo oder als root ausgeführt, oder?

Nach weiterem Research:
Die von dir genannten Optionen wie

mount -a

funktionieren nicht. Wieso kann ich nicht sagen.

Ein kurzer check ergibt:

# pvesm status
unable to activate storage 'proxmox-backup' - directory '/mnt/pve/proxmox-backup' does not exist or is unreachable

Führe ich allerdings diese beiden Befehle nacheinander aus, dann funktioniert es wieder:

umount -f -a -t cifs -l
mount -t cifs

Dies lösst aber nur das Problem mit dem SMB Mount, welcher über das Webinterface gemountet wurde. Aber die anderen sollen eh im Optimalfall nach Docker umziehen. Ist dir hier zufällig bekannt, wie ich diese "volumes" in einer docker-compose file definiere ohne das Passwort in der Datei ablegen zu müssen?
Da "Secrets" möchte ich natürlich nicht in meiner Git-Repo haben, aber der einzige mir bekannte Weg setzt docker-swarm vorraus.

 

[snaxilian]

Ist dir hier zufällig bekannt, wie ich diese "volumes" in einer docker-compose file definiere ohne das Passwort in der Datei ablegen zu müssen?

Ich habe mal in einem Projekt folgendes Setup gesehen:
Credentials in Ansible Vault und das Docker-Deployment war in einem Ansible Playbook, Versionsnummern in entsprechenden variable-files aber da war Ansible usw. schon da, war also kein Mehraufwand.

In einer privaten, nicht-öffentlichen Umgebung wo eine einzelne Person auf den Server kommt, kann man auch Credentials in eine Datei packen mMn. Owner auf nur den einzelnen Nutzer setzen und Permissions auf 400.