Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Hiroshi Okano

作成者別アーカイブ: Hiroshi Okano

ESXi 6.0 パッチ適応に関して

はじめに

VMware vSphere 6.0 がリリースされて3ヶ月ほど経ちますが、2015年6月11日現在、ESXi 6.0 に対して2つのパッチが出ています。このパッチ適応に関して、いくつかトラブルが報告されているようですので、今回の Blog では安全なパッチ適用方法をご案内します。なお、このパッチ適応方法は恒久的な物ではなく、あくまで現存する問題を回避するための手法を示す物ですのでご了承下さい。

https://my.vmware.com/group/vmware/patch#search

 

確認している問題

 HP 社の Gen9 サーバに、HP 社の提供する Custom イメージでESXi 6.0をインストールした後、VMware 提供のパッチ(ESXi600-201505001 / 04001)を当てるとリブート後ローカルディスクが見えなくなる。

 ローカルディスクが見えなくなる現象が確認されているのは、現在HP 社の Gen9 サーバですが、影響の差はあれ、他のOEMのカスタムイメージでも何かしらの不具合が発生する可能性があります。不意に VMwareのドライバに置き換わってしまう可能性があるためです。

 OEM カスタムイメージ一例はこちら(VMware のサイトで提供分)

 ※各 OEM サイトにて提供されているカスタムイメージも同様です。

  元々 VMware 提供のバイナリでインストールを実行し、ドライバを変更していない場合はこの限りではありません。

 

詳細

コマンドラインにてパッチ適応を行う場合、通常以下のコマンドを利用しますがこの場合発生します。

 esxcli software profile update -d <path>/ESXi600-xxxx.zip -p <profile-name>

本来パッチ適応には利用すべきでなはいコマンドですが、以下のコマンドでも発生します。

 esxcli software vib update -d <path>/ESXi600-xxxx.zip

関連KB

http://kb.vmware.com/kb/2110557

 

原因

 ESXi 6.0 で各 OEM が提供するESXi 6.0のカスタムイメージの中には、VMware 提供のパッチに含まれるドライバより “バージョンが古いと認識される物” が含まれます。例えば、HP 社のカスタムイメージに対し、上記コマンドで VMware 提供のパッチを適応すると、以下のドライバがVMware の物と置き換わります。

  ・scsi-hpsa 5.5.0.84-1OEM.550.0.0.1331820 —–> 6.0.0.44-4vmw.600.0.0.2494585

  ・qlnativefc 1.1.39.0-1OEM.550.0.0.1331820 —–> 2.0.12.0-5vmw.600.0.0.2494585

  ・scsi-mpt2sas 15.10.06.00.1vmw-1OEM.550.0.0.1198610 —–> 19.00.00.00-1vmw.600.0.0.2494585

 scsi-hpsaのドライバが置き換わる影響で、Gen9サーバでは、リブート後ローカルディスクが見えなくなります。

 

 HP社推奨のドライバリストはこちらです。

http://vibsdepot.hp.com/hpq/recipes/HP-VMware-Recipe.pdf

※通常、OEMのカスタムイメージに含まれるドライバ群は、VMware提供のパッチよりドライババージョンが新しいため、update オプションを指定してコマンドを実行すれば置き換わってしまうことはないのですが、今回のESXi 6.0 のOEMカスタムイメージ場合はドライババージョンが古い物が含まれているためこの様な問題が起こります。

回避方法

 パッチの中から、必要なモジュールのみインストールします。今回の、ESXi600-201504001 及び、 ESXi600-201505001 の場合は、esx-base のみ更新されていますので、以下のコマンドで、esx-base のみ更新してください。

 

 esxcli software vib install -d <path>/ESXi600-201504001.zip -n esx-base

 

パッチにてアップデートされたモジュールに関しては、こちらを参照いただき、必要なモジュールのアップデートをお願いできれば幸いです。


VMware ESXi Patch Tracker

https://esxi-patches.v-front.de/

ご迷惑おかけして誠に申し訳ありませんが、上記ご認識のほどよろしくお願いします。

 

 

VMware vSphere Virtual Volumes に対するHP 3PAR StoreServの実装

はじめに

vSphere 6.0 で実装されたVMware vSphere Virtual Volumes (VVol) は、対応するストレージと連携することにより初めて利用可能となる機能です。VVolの全体的な話はこちらでご紹介させていただきましたが、今回は、主にストレージ側から見たVVol の実装とそのメリットについて、日本HPの3PAR担当プリセールスの伊東様に執筆いただきましたのでご紹介いたします。

VVol 概要とメリット

vSphere 6.0 から新たに実装されたVVol はストレージベンダーにとっては2015年で最も重大なニュースであり非常に大きなインパクトを与えています。特にSANストレージがVVol に対応することでこれまでのLUN + VMFSでは不可能であったり不便であったりしたことが大幅に改善されます。

どのように改善、変化したかということを下図で示します。SANストレージとNASストレージでは同じ利用目的のデバイスでありながら管理の方法やその特性が全く違っていました。

 

VVol を利用すると、vCenter Server からSANもNASも同じVVol Datastoreの定義をすることができ、見え方、使い方の違いを無くすことができます。

 

SANストレージにとっては、今まではほぼ不可能に近かった仮想マシン毎にボリュームを分け、サービスレベルを個別に設定することが可能になり、様々なメリットが生じてきます。

VVol の対応により、SANストレージは今までと同様の高いパフォーマンスを提供しながらストレージリソースのシンプルな管理、きめ細かなSLA定義、効率の良いストレージ機能の提供が可能となります。

3PAR とVVol の関係について

HP 3PARとVVol には長い歴史があります。まだ3PAR がHP にマージされる前の4年以上前からVVol との関係がスタートしています。その後、3PAR はHP の主力ストレージとなりましたが、HP がVVol のオリジナル開発パートナー5社のうち1社となり、更に3PAR がFCストレージのリファレンスプラットフォームに選ばれました。開発の途中経過はHPのブログやエキシビションで発表しており、2014年半ばにはVVol のベータプログラム開始時に準備が整っていた3製品のうちの1つとなりました。最終的にVVol がGAとなった2015年3月時点でもVVol が提供する機能を全てカバーしています。

では、HP 3PAR がVVol の機能をどのように実装し、実際にどのように動作するかということを解説していきます。

VVol をサポートするための実装

・VASA 2.0プロバイダ

 vCenter Server / ESXとやり取りするストレージ管理サービスでvCenter Serverからのリクエストを受け取り、ストレージの機能や制御の伝達・翻訳する役目を果たします。

