Timeouts bei diversen Aktionen

[NothingTV]

Hallöchen,

ich habe hier einen Cluster mit knapp 40 Nodes und über 2k VMs mit rbd storage (ceph cluster), je mehr VMs und Nodes dazukommen, desto langsamer wird so gut wie jede Aktion (VM starten, stoppen, disk hinzufügen, löschen, vnc, etc.), sehr oft kommt es sogar zu Meldungen wie "cfs-lock 'storage-replica3' error: got lock request timeout" oder "ACL update failed: cfs-lock 'file-user_cfg' error: got lock request timeout". Hat jemand ähnliche Erfahrungen und kann ggf. Tipps zum optimieren geben?

Liebe Grüße

 

[dietmar]

Hast du ein physikalisch getrenntes cluster netzwerk?

 

[NothingTV]

Hast du ein physikalisch getrenntes cluster netzwerk?

ja, also uns gehen wirklich komplett die Ideen aus, was wir noch prüfen/optimieren können

 

[Falk R.]

Hi, das klingt extrem nach Netzwerk.
Bei einem Cluster mit 40 Nodes muss man das Netzwerk schon gut sizen und monitoren.
Kannst du uns dein Netzwerksetup etwas erklären?

 

[NothingTV]

Kannst du uns dein Netzwerksetup etwas erklären?

Klar, also unsere Proxmox Nodes haben alle 2x10G sowie 2x 40G. Unsere Ceph Nodes haben jeweils 2x 40G.
Die Ceph Nodes hängen an einem 160G Switch, womit sie dann mit unseren Proxmox Nodes kommunizieren, bzw. den Speicher bereitstellen, welcher auch keinerlei Probleme innerhalb der VMs zeigt.
Wir unterscheiden hier zwischen 3 verschiedenen VLANs. Eines für interne Kommunikationen zwischen den Ceph Nodes, eines für Ceph zum Proxmox Node und eines nur für die Proxmox Nodes.
Wir sehen im Monitoring auch keinerlei Engpässe, keinerlei Discards oder sonstiges, daher haben wir diese Art Probleme bisher ausgeschlossen. Aber es kann ja sein, dass wir da noch auf etwas besonderes achten müssten.

Wir mussten konkret letzte Woche mehrmals den pveproxy neustarten, da alles extrem unresponsive wurde und man regelmäßig in timeouts lief. Nach dem Neustart des pveproxies geht es für einen Moment, aber führt man dann diverse Aktionen âla Destroys, Creates, etc. aus, kracht es wieder in der GUI und der API. Die VMs selbst merken davon jedoch nichts, was umso seltsamer ist, denn auch innerhalb der VMs müsste das dann ja auffallen, wenn es irgendwo Engpässe geben würde.

 

[Falk R.]

Ich versuche das mal zu verstehen. Ihr habt 2x40G mit Ceph Cluster und Ceph Public per VLAN getrennt? Nutzt ihr da LACP und wenn ja, mit welcher Option?
Die PVE haben 2x40G für Ceph Public und 2x10G für LAN und Corosync?

Bei 40 Nodes wäre 40G auch schon recht knapp, aber könnte je nach Disks noch OK sein.
Auf den Ceph Nodes müsste das Netzwerk auch deutlich ausgelasteter sein.

Wie viele OSDs habt ihr denn und wie sehen eure Pools aus? EC Pools dabei? Wenn ja, wie habt ihr die Metadaten verteilt?

 

[NothingTV]

Ihr habt 2x40G mit Ceph Cluster und Ceph Public per VLAN getrennt?

Pro Ceph Node 2x40G, das Ceph ist nicht public, es gibt ein internes VLAN wodurch die Ceph Nodes untereinander kommunizieren können und eines vom Ceph Cluster zum Proxmox Cluster, was ebenfalls über die 2x40G je Node geht, angeschlossen an einem 160G Switch.

Nutzt ihr da LACP und wenn ja, mit welcher Option?

Ja, verwenden 802.3ad (layer3+4)

Die PVE haben 2x40G für Ceph Public und 2x10G für LAN und Corosync?

fast korrekt, Ceph ist nicht public, Corosync läuft aber auch über die 40G Karten über eines der zuvor genannten VLANs. Nur die VMs laufen über die 2x10G

