VxRail: Noder kan oppleve høy LSOM-overbelastning

Merk: informasjonen som leveres basert på VMware KB 82619(ekstern lenke). Se gjennom artikkelen for potensielle nyere oppdateringer.

Når du kjører VxRail-versjonene 4.7.511-526 og 7.0.130-132, kan du oppleve følgende problemer:

• "Antall elementer i utførelsestabellene" er mer enn 100k og reduseres ikke over en periode på timer.
• Tap av mulighet til å se filer og mapper på vSAN-datalageret
• Alvorlig redusert ytelse
• Én eller flere noder med høy minnebelastning for Local Log Structured Object Management (LSOM) (se kommando 1).
• "Antall elementer i utføringstabellene" er mer enn 100k (se kommando 2).
• Minneoverbelastning som har overført seg til alle nodene i klyngen.
• Logger meldinger i vmkernel.log:
  • LSOM: LSOM_ThrowCongestionVOB:3429: Throttled: Virtual SAN node "HOSTNAME" maximum Memory congestion reached.
• Logger meldinger i vobd.log og vmkernel.log
  • LSOM_ThrowAsyncCongestionVOB:1669: LSOM Memory Congestion State: Exceeded. Congestion Threshold: 200 Current Congestion: 204.

Følgende skriptede kommandoer kan brukes til å finne ut om verten kan ha dette problemet.
Manus 1

while true; do echo "================================================"; date; for ssd in $(localcli vsan storage list |grep "Group UUID"|awk '{print $5}'|sort -u);do echo $ssd;vsish -e get /vmkModules/lsom/disks/$ssd/info|grep Congestion;done; for ssd in $(localcli vsan storage list |grep "Group UUID"|awk '{print $5}'|sort -u);do llogTotal=$(vsish -e get /vmkModules/lsom/disks/$ssd/info|grep "Log space consumed by LLOG"|awk -F : '{print $2}');plogTotal=$(vsish -e get /vmkModules/lsom/disks/$ssd/info|grep "Log space consumed by PLOG"|awk -F : '{print $2}');llogGib=$(echo $llogTotal |awk '{print $1 / 1073741824}');plogGib=$(echo $plogTotal |awk '{print $1 / 1073741824}');allGibTotal=$(expr $llogTotal + $plogTotal|awk '{print $1 / 1073741824}');echo $ssd;echo " LLOG consumption: $llogGib";echo " PLOG consumption: $plogGib";echo " Total log consumption: $allGibTotal";done;sleep 30; done ;

Eksempel på utdata

Fri Feb 12 06:40:51 UTC 2021  

529dd4dc--xxxx-xxxx-xxxx-xxxxxxxxxxxx
   memCongestion:0 >> This value is higher than 0 ( ranger 0-250 )
   slabCongestion:0
   ssdCongestion:0
   iopsCongestion:0
   logCongestion:0
   compCongestion:0
   memCongestionLocalMax:0
   slabCongestionLocalMax:0
   ssdCongestionLocalMax:0
   iopsCongestionLocalMax:0
   logCongestionLocalMax:0
   compCongestionLocalMax:0
529dd4dc-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx
    LLOG consumption: 0.270882
    PLOG consumption: 0.632553
    Total log consumption: 0.903435

Manus 2

vsish -e ls /vmkModules/lsom/disks/ 2>/dev/null | while read d ; do echo -n ${d/\//} ; vsish -e get /vmkModules/lsom/disks/${d}WBQStats | grep "Number of elements in commit tables" ; done | grep -v ":0$"

Eksempelutdata
(Dette er bare på hurtigbufferdisker, du kan ignorere eventuelle resultater fra kapasitetsdisker)

52f395f3-03fd-f005-bf02-40287362403b/   Number of elements in commit tables:300891
526709f4-8790-8a91-2151-a491e2d3aec5/   Number of elements in commit tables:289371

Konfigurasjonsverdiene for scrubber ble endret i vSAN 6.7, P04- og vSAN 7.0 U1 P02-utgivelser for å skrubbe objekter med høyere frekvens. Denne endringen fører til vedvarende navigeringsfremdrift for hvert objekt oftere enn før. Hvis det er inaktive objekter i klyngen, akkumuleres skrubber for å begå tabelloppføringer for disse objektene ved LSOM. Til slutt fører akkumuleringen til overbelastning av LSOM-minnet.

Inaktive objekter i denne sammenhengen refererer til objekter som ikke er tilknyttet, slått av VM-er, repliserte objekter og så videre.

1. Sett problemverten i vedlikeholdsmodus med Sikre tilgjengelighet, og start deretter verten på nytt.
2. Demonter og monter diskgruppene for hver vert på nytt ved hjelp av Sikre tilgjengelighet.

1. Endre scrubberfrekvensen til en gang per år:

esxcfg-advcfg -s 1 /VSAN/ObjectScrubsPerYear​​​​

2. Deaktiver vedvarende indikatorinntaker:

esxcfg-advcfg -s 0 /VSAN/ObjectScrubPersistMin