・プロトコルエンドポイント

 FCファブリックのアクセスをシングルポイントにする仮想デバイスで通常のLUN 検出コマンドで検出されます。ストレージ管理ツールに触る必要が無く、ストレージ管理者が介在しなくてもvCenter Serverからストレージの切り出しが可能です。各仮想マシンにはVMDK, Config, Swap, Memory, Snapshotなど複数個の3PAR VV*(Virtual Volume)が作成されることになるため、従来よりも多数の3PAR VVが作成されることになりますが、3PAR はもともと多数のボリューム構成をサポートしており、その範囲内であれば全く問題なく利用可能です。

 *3PAR VV(Virtual Volume)とは:3PAR内では、ホストに提供するLUに相当するボリューム のことを従来よりVirtual Volumeと呼んでいます。
  vSphere VVol環境ではVVol = 3PAR VVとなります。なおvSphere VVolはVirtual Volumesとも呼びますので、混同しないようご注意ください。

・VVol Datastore(ストレージコンテナ)

 3PAR ではオプション機能のVirtual Domainを利用すると1台の3PAR を仮想的に複数のストレージとして管理単位を分割出来るためストレージコンテナを複数に分割することが可能です。Virtual Domainを利用しない場合は3PAR が丸ごと1台がストレージコンテナとなります。

3PARのVASAプロバイダはビルトインで、3PARのコントローラノード上のサービスとして動作します。インストールなど不要でコマンドによりサービスを起動するだけで即座に利用可能となります。

VASAプロバイダがストレージコントローラ上に組み込まれていることによって得られる見過ごすことのできないメリットがあります。

・インストール不要で追加のセットアップや構成が不要

・高可用性、自動フェイルオーバ

・個別のバージョン管理、アップデートが不要

ストレージ装置によっては仮想アプライアンスなどの形でVASAプロバイダが提供されているケースもあり、構築にそれなりの手間が生じますが、3PARのVASAプロバイダは上記の通り極めて簡単に構築可能で、かつ、可用性に優れる実装となっています。

また、3PARがサポートするVV(ボリューム) 数は下記の通り、非常に多数を作成することが出来るため、VVol で懸念となるボリューム数の増大は3PAR では全く気にする必要がありません。

モデル

7200/7400

7440/7450

10000

最大VV数

16000

32000

32000

 

VVol + 3PARで何が出来るか?

VVol 環境で利用可能となる3PAR の独自機能を下記に挙げます。

・ベンダーニュートラルな機能として提供(VVol 必須の機能)

  Thin / Thick Provisioning

・ベンダー固有の機能として提供

  Common Provisioning Group :ボリューム構成テンプレート

              プライマリ用とスナップショット用を別々に選択可能

  Thin Persistence(Zero Detect):ゼロデータ検知・リクラメーション

  Thin Dedupe:重複排除機能

・その他vCenter Serverから行えるストレージ機能

 スナップショットの作成

  Virtual Copy(スナップショット機能)との連携:

   仮想マシンの操作メニューからスナップショット作成を行うと、3PAR側でVirtual Copyを作成

・現時点で3PAR 管理ツールにより設定すれば使える3PAR 機能

  ストレージQoS:Priority Optimization

  フラッシュキャッシュ:Adaptive Flash Cache

  将来的にはVVolに対応した機能として提供する予定です。

Storage Policy-based Management(SPBM)のサポート

仮想マシンのストレージに対するビジネスニーズを満たすためのフレームワークです。

  • SPBM によって、仮想マシンをストレージ上でプロビジョニングする際にアプリケーションの要件にマッチしたボリュームを提供するための仕組みになります。
    • ストレージがサポートしている機能をvSphereのPolicy-base Provisioning エンジンに対して公開
    • 仮想マシンが作成される際、ビジネスニーズにマッチした機能をアサインする
      • 仮想マシン毎、必要な機能がボリュームに対してアサインされる(スナップショットも仮想マシン毎)
    • SPBMエンジンは、要件を満たし互換性を持ったデータストア(ローカルディスク、LUN、vSAN、VVol )がどれかというのを認識
    • 仮想マシンは適切なESXホストおよびストレージでプロビジョニングされる
    • SPBM は各ボリュームのコンプライアンスを監視
    • 仮想マシンに紐づけたストレージが機能要件を十分に満たしているかを監視していく役割も担っている

3PARでVVolを利用するための環境

  • vSphere 6
  • 3PAR OS :3.2.1MU2 Patch 12
  • 3PARソフトウェアライセンス類
    • OS Suite        :必須
    • Virtual Copy         :必須
    • Virtual Domain        :オプション
    • Priority Optimization    :オプション
  • FC HBA, FCoE アダプタ

3PARでVVol を利用するために最初に実施すること

下記の手順でVVol利用の準備を行います。

  1. VASA プロバイダ サービスの起動: 3PAR CLI にて、”startvasa” コマンドを実行
  2. <オプション>VVol 用のドメイン、ユーザの作成
  3. CPGの作成 :全てのCPG が機能プロファイルとしてvSphere に提供されます
  4. VASA プロバイダの登録:vCenter Server から VASA プロバイダをスキャン
  5. ESXi ホストを 3PAR に登録:通常の手順で登録。ESXからプロトコルエンドポイントを確認
  6. VVol データストア(Storage Container)をマウント:通常のデータストアと同じ手順。
  7. ストレージポリシーを作成

手順のイメージをいくつか紹介します。

  1. VASAプロバイダの準備はサービスの確認と開始のコマンドを実行するだけで完了です。

④VASA プロバイダの登録はvCenter Server の新しいストレージプロバイダの追加を実行します。

⑤ESXi ホストの登録を実施しますが、3PAR では通常行っているホストの登録コマンドを実行するだけで完了です。またホスト登録の実施を行うだけでプロトコルエンドポイントとなるLUが有効になります。

 ホスト登録のための3PAR コマンド:cli# createhost –persona 11 <host name> <WWN> 

 ESXi 側では通常のデバイスのスキャンを行い、ストレージデバイスにLU が確認できることと、そのデバイスがプロトコルエンドポイントとして認識されていることを確認します。

 

プロトコルエンドポイントはESXi から見るとSCSIデバイスが見えますが、3PAR 内ではボリュームの実体は作られません。

⑥VVol データストアのマウントをした後、データストアのサマリ情報を見るとストレージ機能プロファイルという項目があり、そこに3PAR の CPG が列挙されてきます。CPGには 3PAR のドライブタイプ、 RAID レベル、ストライプ幅を決める設定が含まれます。


⑦ストレージポリシーの作成では3PARの機能の組み合わせを一つ一つ構成していきます。

まずポリシー名を設定します。


