Enjoy extremely fast cloning with NetApp VAAI-NAS


まとめ

  • Virtual Storage Console をインストール
  • ESXi に VAAI-NAS モジュールを追加
  • vSphere Web Clinet の UI から Virtual Storage Console 機能で ESXi に NFS データストアを追加
  • Enjoy extremely fast clone
  • Virtual Volumes の登場で変わる Block Datastore vs File Datastore

はじめに

前回のエントリー で、NetApp ONTAP Simulator のセットアップが完了しました。このエントリーでは、NFS データストアを作成し驚異的な速度の Clone の実行までを見ていきます。

手順

手順の概要は以下のようになります。

  • Virtual Storage Console のインストール
  • ESXi への VAAI-NAS モジュールの追加
  • NFS データストアの追加
  • 仮想マシンの作成 & Clone !!

手順の動画はこちらになります。

Virtual Storage Console のインストール

VSC-6.0-Win64.exe をダブル クリックし、「次へ」「次へ」とクリックしてバイナリのインストールが終了します。

インストーラーが終了すると、ブラウザが localhost で起動している VSC のページを開きます。このページは、vSphere Web Client Plugin として VSC の UI を vSphere Web Client Server に登録するためのものです。

ESXi への VAAI-NAS モジュールの追加

VAAI-NAS 用の VIB ファイルを所定の場所に置くと VSC から ESXi へ VAAI-NAS 用 VIB をインストールできるようになります。深追いはしていないのですが、VSC の NFS VAAI ツールからはインストールできませんでした。動画では手動でインストールしていますが、インベントリツリーから、ESXi ホストを選択し、コンテキストメニューから VIB をインストールすることができました。

コマンドラインでも VIB ファイルはインストールすることが出来ます。動画ではデータストアに VIB ファイルを含む ZIP ファイルをアップロードし、下のコマンドラインでインストールしています。この VIB ファイルは ESXi の再起動が必要になります。

NFS データストアの追加

インベントリツリーのデータセンターから、VSC で追加されたメニューを使ってデータストアを追加します。ONTAP のコマンドラインでも追加できるはずなのですが、自身の NetApp Level が低いため、大人しく VSC の UI から追加します。この操作で ONTAP 上に Volume の作成、Export の設定、ESXi のNFS 向け諸設定までを一気にやってくれます。

コマンドラインは Export の設定で挫折しました…Orz

仮想マシンの作成 & Clone !!

ここまでの手順で準備が整いました。動画では 2.47GB を使用した Thin Provisioning の VMDK ファイルを持つ仮想マシンをクローンしています。Copy-on-Write であるが故に様々な機能が発展した WAFL の恩恵を受け、クローンの処理は、ONTAP 側のメタデータコピーで完了してしまうため、僅か 2 秒でクローンが完了しました。

最近のフラッシュベースのストレージのほとんどが Copy-on-Write を採用し、OS 内のファイルシステムである ZFS や btrfs さえもが Copy-on-Write となっている現在において、WAFL の功績は見逃せないと強く思うのです。
未来を見通してた?Data ONTAP WAFLのこだわりを解剖

NFS データストアってずるくね ?

閑話休題。

さて、NFS データストアと、iSCSI や FC 接続の VMFS データストアの違いの一つとして、ストレージ機器が仮想ディスクファイルが保存されているアドレスを認識できるか否か ? というものがあります。

VMFS データストアをブロックデバイス上に作成しても、ストレージ側では仮想マシンファイルが LUN 上のどのブロック アドレスにマップされているかを認識できないため、仮想マシン単位のスナップショットなどは行えませんでした。このため、物理サーバーではよく使われていた LUN のスナップショットやクローンを使ったバックアップでは、複数の仮想マシンに対してリストアを行ってしまうので仮想環境では使いにくいモノでした。

それでもストレージの機能を使い切るため RDM を使ったり、1 VM/LUN としたり 1 VMDK/LUN としたりと厳しい制約で自縄自縛となっている環境もあると思います。

認識できない理由は単純で、ストレージ機器が VMFS を認識しないことと、VMFS ファイルシステムのメタデータを変更できない (ESXi 群が操作するのでストレージが弄ってはいけない) からです。

