VMware vSphere Virtual Volumes (VVols) のご紹介

はじめに

VMware vSphere Virtual Volumes は、VMware vSphere 6.0 に初めて搭載されたストレージの機能です。VMware が十数年に渡り提供してきた Hypervisorである、ESX / ESXi はブロックストレージとして、LUN + VMFS の仕組みを踏襲してきました。VVols はこの枠組みを超える革新的な機能で、vSphere ユーザーに多くのメリットを提供します。今回は、この魅力溢れる新機能についてご紹介いたします。なお、”Virtual Volumes” や “VVols” という言葉ですが、仕組み全体を指す場合と、仮想マシンのオブジェクトを指す場合、またボリュームをマウントする際のデータストアとしての3通りの意味があります。混乱を避けるため、本Blogでは以下のように使い分けたいと思います。（一般的な使い分けではありませんのでご了承下さい）

• 全体的な仕組みとしての VVols・・・Virtual Volumes
  
• オブジェクトとしての VVols・・・ VVols もしくは VVol（特定の単一オブジェクトを指す場合）
  
• データストアとしての VVols・・・VVol データストア
  

Virtual Volumes 登場の背景

ESX / ESXiが長らく踏襲してきた LUN + VMFS という形、とりわけ、VMFS は軽く高機能なクラスタファイルシステムで、バージョンアップと共に、SCSI Reservation の最適化や取り扱える最大ファイルサイズの拡張、VAAIで代表される各種オフロードなど、より大規模環境をハイパフォーマンスでストレス無く扱えるようその機能を拡張してきました。しかしながら、様々な Tier (パフォーマンス要件や可用性要件) を持つシステムが仮想環境に混在するようになると、あらかじめパフォーマンス、可用性、必要容量などを想定して切り出す必要のある LUN という概念では時として柔軟な対応が出来ず、例えば、データストアに空き容量はあるけど要件にあわない・・・、など無駄が生じたり、必要な機能を持つ LUN を新規に切り出すために時間を要したりなど、仮想環境の利点である迅速性を阻害するリスク要因の1つにもなってきました。

また、様々な Tier をサポートするために、同一ホストへの（NFSとFCなどの）異なるストレージ装置や、異なるRAIDレベル、異なるディスクデバイス（SSD、FC、NL-SAS等）が混在して接続されるケースも多くなり、管理者がそのストレージ特性を理解して仮想マシンを最適に配置しなければならない、という管理負荷の面での問題点も顕在化する可能性がありました。



この問題に対処するため、Virtual Volumes では、あらかじめ予測と準備が必要な LUN という仕組みを廃止し、各仮想マシンディスクを1個のVVolオブジェクトとしてストレージが直接管理する仕組みを提供します。このVirtual Volumes の管理側のメリットは大きく、例えば以下のようなことが可能となります。

• ストレージ側で、あらかじめ容量や可用性などを定義したLUNを作成する必要はない
  
• 仮想マシン作成時に必要な容量、可用性を担保したVVolsがダイナミックに切り出される
  
• 仮想マシンに必要なストレージの機能が、vSphere側からポリシーとして定義可能
  
• 豊富なストレージ機能を直接仮想マシンディスク（VVols）に作用させることが可能
  
• ストレージの機能を利用した、仮想マシンディスク毎のバックアップリストアが可能
  

Virtual Volumes 全体像

Virtual Volumes はいくつかのコンポーネントが連携して動作します。全体像は以下の通りです。

• VASA プロバイダ
  
  • ストレージベンダー提供のコンポーネント
  • VVols の作成や複製、削除に関わるコントロールプレーンの機能を提供
    仮想マシンの作成、電源オン、スナップショット作成などの操作の際、必要な VVols を作成する
  • ストレージに実装された機能をvSphere側から把握するためのアクセスポイント
    一つの VASA プロバイダーから複数アレイ管理も可能
  • 実装方法はベンダー依存
    専用管理サーバー（仮想アプライアンス）
    ストレージ Firmware
  • ESXi と vCenter Server は VASA プロバイダーと接続
    
