VxRail: 노드에 높은 LSOM 정체가 발생할 수 있음

참고: VMware KB 82619(외부 링크)를 기반으로 제공된 정보입니다. 잠재적인 최신 업데이트에 대해서는 문서를 검토하십시오.

VxRail 버전 4.7.511-526 및 7.0.130-132를 실행할 때 다음과 같은 문제가 발생할 수 있습니다.

• "Number of elements in the commit tables"가 100,000개를 초과하며 몇 시간 동안 감소하지 않음
• vSAN 데이터스토어의 파일 및 폴더를 볼 수 없음
• 심각한 성능 저하
• LSOM(Local Log Structured Object Management) 메모리 혼잡도가 높은 하나 이상의 노드입니다(명령 1 참조).
• "Number of elements in the commit tables"가 100,000개 초과(명령 2 참조).
• 클러스터의 모든 노드에 전파된 메모리 정체
• vmkernel.log의 로그 메시지:
  • LSOM: LSOM_ThrowCongestionVOB:3429: Throttled: Virtual SAN node "HOSTNAME" maximum Memory congestion reached.
• vobd.log 및 vmkernel.log의 로그 메시지
  • LSOM_ThrowAsyncCongestionVOB:1669: LSOM Memory Congestion State: Exceeded. Congestion Threshold: 200 Current Congestion: 204.

다음 스크립트 명령을 사용하여 호스트에 이 문제가 발생할 수 있는지 확인할 수 있습니다.
스크립트 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 ;

샘플 출력

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

스크립트 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$"

샘플 출력
(캐시 디스크에만 해당하므로 용량 디스크의 결과는 무시할 수 있음)

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

더 높은 빈도로 개체를 스크러빙하도록 vSAN 6.7 P04 및 vSAN 7.0 U1 P02 릴리스에서 스크러버 구성 값이 수정되었습니다. 이 변경으로 인해 각 오브젝트의 스크러버 진행이 이전보다 더 자주 유지됩니다. 클러스터에 유휴 오브젝트가 있는 경우 스크러버는 LSOM에서 이러한 오브젝트에 대한 커밋 테이블 항목을 누적합니다. 결국 누적으로 인해 LSOM 메모리 정체가 발생합니다.

이 컨텍스트에서 유휴 상태인 오브젝트는 연결되지 않은 오브젝트, 전원이 꺼진 VM, 복제된 오브젝트 등을 나타냅니다.

1. Ensure Accessibility를 사용하여 문제가 있는 호스트를 유지 보수 모드로 전환한 다음 호스트를 재부팅합니다.
2. Ensure Accessibility를 사용하여 각 호스트의 디스크 그룹을 마운트 해제했다가 다시 마운트합니다.

1. 스크러버 빈도 를 1년에 한 번으로 변경합니다.

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

2. 스크러버 지속 타이머를 비활성화합니다.

esxcfg-advcfg -s 0 /VSAN/ObjectScrubPersistMin