「コミット テーブルの要素数」が多いため、vSAN ノードで LSOM メモリの輻輳が発生する (vSAN 6.7 U3/vSAN 7.0 U1)
search cancel

「コミット テーブルの要素数」が多いため、vSAN ノードで LSOM メモリの輻輳が発生する (vSAN 6.7 U3/vSAN 7.0 U1)

book

Article ID: 320831

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

免責事項：これは英文の記事「vSAN nodes experience LSOM Memory congestion due to high "Number of elements in commit tables" (vSAN 6.7 U3/vSAN 7.0 U1)」の日本語訳です。
記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。
 
 
このナレッジベース記事では、特定のビルド vSAN 6.7 P04、vSAN 7.0 U1 P02 (vSAN 7.0 U1c) での LSOM メモリの輻輳の問題に対処します。

Symptoms:

コミット テーブルの要素数が 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
スクリプト 1：すべてのvSANホストで既存のLSOMメモリの輻輳を確認します 
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 ;

出力例：

529dd4dc-####-####-####-###############
   memCongestion:### >> This value will be higher than 0
   slabCongestion:0
   ssdCongestion:0
   iopsCongestion:0
   logCongestion:0
   compCongestion:0
   memCongestionLocalMax:0
   slabCongestionLocalMax:0
   ssdCongestionLocalMax:0
   iopsCongestionLocalMax:0
   logCongestionLocalMax:0
   compCongestionLocalMax:0 
529dd4dc-####-####-####-###############
    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 つのディスクグループの出力例（キャパシティディスクは無視します）：

529395f3-####-####-####-###############/   Number of elements in commit tables:300891    >> Disk Group affected ( = Value > 100K )  
526709f4-####-####-####-###############/   Number of elements in commit tables:289371    >> Disk Group affected ( = Value > 100K )

Environment

以下の vSphere / vSAN リリースで、この特定の LSOM メモリ輻輳（LSOM Memory Congestion） の原因が確認されています：
 
vSAN 6.7.x:
vSAN 6.7 U3 P04 ( 17167734 ) から、6.7 U3 P05 ( 17700523 ) 未満が含まれます：
  • ESXi 6.7 Update 3 P04: 17167734
  • ESXi 6.7 Update 3 EP18: 17499825
vSAN 7.0.x
vSAN 7.0 U1c ( 17325551 ) から、7.0 U2 GA ( 17630552 ) 未満が含まれます：
  • ESXi 7.0 Update 1c ( 17325551 )
  • ESXi 7.0 Update 1d ( 17551050 )

Cause

大量のコミット テーブル エントリによる LSOM メモリの輻輳。

スクラバ構成値は、vSAN 6.7 P04 および vSAN 7.0 U1 P02 リリースで変更され、より高い頻度でオブジェクトをスクラブします。
これにより、各オブジェクトのスクラバの進行が以前よりも頻繁に持続します。
クラスタにアイドル状態のオブジェクトがある場合、スクラバによって作成されたこれらのオブジェクトのコミット テーブル エントリは LSOM に累積されます。
最終的に、累積によって LSOM メモリの輻輳が発生します。

このコンテキストでのアイドル オブジェクトとは、関連付けられていないオブジェクト/パワーオフになっている仮想マシン/レプリケートされたオブジェクトなどを意味します。

Resolution

これは、次の 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 で修正をリリースしました。


Workaround:

注：ユーザーが LSOM メモリの輻輳を事前に確認していない場合でも、次の設定変更を適用することを推奨します。

  1. スクラバの頻度を年に 1 回に変更する。 
    # esxcfg-advcfg -s 1 /VSAN/ObjectScrubsPerYear
  2. スクラバの保持タイマーを無効にする。 
    # 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
  • ホスト全体のすべてのディスクグループで「コミット テーブルの要素数」の値を特定したら、次の手順を降順で実行します（値の最も大きいホスト/ディスクグループから値の最も小さいホスト/ディスクグループ）。
    1. [アクセシビリティの確保] オプションを使用してホストをメンテナンス モードにします（ホストを再起動する必要がある場合のみ）。
    2. または、CLI/ユーザー インターフェイスを使用してディスクグループをアンマウントおよび再マウントします（アクセシビリティの確保）。
    3. クラスタ内のすべてのノードで、ステップ 1 または 2 のいずれかを 1 つずつ順番に実行します（降順）
  • 上記のタスクがすべてのホストに対して実行されたら、クラスタ内のすべてのホストに対して次の構成オプションを設定します。
    1. スクラバの頻度を年に 1 回に変更する。 
      # esxcfg-advcfg -s 1 /VSAN/ObjectScrubsPerYear
    2. スクラバの保持タイマーを無効にする。 
      # esxcfg-advcfg -s 0 /VSAN/ObjectScrubPersistMin


Additional Information

Impact/Risks:
コミット テーブルのエントリ数が多い場合に発生する LSOM メモリの高輻輳によるパフォーマンスの低下。

Powered by Wolken Software