• プロトコルエンドポイント
  • ストレージ管理者が定義する、ESXi からのI/O アクセスポイント
    ラウンドロビンやMRU 等のパスポリシーもプロトコルエンドポイントに対して設定される
  • 容量提供を目的としない管理 LUN / NFS 共有の位置づけ
    実容量を持つ、各仮想マシンの VVols は、プロトコルエンドポイントの後ろに存在するサブLUNとして存在
  • 各LUNに対してI/Oパスが定義される従来の方法に比べ、アクセスポイント数を大きく削減
  • SAN と NAS のすべてのプロトコルと互換性

    iSCSI、NFS v3、FC、FCoE
    

• ストレージコンテナ
  
  • ストレージ管理者が定義する、VVols を収容する論理的プール
    
  • プロトコルエンドポイントの背後で容量を定義
    
  • 定義や最大コンテナ数はストレージ装置に依存
    
  • vSphere 管理面からはデータストアの概念
    

上記の他、データサービスとしてストレージの機能を定義する領域があります。定義された機能は VASA プロバイダ経由で vCenter Server へ通知され、仮想マシン作成の際利用されます。
既存の LUN + VMFS と、Virtual Volumes におけるコンポーネントの実装の比較は以下の通りです。I/O アクセスや容量、サービスレベルを画一的に定義していた LUN を、それぞれプロトコルエンドポイント、ストレージコンテナ、ストレージポリシーに分解、定義していることが分かります。また、繰り返しになりますが、LUN は事前に作成され、複数の仮想マシンを収容しますが、Virtual Volumes では、仮想マシン作成の際に VVols が直接ストレージに作成され、オブジェクトの粒度も仮想マシンディスクそのものとなります。

Virtual Volumes セットアップ

Virtual Volumesは、ストレージと連携した機能です。このため、Virtual Volumes 利用には対応したストレージが必要となります。Virtual Volumes をサポートするストレージに関しては、こちらをご確認下さい。また、Virtual Volumes が利用可能な vSphere の License に関しては、こちらからご確認いただけますが、Standard 以上となっています。
セットアップの際も、まずはプロトコルエンドポイントや VASA プロバイダ、ストレージコンテナ等をストレージ装置側で設定しておく必要があります。セットアップ方法はストレージ装置毎に様々で、例えば VASA プロバイダが、ストレージコントローラに内蔵されていて、サービスを起動させるのみという簡単セットアップというストレージ装置もあれば、仮想アプライアンスをデプロイしてセットアップを完了させるストレージ装置もあります。ストレージコンテナも、装置丸ごと1つ見せることを基本とするストレージ装置もありますし、最初から細かくストレージコンテナを定義できる物もあります。これらの設定方法に関しては、各ストレージベンダーのマニュアルをご確認下さい。

ストレージ装置側で、上記コンポーネントの定義や、ストレージ装置へのESXiホストの登録などが完了すれば、そこから先は vSphere 側からセットアップを進めることが出来ます。

1. VASAプロバイダをvCenter Serverに登録します。
VASAプロバイダの登録自体は非常に簡単です。登録も各ストレージ装置毎に方法が異なりますが、HP社の3PAR StoreServ （以下3PAR）におけるVASAプロバイダ登録画面は以下の通りです。


2. プロトコルエンドポイントの認識
通常の HBA のリスキャンを実行することにより、ESXi ホストにプロトコルエンドポイントが見えてきます。



こちらもストレージ装置により様々ですが、ブロックデバイスでは、プロトコルエンドポイント用に非常に小さな LUN が1つ見えます。3PAR の場合はLUN番号が 256 で、512 Byte の小さなLUNとなっています。



ラウンドロビンや MRU 等のパスポリシーもプロトコルエンドポイントに対して設定されていることが分かります。プロトコルエンドポイントがホストから見えると、自動的にその裏側にあるストレージコンテナもホストから見える様になり、データストアとしてマウントすることが可能となります。

3. VVol データストアのマウント
ストレージ装置で作成されたストレージコンテナをVVol データストアとしてESXi ホストにマウントすると仮想マシンの作成が可能となります。仮想マシン作成の際、指定を行うストレージポリシーに関するご説明はこちらをご確認下さい。なお、定義可能なストレージポリシーはストレージ装置により異なります。