次にルールセットを作成で、ルールの中に 3PAR の機能を選択していきます。

プライマリボリューム用の CPG、スナップショットデータを格納用のCPGの選択、リクラメーション機能のThin Persistence、重複排除機能のThin Deduplicationを必要に応じて追加します。


この例では、プライマリボリュームはFCドライブのRAID 1に、スナップショットはFCドライブのRAID 6 に、リクラメーション機能もONというポリシーを設定したことになります。


ルールの設定の後は、互換性ありと表示されているVVol のデータストアを選択します。


設定内容の確認を行い、ポリシーの作成は完了となります。


 

仮想マシンの作成

最後に一番重要な、仮想マシンの作成とそれに伴い自動的に作成されるボリュームについて、実際の作成画面等を用いて紹介していきます。

通常の手順で新規仮想マシンの作成を開始します。


ストレージの選択で、仮想マシン ストレージ ポリシーでVVol 用に作成したポリシーを選択します。ここで選択したポリシーに応じて仮想マシンの作成と共にボリュームが作成されます。


仮想マシン ストレージ ポリシーで選択されたポリシーに対して、互換性のあるデータストアが互換性ありにリストアップされます。ここでは”VVOL”という名前で作成されたVVol データストアを選択します。


最後はサマリが表示され問題なければ完了となります。


 

仮想マシンを作成すると、3PAR 上で仮想マシンに応じたVVが自動的に出来上がります。通常運用では3PAR側のVVの状態を特に意識する必要はありませんが、参考までにその確認の方法を紹介します。

VVol 用に自動的に作成された3PAR VVの表示コマンドshowvolvm –vvの実行結果で仮想マシンとVVol 名、VVol タイプ等と3PAR VVとの対応が確認できます。仮想マシン作成時点では、Config 用とData 用のボリュームが作成されています。

仮想マシンのパワーオンを実行するとSwap 用のボリュームが自動的に作られます。

仮想マシンのスナップショットを作成では、従来の手順で仮想マシンのメニューからスナップショットの作成を実行します。

スナップショットの作成手順を行うことでVVol の場合は自動的にストレージネイティブのスナップショット機能 = 3PARではVirtual Copy が自動的にとられます。

仮想マシンのメモリのスナップショットをチェックしておくと VVol ではストレージ側に Memory というタイプのボリュームを作成します。

以上、仮想マシンの作成やスナップショットの作成は全てvCenter Server 側の UI から実施可能で、3PAR 側でのボリュームの確認は任意ですので必要に応じて 3PAR のコマンドから確認してください。

現時点でまだ VVol 機能に対応していないストレージ QoS やフラッシュキャッシュ機能は 3PAR のコマンドから設定いただきご利用いただくことが可能となっております。将来的には VVol 機能の一つとして選択できるように実装される予定です。

 

最後に

HP 3PAR が VVol の開発当初から関わり、リリースと同時に完全にサポートしていることをご理解いただいたと思いますが、 VVol 機能自体がまだまだ発展途上の技術であり今後にのびしろを多く残している機能です。

特に2015年5月時点では VVol で作成されたボリュームをストレージでレプリケーションする機能は実装されていませんし、バックアップに関しても対応しているバックアップソフトウェアも少ないのが現状です。

3PAR は引き続きVVol 対応用の機能を拡充し VVol の進化に追従していく予定ですので、是非今からご利用のご検討をスタート頂ければと思います。

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 から利用可能というところも見逃せない点です。今後の機能拡張にもご期待下さい!

Hiroshi Okano

岡野 浩史

リードシステムズエンジニア (VCP3/4/5-DCV, VCP-NV, VCAP4/5-DCA, VCAP4/5-DCD)
エコシステム含めたパートナービジネスの拡大をミッションとしているエンジニアです。前職ではx86ベンダーやCPUベンダーといったハードウェアエンジニア畑を歩んできましたので、デバイスレベルの動きやHPC等のベンチマーク等に深い知識を持ちます。PartnerExchange や vForum などのイベントでは、リリース前の vSphere Core の機能紹介や Virtual SAN のセッションを担当する機会も多いので、”どこかで見たことのある顔”と思われる方もいらっしゃるのではないかと思います。今後もこの様な活動を続けていく予定です。よろしくお願いします!

VMware Virtual SAN 利用時の vSphere HA 設定に関するベストプラクティス

はじめに

