コメントVMware仮想マシンにはストレージが必要です。VVOL（仮想ボリューム）は、このプロセスを自動化する手段です。これにより、VMware管理者がストレージ管理者とやり取りしてストレージをプロビジョニングする際の遅延を回避できます。ほぼすべてのストレージアレイベンダーがVVOLをサポートしていますが、ユーザーのデータセンターでは大規模な導入は進んでいません。そこで当然の疑問が浮かび上がります。なぜ導入されないのでしょうか？
VVOL スキームは複雑すぎるのでしょうか？ おそらく焦点が限定されすぎているのでしょう。
まとめると、仮想マシン（VM）は、ストレージアレイ内の論理ユニット（LUN）であるVMFSデータストアに保存されるVMDKファイルと考えることができます。NFSベースのアレイでは、データストアはアレイのファイルシステムを使用します。SANでは、VFMSはアレイソフトウェアによってブロックストア上にオーバーレイされます。
SANでは、VMのVMDKファイルによって使用されるLUNをVMに割り当てる必要があります。VVOL方式では、VMDKはVVOL自体がLUNであるVVOLに保存されます。
これらはすべて、VMwareのソフトウェア定義ストレージ（SDS）戦略、そして包括的なソフトウェア定義データセンタービジョンの一部です。SDSは、（VMwareを使用する）データセンターのストレージプレーンを抽象化・仮想化し、その消費量をコントロールプレーンのポリシーで定義された要件に合わせて調整する機能を提供します。
VMwareによると、Virtual Volumesデータストアは容量の境界とアクセスロジックを定義し、プールにプロビジョニングされたVMがアクセスできる一連のデータサービスを公開します。Virtual Volumesデータストアは純粋に論理的な構造であり、必要に応じて、中断することなく、また新しいファイルシステムでフォーマットすることなく、即座に構成できます。
仮想ディスク（VVOLデータストア）は、アレイレベルでのデータ管理の主要単位となります。これにより、Virtual VolumesデータストアはVM中心の容量プールとなり、VM単位の粒度でストレージ操作を実行できるようになり、個々のVMにネイティブのアレイベースのデータサービスをプロビジョニングできるようになります。管理者は、個々のVMに適切なストレージサービスレベルが提供されることを確実にできるようになります。
これを実現するには、VMwareシステムがデータセンター内のどのストレージアレイがVVOLプロビジョニング指示に応答でき、どのアレイが応答できないかを認識する必要があります。ここが複雑な部分です。
VVOLアーキテクチャ
これは、VMware API for Storage Awareness (VASA) スキームを通じて行われます。ストレージアレイは、VASA を使用してサポートするサービスを VMware ESXi (publish) に通知します。つまり、ストレージアレイは VASA プロバイダーです。ESXi はサービス可用性リストを作成します。VMware 管理者は、VM ポリシーを作成する際に、このリストから容量とさまざまなクラスのデータサービスを選択します。ポリシーは、ゴールド、シルバー、ブロンズのような階層構造にすることができ、一部の VM がミッションクリティカル、他の VM がそれほど重要ではない、他の VM が低優先度であるといった状況を反映します。
したがって、ゴールド ポリシーでは、重複排除されずにフラッシュ デバイスに保存される、完全にミラー化されたデータを指定できます。
ポリシーに基づいてVMまたはVMセットを作成し、ストレージのプロビジョニングを自動化できます。これらはすべて、ストレージポリシーベース管理（SPBM）の範疇に入ります。
VVOL には、使用可能な容量、RAID レベル、スナップショットおよびレプリケーションのステータス、可用性、キャッシュ、セキュリティ (暗号化)、重複排除、階層化、プロトコル アクセス ルート、シック/シン プロビジョニングなど、VVOL の機能について説明するメタデータがあります。
アレイには、ファイバーチャネル、NFS、iSCSI など、使用されるアクセスプロトコルを定義するプロトコルエンドポイントがあります。これらのエンドポイントは、ブロックベースアレイ上で LUN として実装され、複数のホストからの複数の VM レベルの VVOL 要求をエンドポイント経由で分割し、アレイソフトウェアによって個別に処理するため、IO デマルチプレクサとも呼ばれます。
アレイはこれらのエンドポイントを介して、異なるVMから個々のVMのVVOLに適用されるIO要求を受信します。アレイコントローラソフトウェアは、これらの要求をRAIDグループやLUNなどの独自の内部抽象化に変換し、処理を実行して、制御対象の個々のSSDまたはディスクドライブにルーティングする必要があります。
VMはVM全体ではなく、単一のVMコンポーネントを扱います。個々のVMのVVOLの数は16以上になる場合があり、例えばVMの基本構成、スワップ、C:およびD:ディスクファイル、クローンセット、2つのスナップショットなどで構成されます。アレイは、以下の範囲をカバーするのに十分なボリュームをサポートする必要があります。
- VMあたりの仮想ディスク数が2倍
- VMの総数を掛ける
- クローンバックアップの数（仮想マシンの数×仮想ディスクの数）×クローンバックアップ
- 差分バックアップの数 - (仮想マシンの数 x (仮想ディスクの数 + 1)) x (保存するスナップショット世代の数 + 1)
- スナップショットのボリューム数 - ( 1 + 仮想ディスクの数) x スナップショットの数
- サスペンションのボリューム - サスペンションの数
- システム構成のボリューム数 - フレキシブルティア機能のボリューム数 + RAIDグループ数 + オプションで作成したボリューム数 + VVOLデータストア数 + 1
アレイではサポートできるボリュームの総数に制限があり、Fujitsu ETERNUS DX200F では最大 1,536 個、DX200 S3 では最大 4,096 個をサポートします。
