Erfahrungen mit Netzwerkkonfiguration (Bonds, Bridges) gefragt

[Naumburger-Bauunion]

Guten Tag,

man sieht an meinen Posts, dass ich neu hier bin - man möge mir verzeihen.

Mein Wissensstand : Ich denke, die grundsätzlichen Dinge zu Proxmox sind mir geläufig. Ich habe einen einzelnen Host produktiv am laufen - neben ESXI-Hosts .
Ich möchte alle ESXIs entfernen und gegen ein Proxmox Cluster austauschen.
Dazu habe ich im Vorfeld aus 4 recht schwachen alten Servern ein Cluster gebaut, um das Zusammenspiel mit Cluster, HA und gemeinsamen iSCSI-Storage zu erforschen.

So - jetzt habe ich zwei neue Hosts, beide mit aktuellem Proxmox und Subscription aufgesetzt und ein Cluster erzeugt.
HA geht noch nicht, dazu braucht es ja einen dritten Host - der läuft aber grad noch mit ESXi - weshalb ich den schnell "leeren" würde.

Meine Frage bezieht sich auf die Netzwerkverbindungen.

Folgende Konfiguration habe ich mir vorgestellt (pro Host) :

LAN1, 10GBit - Managementschnittstelle für Weboberfläche, IP-Netz A
LAN2+3, 2x10GBit Bond1 - Schnittstelle zu Cluster, IP-Netz B - < Linux Bridge dafür gemacht
LAN4+5, 2x10GBit Bond2 - Schnittstelle zu iSCSI, IP-Netz C -> Linux Bridge dafür gemacht
LAN6+7, 2x10GBit Bond3 - Schnittstelle VMnet, keine IP-Adresse zugewiesen - Bridge gemacht, für die VMs ins Domänennetz

Die Bonds sind allesamt als LACP(802.3ad) Hash layer3+4 erzeugt. Der Switch (Netgear M4350xxx) spielt mit.

Nun habe ich beim testen zufällig bemerkt, dass VMs auf Host A auf einmal keine Verbindung in Domänennetz hinkriegen - auch kein DHCP o.ä., auf HOST B aber schon.
Sogar wenn ich eine VM von Host A auf Host B migriere, hat diese auf einmal eine normale Verbindung.

Den nicht funktionierenden Host habe ich neu gestartet, die Kabelverbindungen geprüft und Bond und Bridge neu erstellt - nix.

Nun die Frage, welche Erfahrungen Ihr so habt.

Macht vielleicht eine andere Bond-Art Sinn, womöglich eine, wo man den Switch nicht explizit konfigurieren muss ?
Muss ich da starke Einbußen hinnehmen bezüglich Durchsatz und Latenz ?

Ich brauche quasi sehr schnell reagierende Maschinen - da sind bis zu 20 Server drauf, teilweise auch mit Datenbanken (Exchange).

Deshalb habe ich sämtliche Verbindungen mit 2x10GBit LWL Karten (als LAG) hergestellt und mir eingebildet, damit eine hohe Geschwindigkeit zu erzielen.

So, viel Text - ich hoffe auf gute Tips.

Vielen Dank !

Der Mike

 

[mikee]

Moin,

prüfe noch mal die LACP-Konfiguration an allen teilnehmenden Ports und Devices ob identisch. Ggf. mal L2+L3 probieren. Ich erinnere mich düster, dass ich mit L3+L4 Probleme hatte.

m.

 

[Dunuin]

So - jetzt habe ich zwei neue Hosts, beide mit aktuellem Proxmox und Subscription aufgesetzt und ein Cluster erzeugt.
HA geht noch nicht, dazu braucht es ja einen dritten Host - der läuft aber grad noch mit ESXi - weshalb ich den schnell "leeren" würde.

Cluster braucht immer 3 Nodes, nicht nur bei HA. Hast du nur 2 Nodes darfst du keinen von beiden ausschalten/neustarten weil der andere dann auch nicht mehr funktioniert (PMXCFS geht read-only und lässt keine Änderungen mehr zu und Dinge wie VMs starten wird fehlschlagen), da dir dann Quorum fehlt. Und neustarten sollte man die Nodes ja regelmäßig, damit auch neue QEMU- und Kernel-Versionen benutzt werden. Sprich, 2-Node-cluster sollte man nie produktiv betrieben.

 