VMware Virtual SAN は、vSphere5.5 Update1 以降のESXiカーネルに組み込まれた魅力あふれるストレージの新機能で以下のような特徴を持ちます。

  • ローカルサーバに搭載されたディスクを利用した共有ストレージ
    大容量安価な磁気ディスクと、高速低遅延なフラッシュデバイスを組み合わせたハイブリッド型 

  • ストレージポリシーによる管理
    可用性やパフォーマンスを仮想ディスクの粒度で定義

  • 柔軟な拡張
    ホスト追加による動的なストレージ拡張(3~32ノードをサポート)

  • Virtual SANでは、コンピューティング機能とストレージの機能を共にサーバで提供しますので、上記の通り非常に拡張性に富んだストレージサービスの提供が可能となるのですが、ストレージサービスをサーバに統合しているが故、主に仮想マシンの可用性に関する面で少しばかり注意が必要となります。本Blogでは、この点にフォーカスを当ててご説明いたします。なお、本Blogでは、Virtual SANの基本的な構成に関する説明は割愛させていただきます。また、vSphere5.5 Update 2 (2014年9月)の情報で作成させていただいており、将来的に変更になる可能性がありますのであらかじめご了承下さい。

    Virtual SANの耐障害性

    ストレージポリシーと仮想ディスクの配置

    一般的なRAIDコントローラでは、Disk障害に対応するためにミラーやパリティを構成しますが、Virtual SANの場合はホスト自体の障害に対応するため、例えば、”許容障害数=2″のストレージポリシーで作成された仮想マシンの仮想ディスクは、3台のホストにまたがって書き込まれます。


    障害時の動き

    Virtual SANは一種のクラスタとして動作します。お互いの死活監視は、Virtual SANネットワークを利用したハートビートのみで実装されています。Virtual SAN ネットワークはチーミングによる冗長化が可能ですし、その重要性を考えると冗長化は必須とも言えますが、万が一冗長化されている Virtual SAN ネットワークが全て切断されてしまうと、ホスト自体が障害で落ちてしまったのか単なるVirtual SANネットワークの障害なのか知るすべがありません。これは、ネットワークのハートビートだけでなく、ハートビートデータストアやゲートウェイへのPingを使って、相手の状態や自分自身の状態をインテリジェントに確認していくvSphere HAとは大きく異なる点なのですが、実は凄く理にかなっています。

    vSphere HAの障害時の優先事項は仮想マシンの稼働を最大化させることです。このため、上記の通りインテリジェントに状態を判断し、仮想マシンへのアクションを適切にハンドリングすることを試みるのですが、Virtual SANが、障害時に最も優先する事項は、”Diskの一貫性を保つ”ことです。



    例えば、上記のような3面ミラーの構成時に、esxi‒01が何らかの障害によりVirtual SANネットワークから切断されてしまった場合、分断されたミラーが共にアクセス可能な状態で放置されると、互いに異なる変更が発生し、ミラーの一貫性が失われる危険性があります。これを防ぐため、Virtual SAN は障害時、片方のミラーオブジェクトを即時にロックすることによりミラーオブジェクトの一貫性を保ちます。これが障害時にVirtual SANが最も優先する事項です。つまり、Virtual SANは、インテリジェントに相手の状態を把握することよりも、ミラーオブジェクトの一貫性を保つために”即時性”を最優先しているといえます。

    オブジェクトロックアルゴリズム

    先述の通りVirtual SANは障害時、必要に応じ特定のディスクオブジェクトをロックします。このロックの判断は、

    “ディスクオブジェクト数” +”監視オブジェクト数”

    がオブジェクト総数の過半数を獲得できたか否かによって判断されます。その結果、過半数の獲得ができなかったオブジェクトがロックされます。例えば、許容障害数 = 1で仮想Diskを作成すると、下記の様に、2面のミラーオブジェクトとは別に”監視オブジェクト(英語名Witness)”があらかじめ作成されます。



     
    この状態でesxi-01のVirtual SANネットワークが何かしら障害を起こしてしまった場合、それぞれのパーティションには、
     
     esxi-01側・・・Diskオブジェクトが1つ
     esxi-02~05側・・・Diskオブジェクト1つ + 監視オブジェクト1つ = 計2つ

    のオブジェクトが存在することになり、過半数を獲得できなかったesxi-01上に存在するDiskオブジェクトがロックされます。一方、過半数を獲得したESXi02~05側のDiskオブジェクトはアクセス可能なオブジェクトとして稼働を続けます。

    このオブジェクトのロックは、どちらのVirtual SANパーティションを生かすかという全体的な判断ではなく、仮想ディスクごとに行われます。例えば、同じ環境に、許容障害数 = 0で作成されていた仮想ディスクオブジェクトが存在していた場合(下記青色のvmdk)、こちらのオブジェクトはesxi-01上でロックされることなく稼働を続けます。


     

    少し話はそれますが、上記した内容を鑑みると、許容障害数 = nの場合、障害時に少なくともn+1個のオブジェクトが正常なホスト側に残る必要があることが分かります。つまり、許容障害数 = n を構成するためには、最低でも

    n + (n+1) = 2n+1 台

    のホストが必要になります。例えば、3面ミラー(許容障害数 = 2)を構成するためには、最低5台のホストが必要ということになります。



    なお、仮想マシンに関するオブジェクトは仮想ディスクファイル(vmdkファイル)の他に、仮想マシンの構成ファイル(vmxファイル)などが含まれるVMホームオブジェクトも存在しますが、VMホームオブジェクトのロックのアルゴリズムも前記した仮想ディスクファイルと同様となります。

    仮想マシンの可用性

    あらかじめ監視オブジェクトを必要数準備しておき、障害時に過半数のオブジェクトが獲得出来なかったオブジェクトをロックするというアルゴリズムは、障害対応の即時性が高く、仮想ディスクのイメージの一貫性を担保する優れたオブジェクト管理の仕組みです。しかしながら、仮想マシンのサービスレベルを守るという面で考えると、ちょっと困ったことが起こる可能性があります。例えば許容障害数 = 1で作成された仮想マシンがesxi-01上で稼働し、仮想ディスクが以下のように配置されている場合の障害時の動きについて考えてみます。



    esxi-01がネットワーク障害で分断されると、以下のことが起こります。

    • esxi-01上のディスクオブジェクトがロックされる(過半数を確保できないため)
    • ロックされていないミラーオブジェクトはesxi-03上に存在
    • esxi-01 上の仮想マシンのI/Oは Virtual SANネットワークがアクセス不可能なため esxi-03 に到達できない

    このため、仮想マシンのI/Oは停止してしまいます。

    この仮想マシンを正常に稼働させるには、esxi-02~05側で仮想マシンを稼働させる必要がありますが、この動きはVirtual SANではなく、vSphere HAにより担保されます。Virtual SANとvSphere HA は共にクラスタに定義するサービスの1つで、同時に利用することも可能です。しかしながら、例えば上記の例の様な場合に、esxi-01側のミラーオブジェクトがロックされ、アクセス可能なミラーオブジェクトがesxi-03にあることをVirtual SANからvSphere HAに通知するような連係機能は現在のところ実装されていません。つまり、”esxi-02~05側で仮想マシンを稼働させる”ために、vSphere HAが独自に Fail Over 動作を起こす必要があります。

    仮想マシンのサービスレベルを守るためのvSphere HAの設定

    Virtual SAN 環境でvSphere HA を利用した場合、vSphere HAのハートビートネットワークはVirtual SANネットワークを利用します。Virtual SAN 有効時、無効時の vSphere HA の初期設定は以下の通りです。



    vSphere HAには以下の通り4つの状態があり、vSphere HAによる仮想マシンのFail Overは、ホスト障害の際、もしくはホストが隔離状態になった場合に発生します。

    • 正常な状態
    • ネットワークパーティションの状態

      互いのハートビートのみが途切れた状態。ハートビートデータストアによりお互いの稼働が確認され、かつ、両者共に隔離アドレスへのPingも成功する場合はこの状態となります。クラスタは分割されそれぞれが vSphere HA クラスタとして機能します。仮想マシンのFail Overは起こりません。Virtual SAN構成の場合、ハートビートデータストアが無い構成も想定されますが、その場合は、vSphere HA レベルのスプリットブレインとなり、仮想マシンの二重起動が起こる可能性があります。

    • ホスト隔離の状態

      互いのハートビートが途切れ、かつ、障害ホストの隔離アドレスへのPingが失敗する場合この状態となります。仮想マシンのFail Overはオプション設定により可能(初期設定は無効)です。

    • ホスト障害

      仮想マシンはFail Overします

    ネットワーク障害の際には、ネットワークパーティションではなく、ホスト隔離の状態にすること、及び、隔離時に仮想マシンのFail Overが起こるよう設定を施しておくことが必要となります。このため、以下の2点の設定変更を実施します。
     
    1.vShere HAをネットワークパーティションではなく、ホスト隔離状態にする
     
    Virtual SANネットワーク障害時に、隔離アドレスへのPing応答を切断する必要があります。
    このため、vSphere HAの詳細オプションを利用して隔離アドレスをVirtual SANネットワーク側に変更します。
     
     das.usedefaultisolationaddress = false
     das.isolationaddressX = <Virtual SAN Networkより確実にアクセス可能なIP>
     
    2.vSphereHAのオプション設定で、ホスト隔離時の対応を、”パワーオフ後、フェイルオーバー”に設定する


    この2つの設定を施しておけば、Virtual SANネットワークが切断された際、vSphere HAが隔離状態となり、隔離されたホスト上の仮想マシンが、正常なホスト上にFail Overされ、仮想マシンサービスが復旧します。

    ハートビートデータストアに関しては必須ではありませんが、もし存在すれば、相手の状態を正確に把握することが可能となるため、仮想マシンの2 重起動を防止することが可能となります。

    設定変更の影響

    上記の設定は必ずしも全ての仮想マシンの稼働の最大化を図る物ではなく、仮想マシンに想定されるサービスレベルを守るための物です。ここで言う、仮想マシンのサービスレベルとは、

    “許容障害数以内のホスト障害であればサービスが継続、もしくは、 vSphere HA の機能で仮想マシンがFail Overしてサービスが復旧すること”

    を意味します。初期設定では、特にネットワーク障害の際にこの期待値に添えない(仮想マシンのFail Overが起こらない)可能性がありますが、前記した設定を施す事により仮想マシンに想定されるサービスレベルを守ることが可能となります。

    ここで1つ心得ておきたいことは、許容障害数を超えてしまった仮想マシンにとっては、必ずしもこの設定が可用性を向上する物ではないことです。例えば、前記した例で、許容障害数 = 0で作成された青色のvmdkファイルは、esxi-01のネットワーク障害時でも稼働は可能ですが、上記設定に変更してしまうと仮想マシンはパワーオフしてしまいます。今回ご紹介した設定は、仮想マシンに想定されるサービスレベルを守るための設定と理解下さい。

    まとめ

    今回は、Virtual SAN の障害時の動き、及び、Virtual SAN 上の仮想マシンの可⽤性を設計者の意図した通りに担保するための設定についてご紹介させていただきました。繰り返しになりますが、Virtual SAN ネットワークはチーミングによる冗⻑化が可能ですし、その重要性を考えると冗⻑化は必須です。その冗⻑化でも対応できない万が⼀の際にも、仮想マシンのサービスレベルを担保するためのデザイン手法として本資料をご利⽤頂ければ幸いです。

    このブログの内容は、こちらからWhitePaperとしてもダウンロードいただけます。是非ご利用下さい。

    参考情報

    VMware Virtual SAN & vSphere HA Recommendations
    http://blogs.vmware.com/smb/2014/10/vmware-virtual-san-vsphere-ha-recommendations.html

    Hiroshi Okano

    岡野 浩史

    リードシステムズエンジニア (VCP3/4/5-DCV, VCAP4/5-DCA, VCAP4/5-DCD)
    エコシステム含めたパートナービジネスの拡大をミッションとしているエンジニアです。前職ではx86ベンダーやCPUベンダーといったハードウェアエンジニア畑を歩んできましたので、デバイスレベルの動きやHPC等のベンチマーク等に深い知識を持ちます。PartnerExchange や vForum などのイベントでは、リリース前の vSphere Core の機能紹介や Virtual SAN のセッションを担当する機会も多いので、”どこかで見たことのある顔”と思われる方もいらっしゃるのではないかと思います。今後もこの様な活動を続けていく予定です。よろしくお願いします!


    Trend Micro Deep Security と vSphere Auto Deploy で大規模環境セキュリティを楽々管理する!

    【はじめに】
     

    前回ご説明させていただいた、大規模環境のインフラ管理負荷を劇的に改善するvSphere Auto Deploy。そしてアンチウィルスのオフロードを実現し、仮想環境のリソースの最適化を実現する、Trend Micro Deep Security。これら二つは、サーバ仮想化からデスクトップの仮想化まで、幅広く利用可能ですが、特に仮想マシンの集約率が高くかつ、ホスト台数の多くなりがちな仮想デスクトップ環境では、運用・管理面とリソースの有効活用面で大きな効果を発揮します。事実、この組み合わせで是非利用したい! というユーザーからのリクエストはしばしば頂いているのですが、実はこの組み合わせ、主にAuto Deploy側特有の、構成情報の保存・再現方法が確立していなかったため、期待通りに動作させるのがなかなか難しいという問題がありました。

    今回、この状況に終止符を打つべく、VMwareとTrend Micro様で共同検証を実施、その結果、構築方法の確立に至りました!
    続きを読む

    vSphere Auto Deploy + Host Profile + DRS – インフラ管理の自動化

    はじめに

    最近、SaaS、PaaS、IaaS、といった各レイヤをサービスとして受け取り、システムを構築していくというケースも増えてきているのではないかと思います。一方オンプレミスの環境を見てみると、相変わらずハードウェアやリソースの管理が大変・・・。便利そうだけどブラックボックス要素の多いパブリッククラウドと、全てを把握できるものの手間のかかるオンプレミス、どっちを選べばよいのか迷っている方、多いのではないかと思います。今回のBlogでは、大規模なオンプレミス環境で問題になりがちな、サーバリソースの管理負荷を劇的に削減する方法をご紹介します。今回ご紹介する機能は、私自身、3年以上VMwareのLAB環境の管理に利用しておりますが、とても便利です。この便利さを皆様にも是非体験いただければと思います。

    続きを読む

    押さえておきたいvSphereの基本-可用性編 vSphere HA/FT

    押さえておきたいvSphere の基本」の可用性編の1回目として、前回、vSphere DRSをご紹介しました。
    今回は、2回目として、ホスト障害の際にも仮想マシンの稼働を最大化する機能、vShpere HA、vSphere FTに関して順にご紹介します。

    vSphere HA

    ESXiホスト上で稼働している仮想マシンは、そのホストが障害で止まってしまった場合、稼働停止を余儀なくされます。
    vSphere HAは、ホスト障害により止まってしまった仮想マシンを他の正常なホスト上で再稼働する機能を提供します。

    HA-FT-3

    例えば3台のホストがvSphere HAで構成されている上記の様なケースで、真ん中のホストが何らかの障害により止まってしまった場合、このホスト上で動いていた仮想マシンは停止してしまいます。この障害を検知すると、他の正常なホスト(上記の場合は左右ホスト)が仮想マシンを自動的に再度稼働させます。vSphere HA を利用することにより、ホスト障害の際にもサービスのダウンタイムを最小限に抑えることが可能となります。

    物理環境の仮想化への移行の理由は、有り余る物理ホストのリソースの有効活用と、ホスト集約によるTCOの削減というところが多いのですが、仮想環境へ移行すると、vSphere HA が利用可能となり、可用性が飛躍的に向上するということも大きなメリットの1つです。なお、vSphere HA が利用可能なライセンスに関しては、こちらをご確認下さい。
    続きを読む

    vSphere 5.5 の新機能紹介 VMware Virtual SAN その3

    前回、その2では、ストレージポリシーを利用した仮想マシンのSLAの管理についてご説明しました。今回は、Virtual SANの読み書き、及び障害時の動作についてご説明します。

    書き込み処理

     許容障害数=1 で作成された仮想マシンを例にとってご説明します。このポリシーを適応され作成された仮想マシン(仮想ディスク)は、VMDKファイルが2つのホスト内のHDDに分かれて配置されます。

    1. 上記ケースでは、ホストH1とH2にVMDKファイルが配置されています。その際、このオブジェクトに対するオーナーが決まります(上記例ではH1)
    2. 仮想マシンはオブジェクトオーナであるH1に対し、書き込みの要求を発行します
    3. オブジェクトオーナーであるH1は書き込み要求を二つ作成し、H1 とH2 に対して発行します
    4. 各ホストのSSD上で「準備」が完了すると、それぞれ「ACK」を返します(ライトバック動作となります)
    5. オーナーはH1、H2からの「ACK」を受け取るとIO完了を仮想マシンへ通知、仮想マシンでの書き込み処理が完了します
    6. SSD内のキャッシュは数秒間蓄積された後、HDDへディステージされ、SSD領域から削除されます

    読み込み処理

    上記と同じ仮想マシンでの読み込み処理について説明します。

    1. 仮想マシンはオブジェクトのオーナーであるH1に対し、読み込みの要求を発行します
    2. オブジェクト(VMDK)はある容量毎に読み込みを実行するホストがあらかじめ決められています(上記例ではH2)*
    3. H2のキャッシュにヒットした場合はSSDから読み込みます
    4. キャッシュミスした場合はHDDから読み込まれ、SSDにキャッシュされます
    5. 読み込んだ内容がH1に返ります
    6. 仮想マシンの読み込み処理が完了します

    ※このアルゴリズムにより、同一領域が複数のSSDにキャッシュされることが無くなり、SSDの利用効率が最大化します。

    障害及びホストメンテナンスに関して

     ディスク障害時やホスト障害時の仮想マシンの可用性、さらにはホストのメンテナンス時の考慮事項と具体的なオペレーションについてご説明します。

    ディスク障害
     Virtual SANを構成するHDD 1 台が障害を起こした場合、適応されたストレージポリシーに従って仮想マシンの可用性が担保されます。この場合デフォルトである、許容する障害数=1 以上で作成された仮想マシンに関しては連続稼働が担保されます。

     障害を起こしたHDDがエラー状態でオペレーション継続不能な状態に陥った場合、ホストは即座に復旧処理を開始します。上記の場合は薄青の仮想ディスクに対し復旧処理を開始し、以下のような状態となります。


    ”障害を起こしたHDDがエラー状態でオペレーション継続不能な状態” というのが実はミソです。上記したとおりHDDの障害が永久障害と判断される場合は即時復旧となりますが、例えばHDDの状態が分からない様な場合(疑似障害発生のためHDDを抜いた場合など)、ホストはコンポーネントの一時障害か永久障害か区別が付かないため下記ホスト障害同様、一定時間デバイスが復帰するのを待つ動作に入ります。HDDの復旧処理は重い処理であるため、一時障害で戻ってくるのであればそれを待つアルゴリズムになっているということです。

    ホスト障害時
     ホスト障害時の仮想マシンの可用性は、vSphere HA(ホストの可用性)とVirtual SAN(ストレージの可用性)で担保されます。例えば、vSphere HAとVirtual SANを利用した以下のようなクラスタで、一番右のホストが障害でストップしてしまった場合を考えます。

    上記で影響を受けるのは、以下のオブジェクトです。
     障害を起こしたホスト上で稼働する仮想マシン
     障害を起こしたホスト内に存在する仮想ディスク
      薄青・・・3面ミラー構成
      薄緑・・・2面ミラー構成

    この場合、以下のようになります。

    1. 障害を起こしたホスト上稼働していた2つの仮想マシンは、レプリカディスクを利用して他のホストで起動する(vSphere HA)
    2. 一定時間経過してもホストが復帰しない場合*、ストレージポリシーに従い仮想ディスクの再配置を行う(Virtual SAN)

     ※2の一定時間に関しては、ホストの詳細設定VSAN.ClomRepairDelayパラメータで定義されており、デフォルト値は60分となっています。

    ホストメンテナンス・削除時
     通常のクラスタ環境同様、ホストをメンテナンスモードに変更します。このオペレーション時、以下のような確認画面が表示されます。オプションは以下の3つがあります。このオプションを利用することにより、管理者の意図した形でかつ安全に、ホストをVirtual SANから取り外すことが出来ます。なお、この作業は、必ずvSphere Web Clientで行ってください。vSphere Clientではサポートされません。

    ・アクセシビリティの確保(デフォルト)
     該当ホストをVirtual SANデータストアから外しても仮想マシンの動作に問題ない場合、仮想ディスクの待避は行いません。ホストへのパッチ適応や一時的なシャットダウンなど、ホストをメンテナンスしたい時に利用するオプションです。このオプションを選択すると、ストレージポリシーに違反する仮想マシンが出てくる可能性があります。このため、恒久的にホストを削除する場合には適さないオプションです。

    ・全データの移行
     該当ホスト内の仮想ディスクを他のホストへ待避します。多量のデータ転送が発生するため、メンテナンスモードに移行するまでの時間が長くなります。恒久的にホストをVirtual SANから削除する際に適するオプションです。

    ・データの移行なし
     仮想マシンの稼働にかかわらず、仮想ディスクのデータ待避を行いませんので仮想マシンが仮想ディスクへアクセスが出来なくなる可能性があります。

    まとめ

     3回に渡りVirtual SANについてご紹介を行いました。Virtual SANは安価なホストローカルのストレージを利用する、拡張性に富んだストレージの新機能です。現在PublicBetaという位置づけですが、将来のFullサポートを視野に入れ、是非この段階での評価をご検討下さい。

    Virtual SAN Public Beta登録サイト
    http://www.vmware.com/vsan-beta-register.html

    vSphere 5.5 の新機能紹介 VMware Virtual SAN その2

    前回その1でVirtual SANの概要と構築方法についてご説明しました。今回はその続編として、ポリシーベースのストレージ管理とそのポリシーを利用したVirtual SANデータストア上への仮想マシンの作成についてご説明します。

    ※このポリシーベースのストレージ管理は、Virtual SANに限った物ではなく、今後提供されるストレージの機能で実装することを予定しています。

    ストレージポリシー

    ストレージポリシーとは、VMwareがSoftware-Defined Storageで定義している重要な仕組みの一つで、ストレージの可用性、パフォーマンス等のSLAをストレージの機能と連携しながらポリシーで管理していく仕組みを提供するものです。ポリシーベースのストレージ管理には大きく3つの領域があります。

    1. ストレージが有する機能及び通知する領域
    ストレージが機能として包含しその機能を外部に対して公開する領域です。

    2.ポリシーテンプレートを扱う領域
    上記したストレージプロバイダに基づきポリシーのテンプレートを作成する領域です。

    3.テンプレートを仮想マシンに適応する領域
    作成されたテンプレートを仮想マシンに適応する領域です。適応されたテンプレートはストレージ側で理解され、仮想ディスクがポリシー(SLA)に従って配置されることになります。

    それぞれの領域を順を追ってご説明します。

    1. ストレージが有する機能及び通知する領域
    この領域には実装方法が大きく2つあります。

    ストレージ自身が機能として実装
    ストレージが実装している機能を自身で外部公開するもの。上記例では、ストレージが有する可用性99.99%、パフォーマンス100K IOPSを外部に公開している部分となります。外部公開には、ストレージプロバイダ* という仕組みを利用します。Virtual SANもこの機能に対応しています。

    ユーザにより手動で定義される物
    上記がサポートされていないストレージの場合、ユーザー側でタグという形で定義することが可能です。例えばSSDで構成されたデータストア(群)をPlatinum、SATAで構成されたデータストア(群)をBronzeとしてタグ付けすることが可能です。ストレージプロファイルに比べると限定的な定義しか出来ず、どちらかというとデータストアをTire化+グルーピングして管理という利用法になります。

    Virtual SANでは、ストレージプロバイダを利用することにより以下の5種類の定義を行うことが可能です。

    ・許容される障害数(デフォルト:1 最大:3)
    1つのストレージオブジェクトについて許容されるホスト、ネットワーク、およびディスク障害の数を定義します。指定した値+1 個の仮想ディスクが作成されます。

    ・ストライプ数 (デフォルト:1 最大:12)
    単一のVMDKをストライピングして書き込むHDDの数を定義します。

    ・領域の予約 (デフォルト:0% 最大:100%)
    Virtual SANでは仮想ディスクは Thin Provisioningでデプロイされます。領域を確保したい場合は、ここで値を指定します。設定した値(割合)が vmdk に対し Virtual SAN内で予約されます。
    (例)50%設定の場合、10GBのVMDKファイル作成の際に5GB分が予約されます。

    ・フラッシュ読み取りキャッシュの予約 (デフォルト:0% 最大:100%)
    読み取りキャッシュ用に予約したい場合に指定します。

    ・強制的なプロビジョニング (デフォルト:無効)
    「はい」を指定すると、Virtual SANデータストアが仮想マシン作成ポリシーの要件を満たさない場合でもプロビジョニングされます。

    ※設定を変更する場合は、機能と影響範囲を良く理解した上で実施する必要があります。例えばストライプ数は、アプリケーション要件がSSD1台のパフォーマンスを超えない場合、デフォルトの1(ストライプ無し)に設定することをお勧めします。ストライピングによる無用なVirtual SANネットワークへの負荷発生を押さえるためです。

    ※ストレージプロバイダに関して
    ストレージの機能をvCenter Server側から利用するためには、ストレージプロバイダをvCentere Serverへ登録する必要があります。この登録作業は通常手動で行う必要がありますが、Virtual SANの場合はVirtual SANの有効化と共にストレージプロバイダが自動登録され利用可能となります。このため、Virtual SANでは、ストレージプロバイダを手動で登録する必要はありません。

    自動的に登録されたVirtual SAN用ストレージプロバイダ

    2.ポリシーテンプレートを扱う領域
    Virtual SANだけではありませんがポリシーテンプレートを作成するには、以下のように行います。まず、ホーム画面より仮想マシンストレージポリシーアイコンをクリックします。

    「ベンダー固有の機能に基づくルール」でVSANを選択すると、先ほどの5個のポリシーがプルダウンで表示されます。この中で最低 1 つのポリシーを定義します。

    例えば、オブジェクトあたりのディスクストライプ数:1 / 許容する障害の数:1 等を指定してポリシーの作成が可能です。ウィザードを複数回繰り返すことにより、複数のポリシー作成も可能です。

    下記は、ポリシーを3個作成した時の例です。

    3.テンプレートを仮想マシンに適応する領域
    2で作成したポリシーを適応して仮想マシンを作成します。具体的には、仮想マシン作成ウィザードの中のストレージの選択画面で、仮想マシンストレージポリシーを選択することにより、ストレージポリシーを適応した仮想マシンの作成が可能です。

    Virtual SANでは、Thin Provisioningでデプロイされます。このためディスクタイプは定義済みとなっており、変更することは出来ません。

    仮想マシン作成後、仮想ディスクがどのホストに配置されたかを確認することも可能です。例えば、ストライプ数2、許容する障害数1で仮想マシンを作成したときのディスクの配置は以下のようになります。

    これでVirtual SAN上に、ポリシー通りに仮想マシンを配置することが出来ました。

    次回、その3では、Virtual SANでの読み込み、書き込みの動作やホスト障害時の動作についてご説明したいと考えています。

    vSphere 5.5 の新機能紹介 VMware Virtual SAN その1

    このBlogは製品出荷前の情報を含みます。出来る限り正確な情報をお伝えするよう努めておりますが、実際に出荷される製品に搭載される機能や表示と異なる可能性があります。今回ご紹介するVirtual SANのステータスは 2013年 10月末現在 Public Beta であり、実環境での利用はサポートされません。また、最大構成や構成上の制限等は将来変更される可能性があります。あらかじめご了承ください。

    Virtual SAN の特徴

    今回ご紹介するVirtual SANは、従来のvSphereのストレージ概念とは全く異なる、拡張性に富んだストレージの新機能です。VMwareがSoftware-Defined Storage で定義しているポリシーベースでの管理もサポートしています。主な特徴を下記します。

    1. ローカルディスクを利用した共有ストレージ
    Virtual SANの最大の特徴は、各ホストに分散配置された内蔵ストレージを集約し、各ホストから利用可能な1つの共有ストレージとして提供することです。ホスト内蔵の安価で大容量な SAS/SATA の磁気ディスクと高速な SSD を組み合わせた、大容量かつ高速・低遅延な共有ストレージ領域を提供します。

    2. 仮想ディスクレベルで設定可能なSLA
    Virtual SANは従来のLUN+VMFSではなく仮想ディスクを直接オブジェクトとして管理します。このため、従来、LUN毎にしか定義できなかったパフォーマンスや可用性が仮想ディスク毎に定義可能となります。

    3. 拡張が容易なスケールアウト型のストレージ
    上記にも関連しますが、ホストの追加と共にデータストアも拡張される分散スケールアウト型のストレージです。

    4. ポリシーベースのストレージ管理
    仮想環境が大規模化してくるとストレージもTierの管理が必要となってきます。その際、従来行っていたストレージの物理構成(Raidの種類、デバイスの種類、プロトコルの種類)に基づいた手法では管理が煩雑となります。そこで、Virtual SANでは、可用性やパフォーマンスなどのポリシーをベースとしたストレージ管理手法を提供します。

    Virtual SAN構成要素

    Virtual SANは、SSDとHDDを有する3台以上のホストと、そのホスト間を接続する Virtual SANネットワークで構成されます。構成要素は下記の通りです。

    ・Virtual SANネットワーク
    ホスト間のストレージプロトコルの転送を担当します。通信速度としては、1Gbps 及び、10Gbps の両方をサポートしています。*

    ・SAS/SATAコントローラ
    SSDやSAS/SATAのHDDを接続するためのストレージコントローラです。Raidコントローラではパススルーモード、または、HBAモードをサポートしている必要があります。

    ・SSD
    ホストに搭載する、SAS/SATA/PCIeのデバイスを利用します。SSDは恒久的なデータの置き場所ではなく、リードキャッシュ、ライトバックキャッシュとして利用されます。このSSDのパフォーマンスが、Virtual SANデータストアのパフォーマンスに大きく影響します。

    ※Virtual SANとして定義したSSDデバイスは、VMFS/vSphere Flash Read Cache/ホストスワップ領域として利用出来ません。

    ・磁気ディスク(HDD)
    仮想ディスクを恒久的に保存する領域で、Virtual SANデータストアの容量を構成する部分となります。SSDでキャッシュミスした場合の読み出しと、SSDにライトバックされた書き込みキャッシュを最終的にディステージする領域を提供します。

    ※ESXiをインストールしたHDDデバイスはVirtual SAN用のHDDとして利用出来ません。

    ・ディスクグループ
    SSDとHDDは個別にVirtual SAN領域に追加されるのではなく、ディスクグループとしてまとめてVirtual SAN領域に組み込まれます。1 つのディスクグループには必ず1台のSSDと、1~6台のHDDが含まれます。ディスクグループはホストあたり最大5個作成可能です。このため、ホストあたり、SSDは最大5台、HDDは最大30台までVirtual SANでの利用が可能となります。

    ※Virtual SANネットワークには10Gbpsを強く推奨します。理由は以下の通りです。
    Virtual SANでは仮想マシンのvmdkを配置したホストと、仮想マシンが稼働するホストが同一ホストであるとは限りません。また、レプリカの作成やストライピングデータ転送に伴い、Virtual SANネットワークには多量のトラフィックが発生する可能性があります。現行のSATA SSDが6Gbpsインターフェイスを備えていることから考えても、1GbpsのVirtual SANネットワークではパフォーマンス上のボトルネックが生じる可能性が高いというのがその理由です。

    Virtual SAN 全体イメージ

    ・Virtual SANデータストアは、1 つの共有データストアとして各ホストからアクセスが可能です
    ・仮想ディスクを配置するホストと、仮想マシンが稼働するホストに依存性はありません
    vMotion での移行も通常の共有ストレージ同様自由に行うことが出来ます
    ・各仮想ディスク単位で可用性やパフォーマンス等のポリシーを定義することが出来ます
    例えば、下記例では、緑の仮想ディスクは3面ミラー、濃い青の仮想ディスクはミラーとなっています

    Virtual SAN の構築

    Virtual SANの構築は極めて簡単です。以下手順を示します。
    なお、この作業はc#版のvSphereClientからは実行できません。vSphereWebClientをご利用下さい。

    1. Virtual SANネットワークの定義
    Virtual SANを利用するにはまず、各ホストに対し、Virtual SANネットワークの定義を行います。

    2. Virtual SANの有効化
    Virtual SANはクラスタ単位で有効/無効の設定を行います。有効化の際のオプションとして、以下の二つがあります。

    自動・・・Virtual SAN有効化と同時にホスト内のSSDとHDDをVirtual SANデータストアとして自動的に追加
    手動・・・Virtual SANを有効化するのみ。Virtual SANデータストアに追加するSSD、HDDは別途手動で設定

    3. ライセンスキーの入力
    Virtual SANの利用にはライセンスキーの入力が必要です。VMwareが提供する他のアプリケーションのライセンスキーと異なり、クラスタレベルでライセンスキーを定義するところにご注意下さい。


    ※この設定を行わない場合、Virtual SAN構成を作成しても、Virtual SANデータストアの容量が”0”のままとなります。

    4. Virtual SANで利用するSSD/HDDの選択(ディスクグループの作成)
    手順2で手動を選択した場合、Virtual SANに追加するディスクを選択する作業が必要になります。

    ・ディスクグループの作成をクリックし、Virtual SANで利用するSSD 1 台と、HDD 1~6台を選択します。
    ・ディスクグループが複数ある場合は、上記作業を繰り返します。

    選択されたディスクはVirtual SANに組み込まれ、Virtual SANクラスタに所属する各ホストから利用可能となります。
    下記では、300GBのSATA HDD を搭載した4ホストでVirtual SANを構成した例を示します。

    作成後のVirtual SANクラスタの拡張も簡単です。この場合、以下のような様々な方法がサポートされています。

    ・既存のディスクグループへのHDDの追加・・・容量の拡張
    ・既存のホストへのディスクグループ(SSD+HDD)の追加・・・IOPSと容量の拡張
    ・新規ホストとディスクグループの追加・・・IOPS、容量とホストリソースの拡張

    また、ディスクの追加を伴わなず、ホストのみVirtual SANクラスタへ追加することも可能です。このようにVirtual SANは必要なリソースを柔軟に追加・拡張することが可能です。

    次回、Virtual SANがサポートする仮想マシンストレージポリシーについてご説明します。