VxRail: Noder kan opleve høj overbelastning af LSOM
Summary: VxRail-noder fra 4.7.511-526 og 7.0.130-132 kan opleve høj hukommelsesoverbelastning, hvilket fører til ydeevne og mulige vSAN-afbrydelser. Der findes en løsning, som kan deaktivere de tjenester, der forårsager problemet. Opgradering til 4.7.530/7.0.200 løser dette problem. Baseret på VMware KB 82619 ...
Symptoms
Bemærk: De angivne oplysninger er baseret på VMware KB 82619(eksternt link). Læs artiklen for at få eventuelle nyere opdateringer.
Når du kører VxRail version 4.7.511-526 og 7.0.130-132, kan du opleve følgende problemer:
- "Antallet af elementer i forpligtelsestabellerne" er mere end 100k og falder ikke over en periode på timer.
- Tab af muligheden for at se filer og mapper i vSAN-datalageret
- Alvorlig forringelse af ydeevnen
- En eller flere noder med høj overbelastning af LSOM-hukommelsen (Local Log Structured Object Management) (se kommando 1).
- "Antallet af elementer i bekræftelsestabellerne" er mere end 100k (se kommando 2).
- Hukommelsesoverbelastning, der har forplantet sig til alle noderne i klyngen.
- Logfører meddelelser i vmkernel.log:
LSOM: LSOM_ThrowCongestionVOB:3429: Throttled: Virtual SAN node "HOSTNAME" maximum Memory congestion reached.
- Logfører meddelelser i vobd.log og vmkernel.log
LSOM_ThrowAsyncCongestionVOB:1669: LSOM Memory Congestion State: Exceeded. Congestion Threshold: 200 Current Congestion: 204.
Følgende scriptede kommandoer kan bruges til at afgøre, om værten muligvis oplever dette problem.
Script 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å output
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
Script 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$"
Eksempel på output
(Dette gælder kun på cachediske; du kan ignorere alle resultater af kapacitetsdiske)
52f395f3-03fd-f005-bf02-40287362403b/ Number of elements in commit tables:300891 526709f4-8790-8a91-2151-a491e2d3aec5/ Number of elements in commit tables:289371
Cause
Scrubber-konfigurationsværdier blev ændret i vSAN 6.7 P04- og vSAN 7.0 U1 P02-udgivelser for at skrubbe objekter med en højere frekvens. Denne ændring resulterer i vedvarende scrubberfremskridt for hvert objekt oftere end før. Hvis der er inaktive objekter i klyngen, akkumulerer skrubberen commit tabelposter for disse objekter ved LSOM. Til sidst fører akkumuleringen til overbelastning af LSOM-hukommelsen.
Inaktive objekter henviser i denne sammenhæng til objekter, der ikke er tilknyttet, slukket for VM'er, replikerede objekter osv.
Resolution
Hvis en vært har et stort antal elementer i bekræftelsestabellerne, som fastlagt i script 2, anbefales et af følgende to trin for at løse overbelastningen.
- Sæt problemværten i vedligeholdelsestilstand med Sørg for tilgængelighed, og genstart derefter værten.
- Afmonter og genmonter hver værts diskgrupper ved hjælp af Sørg for tilgængelighed.
Løsning:
Hvis det ikke er muligt at opgradere, skal du indtil videre stadig implementere følgende avancerede indstillingsændringer for at afhjælpe dette problem.
- Skift skrubberfrekvens til en gang om året:
esxcfg-advcfg -s 1 /VSAN/ObjectScrubsPerYear
- Deaktiver scrubberens persist-timer:
esxcfg-advcfg -s 0 /VSAN/ObjectScrubPersistMin