PowerScale: Nodes, die aufgeteilt werden, da lldpd keinen Heartbeat mehr an den Dell Back-end-Switch sendet

Es gibt einen Speicherverlust in lldpd und ein Node kann geteilt werden, wenn der Prozess seinen maximal zulässigen Arbeitsspeicher (1 GB) verbraucht hat. Sobald der Node seinen zulässigen Arbeitsspeicher verbraucht hat, sendet er keine LLDP-Pakete mehr an die Back-end-Switches. Ein von Dell qualifizierter PowerScale-Back-end-Switch, auf dem SmartFabric Services (SFS) ausgeführt wird, muss Heartbeat-Pakete (LLDP) von einem Node empfangen. Wenn drei Heartbeats fehlen, wird der Switchport aus seinem dedizierten virtuellen Netzwerk entfernt. Dann kann ein Node nicht mehr über diesen Pfad mit dem Cluster kommunizieren.

Wenn ein Upgrade eines Clusters durchgeführt wird, werden die Nodes nacheinander neu gestartet und bei jedem Neustart werden mehrere Links heruntergefahren und gesichert. Jedes dieser Verbindungsereignisse aus den Neustarts erhöht langsam die Größe der lldpd-VMME-Nutzung. Es ist sehr wahrscheinlich, dass Nodes während eines Upgrades geteilt werden, wenn der Prozess nicht kürzlich neu gestartet wurde.

Dieses Problem kann in den folgenden Szenarien auftreten:

• OneFS-Upgrades
• Normaler Clusterbetrieb

Die aktuelle VMEM-Nutzung kann mit dem folgenden Befehl angezeigt werden, wobei ein RSS-Wert (MAXIMUM Resident Set Size) 1.048.576 KB beträgt. RSS ist die sechste Spalte mit Informationen aus der PS-Ausgabe (links von " - ") (ohne den Node-Namen).

# isi_for_array -s 'ps aux | grep _lldpd | grep -v grep'

Beispielausgabe unten:

cl950x-1# isi_for_array -s 'ps aux | grep _lldpd | grep -v grep'
cl950x-1: _lldpd  1483   0.0  3.2 273804 262168  -  S     6Aug23     74:25.14 lldpd: no neighbor. (lldpd)
cl950x-1: _lldpd  1492   0.0  3.2 273804 262168  -  S     6Aug23     74:31.73 lldpd: no neighbor. (lldpd)
cl950x-2: _lldpd  1483   0.0  2.9 251068 238632  -  S    14Aug23     66:19.68 lldpd: no neighbor. (lldpd)
cl950x-2: _lldpd  1492   0.0  2.9 251068 238632  -  S    14Aug23     66:24.72 lldpd: no neighbor. (lldpd)
cl950x-3: _lldpd  1483   0.0  2.9 251832 239420  -  S    14Aug23     46:25.36 lldpd: no neighbor. (lldpd)
cl950x-3: _lldpd  1492   0.0  2.9 251832 239420  -  S    14Aug23     46:32.24 lldpd: no neighbor. (lldpd)
cl950x-4: _lldpd  1487   0.0  3.1 268052 256212  -  S     8Aug23     50:25.15 lldpd: no neighbor. (lldpd)
cl950x-4: _lldpd  1496   0.0  3.1 268052 256212  -  S     8Aug23     50:36.34 lldpd: no neighbor. (lldpd)
cl950x-5: _lldpd  1483   0.0  3.1 273208 261552  -  S     6Aug23     75:41.91 lldpd: no neighbor. (lldpd)
cl950x-5: _lldpd  1492   0.0  3.1 273208 261552  -  S     6Aug23     75:35.00 lldpd: no neighbor. (lldpd)
cl950x-6: _lldpd  1482   0.0  3.2 274144 262516  -  S     6Aug23     50:49.08 lldpd: no neighbor. (lldpd)
cl950x-6: _lldpd  1492   0.0  3.2 274144 262516  -  S     6Aug23     51:02.88 lldpd: no neighbor. (lldpd)
cl950x-7: _lldpd  1483   0.0  3.2 274004 262380  -  S     6Aug23     50:51.55 lldpd: no neighbor. (lldpd)
cl950x-7: _lldpd  1492   0.0  3.2 274004 262380  -  S     6Aug23     51:03.26 lldpd: no neighbor. (lldpd)
cl950x-8: _lldpd  1483   0.0  2.9 251176 238744  -  S    14Aug23     46:40.93 lldpd: no neighbor. (lldpd)
cl950x-8: _lldpd  1492   0.0  2.9 251176 238744  -  S    14Aug23     46:49.57 lldpd: no neighbor. (lldpd)
                                         ^^^^^^

Die Geschwindigkeit, mit der der lldpd-Prozess den Arbeitsspeicher verbraucht, hängt von mehreren Faktoren ab. Dies ist auch der Grund für den höheren Anstieg der Speicherauslastung während OneFS-Upgrades als normal:

• Größe der Netzwerkkonfiguration auf dem Cluster
• Anzahl der aus der Netzwerkkonfiguration erstellten Subnetze
• Die Anzahl der Netzwerkereignisse wie z. B. "Verbindung unterbrochen" oder "aktiv"
• Wiederkehrende Neustartereignisse

Die Zeitspanne, die _lldpd Prozess benötigt, um die MAXIMAL zulässige Arbeitsspeicherkapazität zu erreichen, variiert von Cluster zu Cluster. Es wurde jedoch festgestellt, dass es eine Korrelation zwischen der Größe der Netzwerkkonfiguration und der Zeit bis zum Ausfall gibt. Das bedeutet, je mehr Gruppennetze, Subnetze und Pools konfiguriert werden, desto eher kann dies geschehen.  

Je nach aktuellem Szenario gibt es mehrere Möglichkeiten, das Problem zu beheben oder zu umgehen:

1. Upgrade von OneFS auf 9.5.0.6 und höher
   • Beachten Sie die Warnmeldungen im Artikel zum Neustart von lldpd vor einem Upgrade aus den betroffenen Versionen.
2. Ein temporärer Workaround wird sofort durch das Neustarten von lldpd-Prozessen durchgeführt. Dies erfordert eine manuelle Intervention, indem der Prozess im gesamten Cluster neu gestartet wird:

   • # killall lldpd

3. Eine vorübergehende Problemumgehung, nachdem das Problem behoben wurde, indem lldpd-Prozesse mit einer Größe von mehr als 500 MB sofort neu gestartet werden:

   • # isi_for_array -s 'ps auxww | grep _lldpd | grep -v grep | awk '"'"'{print $2}'"'"' | while read pid; do procstat -r $pid | grep RSS; done | awk '"'"'{ if ($5 > 500000 && $2 == "lldpd") { command=sprintf("kill %d",$1); system(command); close(command) } }'"'"''

4. Nachdem das Problem behoben wurde (der folgende Befehl ist mit dem vorherigen Befehl identisch), kann dies in einer Bildschirmsitzung ausgeführt werden, um die Überprüfung alle 1200 Sekunden durchzuführen.

   • # while true; do isi_for_array -s 'ps auxww | grep _lldpd | grep -v grep | awk '"'"'{print $2}'"'"' | while read pid; do procstat -r $pid | grep RSS; done | awk '"'"'{ if ($5 > 500000 && $2 == "lldpd") { command=sprintf("kill %d",$1); system(command); close(command) } }'"'"''; sleep 1200; done