Corosync und bekannte Limitierungen

[Alvin2k8]

Hi,

gibts bekannte Limitierungen was corosync angeht?
Sollte ein Cluster eine Anzahl an Servern nicht überschreiten?

Teilt mal bitte eure Erfahrungen mit mir.

Wir sehen aktuell die Sache, es laufen ca. 400 Replikas auf 20 Servern...das anschauen der Replikas geht und geht mal nicht.
Sieht nach Corosync aus..

Danke für euer Feedback!

 

[Johannes S]

Technisch hibt es keine, praktisch wird von Clustern mit 30-50 Knoten berichtet:

D

Thread 'Proxmox 7.X biggest number of nodes in cluster !'

Oct 17, 2021

Dear Proxmox team ,

A quick question regarding the number of possible nodes within proxmox 7.x cluster .
What is the limitation in terms of numbers of nodes in one cluster ?
We simply would like to understand how big the cluster can be ?
is it possible to have 100+ nodes in one cluster or simply need to split the nodes in 32 nodes per groups?
Also we would very much appreciate it if you kindly attach links/articles/pdfs ( if exist of course ) of a very large implementations of proxmox cluster limitations in terms of number of nodes .
Thank you very much for your help in advance .

Best...

• Dave.r
• large cluster proxmox 7 proxmox cluster proxmox cluster node
• Replies: 3
• Forum: Proxmox VE: Installation and configuration

Es hängt natürlich auch an so Sachen wie der eingesetzten Hardware und dem Netzwerksetup ab, corosync sollte auf einen dezidiert Netzwerk betrieben werden, Ceph/ZFS replication auch sein eigenes Netz bekommen:

The Proxmox VE cluster stack requires a reliable network with latencies under 5 milliseconds (LAN performance) between all nodes to operate stably. While on setups with a small node count a network with higher latencies may work, this is not guaranteed and gets rather unlikely with more than three nodes and latencies above around 10 ms.
The network should not be used heavily by other members, as while corosync does not uses much bandwidth it is sensitive to latency jitters; ideally corosync runs on its own physically separated network. Especially do not use a shared network for corosync and storage (except as a potential low-priority fallback in a redundant configuration).

https://pve.proxmox.com/wiki/Cluster_Manager#_cluster_network


By default, Proxmox VE uses the network in which cluster communication takes place to send the migration traffic. This is not optimal both because sensitive cluster traffic can be disrupted and this network may not have the best bandwidth available on the node.

Setting the migration network parameter allows the use of a dedicated network for all migration traffic. In addition to the memory, this also affects the storage traffic for offline migrations.
The migration network is set as a network using CIDR notation. This has the advantage that you don’t have to set individual IP addresses for each node. Proxmox VE can determine the real address on the destination node from the network specified in the CIDR form. To enable this, the network must be specified so that each node has exactly one IP in the respective network.
https://pve.proxmox.com/wiki/Cluster_Manager#_guest_migration