[Naumburger-Bauunion]

Moin,

prüfe noch mal die LACP-Konfiguration an allen teilnehmenden Ports und Devices ob identisch. Ggf. mal L2+L3 probieren. Ich erinnere mich düster, dass ich mit L3+L4 Probleme hatte.

m.

Hi, also ich habe was rausgefunden - schaue aber morgen nochmal drüber.
Ich war komplett auf dem Holzweg. Folgendes ist passiert :

Die Hosts und das Cluster waren komplett funktionstüchtig konfiguriert.
Dann habe ich die Subscription eingetragen und die ganzen anfallenden Updates incl. Reboot durchgeführt.
Zuerst ist es mir nicht aufgefallen bzw. ich kann es immer noch nicht glauben :
Es wurden die Netzwerkanschlüsse umbenannt !! Also z.B. von eno1 auf eno1fs0 usw.
Damit waren meine Bonds quasi funktionsunfähig und ich musste alle löschen und mit den neuen Bezeichnungen neu erstellen.
Auf einmal funktionierte wieder alles - incl. den LAGs mit LACP.

Allerdings habe ich ziemlich lange gebraucht, bis mir das überhaupt aufgefallen ist - es gab keine Fehleranzeigen oder so.

Also wenn das die Regel bei Kernelupdates ist, dann gute Nacht Marie !

 

[Naumburger-Bauunion]

Cluster braucht immer 3 Nodes, nicht nur bei HA. Hast du nur 2 Nodes darfst du keinen von beiden ausschalten/neustarten weil der andere dann auch nicht mehr funktioniert (PMXCFS geht read-only und lässt keine Änderungen mehr zu und Dinge wie VMs starten wird fehlschlagen), da dir dann Quorum fehlt. Und neustarten sollte man die Nodes ja regelmäßig, damit auch neue QEMU- und Kernel-Versionen benutzt werden. Sprich, 2-Node-cluster sollte man nie produktiv betrieben.

Hmm, da habe ich aber anderes gelesen - bzw. getestet. Cluster mit 2 Nodes läuft bei meinem Testnetzwerk ganz normal. Auch Migrationen (manuell) sowie Wartungsmode ON/OFF geht. Zumindest lässt es sich erstmal einrichten, was man bei HA nicht kann. Da muss zwangsläufig ein dritter Host im Cluster sein.
Aber Du hast recht - ein 2 Node Cluster soll es am Ende nicht werden. Ich habe aber momentan nur 2 zur verfügung, der dritte beherbert noch einen ESXi. Dessen VMs müssen erstmal auf einen der zwei Nodes "geparkt" werden, dann kann ich den ESXi killen und den 3. Proxmox Host draus bauen.

 

[Dunuin]

Hmm, da habe ich aber anderes gelesen - bzw. getestet. Cluster mit 2 Nodes läuft bei meinem Testnetzwerk ganz normal. Auch Migrationen (manuell) sowie Wartungsmode ON/OFF geht. Zumindest lässt es sich erstmal einrichten, was man bei HA nicht kann. Da muss zwangsläufig ein dritter Host im Cluster sein.

Ja, läuft solange beide IMMER laufen. Dann hast du ja noch 2 von 2 Votes und damit ÜBER 50% der Votes und Quorum. Ist einer von beiden warum auch immer nicht erreichbar, dann hat der verbleibende nur noch 1 von 2 Votes, damit nur 50% der Votes, Quorum fehlt und der verbleibende Node macht dicht, damit es nicht zum Split-Brain kommt. Daher will man immer mindestens 3 Nodes, dass da mit 2 von 3 Votes mit 66% weiterhin Quorum besteht, auch wenn ein Node mal nicht erreichbar ist.

 

[Falk R.]

Hi, also ich habe was rausgefunden - schaue aber morgen nochmal drüber.
Ich war komplett auf dem Holzweg. Folgendes ist passiert :