VVols オブジェクトの種類と仮想マシン作成時の動作

仮想マシンを作成すると、仮想マシンオブジェクトとして複数の VVol が作成されますが、この VVol にはいくつかの種類があります。この種類と実際のVVol 作成の動作についてご説明します。まず種類ですが、以下の5種に分類されます。

1. Config-VVol・・・仮想マシン構成（vmx ファイル）、ログ
   
2. Data-VVol・・・VMDK やスナップショット
   
3. Swap-VVol・・・Swap ファイル（仮想マシン起動時のメモリスワップ領域）
   
4. Mem-VVol・・・メモリー付きスナップショット取得時やサスペンド等、仮想マシンのメモリデータ
   
5. Other-VVol・・・その他ソリューション用途
   

仮想マシンを作成すると、仮想マシン基本VVolである、1. Config-VVol と、2. Data-VVol が作成されます。次に仮想マシンの電源を On すると、3. Swap-VVol が作成されます。上記キャプチャは、仮想マシン作成の後、PowerOn し、さらに、仮想マシンのメモリ付きスナップショットを取得したときに作成される5個の VVol を示しています。この様に、1つの仮想マシンに対して複数の VVol が作成されますが、データストアブラウザで見ると通常の VMFS ボリュームに作成された仮想マシン同様、1つの仮想マシンのパスの中に各データが保存されているように見えます。つまり、仮想環境の管理者が直接 VVols オブジェクトを意識する必要はありません。

VVols のバインド

直接管理者の目に触れる部分ではありませんが、プロトコルエンドポイント背後に存在する、各 VVols が ESXi ホストからアクセス可能となる仕組みをご説明します。仮想マシンの作成やパワーオン操作に伴い際に作成された VVols はプロトコルエンドポイントのサブ LUN として定義され、バインドという処理を介して ESXi からアクセス可能となります。簡単に申し上げると、バインドはアクセスを必要とする ESXi に対しストレージ装置が作成した VVols オブジェクトを見せてあげる処理、ということになります。具体的には以下の通りです。

1. ESXi が VASA プロバイダ経由でバインド処理を発行
2. ストレージ装置はプロトコルエンドポイント ID と実際の I/O 発行先であるサブ LUN ID （VVols オブジェクト ID ）を応答*
   *NFSの場合は、ファイルパスとなります
3. ホストよりアクセス可能（1：1のマッピングにより排他処理）となります
   

この処理の実行により、ESXi ホストは対象 VVols に対して I/O の実行が可能となります。

Virtual Volumes のメリット

Virtual Volumes のメリットは以下の通りです。

• 豊富なストレージ機能を直接仮想マシンディスク（VVol）に作用させることが可能
  スナップショット、クローン、フラッシュキャッシュ、重複排除、暗号化、リモートレプリケーション…etc
• 仮想ディスク毎に必要なストレージの機能を、vSphere 側からポリシーとして定義可能
  
• アクセスポイントをプロトコルエンドポイントに集約することにより、最大 LUN 数の問題を回避
  

  多数の RDM を運用されているユーザには大きなメリットとなります
  

例えば、vSphere Web Client 上から仮想マシンのスナップショットを取得すると、VMFS 上の仮想マシンであれば、VMFS がサポートする Redo log ベースのスナップショットとなりますが、Virtual Volumes の場合は、同一のオペレーションでストレージベースのスナップショットとなります。特に I/O 要件の高い仮想マシンのバックアップに、VADP + VMFS ベースのスナップショットを利用している場合にはこのメリットは極めて大きく、スナップショット作成時、削除時にほとんどパフォーマンスの劣化の無い安定したバックアップの取得が可能となります。*

　*ストレージがサポートするスナップショットの機能に依存します。

まとめ

リリースされたばかりで対応ストレージがまだ少ない点、ポリシーで定義可能な項目が本来のパフォーマンスや可用性を伴っていない点など、現状では課題も垣間見えるのですが、Virtual Volumes は非常に将来性豊かなストレージの新機能です。また、vSphere の Standard License から利用可能というところも見逃せない点です。今後の機能拡張にもご期待下さい！