VxRail：节点可能会遇到严重的 LSOM 拥塞

提醒：信息基于 VMware 知识库文章 82619（外部链接）提供。查看文章以了解任何潜在的较新更新。

运行 VxRail 版本 4.7.511-526 和 7.0.130-132 时，您可能会遇到以下问题：

• “提交表中的元素数量”超过 100k，并且在几个小时内不会减少。
• 无法查看 vSAN 数据存储上的文件和文件夹
• 性能严重下降
• 一个或多个节点呈现严重的本地日志结构化对象管理 （LSOM） 内存拥塞（请参阅命令 1）。
• “提交表中的元素数量”超过 100k（请参阅命令 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 内存拥塞。

此上下文中的空闲对象是指未关联、已关闭电源的虚拟机、复制的对象等。

1. 将问题主机置于维护模式，并采用“Ensure Accessibility”选项，然后重新启动该主机。
2. 在采用“Ensure Accessibility”选项的情况下，卸载和重新装载每个主机的磁盘组。

1. 将清理器频率更改为 每年一次：

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

2. 禁用清理器持续计时器：

esxcfg-advcfg -s 0 /VSAN/ObjectScrubPersistMin