Die Hosts und das Cluster waren komplett funktionstüchtig konfiguriert.
Dann habe ich die Subscription eingetragen und die ganzen anfallenden Updates incl. Reboot durchgeführt.
Zuerst ist es mir nicht aufgefallen bzw. ich kann es immer noch nicht glauben :
Es wurden die Netzwerkanschlüsse umbenannt !! Also z.B. von eno1 auf eno1fs0 usw.
Damit waren meine Bonds quasi funktionsunfähig und ich musste alle löschen und mit den neuen Bezeichnungen neu erstellen.
Auf einmal funktionierte wieder alles - incl. den LAGs mit LACP.

Allerdings habe ich ziemlich lange gebraucht, bis mir das überhaupt aufgefallen ist - es gab keine Fehleranzeigen oder so.

Also wenn das die Regel bei Kernelupdates ist, dann gute Nacht Marie !

Das ist nicht immer so, aber im 6.6er Kernel hat Intel neue Treiber verteilt und hält sich jetzt an die Namenskonventionen der anderen Hersteller.
Das Thema ist nicht neu und betrifft alle Linux Basierenden Systeme beim Wechsel von pre 6.6 Kernel zu 6.6 oder höher. Proxmox ist von 6.5 auf 6.8 gegangen.
Das sollte jetzt also nicht so schnell wieder vorkommen.

Zu deiner Konfiguration. Bitte niemals Bonds für iSCSI benutzen. Mache NAS Hersteller machen soetwas und läuft auch einigermassen, aber wenn man ein vernünftiges iSCSI Storage hat macht man Multipathing und da sollte man kein LAG (LACP) benutzen.

 

[Naumburger-Bauunion]

@Falk R.
Nach längerer Zeit möchte ich mich nochmal melden. Mir lässt Deine Info, niemals Bonds für iSCSI zu verwenden keine Ruhe und ich möchte Dich bitten, mir - falls das möglich ist - eine Anleitung zu geben, wie man meine Konfiguration optimieren kann. Dazu folgend erstmal die jetzige Konfiguration und dann die gewünschte.


Aktuell :

3 Hosts
Alle 3 haben folgende Netzwerkanschlüsse : 6 x 10GBit/s LC, zzgl ein oder zwei 1GBit/s für Management
Die 6 10GBit möchte ich wie folgt belegen :
bond0 = LACP aus 2 Anschlüssen = vmbr1 Linux bridge = IP 10.10.1.1/24 = Clusterschnittstelle
bond1 = LACP aus 2 Anschlüssen = vmbr2 Linux bridge = iSCSI (momentan nicht benutzt, deshalb noch keine eigene IP, würde 10.20.1.0/24 benutzen)
bond2 = LACP aus 2 Anschlüssen = vmbr3 Linux bridge = VMnet = für virtuelle Maschinen

Gewünscht :

Wenn Du nun sagst, Bonds wären für iSCSI nicht das richtige, sondern eher Multipathing, dann bräuchte ich mal eine Anleitung, wie ich das machen soll.

Also wahrscheinlich bond1 auflösen und die beiden Netzanschlüsse einzeln betreiben (IP 10.10.1.1 und 10.10.1.2).
Auf den anderen Hosts müsste das ja genauso passieren und dann die Adressen 10.10.1.3,..4 und ..5,..6 bekommen.

Der Host, auf dem iSCSI LUND und Target vorhanden sind, ist ein Synology HA Cluster.
Dort habe ich momentan 4 x 10GBit Anschlüsse zur Verfügung. Davon ist eine als Heartbeat und eine als Cluster-Schnittstelle konfiguriert. Zwei davon sind noch frei.

Ich könnte mir vorstellen, dass ich dann insgesamt 2 oder gar drei der Schnittstellen für iSCSI zur Verfügung stellen könnte. Diese hätten dann jedoch 3 IP-Adressen (da ja kein Bond mehr) - Bsp. 10.10.1.10,...11,...12

Ich kann bei Synology dem Target ein Netzwerk Bindung zuordnen (alle oder einzelne Netzanschlüsse) - in diesem Fall wohl die drei oben genannten.

So - jetzt stellt sich mir die Frage, wie ich das Ganze so konfiguriere, dass alle Hosts mit möglichst vollem Speed auf den iSCSI Host zugreifen können.

Mit Bonds überall wäre das ja kein Problem - überall eine Adresse und gut.
Wie ist es aber mit Multipathing ?

