vSAN 8.0 U2 以降で DomClientReadCache がデフォルト無効化された件

概要

vSAN 8.0 Update 2 から、読み取り性能に効いてきた DOM クライアント読み取りキャッシュ（DomClientReadCache）がデフォルトで無効化されている。CPU 負荷の軽減が狙いのようだが、小規模データセットでは IO 性能が低下しうる。実機（ESXi 8.0 U3）で実際に変更になっているかを確認し、有効化を検討すべきケースを整理する。

要点

  • vSAN 8.0 U2 以降、/VSAN/DomClientReadCache はデフォルトで 無効（0） になった。
  • 目的は CPU 使用率の削減。大規模データセットではキャッシュヒット率が低く、キャッシュの恩恵よりも CPU コストの方が大きいと判断されたため。
  • 副作用として、ワーキングセットが小さい環境（目安 5GB 未満）では読み取り性能が低下する場合がある。
  • CPU に余裕があり、かつデータセットが小さい環境では、再度有効化することで性能を取り戻せる可能性がある。
  • 実機の ESXi 8.0 U3 で確認したところ、設定値は確かに 0 だった。

DomClientReadCache とは何か

vSAN の I/O パスは、各仮想マシンの側で動く DOM（Distributed Object Manager）クライアントと、オブジェクトごとに存在する DOM オーナーという役割に分かれている。読み取り要求が来ると、まず DOM クライアントが自身のキャッシュ（DOM client read cache）に最近読んだブロックがあるかを確認し、ヒットすればそこで即座に応答する。ヒットしなければ DOM オーナーに問い合わせ、下位レイヤーからデータを取得し、チェックサム検証・展開を経て VM に返す、という流れになる。

つまり DomClientReadCache は、この「DOM クライアント層で完結できる読み取り」を増やすためのメモリ内キャッシュである。ヒットすればストレージ下位層への往復や CPU 処理（チェックサム・伸張など）を省ける。

8.0 U2 で何が変わったのか

vSAN 8.0 Update 2 から、この DomClientReadCache が デフォルトで無効（値 0）に変更された。Broadcom（旧 VMware）のナレッジ記事 KB 313370 でこの挙動と回避策が公式に説明されている。

なぜ無効化したのか。 Broadcom の説明では、DomClientReadCache を無効化すると、特に大規模データセットのシナリオで CPU 使用率が大幅に低下し、全体性能が向上するとされている。理由は、現状のキャッシュサイズでは大規模データに対してヒット率が低く、キャッシュによる性能上のメリットを十分に得られないため。結果として、一般的なケースの性能を優先し、デフォルトで無効化するという判断が下された。

この変更は、キャッシュ管理そのものが消費する CPU 消費を削減する狙いがある。vSAN のモジュールは ESXi カーネル内で動作するため、ホストの CPU が逼迫すると vSAN の性能にも影響がでる。ヒット率の低いキャッシュを維持し続けるよりも、その CPU を I/O 処理に回した方が総合的に速い、という判断と考えられる

影響 — 小規模データセットでの性能低下

ただしこれは万能ではない。KB 313370 は、次のような症状を明記している。

Symptom: ワーキングデータセットが小さい場合（目安として 5GB 未満）、ユーザーは性能低下を観測する可能性がある。

データセットが小さければ、キャッシュサイズが限られていてもワーキングセット全体をキャッシュに収められるため、ヒット率が高くなり、キャッシュの恩恵を十分に受けられる。ところがデフォルトが無効になったことで、こうした小規模環境ではせっかくのキャッシュ効果が失われ、読み取り I/O 性能が落ちてしまう。vSANのユースケース全体を見通した場合に、今回の変更は有効だといえるが、一部の小規模データセットのシナリオでは性能上の欠点が生じるため、ケースバイケースで判断する必要がある

整理すると、トレードオフは次のようになる。

観点キャッシュ無効（デフォルト / 8.0 U2+）キャッシュ有効（回避策で有効化）
大規模データセットCPU 削減・総合性能が向上（ヒット率が低くキャッシュの恩恵は小さい）キャッシュ管理の CPU コストが上乗せされ、恩恵は限定的
小規模データセット（< 5GB 目安）読み取り性能が低下しうるヒット率が高く読み取り性能を回復できる
CPU リソース消費を抑えられるキャッシュ処理分の CPU を消費する

実機での確認（ESXi 8.0 U3）

実際に ESXi 8.0 Update 3 のホストで現在値を確認した。まずビルドとバージョンを確認する。

[root@esx11:~] vmware -vl
VMware ESXi 8.0.3 build-24859861
VMware ESXi 8.0 Update 3

続いて DomClientReadCache の現在値を取得する。

[root@esx11:~] esxcfg-advcfg -g /VSAN/DomClientReadCache
Value of DomClientReadCache is 0

KB 313370 が示すとおり、8.0 U2 以降の挙動が 8.0 U3 でも引き継がれており、デフォルトで無効（0）であることが確認できた