ストレージ自身が VMFS ファイルシステム見切って ATS や SCSI Reservce を発行すれば破綻しないかも知れない…がやはり VMFS ファイルシステムはプロプライエタリなので無理がある…

もっとも黒魔術的な実装でこれを可能にしているストレージもあったりなかったり…

1 から学ぶ VMware on NetApp 第十二回 VSC を使って一味違うリストア運用を実現

VMFS ファイルシステムは、メタデータに仮想ディスクファイルがどのブロックアドレスに配置しているかという情報を持っています。これは vmkfstools -t0 ${VMDK_File} という隠しオプション (Blog で明かしている以上隠しオプションもなにもないのですが…Cormac Horgan め…) で確認することができます。

Some useful vmkfstools ‘hidden’ options

Block ストレージ ベンダーからすると、「この情報を API で渡せ、その後はストレージ側で Replication, Snapshot などエレガントに処理するから!」となるのですが、VMFS ファイルシステムのメタデータをストレージ機器の状態と連動してアトミックに変更できるようにしないと、VMFS ファイルシステムが壊れてしまいます。この状況を、VMFS ファイルシステムをなくし ESXi ホストがブロックアドレス管理をしなくて良いようにすことで打開するのが Virtual Volumes になります。

一方、NFS データストアの場合は、データストアのファイルシステムはストレージ側で管理され、ESXi 側では関知しません。つまり、ストレージ側でメタデータを使い倒して仮想ディスクファイルにストレージ機能の処理を縦横に施せるということなります。

VAAI-NAS の Space Reserve 機能を使って、ESXi とNFS 側のファイル システムで多少は連携できるになっています。NFS データストアに VMDK を作る場合、VAAI-NAS がない場合 Thin Provisioning フォーマットでしか作れませんが、VAAI-NAS Space Reserve が利用できる場合は Lazy Zero-ed Thick や Eagar Zero-ed Thick といったフォーマットを NFS データストアであっても利用することが出来ます。

Virtual Volumes で Block の逆襲か ?

Virtual Volumes の説明は上記の URL を見て頂くとして、Block ストレージにとっては、仮想マシン ディスク個別にストレージの機能をリミッターを解除してフル適用出来るようになる画期的な仕組みとなります。Protocol Endpoint や Storage Container の実装方法はストレージ ベンダーに任されていますが、Block ストレージにおける Virtual Volumes は SNIA でも規定されている Subsidiary LUN (Sub LUN) で実装されているケースが多いと思います。Sub LUN のアドレスはストレージが完全に把握しており、ESXi ホスト側を慮らなければならない VMFS ファイル システムは Virtual Volumes にはないので、Sub LUN 毎にストレージ独自の機能が使えることになります。もちろん、各機能が Sub LUN に対応するというのが条件になります。

Virtual Volumes の操作は、各ストレージベンダーが実装した VASA Provider (vStorage API for Storage Awareness Provider) に vCenter Server や ESXi がリクエストを送ることになります。これまでの VASA では、Thin Provisioning, Compression, Dedupe, FC/iSCSI/NFS などの LUN の情報を vCenter Server 側に送りストレージ プロファイル作成の補助的な役割を担っていました。しかし、Virtual Volumes においては VASA Provider が非常に重要なコンポーネントとなり、もやは Awareness とは言えないほどになっています。VMware NSX で NSX Controller が非常に重要なコンポーネントであるように、Virtual Volumes では VASA Provider が非常に重要なコンポーネントとなっています。

とはいえ、Virtual Volumes は NFS でも対応しており、NFS データストアと VMFS データストアの使い勝手の違いを隠蔽し、単一の使い勝手に集約するという側面もあります。

NFS or Block ?

vSphere のストレージとして FC, iSCSI, NFS のどれが一番いいですか?という質問は 2, 3 年前はよく受けました。

ズバリの答えをだすのは諸事情あって難しいところですが、お客様の絶対に譲れない要件と、そのお客様が昔遭遇した嫌な思い出によって決定しているのが実情です。プロトコルの優劣ではなく、プロトコルの上に乗るストレージ サービス、運用の慣れといった全体を鑑みた判断をしてください、とアドバイスしています。それぞれのプロトコルによる使い勝手、制約の違いを明確にしたい場合は、以下を参照してください。

Storage Protocol Comparison – A vSphere Perspective

コメントを残す