Kleines Gimmick am Rande - ich habe für Umkonfigurationen nur ein kleines (eigentlich garkein) Wartungsfenster, da das Ganze produktiv läuft....
Es müste also ohne viel Probieren konfigurierbar sein.

So, nun iist mein Roman am Ende ich hoffe, nicht zu lang.

Danke für Eure Hilfe ;-)

Update : natürlich bitte möglichst mit Weboberfläche - ich habs leider nicht so mit der Kommandozeile ;-)

 

[Falk R.]

Update : natürlich bitte möglichst mit Weboberfläche - ich habs leider nicht so mit der Kommandozeile ;-)

iSCSI mit Multipath ist beim PVE immer komplett im CLI.

Wie Synology das handhabt, weiß ich nicht, daher mal eine generelle Beispielkonfiguartion:

Server hat 2 NICS für iSCSI 192.168.1.1 und 192.168.2.1
Nic1 geht auf iSCSi Switch 1 und Nic2 geht auf iSCSi Switch 2.
Am besten kennen sich die beiden Switches gar nicht um eine echte Redundanz zu gewährleisten wenn Logische Fehler auftreten.
Storage hat 2 Controller:
Controller 1 192.168.1.11 und 192.168.2.11
Controller 2 192.168.1.12 und 192.168.2.12
Jeweils Nic1 geht auf iSCSi Switch 1 und Nic2 geht auf iSCSi Switch 2.

Damit hat der Host 4 Pfade:
192.168.1.1 - 192.168.1.11
192.168.1.1 - 192.168.1.12
192.168.2.1 - 192.168.2.11
192.168.2.1 - 192.168.2.12

So sieht ein klassiches Multipath Setup aus. Da kann ein Netzwerkport im Server, ein Switch oder auch ein Storagecontroller ausfallen.
Für ein sauberes Multipathing sollen die NICs im Server immer in getrennten Subnetzen agieren.

Jetzt zur Synology, Ich persönlich mag ein iSCSI von NAS Systemen gar nicht.
Du hast einen Rechner (NAS) der ein Raid und Dateisystem auf die Platten legt. Auf dieses Filesystem werden große Dateien angelegt, welche als iSCSI LUN exportiert werden. Im PVE nutzt man zum Glück kein extra Filesystem wie bei vSphere, aber das LVM ist auch wieder eine extra Verwaltungsschicht. in der VM kommt da drauf auch wieder ein neues Dateisystem.
Wenn NAS dann nutze ich lieber NFS, wo der Host das NAS Dateisystem nativ nutzen kann und dann gehen auch Snapshots und andere qemu Features. Das Optimum für ein NAS wäre NFS 4.1 was auch Multipathing kann, aber auch über einen Bond supportet ist.

Der iSCSI Umbau völlig ohne Downtime ist zwar möglich aber etwas Tricky.
Wenn du genug Platz hast würde ich das Netzwerk im Bond lassen und aus dem NAS ein NFS Share an die PVE geben und dann die VMs migrieren.

 

[Naumburger-Bauunion]

Danke für die ausführliche Beschreibung. Ich sehe, ich war bisher etwas auf dem Holzweg.
zu NFS - hatte ich schon einmal probiert und festgestellt, dass es hierbei sehr viel langsamer geht.
Warum weiß ich nicht - vielleicht liegts an Synology...

In der hiesigen Konfiguration muss ich (leider) alles über je einen Switch am physischen Standort der Hosts anschließen.
Das sollte funktionell hoffentlich kein Problem sein - außer, wenn ein Switch ausfällt.


Ich habe zusätzlich mal ChatGPT gefragt und nachfolgende Anleitung (Auszug) erhalten :