有効化の方法

小規模データセット環境における性能低下懸念の回避策として、次の advanced config オプションでクライアントキャッシュを有効化できる。

[root@esx11:~] esxcfg-advcfg -s 1 /VSAN/DomClientReadCache
# 適用後、値が 1 になっていることを確認
[root@esx11:~] esxcfg-advcfg -g /VSAN/DomClientReadCache
Value of DomClientReadCache is 1

元に戻す（無効化する）場合は -s 0 を指定する。この設定はホストごとの advanced setting のため、クラスタ内の全ホストで統一して適用するのが望ましい。KB では「この回避策は 8.0 U2 より後のバージョンで必要になる」と補足されている。

注意。 KB 313370 上、これは Resolution（恒久対処）ではなく Workaround（回避策）として位置づけられている。可能であれば、設定変更は本番クラスタへ一括適用する前に、必ず検証環境で実ワークロードのベンチマークを取り、CPU 使用率と I/O 性能の両面で効果を確認できることが望ましい

有効化を検討すべきケース

デフォルトの無効設定はあくまで「大半の一般的なケース」を優先したもの。以下の条件に当てはまるなら、有効化を試す価値がある。

  • ワーキングセットが小さい（5GB 未満が目安）。キャッシュに全体が収まりヒット率が高くなるため、読み取り性能の回復が期待できる。
  • CPU に余裕がある。ホストの CPU Ready 値が低く（目安として 1% 未満）、CPU がボトルネックになっていない環境。余った CPU をキャッシュ処理に充てられる。
  • 読み取り主体で、レイテンシに敏感なワークロード。キャッシュヒットによる下位層往復の削減が性能に効きやすい。

逆に、CPU が逼迫している（CPU Ready が高い、高集約率、オーバーサイジング気味）環境や、ワーキングセットが大きくヒット率が見込めない環境では、デフォルトの無効のままにしておくのが無難といえる。有効化すると CPU 負荷が増し、かえって vSAN 全体の性能を損なう可能性がある

まとめ

vSAN 8.0 U2 以降で DomClientReadCache がデフォルト無効化されたのは、大規模データセットにおける低ヒット率と CPU コストのトレードオフを踏まえた、合理的なデフォルト変更であるといえる。一方で、小規模かつ CPU に余裕のある環境では、この変更が読み取り性能の低下として表面化しうるため、ユーザ目線では地震の環境と照らし合わせて有効性を判断したい。自分の環境がどちら側にいるのか、ワーキングセットのサイズと CPU Ready 値を見て判断し、必要に応じて回避策で有効化することが望ましい。「CPU が余っているか」と「データセットが小さいか」の二点が重要となる。

参考情報

  1. Broadcom KB 313370 — Enable DomClientReadCache for the smaller working dataset（症状・原因・回避策の一次情報。2024-05-11 公開）
  2. VMware — Fast and Efficient Reads in vSAN Express Storage Architecture（DOM クライアント読み取りキャッシュを含む ESA の読み取りパス解説）
  3. Broadcom KB 429468 — Host CPU overutilization may negatively impact vSAN performance（vSAN と CPU Ready 値の関係）

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

vSAN OSA更改時の考慮事項

  この投稿は、 vExperts Advent Calendar 2025 の 8 日目です。 文字ばかりですがご容赦ください     この記事の概要 VCF9 のリリースによって vSAN OSA の一部の Hybrid 構成が Deprecate になった。 そのため、 OSA 環境の更改においては ESA へのトランジションの検討が盛んになっている。 一方で、 ESA へのトランジションにおいては、 HCI のメリットの一つであるシームレスな更改手法（玉突き方式）がつかえない、といった 考慮事項も存在する。 本記事では、 vSAN クラスタの更改時によくある考慮事項を紹介する。   想定既存環境 以下のようなサンプル環境の更改を想定する   vSAN OSA クラスタ（ vSAN Ready Node 、クラスタ内の全ノードが更改対象） ライセンスはリテール版を利用し、 HW と更改時期がずれているため、更改対象ではない。 外部ストレージは無し TOR スイッチの HW 更改の対象に含める   ※ OEM ライセンス利用時や、 vSAN Ready Node より上位となる専用アプライアンスを利用している場合、 ライセンスや保守サービスにかかわる考慮事項が追加され、より複雑となることがあるが、本記事では考慮しない。   更改パターン   移行方法とストレージアーキテクチャをベースに大別すると以下の 4 パターンが考えられる。   OSA 玉突き更改 OSA 新規クラスタ ESA 新規クラスタ 分離型新規クラスタ（ vSAN MAX or 外部ストレージ）   更改パターンを選択する際の考慮事項を次項に列挙する     考慮ポイント 実績と安定性 OSA と外部ストレージ構成は実績や安定性の観点で申し分ない ESA も 2022 年にリリースされて以来、大きな不具合もなく現在に至る印象があるが実績の面では OSA や外部ストレージが勝る トラブルシューティングに関しても OSA/ ...
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む