VxRail: Вузли можуть відчувати високу затору LSOM

Примітка: інформація надана на основі VMware KB 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