はじめに

vSphere 6 で追加されたストレージの新機能の一つに Virtual Volumes (VVols) があります。この Virtual Volumes は特に Block Storage (FC, iSCSI) にとって非常に良いインパクトを与える機能となっています。一つの LUN に複数の VM の仮想ディスクが格納される仮想環境は、LUN という粒度でしかデータを扱えない Block Storage にとって永く歯がゆいモノでした。

物理環境では、LUN は NTFS, ext4, xfs, VxFS などでフォーマットされ、一つの物理マシン、あるいは、1 セットのクラスタのための LUN でした。このためバックアップ、リストアを LUN 単位で行うことに、何の問題もありませんでした。しかし、仮想環境となり、LUN は VMFS でフォーマットされ、その VMFS の上に多数の仮想ディスクファイルがある状況となります。つまり、一つの LUN に複数の仮想マシンの仮想ディスクが格納されることとなり、一つの LUN 操作 (スナップショットやリストア) が複数の仮想マシンに影響することとなります。これでは、LUN のリストアは一つの仮想マシンだけではなく複数の仮想マシンをリストアすることとなってしまい、バックアップ/リストアの観点からは非常に都合が悪い (むしろ使い物にならない) ことでした。もちろん、vStorage API for Data Protection (VADP) を使い、ストレージのスナップショットに頼らないバックアップを取ることで対応することは出来ます。しかし、ストレージのスナップショットと遠隔レプリケーションによってバックアップを実装したいという要望も少なからずあり、大容量かつクリティカルな環境ほど最後にたたみ込み処理がどうしても必要となってしまう VMware のスナップショットを使う VADP を敬遠するケースも少なからずありました。(Change Block Tracking (CBT) や重複排除を駆使してたたみ込み処理を極小化する努力もあるのですが…この辺嫌な思い出がある方ほどどうしても…)

一方 NFS は、ストレージがファイルシステムを持ち、ストレージ内のどのブロックアドレスに仮想ディスクが配置されているのかを見切ることが出来ます。インテリジェンスのある NFS ストレージであれば、ファイルシステム全体ではなく仮想ディスク単位でスナップショットやリストアを行えるのです。一方 Block Storage は、どのブロックアドレスに仮想ディスクがあるのか見切ることが出来ず、仮想マシン単位でスナップショット、リストアを行うことができません。Block Storage は LUN 上の VMFS ファイルシステムを見切ることが出来ないためです。この状況を一変させるのが VVols となります。

Block Storage における VVols では、VMFS ファイルシステムをなくすことによって、ストレージが仮想ディスクのブロックアドレスを見切れるようになっています。VVols の実装はストレージベンダーに委ねられているのですが、Subsidiary LUN を LUN の中に作成することにより実現しているケースが多いと思われます。Block Storage の VVols における仮想ディスクは、VMFS の時のような仮想ディスクファイルではなく Subsidiary LUN にマップされます。この Subsidiary LUN のアドレスは、Subsidiary LUN をストレージが作成しているのですから当然ストレージが見切っており、結果 Block Storage が仮想ディスク単位にスナップショットやレプリケーションなどのストレージ独自の機能を適用出来ることになります。なお、Subsidiary LUN は t10 でも定義されている標準なので、VVols 自体はそれほど奇をてらった仕組みではありません。(実際には *.vmx などが複数のファイルが置かれる Config VVols はその限りではありませんが、それでも仮想マシンが異なれば Config VVols も異なり、ストレージにとって独立したエンティティとなります)

VVols は他にもメリットがあります。仮想マシンのスナップショットを取得した状態でも、I/O 性能が落ちないことです。VVols がない VMDK ベースでの実装は、スナップショットの階層を辿らなければ本当に Read すべき Block を探せなかったためスナップショットの階層の分だけ Read I/O が増えていました。これに対し VVols でストレージ側にスナップショットの実装をオフロードした結果、ほぼ通常と変わらない I/O 性能を出すことが出来るようになっています。また、Protocol Endpoint、Storage Container や Virtual Volumes で、Block と NFS という 2 つのデータストアの違いを隠蔽し、vSphere からするとどちらも機能的には透過的に扱えるようになることもメリットとして挙げられます。(…まぁ、両方同時に使っている人がどの程度いるのかという話はありますが…Storage Policy Based Management (SPBM) を Block と NFS で分けて考えなくて良いというのはよいのやもしれん…)

なお、VVols を実装しているストレージは、こちらの Compatibility Guide で確認することができます。並み居る米系ベンダーに先駆けて、日系ベンダーが 3 社が早々に対応していただけたということもあり、今後もかなり熱い機能拡充の展開が期待できると思います。

と日系ベンダーや Block Storage を持ち上げておいて何ですが、豪勢なストレージが手元にない環境で気軽に Virtual Volumes を試すために NetApp Simulator を用いた NFS VVols 環境を作り上げる手順を以下にまとめます。