Bei 40 Nodes wäre 40G auch schon recht knapp, aber könnte je nach Disks noch OK sein.

Pro Node 2x 40G, das wird doch reichen oder nicht? Mit dem Ceph Cluster verbunden über 160G. Da ist auch nichts ausgelastet, das haben wir an mehreren Stellen bestätigen können.

Noch ergänzend: In den corosync logs ist sowas zu sehen:
```
Token has not been received in 16387 ms
```
Pings zu sämtlichen Nodes (auch Ceph) resultiert konstant in <0.1ms Bereichen.

 

[Falk R.]

Schau dir mal deine Ceph Konfiguration an. Es gibt immer ein Ceph Public Network. Das hat überhaupt nichts mit Proxmox zu tun.
Das Ceph Public und Ceph Cluster haben bestimmte aufgaben, daher ist es wichtig zu wissen, was wie konfiguriert ist.

Ich weiß auch nicht was für ein 160G Switch das sein soll, soetwas habe ich noch nie gesehen und gibts auch in keiner Spezifikation.
40G ist z.B. Quad 10G.
100G ist Quad 25G.
200G gibts als Quad50G oder octa 25G.
Dazwischen kenne ich keinen Standard.

Ich hoffe euer Corosync läuft nicht nur auf der 40G Verbindung, sondern mindestens auch ein zweiter Ring auf den 10G.

40G ist gar nicht so viel. Wenn ihr wirklich 40 Nodes habt, wäre das sogar ganz schön wenig. Ich habe kleine 3 Node Cluster mit 100G Ceph am laufen und schaffe (all NVME) bis zu 60 GBIt Auslastung auf dem Netzwerk.

 

[NothingTV]

Es gibt immer ein Ceph Public Network.

Sorry, habe ich da falsch verstanden, die Ceph Nodes sind Public auch über 10G angebunden. Ich ging davon aus, du meintest die Storage Anbindung.

160G Switch

Unglücklich formuliert, ich meinte, dass die Ceph Nodes damit insgesamt angebunden sind an zwei DCS-7050QX-32.

Ich hoffe euer Corosync läuft nicht nur auf der 40G Verbindung, sondern mindestens auch ein zweiter Ring auf den 10G.

Gibt es dazu best-practices?

40G ist gar nicht so viel.

2x pro Node? Das ist nicht viel? Wir reden hier ja nicht von insgesamt 40G, jeder einzelne Node hat 2x40G, wenn das nicht viel ist, was wäre denn dann ideal? Also bitte nicht falsch verstehen, möchte es einfach verstehen. Ich monitore auch aktiv die Auslastung der Ceph Nodes, hier kommen nicht ansatzweise 40G zusammen je Node. Gut möglich, dass wir einfach andere Adapter benötigen, aber ich sehe hier beim besten willen keinerlei Engpass.

 

[Falk R.]

Sorry, habe ich da falsch verstanden, die Ceph Nodes sind Public auch über 10G angebunden. Ich ging davon aus, du meintest die Storage Anbindung.

Ja ich meine die Storage Anbindung.
Das Ceph Cluster Netzwerk ist für den Traffic zwischen den OSD.
Das Ceph Public Netzwerk ist für die Anbindung der Monitor und die Anbindung der Verbraucher (PVE VMs) zu den primary OSDs.

Unglücklich formuliert, ich meinte, dass die Ceph Nodes damit insgesamt angebunden sind an zwei DCS-7050QX-32.

Gibt es dazu best-practices?

Ja, frage mich jetzt aber nicht genau wo es steht. Habe es damals in der Schulung so gelernt, aber vorher auch schon gelesen.

2x pro Node? Das ist nicht viel? Wir reden hier ja nicht von insgesamt 40G, jeder einzelne Node hat 2x40G, wenn das nicht viel ist, was wäre denn dann ideal? Also bitte nicht falsch verstehen, möchte es einfach verstehen. Ich monitore auch aktiv die Auslastung der Ceph Nodes, hier kommen nicht ansatzweise 40G zusammen je Node. Gut möglich, dass wir einfach andere Adapter benötigen, aber ich sehe hier beim besten willen keinerlei Engpass.