Dabei stellen sich mir Fragen, da ich bisher angenommen habe, dass Storages und Volumegruppen immer schön
auf dem Cluster (Rechenzentrum (Clustername) und nicht auf den einzelnen Hosts erzeugt werden

Die Step by Step Anleitung klingt plausibel, jedoch habe ich Schwierigkeiten, die für mich passenden Einträge vorzunehmen.
Besonders bei Punkt "Multipath Konfiguration anpassen".

Hier fehlt mir irgendwie, woher das Cluster bzw. die Hosts "wissen" welche Netzkarten sie benutzen sollen usw.

Könntest Du ggf. in der folgenden Vorlage Beispiel-Einträge machen, passen zu Deiner vorab geschriebenen Konfiguration ?

Ich denke, dann könnte ich mir das herleiten.

Vielen Dank im Voraus - ich weiß, viel verlangt. Aber ich möchte vor "Try and Error" ein wenig Absicherung durch Erfahrungen anderer einbringen.

ChatGPT:

iSCSI-Initiator auf den Proxmox Hosts konfigurieren
iSCSI-Pakete installieren (falls noch nicht vorhanden):
Auf jedem Proxmox Host führe folgendes aus:

apt update
apt install open-iscsi multipath-tools


iSCSI-Initiator konfigurieren:
Öffne die Konfigurationsdatei /etc/iscsi/iscsi.initatorname und stelle sicher, dass der Initiatorname eindeutig ist:

InitiatorName=iqn.1993-08.org.debian:01roxmox-hostname

iSCSI Discovery und Login:
Starte den iSCSI-Dienst:

systemctl start iscsid

Führe die Discovery auf allen Proxmox Hosts durch:

iscsiadm -m discovery -t sendtargets -p <Synology-IP-Adresse>


Logge dich auf dem iSCSI Target ein:


iscsiadm -m node --login

Multipath auf den Proxmox Hosts konfigurieren
Multipath-Konfiguration anpassen:

Öffne die Datei /etc/multipath.conf und füge folgendes hinzu (Passe die Werte entsprechend deiner Umgebung an):

defaults {
user_friendly_names yes
path_grouping_policy multibus
path_selector "round-robin 0"
failback immediate
no_path_retry queue
checker_timeout 100
}

blacklist {
devnode "^sd[a-z]"
}

multipaths {
multipath {
wwid "<WWID des LUN>"
alias mpath0
}
}

devices {
device {
vendor "SYNOLOGY"
product "iSCSI Disk"
path_grouping_policy multibus
path_checker tur
rr_weight priorities
no_path_retry queue
}
}


Multipath aktivieren und überprüfen:
Aktiviere den Multipath-Dienst:

systemctl enable multipath-tools
systemctl start multipath-tools

Überprüfe die Konfiguration:

multipath -ll

iSCSI LUNs in Proxmox einbinden
LVM auf iSCSI-LUNs erstellen (optional):

Wenn du LVM (Logical Volume Manager) verwenden möchtest, erstelle eine PV (Physical Volume):

pvcreate /dev/mapper/mpath0

Erstelle eine VG (Volume Group):

vgcreate vg_iscsi /dev/mapper/mpath0


Storage in Proxmox hinzufügen:

• Gehe in der Proxmox-Weboberfläche zu "Datacenter" > "Storage".
• Klicke auf "Add" und wähle den gewünschten Typ (z.B. LVM oder iSCSI).
• Wähle das neu erstellte LUN bzw. die Volume Group aus und konfiguriere den Speicher.

 

[Falk R.]

Danke für die ausführliche Beschreibung. Ich sehe, ich war bisher etwas auf dem Holzweg.
zu NFS - hatte ich schon einmal probiert und festgestellt, dass es hierbei sehr viel langsamer geht.
Warum weiß ich nicht - vielleicht liegts an Synology...

Welche NFS version hattest du genutzt?

In der hiesigen Konfiguration muss ich (leider) alles über je einen Switch am physischen Standort der Hosts anschließen.
Das sollte funktionell hoffentlich kein Problem sein - außer, wenn ein Switch ausfällt.

Genau das ist das größte Problem. Wenn der Switch aussteigt, hast du gar nix mehr und im schlimmsten Fall sind ein paar Daten in den VMs Korrupt. (Ist zwar selten, aber leider schon gesehen)

Ich habe zusätzlich mal ChatGPT gefragt und nachfolgende Anleitung (Auszug) erhalten :

Ich schreibe lieber nicht was ich von ChatGPT und technischen Anleitungen halte.

Dabei stellen sich mir Fragen, da ich bisher angenommen habe, dass Storages und Volumegruppen immer schön
auf dem Cluster (Rechenzentrum (Clustername) und nicht auf den einzelnen Hosts erzeugt werden

Den Datastore erzeugst du da, aber du musst einmal aus dem Multipath Device ein pvcreate und ein vgcreate ausführen. Das auf einem beliebigen Host. Bei einem ESXi muss man auch auf einem Host Partitionieren und Dateisystem erzeugen. Die anderen Host lesen die Informationen nachher aus.

Hier fehlt mir irgendwie, woher das Cluster bzw. die Hosts "wissen" welche Netzkarten sie benutzen sollen usw.

Deswegen definiert man ja die extra Subnetze für iSCSI. Damit Weiß der Host auf welcher NIC diese Subnetz zu finden ist und nutzt diese NIC.
Das ist elementar Wichtig bei iSCSI.

ChatGPT:

iSCSI-Initiator auf den Proxmox Hosts konfigurieren
iSCSI-Pakete installieren (falls noch nicht vorhanden):
Auf jedem Proxmox Host führe folgendes aus:

apt update
apt install open-iscsi multipath-tools

alles richtig

iSCSI-Initiator konfigurieren:
Öffne die Konfigurationsdatei /etc/iscsi/iscsi.initatorname und stelle sicher, dass der Initiatorname eindeutig ist:

Der ist immer eindeutig generiert.

iSCSI Discovery und Login:
Starte den iSCSI-Dienst:

systemctl start iscsid

Führe die Discovery auf allen Proxmox Hosts durch:

iscsiadm -m discovery -t sendtargets -p <Synology-IP-Adresse>

Dies für alle IPs durchführen

Logge dich auf dem iSCSI Target ein:

iscsiadm -m node --login

Multipath auf den Proxmox Hosts konfigurieren
Multipath-Konfiguration anpassen:

Öffne die Datei /etc/multipath.conf und füge folgendes hinzu (Passe die Werte entsprechend deiner Umgebung an):

Bei Debian (Proxmox) ist keine multipath.conf vorhanden, sondern muss von Hand angelegt werden.

defaults {
user_friendly_names yes
path_grouping_policy multibus
path_selector "round-robin 0"
failback immediate
no_path_retry queue
checker_timeout 100
}

blacklist {
devnode "^sd[a-z]"
}

multipaths {
multipath {
wwid "<WWID des LUN>"
alias mpath0
}
}

devices {
device {
vendor "SYNOLOGY"
product "iSCSI Disk"
path_grouping_policy multibus
path_checker tur
rr_weight priorities
no_path_retry queue
}
}

Ich nutze folgende Optionen:
blacklist {
wwid .*
}

blacklist_exceptions {
vendor "Hersteller"
product "Arrayname"
}
Bei Hersteller muss dan Synology rein und bei Arrayname iSCSI Disk.
Den Punkt multipaths lasse ich weg, Ich nutze dann lieber die CLI, wo du einfach multipath -a /dev/sda nutzt wenn sda ein Pfad zur Synology ist.
Der macht dann automatisch die wwid draus.

Multipath aktivieren und überprüfen:
Aktiviere den Multipath-Dienst:

systemctl enable multipath-tools
systemctl start multipath-tools

Überprüfe die Konfiguration:

multipath -ll

Falls er nicht alles korrekt anzeigt multipath -v3 macht einen Multipath rescan.

iSCSI LUNs in Proxmox einbinden
LVM auf iSCSI-LUNs erstellen (optional):

Wenn du LVM (Logical Volume Manager) verwenden möchtest, erstelle eine PV (Physical Volume):

pvcreate /dev/mapper/mpath0

Erstelle eine VG (Volume Group):

vgcreate vg_iscsi /dev/mapper/mpath0


Storage in Proxmox hinzufügen:

• Gehe in der Proxmox-Weboberfläche zu "Datacenter" > "Storage".
• Klicke auf "Add" und wähle den gewünschten Typ (z.B. LVM oder iSCSI).
• Wähle das neu erstellte LUN bzw. die Volume Group aus und konfiguriere den Speicher.

Soweit sieht das ganz OK aus was ChatGPT geschrieben hat. Hatte wohl einen guten Tag.

 

[Naumburger-Bauunion]

Welche NFS version hattest du genutzt? : v4.1

Hmm, also ich denke, ich werde dafür doch mal ein WE opfern. Das ist mir im laufenden Betrieb (mit angekündigter Downtime von 1h oder so) zu heiß.

Aber Vielen Dank für Deine Ausführungen - das müsste eigentlich helfen.

Proxmox ist momentan bei mir im "selflearning process" - ein Seminar steht an, ist leider bis Mitte 2025 fast alles ausgebucht :-(

 

[Falk R.]

Wenn du gar nicht klar kommst, ich mache soetwas auch beruflich als Dienstleister.

 

[Naumburger-Bauunion]

Wenn du gar nicht klar kommst, ich mache soetwas auch beruflich als Dienstleister.

Schaun wir mal - ich werds mir auf jeden Fall merken ;-)

 

[Naumburger-Bauunion]

ch nutze folgende Optionen:
blacklist {
wwid .*
}

blacklist_exceptions {
vendor "Hersteller"
product "Arrayname"
}
Bei Hersteller muss dan Synology rein und bei Arrayname iSCSI Disk.
Den Punkt multipaths lasse ich weg, Ich nutze dann lieber die CLI, wo du einfach multipath -a /dev/sda nutzt wenn sda ein Pfad zur Synology ist.
Der macht dann automatisch die wwid draus.

Bis dahin habe ich auf einem Host alles soweit abgearbeitet.
In der multipath.conf steht jetzt genau folgendes :

blacklist {
wwid.*
}

blacklist_exceptions {
vendor "SYNOLOGY"
product "iSCSI Disk"


weiter nix.

den CLI Befehl multipath -a /dev/xxx würde ich gerne nutzen, jedoch zeigt die Weboberfläche bei DISKS nur die lokalen an, keine vom iSCSI.
Wie kriege ich die bzw. wo steht die wwid des LUN, damit ich es in die .conf eintragen kann ?

Im Synology SAN Manager steht lediglich die IQN und der (selbst festgelegte) Name, hier "proxmox-cluster-lun" .

 

[Falk R.]

Mach mal rescan-scsi-bus.sh danach solltes du bei lsblk die Disks sehen.
Wenn die Disks da sind kann multipath auch einmal zu rescannen angeregt werden mit multipath -v3 und dann solltest du mit multipath -l die Pfade sehen.

 

[Naumburger-Bauunion]

So wie es aussieht ist es sdd - mit nem Haufen Disky drunter - naja, könnte stimmen, die Synology hat viele

Bei multipath -a /dev/sdd kommt folgendes :

missing value for option "wwid.*" on line 2
line 6 invalid keyword in the blacklist_exceptions section: vendor
line 7 invalid keyword in the blacklist_exceptions section: product
wwid '3600xxxxxxxxxxxxxx' added


Die nochmal aufgerufene .conf ist unverändert - also kein selbständiger Eintrag der wwid

 

[Falk R.]

Die Einträge müssten in dem Unterordner multipath.d landen. Aber bei deiner exception passt noch etwas nicht.

blacklist_exceptions {
    vendor    "Hersteller"
    product    "Arrayname"
}

Hast du die schließende Klammer drin? Die Einrückung passt auch?

 

[Naumburger-Bauunion]

Hier ist mal die komplette multipath.conf
------------------------------
defaults {
user_friendly_names yes
path_grouping_policy multibus
path_selector "round-robin 0"
failback immediate
no_path_retry queue
checker_timeout 100
}

blacklist {
devnode ""
}

blacklist_exceptions {
wwid 36001405f7932cf6d77e0d44fad93c9d0
}

multipaths {
multipath {
wwid "36001405f7932cf6d77e0d44fad93c9d0"
alias mpath0
}
}

devices {
device {
vendor "SYNOLOGY"
product "iSCSI Disk"
path_grouping_policy multibus
path_checker tur
rr_weight priorities
no_path_retry queue
}
}
------------------------------------

Die wwid sollte stimmen.

Ich habe noch etwas rumexperimentiert unter zuhilfenahme des proxmox wiki.
Jetzt bin ich glaube ich an dem Punkt, wo ich nicht mehr weiß, was ich tue..

Ich weiß nicht, ob das conf. file das Problem ist, oder was anderes.

Die Frage wäre - wenn Du das als Dienstleistung machst - wie würde das vonstatten gehen ?
Der Adminrechner könnte temporär sicher mal ans Netz für Teamviewer oder anydesk.

Wenn Du drüberschauen könntest, kannst Du bestimmt abschätzen, was der Spaß kostet - oder ?