現状、仮想アプライアンスで VVols を試すには NetApp しか選択肢がないのと、NetApp が NFS VVols のデザインパートナーだったので…

準備

今回の Virtual Volumes 環境は、以下のコンポーネントを使って実現します。

vCenter Server 6.0 / vSphere ESXi 6.0
NetApp ONTAP Simulator 8.2.3 (VSIM)
NetApp Virtual Storage Console 6.0 (VSC)
NetApp VASA Vender Provider 6.0P1 (VP)

VP 以外は、前々回と前回のエントリーを参照してください。

VP は、6.0 (無印) は日本語/中国語環境でメニューが文字化けしてしまう問題があるため、6.0P1 を利用してください。通常の support.netapp.com のダウンロードからは辿り着けないので、以下から取得してください。

Bug 906805: Japanese, Chinese characters fail to show up correctly in VASA Provider user interface

手順

動画

手順をなぞった動画は以下をご覧下さい。

VASA Vender Provider (VP) のデプロイと初期設定

NetApp の VP は仮想アプライアンスとして実装されています。OVF をデプロイするときによく使われる以下の値を入力してデプロイします。

Hostname
IP Address
Netmask
Gateway
Primary DNS
Secondary DNS
Search Domains

動画ではデプロイ済みの仮想マシンの vApp パラメータの確認をしています。

デプロイが終わったら、VP の仮想アプライアンスをパワーオンします。VMware Tools のインストールを促されますので、コンソールの手順に従います。

VMware Tools のインストールが終わり、再起動し maint ユーザー、vpserver ユーザーのパスワードを設定します。vpserver ユーザーのパスワードは後ほど VP 登録時に設定することになります。

Virtual Storage Console (VSC) から VP を登録

VP の登録は vCenter Server から行えますが、NetApp 的に正しい作法としては VSC から登録します。Nested の環境のためなのか、Active Directory と NetApp OnCommand System Manager と VSC を同居させているのが問題かは不明ですが、VSC のサービスが停止していると、VP の登録を行えません。VP の登録のリンクをクリックしても無反応の場合は、VSC のサービスの起動状態を確認してください。

ホーム > Virtual Storage Console > 設定 > VASA Vender Provider の登録 / 登録解除

ここで VP のホスト名 (または IP アドレス) と vpserver ユーザーのパスワードを入力します。

ホーム > ホストおよびクラスタ > vCenter Server を選択 > 管理 > ストレージプロバイダ

と辿ることで VP が登録されたことを確認できます。

ストレージ機能プロファイルの作成

VVol データストアを作成するに、対象となる clustered DataONTAP の Storage Virtual Machine にストレージ機能プロファイルがなければなりません。適当に1つ FlexVol を作成しておき、VSC の VASA メニューから自動作成しておくと良いでしょう。

ホーム > Virtual Storage Console > VASA Provider for clustered Data ONTAP > ストレージマッピング > 自動生成

今回使用した Simulator では、前々回のエントリーで FCAL のディスクを追加したので、デフォルトで定義されているストレージ機能プロファイルには該当しませんでした。このため自動生成という手順が必要となっています。

VSC からの NFS VVol データストアの作成

VSC と NetApp VP の組み合わせでは、NFS Vvol データストアの作成と FlexVol の作成をウィザードの一連の操作で行うことが出来ます。

データセンター (右クリック) > VASA Provider for clustered Data ONTAP > vVol データストアのプロビジョニング

NFS VVol のサマリを確認すると /vmfs/volumes/vvol.{UUID} となっており通常のデータストアとは異なることを確認できます。

VVol データストアに仮想マシンをクローン & 仮想マシンの起動

最後に、通常の NFS データストア上にある仮想マシンのクローンを、NFS VVol データストアにクローンします。

Simulator なので 3 MB/sec しか出ていません。まず NVRAM は擬似的に仮想ディスクとして実装されていること、そして Aggregate の RAID を構成するディスクも擬似的に仮想ディスク上に実装されているので、1 I/O を処理するのに、何倍もの I/O が Simulator 内部では発生しています。また、クローン元とクローン先が実は VSIM の同じ Aggregate というのもスループットを半減させています。PCIe SSD、RAID を構成する本数を減らす、RAID 4 で構成などチューニングは考えられますが、まぁ仮想アプライアンスなので「やむなし」としています。

クローン終了後、無事仮想マシンが起動できることを確認できました。

VVols の意義 (番外)

VVols によってストレージの機能をより仮想環境に発揮できることは非常に意義があることだと思っています。しかし、それ以上に、この VMware という、Windows でもない Linux でもない Unix でもない仮想化ベンダーのビジョンに対しストレージベンダー各社からの賛同を頂き、そのビジョンを実現していただけたことに最も意義があると感じています。クラウドやコンテナなど様々な潮流が出てきてはいますが、地味ながら着実にハイパーバイザーの仮想化も進歩しているのだなぁと実感する次第です。

Setting up VMware Virtual Volumes with NetApp VASA Vender Provider and NetApp Simulator