仮想化管理の経験がある方なら、SAN上でLUNを細かく分割し、VMFSデータストアをフォーマットしてからESXiに割り当てるという骨の折れる作業に馴染みがあるでしょう。この手法は、中に入れる写真のサイズが決まっていないのに、先に固定サイズの額縁を作ろうとするようなものです。柔軟性に欠け、管理に非常に多くの時間を費やすことになります。
VMware vSphere Virtual Volumes (vVols) は、このゲームのルールを根本から変えます。扱いにくい「コンテナ」(LUN)を管理する代わりに、個々の仮想マシン(VM)オブジェクトを直接管理できるようになります。現代のシステム管理者を単純作業から解放する、vVolsという進化のステップについて詳しく見ていきましょう。
実務における違い:従来のLUN vs vVols
従来のアーキテクチャでは、ストレージ管理者とVMware管理者の意思疎通がボトルネックになることがよくありました。例えば、高いIOPSを必要とする SQL Server用のVMが必要な場合、ストレージ管理者は2TBのLUNを割り当てます。しかし、そのLUN上に配置されたすべてのVMは、パフォーマンス、スナップショット、レプリケーションポリシーが一律に制限されてしまいます。設定を変更したい場合は、VMを別のLUNに移行(Migrate)する必要があり、完了まで数時間待たされることも珍しくありません。
vVolsを導入すると、従来のLUNという概念は完全に消滅します。ストレージデバイスは個々の仮想ディスクファイル(.vmdk)を直接「認識」するようになります。VMを作成する際、vCenterは単に「100GBのディスクを、SSDの速度で、レイテンシ5ms以下、自動暗号化を有効にして作成せよ」と命令を出すだけです。SAN側はこの要求を数秒で自動的に実行します。もう手動でLUNを切り出す必要はありません。
私がDell PowerStoreやPure Storageなどの最新のSAN製品でvVolsを導入した際、その違いは一目瞭然でした。ポリシーを介した詳細なハードウェア制御により、Proxmoxや一般的な共有ストレージを用いた手動管理に比べて、システム運用が圧倒的にスムーズになります。
vVolsのメリットとデメリット
メリット
- VMが停止しないスナップショット (No Stun): スナップショット処理がSANのハードウェアレベルで直接実行されるため、巨大なスナップショットを削除する際にVMが数秒間フリーズする(スタンする)現象が発生しなくなります。
- SPBMによる自動化: VMに「Gold」というタグを付ければ自動的にSSD上に配置され、「Bronze」ならHDDへ移動するといった運用が可能です。すべてがポリシーに基づいて自動で行われます。
- 容量の節約: vVolsはストレージアレイのシンプロビジョニングを最大限に活用します。実際にVMがデータを書き込んだ分だけ、物理容量が消費されます。
デメリット
- VASAプロバイダーへの依存: ストレージベンダーが提供するVASAプロバイダーに障害が発生すると、vVolsの管理操作(作成や削除など)ができなくなります。
- 証明書の設定: vCenterとストレージアレイ間での証明書(Certificate)のやり取りが必要で、初心者には設定が少し複雑に感じられる場合があります。
覚えておくべき3つのコアコンポーネント
- VASA Provider: vCenterとストレージ間の「通訳」の役割を果たします。これにより、vCenterはSANが持つ機能(レプリケーション、重複排除など)を理解できるようになります。
- Storage Container: vVols用にSAN上で定義された論理的な容量枠(クォータ)です。物理的なパーティションではありません。
- Protocol Endpoint (PE): ESXiからの論理的なアクセスポイントです。何百ものLUNパスを管理する代わりに、ESXiは数個のPEを経由して接続するだけで済みます。
vVolsの具体的な設定ステップ
ステップ1:VASA Providerの登録
vCenter Server > 設定 > ストレージプロバイダーに移動します。追加をクリックし、SANベンダーから提供されたVASAのURLを入力します。通常、URLは https://<storage-ip>:8443/vasa/version.xml のような形式になります。追加後、ステータスが「Active」になっていることを確認してください。
# PowerCLIを使用してプロバイダーのステータスを素早く確認する
Get-VasaProvider | Select Name, Status, Url
ステップ2:vVolsデータストアの作成
データストア > 新しいデータストアを選択し、タイプとして VVOL を選びます。SAN上の利用可能なストレージコンテナがリストアップされるので、対象を選択して名前を付けます。このプロセスは、従来のVMFSフォーマットよりもはるかに高速です。
ステップ3:ストレージポリシー (SPBM) の作成
これがvVolsの真髄です。データストアを手動で選ぶのではなく、ポリシーにデータの保存場所を決定させます。
- ポリシーおよびプロファイル > 仮想マシンストレージポリシー > 作成を選択します。
- ポリシー構造で、使用しているストレージベンダーのルールを選択します。
- パフォーマンスクラス (IOPS)、レプリケーション、暗号化などのパラメータを設定します。
PowerCLIによるスマートな運用
大規模な環境では、個々のVMを目視で確認するのは非効率です。私はよくスクリプトを使用して、ポリシーに違反しているVMがないかスキャンします。もしステータスが Non-Compliant(非準拠)であれば、すぐにSAN側のリソースを確認する必要があります。
# 全仮想マシンのポリシー準拠状況をスキャンする
$report = Get-VM | Get-SpbmEntityConfiguration
$report | Where-Object {$_.ComplianceStatus -ne "Compliant"} | Select Entity, ComplianceStatus
実務的なアドバイス:いつvVolsへ移行すべきか?
vVolsは強力ですが、あらゆる規模の環境にとっての万能薬ではありません。例えば、ホストが2台だけで、一般的なNASからiSCSI接続しているようなラボ環境であれば、シンプルなVMFSのままが良いでしょう。vVolsが真に価値を発揮するのは以下のようなケースです。
- 50台以上のVMがあり、それぞれ異なるパフォーマンス要件がある場合。
- 大規模なデータベースに対して、システムに負荷をかけずに頻繁にスナップショットを取得する必要がある場合。
- 企業としてSDDC (Software-Defined Data Center) を目指し、APIによる完全な自動化を推進している場合。
vVolsへの移行は、フィーチャーフォンからスマートフォンへアップグレードするようなものです。ポリシーや証明書の扱いに慣れるまで少し時間はかかるかもしれませんが、それによって得られる管理効率の向上は、その苦労に見合う十分な価値があります。皆さんの導入が成功することを願っています!