Anmerkung: Dieses Migration-Network wird auch für die Storage Replication mit ZFS benutzt (siehe: https://forum.proxmox.com/threads/zfs-storage-replication-network.37252/post-183092 )
Für Ceph gilt dagegen:

The volume of traffic, especially during recovery, will interfere with other services on the same network, especially the latency sensitive Proxmox VE corosync cluster stack can be affected, resulting in possible loss of cluster quorum. Moving the Ceph traffic to dedicated and physical separated networks will avoid such interference, not only for corosync, but also for the networking services provided by any virtual guests.
https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster

Es wäre also gut, wenn du mal deine Hardware und deinen Netzwerkaufbau genauer beschreibst, damit man das im Detail betrachten könnte.

 

[Alvin2k8]

Was sollte man denn in einem "größeren" Cluster tunen?

 

[Johannes S]

Was sollte man denn in einem "größeren" Cluster tunen?

Naja, für Ceph wird zum Beispiel die Verwendung eines 10Gbit Netzwerks als absolutes Minimum angesehen, bei größeren Clustern und mehr OSDs pro pro Knoten reicht das aber nicht mehr (siehe diverse Diskussionen hier im Forum z.B. folgende zu einen Setup mit 10Gbit, 33 OSDs (SSDs-Platten) und vier Knoten:
https://forum.proxmox.com/threads/kann-ceph-flaschenhals-nicht-finden.158531/

Sprich: Es wäre wirklich wichtig zu wissen, wieviele Knoten mit wievielen Platten wie miteinander verbunden sind, dann kann man über das Tuning reden

 

[Alvin2k8]

20 Knoten, 6 Platten pro Knoten im Z2, kein Ceph, 10G aber nur eine Karte

 

[Johannes S]

20 Knoten, 6 Platten pro Knoten im Z2, kein Ceph, 10G aber nur eine Karte

Dann wäre (als jemand, der selbst PVE nur im Homelab einsetzt) nach den früheren Diskussionen meine Vermutung, dass hier der Haase im Pfeffer liegt: Eigentlich sollte es drei Netzwerke geben (dezidiertes für corosync (muss nicht mal eine sonderlich dicke Leitung sein, Punkt ist die Latenz kleinzuhalten, indem sonst nichts darüber läuft), einmal Ceph (das wäre dann die 10 G) und dann eine weitere Karte für die Anbindung der Clients an die gehosteten VMs. Zusätzlich könnte es noch sinnvoll sein für Corosync noch ein zweites Netzwerk für Redundanz bei einen Ausfall hinzuzufügen, die Doku sagt dazu folgendes:

If no priorities are configured manually (or two links have the same priority), links will be used in order of their number, with the lower number having higher priority.
Even if all links are working, only the one with the highest priority will see corosync traffic. Link priorities cannot be mixed, meaning that links with different priorities will not be able to communicate with each other.
Since lower priority links will not see traffic unless all higher priorities have failed, it becomes a useful strategy to specify networks used for other tasks (VMs, storage, etc.) as low-priority links. If worst comes to worst, a higher latency or more congested connection might be better than no connection at all.
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_redundancy

Mit anderen Worten: Es gibt ein Netzwerk, was nur für corosync genutzt wird und das für Ceph und die Kommunikation mit den Clients der VMs werden mit niedrigerer Priorität für Ausfallszenarien genutzt.

Und in der bereits oben verlinkten Debatte war auch durch die Bank weg die erste Empfehlung, doch 25 oder besser noch 100Gbit für das Ceph-Netzwerk zu nehmen und da ging es ja um einen deutlich kleineren Cluster als bei dir.

Siehe dazu auch die bereits verlinkte Wikiseite zu HCI mit Ceph:

We recommend a network bandwidth of at least 10 Gbps, or more, to be used exclusively for Ceph traffic. A meshed network setup [4] is also an option for three to five node clusters, if there are no 10+ Gbps switches available.

Important The volume of traffic, especially during recovery, will interfere with other services on the same network, especially the latency sensitive Proxmox VE corosync cluster stack can be affected, resulting in possible loss of cluster quorum. Moving the Ceph traffic to dedicated and physical separated networks will avoid such interference, not only for corosync, but also for the networking services provided by any virtual guests.
For estimating your bandwidth needs, you need to take the performance of your disks into account.. While a single HDD might not saturate a 1 Gb link, multiple HDD OSDs per node can already saturate 10 Gbps too. If modern NVMe-attached SSDs are used, a single one can already saturate 10 Gbps of bandwidth, or more. For such high-performance setups we recommend at least a 25 Gpbs, while even 40 Gbps or 100+ Gbps might be required to utilize the full performance potential of the underlying disks.

If unsure, we recommend using three (physical) separate networks for high-performance setups:

• one very high bandwidth (25+ Gbps) network for Ceph (internal) cluster traffic.
• one high bandwidth (10+ Gpbs) network for Ceph (public) traffic between the ceph server and ceph client storage traffic. Depending on your needs this can also be used to host the virtual guest traffic and the VM live-migration traffic.
• one medium bandwidth (1 Gbps) exclusive for the latency sensitive corosync cluster communication.

https://pve.proxmox.com/wiki/Deploy...r#_recommendations_for_a_healthy_ceph_cluster

Weitere Betrachtungen überlasse ich dann mal den Profis hier, mein Wissen zu Ceph ist leider nicht praktischer Natur (da es für mein Homelab völliger Overkill wäre)