Proxmox 3-Knoten-Cluster: Probleme mit Netzwerkeinstellungen bei Clusterbildung(Simple Routing)

SlimTrainEE

New Member
Feb 18, 2025
12
4
3
Hallo liebe Proxmox-Community,

ich werde ein 3-Knoten-Cluster im Homelab einrichten und dazu auch bald einen bebilderten Post erstellen.
Z.Z. scheitere ich aber gerade am Aufbau des Netzwerk.

Für die Netzwerklogik habe ich mich an diesem Doc orientiert und mich erstmal für das einfache Simple Routing Setup entschieden -> https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server .
Ich verstehe auch diese Einstellungen aus dem Doc:

# Connected to Node2 (.51)
auto ens18
iface ens18 inet static
address 10.15.15.50
netmask 255.255.255.0
up ip route add 10.15.15.51/32 dev ens18
down ip route del 10.15.15.51/32

# Connected to Node3 (.52)
auto ens19
iface ens19 inet static
address 10.15.15.50
netmask 255.255.255.0
up ip route add 10.15.15.52/32 dev ens19
down ip route del 10.15.15.52/32


Dabei wird jeder Karte, die zwei Interfaces hat, auf jedem Interface die gleiche IP zugewiesen und eine statische Route erstellt, die auf genau eine andere IP-Adresse(/32), eines Nachbarknotens zeigt.
Auf diese Weise lässt sich eine Ringtopologie aufbauen, mit statischen Routen zwischen jeweils zwei Knoten, die über die zu benutzenden Interfaces definiert ist.

Mein Problem ist jetzt, dass bei der Clustererstellung via WebGUI, ein Interface angegeben wird. Allerdings zeigt ein Interface in einer Ringtopologie hier nur auf einen Knoten. Der andere Knoten, kann von dem Interface nicht gesehen werden. Wenn ich beide Interfaces angebe, dann sagt er mir, dass "duplicate link address not allowed".

Ich hatte das Cluster einmal gebildet via einer vmbr, der ich dann eine IP-Adresse zugewiesen hatte und die NICs als Members in die Bridge geladen habe. Das hat funktioniert und, die WebGUI war mit nur einer IP-Adresse dann auch bedient aber das hat natürlich einen Layer-2 Switching Loop verursacht.

Wie kann man also ein 3-Knoten-Cluster, mit Simple Routing, erstellen?
Irgendwie muss es doch gehen.
 
Lösungsansatz: Erstellung des Clusters via Shell und die Knoten auf der Standard-IP des Web-Dienstes hinzufügen. Dann den Corosync-Dienst auf ein anderes Subnetz legen.
Die Erstellung funktioniert allerdings kann die IP des Corosync nicht durch ein anderes Subnetz ersetzt werden, da es dann zu Zertifikatsfehlern kommt. Im Zertifikat ist die IP-Adresse des Web-Dienstes hinterlegt.
 
Fortschritt:
Es ist möglich, bei der Clustererstellung via Shell zwei Netze mitzugeben und den Netzen dabei Gewichtungen zu geben. Das Netz mit dem höheren Gewicht wird dabei bevorzugt behandelt. Soweit so gut.
"pvecm create CLUSTERNAME --link0 10.10.10.1,priority=15 --link1 10.20.20.1,priority=20"

Ein Blick in die corosync.conf zeigt dann auch, dass die Erstellung des Clusters mit diesen Eigenschaften funktioniert hat.

Problem:
Wenn ein Knoten hinzugefügt werden soll, dann bricht der Clusterjoin ab, mit der Meldung:
"check cluster join API version
No cluster network links passed explicitly, fallback to local node IP '192.168.2.20'
Request addition of this node
An error occurred on the cluster node: no links given but multiple links found on other nodes, fallback only supported on single-link clusters
Cluster join aborted!
"
Soweit so doof.

Lösungsantz:
Zweites Netz wieder aus corosync.conf entfernen und nachträglich hinzufügen.
 
Last edited:
Gelöst:
Ich habe das Cluster erstellt auf dem Netz, auf welchem auch der Webserver läuft. Ein Clustererstellung auf einem anderen Netz ergibt einen Zertifikatsfehler, siehe oben.
Dann habe ich die corosync.conf angepasst und jedem Knoten eine weitere IP-Adresse(y.y.y.y) hinzugefügt.

nodelist {
node {
name: xxx3
nodeid: 3
quorum_votes: 1
ring0_addr: x.x.x.x
ring1_addr: y.y.y.y
}
node {
name: xxx1
nodeid: 1
quorum_votes: 1
ring0_addr: x.x.x.x
ring1_addr: y.y.y.y
}
node {
name: xxx2
nodeid: 2
quorum_votes: 1
ring0_addr: x.x.x.x
ring1_addr: y.y.y.y
}
}


Dann noch den unteren Teil der Datei anpassen, um die Gewichtung der Netze festzulegen um sicherzustellen, dass der Corosync-Dienst auch das dedizierte Netz für sich benutzt:

totem {
cluster_name: Alpha-Cluster
config_version: 3
interface {
knet_link_priority: 15
linknumber: 0
}
interface {

knet_link_priority: 20
linknumber: 1
}

ip_version: ipv4-6
link_mode: passive
secauth: on
version: 2
}


Ein Test, bei dem ich die Verbindung zum Webserver an zwei Knoten rausgezogen habe, hat dann dazu geführt, dass der Webserver nicht mehr erreichbar war aber die Kommunikation im Cluster an davon nicht betroffen. Kein Knoten im Cluster ist auf ROT gewechselt.

Wäre cool, wenn das auch einfacher ginge :D
 
Last edited: