VMware vSphere Distributed Services Engineによるサーバー最適化：CPU一人に「すべての重荷」を背負わせない – ITFROMZERO

Table of Contents

CPUが「何でも屋」を強いられる苦悩

NVIDIA BlueField-2カードを搭載したDell PowerEdge R750サーバーでvSphere 8を半年以上運用してみて、ある現実に気づきました。それは、CPUリソースが過剰に浪費されているということです。通常、CPUリソースの約20〜30%（デュアルソケットシステムでは8〜12コアに相当）が、単なる「インフラ管理」タスクのために消費されています。

パケットのカプセル化（encapsulation）、NSXファイアウォールの検査、ストレージトラフィックの管理といった作業は、膨大なリソースを食いつぶします。大規模なデータベースやI/O負荷の高いアプリケーションを実行すると、CPUオーバーヘッドによってレイテンシ（遅延）が急増します。ここで真価を発揮するのがvSphere Distributed Services Engine (DSE)です。メインCPUにあらゆる処理を押し付けるのではなく、ネットワークとセキュリティの負荷をすべてDPU（Data Processing Unit）、つまりネットワークカード上の専用チップに肩代わりさせるのです。

vSphere Distributed Services Engineの仕組み

簡単に言うと、vSphere DSEはDPUカードをメインCPUと並行して動作する「有能なアシスタント」に変えます。このとき、サーバーでは2つのESXiインスタンスが動作することになります。1つは従来のx86 CPU上で動作するフルバージョン、もう1つはDPUカードのARMコア上で動作する軽量版です。

旧来のアーキテクチャでは、Distributed Switchを通過するすべてのパケットは、チェックのためにメインCPUを経由する必要がありました。vSphere 8はこのルールを変えました。データフローは仮想マシン（VM）から直接DPUに送られ、「その場」で処理されます。これにより、メインCPUはアプリケーションのロジック処理に完全に集中できるようになります。

DPU – 単なるネットワークカードではない

NVIDIA BlueFieldやAMD PensandoといったDPUシリーズは、実質的には小型のコンピュータです。独自のCPU、RAM、OSを備えています。vCenterに統合すると、これらは単なるNIC（ネットワークカード）ではなく、真のハードウェアアクセラレータ（Hardware Accelerator）として認識されます。

実務的な導入プロセス

DSEの導入には、ハードウェアの綿密な準備が必要です。カードを挿せばすぐに動くというわけではなく、以下のステップに注意する必要があります。

1. 互換性とファームウェアの確認

まず、VMwareのHCL（互換性リスト）を念入りにチェックしてください。私は以前、ファームウェアが古いためにBlueField-2カードが正しく認識されず、午前中を丸ごと無駄にしたことがあります。DPUのファームウェアが、インストール予定のESXiバージョンと同期していることを確認してください。

サーバーのBIOSで、以下のオプションを有効にします：

SR-IOV: Enable（リソース割り当てに必須）。
IOMMU / VT-d: メモリへの直接アクセスを許可するモード。
PCIe Slot Bifurcation: ベンダーのドキュメントに従い、通常はAutoまたはx16に設定。

2. vSphere Lifecycle Manager (vLCM) による並行インストール

最大の違いは、ホストにESXiをインストールしてから後で考えるのではなく、vLCMを使用してホストとDPUの両方に同時にイメージをデプロイすることです。

vCenterでESXiベースイメージを含むクラスターイメージを作成します。
対応するベンダーアドオン（例：NVIDIA BlueField-2アドオン）を追加します。
修正（Remediation）を選択する際、「Enable Distributed Services Engine」にチェックを入れます。

インストール完了後、以下のコマンドを使用してDPUが正常に動作しているか確認します：

# ホスト上のDPUデバイスを一覧表示
esxcli network ens dpu list

# vmnicの接続ステータスを確認
esxcli network ens dpu get -n vmnic0

3. Distributed Switch (vDS) の設定

オフロード機能を有効にするには、バージョン8.0以降のvSphere Distributed Switchを作成する必要があります。

Network Offloads Modeの項目で、NoneからDPUに変更します。
DPUのアップリンクをスイッチに割り当てます。
その後作成されるポートグループは、自動的にハードウェアアクセラレーションの恩恵を受けます。

システムにNSXが導入されている場合、マイクロセグメンテーションのルールはDPU上のARMチップに直接プッシュされます。これにより、ネットワークカードの入り口で攻撃を阻止できるようになります。

数値による効果の検証

システムが実際にオフロードされているかどうかを確認するには、vsishツールを使用するのが最も正確です。これはESXiのカーネル層を覗き見るためのツールです。

# オフロードされたパケットの統計を確認
vsish -e get /net/portsets/vSwitch0/ports/[VM_ID]/vmware/offloadStats

offload packetsの数値が継続的に増加していれば、設定は成功です。

6ヶ月間の実戦投入後の記録

vSANとNSXのクラスターをDSEモデルに移行した結果、最も価値のあった3つの変化を記録しておきます：

CPUの解放： 継続的にバックアップを実行しているホストでは、CPU負荷が40%から約15%に低下しました。システム全体の動作が明らかにスムーズになりました。
帯域幅の最大化： 25Gbpsのラインレートを安定して達成。ネットワークカーネルとのリソース競合がなくなったため、アプリケーションのレイテンシが約30%減少しました。
独立したセキュリティ： 万が一、ESXiのパッチの不具合でメインカーネルがハングアップしても、DPU上のファイアウォールルールは維持され、内部のVMを保護し続けます。

ただし、注意点として、vSphere DSEにはEnterprise Plusライセンスが必要です。また、ネットワークカード上で動作する組み込みOSを管理することになるため、トラブルシューティングには通常より時間がかかる場合があります。

結び

DSEは単なる新機能ではなく、サーバーのパワーを再定義する手法です。CPUは収益を生む業務（アプリの実行）に専念させ、パケットの「運び屋」業務はDPUに任せるべきです。インフラの刷新を計画しているなら、今からSmartNICに投資することは、長期的には非常に経済的な選択となるでしょう。