Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
コミット テーブルの要素数が 10 万を超えており、何時間経過しても減少しない（以下のスクリプト 2 を参照） または 以下のいずれかの状況に一致する。 1 台以上の vSAN クラスタ ノードで LSOM メモリの輻輳が発生すると、vSAN データストア上のファイルとフォルダを表示できない場合があるLSOM メモリの輻輳によりクラスタのパフォーマンスが大幅に低下する 1 台以上のノードで LSOM メモリの高輻輳が発生する「コミット テーブルの要素数」が 10 万を超えている（以下のスクリプト 2 を参照）メモリの輻輳がクラスタ内のすべてのノードに伝達される。vmkernel.log に次のメッセージが記録される。 LSOM: LSOM_ThrowCongestionVOB:3429: Throttled: Virtual SAN node "HOSTNAME" maximum Memory congestion reached.LSOM: LSOM_ThrowCongestionVOB:3429: Throttled: Virtual SAN node "HOSTNAME"maximum Memory congestion reached ESXi ホストで以下のスクリプトを実行すると LSOM メモリの輻輳を確認できる。 スクリプト 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 ; script-1 からの出力例： 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$" ホスト上の 2 つのディスクグループの出力例： 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 (vSAN 7.0 U1c) での LSOM メモリの輻輳の問題に対処します。
スクラバ構成値は、vSAN 6.7 P04 および vSAN 7.0 U1 P02 リリースで変更され、より高い頻度でオブジェクトをスクラブします。これにより、各オブジェクトのスクラバの進行が以前よりも頻繁に持続します。クラスタにアイドル状態のオブジェクトがある場合、スクラバによって作成されたこれらのオブジェクトのコミット テーブル エントリは LSOM に累積されます。最終的に、累積によって LSOM メモリの輻輳が発生します。 このコンテキストでのアイドル オブジェクトとは、関連付けられていないオブジェクト/パワーオフになっている仮想マシン/レプリケートされたオブジェクトなどを意味します。
コミット テーブルのエントリ数が多い場合に発生する LSOM メモリの高輻輳によるパフォーマンスの低下。
これは、次の vSphere/vSAN リリースで発生します。 ESXi 7.0 Update 1d ビルド：17551050 ESXi 7.0 Update 1c ビルド： 17325551 ESXi 6.7 Update 3 P04 ビルド： 17167734 Workaround セクションを確認して手順を実行します。 VMware エンジニアリング チームはこの問題を認識しており、vSAN 6.7 P05 および vSAN 7.0 U2 GA で修正をリリースしました。
注：ユーザーが LSOM メモリの輻輳を事前に確認していない場合でも、次の設定変更を適用することを推奨します。 スクラバの頻度を年に 1 回に変更する。 # esxcfg-advcfg -s 1 /VSAN/ObjectScrubsPerYear スクラバの保持タイマーを無効にする。 # esxcfg-advcfg -s 0 /VSAN/ObjectScrubPersistMin すでに高いメモリ輻輳の問題が発生しているすべてのホストを修正するには、「コミット テーブルの要素数」をクエリして、以下の手順を実行することを推奨します。 クラスタ内のすべてのホストで次のコマンドを実行して、10 万を超える各キャッシュ ディスクの LSOM コミット テーブルの使用量を確認します。 # 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$" ホスト上の 2 つのディスクグループの出力例： 52f395f3-03fd-f005-bf02-40287362403b/ Number of elements in commit tables:300891 526709f4-8790-8a91-2151-a491e2d3aec5/ Number of elements in commit tables:289371 ホスト全体のすべてのディスクグループで「コミット テーブルの要素数」の値を特定したら、次の手順を降順で実行します（値の最も大きいホスト/ディスクグループから値の最も小さいホスト/ディスクグループ）。 [アクセシビリティの確保] オプションを使用してホストをメンテナンス モードにします（ホストを再起動する必要がある場合のみ）。または、CLI/ユーザー インターフェイスを使用してディスクグループをアンマウントおよび再マウントします（アクセシビリティの確保）。クラスタ内のすべてのノードで、ステップ 1 または 2 のいずれかを 1 つずつ順番に実行します（降順） 上記のタスクがすべてのホストに対して実行されたら、クラスタ内のすべてのホストに対して次の構成オプションを設定します。 スクラバの頻度を年に 1 回に変更する。 # esxcfg-advcfg -s 1 /VSAN/ObjectScrubsPerYear スクラバの保持タイマーを無効にする。 # esxcfg-advcfg -s 0 /VSAN/ObjectScrubPersistMin