Das liegt natürlich auch immer an den Disks di genutzt werden. Wenn an noch HDDs nutzt, dann wird man die 40 GBit nie auslasten, aber bei 40 Nodes hat man ja mindestens 160 OSDs und dann kann man mitunter eine Menge Traffic Produzieren. Ein vernünftig kalkulierter 40 Node Cluster kann ja locker 2000-3000 VMs versorgen und da können die 40G ganz schnell am ende sein.

 

[NothingTV]

Ich danke dir wirklich für den Input, aber ich versichere nochmal, dass es nicht an einem Limit der 40G Karten liegt.
Es ist ein purer NVMe Ceph-Cluster mit derzeit 101 OSDs. Wir haben derzeit eher die Vermutung, dass der Node der von der API angesprochen wird, durch die ganzen requests etwas in die Knie geht. Wir werden daher einen extra Management Node integrieren, der nichts anderes tun soll.

 

[Falk R.]

Meine Erfahrung ist auch, dass Cluster mit 25 GBit besser laufen als mit 40 GBit, mit 100 GBit natürlich noch besser.
10/40G hat eine 2,5fache Latenz wie 25/100G. Bei all NVMe spürt man das schon. Aber die Probleme passen trotzdem nicht so richtig,
Nutzt ih denn Jumbo Frames?

 

[NothingTV]

Die Latenz ist dort zwar geringer, aber wenn das das problem wäre, würde sich das bestimmt in anderen Bereichen und Tests zeigen

Nutzt ih denn Jumbo Frames?

Nein, da wurde sich gegen entschieden.

 

[Falk R.]

Die Latenz ist dort zwar geringer, aber wenn das das problem wäre, würde sich das bestimmt in anderen Bereichen und Tests zeigen

Nein, da wurde sich gegen entschieden.

Eventuell mal checken ob es irgendwo Warteschlangen aufgrund der Paketmengen und nicht wegen der Bandbreite kommt.
Wenn ich mir die Sizing s von den großen Clustern angucke, dann haben die dicke CPUs auch mit viel Single Thread Leistung und viel schnelles Netzwerk. Da ja alle Daten verteilt werden, entsteht ganz viel Ost-West Traffic.
Nutzt ihr denn auch Erasure Coding? Das belastet mit den zusätzlichen Metadaten noch etwas mehr.

 

[NothingTV]

Wir haben jetzt einen dedizierten Management Server, der nichts anderes tun soll, als Requests entgegen zu nehmen und diese zu verarbeiten und wir haben immer noch "cfs-lock 'file-user_cfg' error: got lock request timeout" Meldungen, weniger, aber sie treten immer noch auf.
Das bspw. kann ja wohl nicht mit dem Ceph Cluster selbst in Verbindung stehen, da einige Aktionen wie die Löschung eines Users auf PVE Cluster Ebene passiert.

Ich bin mit meinen Ideen leider komplett am Ende

 

[Falk R.]

Ich glaube auch nicht, dass es direkt am Cluster liegt.
Wenn das Corosync derzeit über das Ceph Netzwerk läuft, dann macht das mal zum sekundär Corosync Netzwerk. Schwenkt mal Corosync auf das normale LAN.

 

[NothingTV]

Ich glaube auch nicht, dass es direkt am Cluster liegt.
Wenn das Corosync derzeit über das Ceph Netzwerk läuft, dann macht das mal zum sekundär Corosync Netzwerk. Schwenkt mal Corosync auf das normale LAN.

Wir prüfen derzeit noch, was für Optionen wir noch ausschöpfen können. Ist dir ggf. ein Setting bekannt, womit wir den besagten Timeout erhöhen können? Unserseits ist es in Ordnung, wenn bspw. rbd rm commands etwas länger dauern, aber der Timeout kommt halt einfach viel zu früh.
Kein fix, aber erstmal ein work-around, damit wir das in Ruhe debuggen können.

 

[2RunX]

hört sich an nach - linux steal time . . .

 

[NothingTV]

hört sich an nach - linux steal time . . .

Auf dem Management node läuft nichts, wirklich nichts.

 

[NothingTV]

Suchen hiermit offiziell nach einem Proxmox Cluster Spezialisten, der sich gegen Bezahlung diesem Problem widmet.
@dietmar ich hoffe das ist in Ordnung?