Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: ストレージ

タグ別アーカイブ: ストレージ

押さえておきたいvSphereの基本~ストレージ編 第3回~

皆様こんにちは。前回は、vSphere のEnterprise エディションで提供される機能によりストレージの能力を最大に活用する方法をお伝えいたしました。引き続き、「押さえておきたいvSphereの基本」と題して、“ストレージを自動的に整える”方法をお伝えします。

ストレージを自動的に整えるとは、どういうことでしょうか?ストレージの能力/性能が最大限に活用できるようになれば、より多くの仮想マシンをストレージ上に配置できるようになります。しかしながら、仮想マシンのI/Oが競合し、ストレージの能力を超えてしまった場合には、仮想マシンのパフォーマンスは悪化してしまいますので、ストレージに対して性能や容量を整える工夫が必要になってきます。

■ストレージを整える

様々なサービスを提供する仮想マシンは、仮想マシン毎にI/O 数、レスポンスタイム、スループット、容量などストレージに対する要件が存在します。仮想マシンが安定して稼働するためには、きちんと仮想マシンの特性を理解して、バランスよく配置することが求められます。例えば、午前にI/O 要求が高まる仮想マシンと午後にI/O 要求が高まる仮想マシンを同一データストアに配置するという形になります。ところが、実際の仮想化環境というのは時間、分、秒といったもっと細かい粒度で稼働状況が変化していきます。また、仮想マシンの増減やシステムを利用するユーザの増減などによっても、CPUやメモリと同じようにストレージの要件は時間の経過とともに変化していきます。そのため、すべての仮想マシンの稼働状況を把握し、IT管理者の方が手動でバランスよく配置し続けることは作業負荷が重くなってしまいます。vSphere のEnterprise plus エディションでは、そのような課題を解決する機能を提供しております。

具体的な例を見ていきます。こちらの図1では、5つの仮想マシンが3台のホストと1つのデータストア上で稼働をしています。ホストは分散されておりますが、データストアは1つのみであり、5つの仮想マシンはこのデータストア上に配置されています。各仮想マシンは、稼働状況に応じて必要なI/Oを発行していますが、あるタイミングでストレージの能力を超えるI/Oが仮想マシンから発行された場合、ディスクI/Oに関する資源の取り合いが発生し、仮想マシンのパフォーマンスが劣化してしまう、またはそのデータストアに配置される仮想マシン全体に影響してしまうことも考えられます。パフォーマンス劣化する仮想マシンが、重要であればあるほど、問題が大きくなりますので、そのようなことが起きたとしても、影響をできるだけ少なくする必要があります。それが、仮想マシンのI/O優先順位を”整える”という機能(Storage I/O Control)です。

3-11

図1:複数の仮想マシンがデータストアを共有する= IOリソースの共有

この機能はストレージの能力に余裕がある場合では発動しませんが、ストレージの能力が枯渇した際(競合状態)に発動されることになります。図2のグラフは、仮想マシンのI/O優先順位を整えるよう設定した各仮想マシンの稼働状況になります。Phase1~3 は、いずれもストレージの能力が枯渇している時間となっており、単一ホストではなく、複数のホストに跨っていても状況を理解し、優先順位に応じて各仮想マシンからのI/O が整えられています。
各仮想マシンの優先順位は予めVM5(4000) >>> VM3,4(750) > VM1,2 (500) としております。
()内は仮想マシンに設定したシェア値です。

Phase2 の時間帯では、非常に高い優先順位を設定している仮想マシン(VM5)がシャットダウンされたことにより、使えるストレージ資源に空きが生じます。稼働している他の仮想マシンは、Phase1 の時より多くのストレージ資源を使えるようになっているため、各仮想マシンのパフォーマンスが向上しています。そして、再びPhase3 でVM5を起動すると、ストレージ資源が優先的にVM5 に提供されるようになります。仮想マシンのI/Oを整えることにより、ストレージ資源を有効活用し、たとえ枯渇したとしても、vSphereの機能で影響を最小限にすることできます。

3-22

図2:シェア値(優先度)の違いにおける負荷の様子

仮想マシンのI/Oの優先順位を整えるという説明をしてきましたが、Storage I/O Controlはストレージが一時的に資源不足になった際の対応策となります。常時発動されているという状況は配置している仮想マシンに対して、常にストレージの資源が足りていないということになりますので、恒久的な対策が必要になります。
例えば、1つのストレージ(データストア)の能力を上げるという方法もありますが、vSphere のEnterprise plusエディションでは、ホストと同じように複数のデータストアをデータストア クラスタとして、”束ねる”ことができます。データストア クラスタに資源が足りなくなった際、新たにデータストアを追加し、データストア クラスタのトータルの資源を簡単に増加させることが可能になります。例えば、100iops,100GBの資源を提供可能なデータストアが3つ登録されているデータストアクラスタは、300iops,300GBのひとつの資源と考えることができるようになります。

3-33

さらに自動的にこのデータストアクラスタを有効活用できるStorage DRS という機能を使用すれば、データストア クラスタ内(複数のデータストア間)で、過去の統計情報を基に負荷や容量を自動的に整えてくれます。自動的に整えられる際は、第1回でご紹介したStorage vMotion を使用し、システム停止させることなく行われます。※ホストのDRS と同様に手動モードで実施することも可能です。

仮想化環境において、ストレージ環境を整える機能を活用することにより、ストレージの負荷や容量を監視しながらの仮想マシンの配置、移行といったIT管理者の負荷を減らす事ができ、仮想環境の特性を活かしたより有効的な使用ができるようになります。

まとめ
今回、vSphere Enterprise plus エディションで提供している機能(ストレージに対する負荷や容量を自動的に整える機能)をご紹介させていただきました。主にESXiが10台以上となる環境では積極的に使用していただきたい機能になります。人間で例えると骨盤のずれで偏りができてしまうと、肩こりや頭痛など体全体の調整を崩してしまったり、本来のパフォーマンスが出せなかったりすることがあるかと思います。この「ズレや偏り」を治すため、整体やマッサージ等コンディションを整えたりします。ストレージでも同様、IOや容量の偏りが原因でシステム全体に影響がでてしまい、本来もっている能力を出せないことは非常にもったいないことです。是非vSphereの機能を有効活用していただき、仮想基盤のコンディション(すなわちパフォーマンス)をさらに高めていただければ幸いです!!

3-4
VMware青山健二/中村朝之

「押さえておきたいvSphereの基本」
~ストレージ編~
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

~ネットワーク編~
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜

~可用性編~
・物理リソースの有効活用と仮想マシンの最適配置~DRSとリソースプール編~
・システム障害に備える仕組み~vSphere HAとFT編~

押さえておきたいvSphereの基本~ストレージ編 第2回~

~ストレージの能力を最大限に引き出す vSphere~
皆様こんにちは!前回は、vSphereのストレージ機能において比較的小規模環境(約ESXi2~3台)でも使用できる代表的な機能をご紹介しました。一般的に仮想基盤は小規模構成から運用開始することが多く、仮想基盤の運用に慣れていくに伴い、規模を拡張していくことが多いです。規模を拡張するにあたり、物理リソースを単に増やしてしまうとコストメリットがなかなか出しにくくなり、安全に統合率(ESXi上で稼動する仮想マシン数)を上げていくことも考慮していく必要があります。そこで安全に統合率を上げていく際、重要な役割を担うポイントの一つとしてストレージがあげられます。

図2-1
 

図1 仮想マシンの増加とIO増加
仮想マシンの台数が増えると、もちろんストレージへのアクセス(通常のIOに加え仮想マシンの作成、テンプレートから仮想マシンを展開、Storage vMotion等)は増えます。ここで忘れてはいけない点として、仮想基盤は物理リソースを「共有」しているという点です。これはIO競合が発生しやすい状態ともいえ、ストレージがボトルネックになりやすい環境にもなりかねません。ここで管理者は仮想マシンの配置を仮想基盤の特性を十分理解する必要がでてきます。ストレージ側に関してはなかなか手が回らず、余裕の持ちすぎたサイジングになってしまう傾向があります。そういった中、vSphereではストレージとより連携し、そもそもストレージが持っている能力を最大限引き出し、管理者に余計な負荷がからない様、下支えをする仕組みを持っております。

■仮想基盤特有、ストレージのボトルネックを抑える
前回VMFSと呼ばれるファイルシステムをvSphereでは持っているとご説明をしました。複数のホストからアクセスされているような環境では、データの整合性のためにファイルシステムのメタデータの更新が必要となる場合、排他制御の仕組みが必要になってきます。vSphere 環境におけるメタデータの更新が必要となる代表的なオペレーションとしては、仮想マシンを新規作成、仮想マシンの起動/停止、vMotion、仮想マシンスナップショット取得時、等実行するタイミングになります。vSphere では、排他制御のためにSCSI-2のディスクリザベーションを利用しており、「LUN全体をロック」して他のホストからのアクセスを抑制するという動作になります。非常に短い時間ではありますが、他のホストで稼動している仮想マシンは、一時的にI/O ができない瞬間が発生してしまいます。 (図2)

図2-2withoutVAAI
 

図2 排他制御が多くかかってしまうと他の仮想マシンに影響してしまう
1LUN上に多く仮想マシンを配置させた結果、排他制御を多く発生させる仮想マシンがあることにより、同じLUN上にある他の仮想マシンのパフォーマンスを劣化させてしまう可能性がでてきます。そのため管理者は、なるべくこの排他制御の影響が出ないよう多くLUNを作成して仮想マシンの配置を細かく分けたり(=管理の煩雑さ増)、必要最低限のみ仮想マシンを配置(=余剰リソース増)させてしまう手法をとってしまいます。ストレージとしては、まだまだ余裕があるにも関わらず、少しもったいない使い方ともいえます。ここでvSphereで持っているStorage APIs for Array Integration(以下VAAI)を使用し、vSphereとストレージが連携することによって、排他制御の単位をLUN全体ではなく、より粒度の小さい単位でロックすることができます。これにより排他制御処理が発生した瞬間もLUN全体がロックされませんので、多くの仮想マシンを1LUN上に配置しても、排他制御による他の仮想マシンへの影響を少なくすることができます。図3(LUNも必要以上に細かく分ける必要性も減ってきますね)

図2-3 VAAIon
 

図3 VAAIを使用した排他制御 他のホストへの影響は最低限に
■ストレージにお願いできることはストレージへお願いする
もう1つ、VAAIの機能でストレージの能力を引き出す機能を紹介します。仮想化基盤を運用、管理するためには、仮想マシンのIO 以外にストレージに対する様々なIOが発生します。具体的には、テンプレートから仮想マシンを展開したり、前回ご紹介したStorage vMotion があげられます。ストレージから見れば、ファイル(ブロック)を“コピー”したり“移動”するような操作です。そのような操作は通常、図4の左のように複製元のストレージからデータをESXiで読み込んだ後、複製先のストレージにデータを書き込むことになります。もちろんこの動作はESXi自身が実施しているので、ESXi側リソース(CPUやメモリ)、ESXiとストレージ間の帯域を多く消費してしまいます。そこでvSphereではこの動作をストレージと連携してストレージ側にお願い、実施してもらうこともVAAIを通じて可能になります。

図2-4
図4 VAAIを使うとストレージ内でコピーが実施される
ESXi側(ハイパーバイザー)で処理している内容をストレージにお願いすることによって、ESXi側の負荷が減り、その分他の仮想マシンへリソース供給できたりします。またコピー中もVAAIを使用すればESXi~ストレージ間の帯域をほとんど使用しないので、他の仮想マシンへの影響も抑えられます。実際にその効果を見てみましょう。図5は、VAAIの有無によるStorage vMotionの結果になります。

図2-5
図5 VAAIの有無におけるStorage vMotion中の帯域
この結果を見ていただくとわかるように、VAAIを使用することで、データの複製がストレージ内で実施されることになるため、ストレージネットワークには、ほとんどデータが流れていないことがわかります。(青い線)また、ストレージ側のCPU使用率も下がり(赤い線)、Storage vMotion に要する時間も短くなっていることがわかります。VAAIはあまり機能として目に見えない「地味な存在」ですが、vSphereとストレージの連携がより密になり、ストレージにお願いできることはストレージにお願いし、仮想基盤全体としてよりリソースの効率性を上げることが可能になります。
上でご紹介した機能は、Enterprise エディションで提供されているStorage APIs for Array Integrationという機能の一部です。(Storage APIs for Array Integrationを通して他に実現できる機能はありますが、詳細はホワイトペーパ をごらんください)
※VAAIを使用するには、事前にVMwareの互換性リストでストレージがVAAIに対応しているか確認します。現状、主要ストレージベンダーから出荷されているストレージ製品であれば、ほぼこの機能に対応しておりますが、Firmwareのバージョンによって差異ありますので、事前にご確認ください。

■サーバ~ストレージ間のパスを整える
最後にESXi~ストレージ間のパスについてご紹介します。
仮想マシンが増えていくことにより、ESXi~ストレージを結ぶ”パス”をより有効に、安全に使用する必要もあります。vSphereでは標準でマルチパス機能を提供しております。もちろん経路障害によるフェイルオーバー動作であったり、IOの振り分け機能も提供しておりますが、Enterpriseエディションにある“”MultiPath”があることにより、ストレージベンダが提供するマルチパスソフトを使用することが可能になります。提供されているマルチパスソフトにより特徴があり、例えばより高度なIOロードバランシングによる帯域の有効活用が可能になったり、経路上の健全性を常に把握し、プロアクティブに障害検知を実施し影響を最小限に抑える等、ESXi~ストレージ間のパスをより整えることが可能になります。また複数のストレージにデータが分散している際、マルチパスソフト側でどのストレージにどのデータがあるのか把握できるので、目的のデータへ一発でアクセスでき余分なIOを発生させない、という特徴をもったマルチパスソフトもあります。ストレージベンダーが提供するより高度なマルチパスを使用することにより、見逃してしまいがちなリソースである「パス」をより有効に活用していただけることも可能になります。

図2-6
図6 パスの凸凹を整える
■まとめ
今回は主にvSphere Enterprise エディションで提供している機能をご紹介させていただきました。最近のストレージにおいては、ご紹介したVAAIに対応しているストレージが多くなってきております。是非このvSphereとストレージの連携に注目していただき、高機能なストレージの能力をより引き出していただき、仮想基盤を有効に使っていただければ幸いです。次回「押さえておきたvSphereの基本~ストレージ編~」では仮想基盤におけるストレージ環境の優先度の定義付けと自動化、をテーマにお送りします。お楽しみに!!

VMware青山健二/中村朝之

「押さえておきたいvSphereの基本」
~ストレージ編~
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

~ネットワーク編~
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜

~可用性編~
・物理リソースの有効活用と仮想マシンの最適配置~DRSとリソースプール編~
・システム障害に備える仕組み~vSphere HAとFT編~

押さえておきたいvSphereの基本~ストレージ編 第1回~

皆様こんにちは!
先週お伝えしたとおり「押さえておきたいvSphereの基本」と題して、仮想環境をご利用するにあたり押さえておきたい機能、ポイントをストレージ、ネットワーク可用性に分けてお伝えしておきます。
初回はストレージ編です。vSphere 環境に限りませんが、ストレージはシステムを稼動させる上で非常に重要なリソースの1つとなるため、ストレージ選定において、容量、可用性、パフォーマンス、コストなどを検討する上で重要なポイントとなります。そこでvSphereが持っているストレージ関連の機能で、どのようなことが実現できるかご紹介していきます。今回は第1回目ということで Standard エディションや標準的に利用できるストレージに関する代表的な機能を3つご紹介致します。

・ストレージ環境を最適化にするファイルシステム~VMFS~
仮想化環境では、物理サーバ(ESXi)とストレージ(ボリューム)の関係が1 : 1となるような形で導入いただくことも可能ですが、m : nとなるように共有ストレージと併せて導入していただくと、システムの運用効率や可用性を高めていただくことができます。

shared-Storage
 

図1 ESXiとストレージのイメージ
m:nのような環境を構成するためには、複数のESXiサーバが同じボリュームに同時にアクセスする必要があります。 FCやiSCSIを使用した共有ストレージ(ブロックデバイス)環境ではVMFSと呼ばれる共有可能なファイルシステム(Virtual Machine File System )を提供しており、このVMFS でフォーマットされた領域に対して複数のESXiホストからアクセス可能としております。ファイルシステムを複数のESXiホストから共有している以上、整合性を保つ何かしらの”仕組み”が必要になってきますが、VMFSの場合SCSI-2のディスクリザベーションを利用して排他制御を実現しています。

共有ファイルシステムといっても特に難しい設定はなく、それぞれのESXiからマウントするだけとなっておりますので、特殊な設定等はなく簡単に実装できてしまいます。ちなみにこの排他制御、標準のVMFSではLUN単位に動作しますが、規模等によってはさらに効率よく実施するための仕組み/VAAIをハードウエア側(ストレージ)と協力して実装しております。(その点は次回に触れていきます。)その他、ファイルシステムの拡張性ももちろん兼ね備えております。仮想環境に関してはディスク容量の拡張が頻繁に行われる傾向がありますがハード側(ストレージ側)における動的拡張の後VMFSのファイルシステム拡張も動的に行えますので拡張作業も安心ですネ。

パフォーマンスでも様々な工夫がされており、特徴的なのがVMFSのブロックサイズです。
一般的にフィルシステムでフラグメントが多発している状況では、連続領域にファイルが配置されていないためI/Oリクエストが複数ブロックに分断され性能劣化の可能性がありますが、VMFSのブロックサイズ(1MB)は一般的なゲストOSのブロックサイズと比較してかなり大きく、ブロック境界を跨ぐ機会が少ないため、仮にVMFS 自体にフラグメントが発生していても性能劣化の影響が少ないです。このようにVMFSは地味な存在ですが、仮想環境をより安心にご使用していただくため大きな役割を担っております。

・より多くの仮想マシンを配置するための工夫~シンプロビジョニング~
様々なストレージ関連の製品で実装されていることもあり、”シンプロビジョニング”という言葉を聞いたことある方も多いかと思います。 一般的にシンプロビジョニング機能を利用していただくと、実際に利用可能な容量以上のボリュームを予め作成できるようになるため、将来の容量増加の見込みがつかないシステムなどに対し、使用していない容量の初期投資を抑えることが可能になります。

例えば、5年間運用するためにディスクサイズを100GB と算出した仮想マシンを10 台作成するとします。本来であれば、約1TB の容量が必要になりますが、1 年間運用した結果、それぞれの仮想マシンは平均20GB ほどしか消費しなかったとすると、導入時200GB 準備すればよかったことになります。ストレージのシンプロビジョニング機能を利用すれば、計画的な増設が可能になります。また、仮想ディスクをシンプロビジョニング形式で作成することにより、約1TB の容量に対して、ディスクサイズを100GB を想定した仮想マシンは10 台以上配置することが可能になり未使用の割り当て領域が削減され、効率的にストレージ容量を使用できるようになります。

 

図2シンプロビジョニング:シンで作成された仮想マシンは使用領域のみストレージ側で消費されている
特に仮想環境では導入当初は小さく始め、その後拡張していく傾向があります。vSphereのシンプロビジョニングを使用して、小さく始めて、必要があれば拡張していくという方式も可能となります。このvSphereのシンプロビジョニング機能も、全てのエディションでご使用いただけます。

・ストレージにおける仮想マシン配置の最適化~Storage vMotion~
仮想環境では、仮想マシンの増加等で構成変更が頻繁に発生する傾向にあります。その際仮想マシンのストレージ配置等構成変更が多く発生するのも仮想環境の特徴のひとつです。仮想マシンはストレージ上のボリューム(LUN等)に格納されておりますが、仮想マシンが増えていくと、容量が枯渇したり、IO競合が多く発生する可能性がありますので、将来的に仮想マシンの配置を変える可能性が高いことも考慮する必要があります。そこでvSphereでは仮想マシンの配置変更をオンラインで実施するための機能”Storage vMotion”を提供しております。

 

図3 Storage vMotionのイメージ 異なるストレージへ仮想マシンをオンラインで移行
Storage vMotionの特徴としては仮想マシンを止めずに仮想マシンを配置しているストレージを変更できます。例えばFCストレージからiSCSIストレージへの移行も可能です。ストレージの容量が足りなくなってきたり、IOの激しい仮想マシンが他の仮想マシンに影響を及ぼす様であれば、IOの負荷分散として仮想マシンの配置変更をオンラインで実施できます。操作も以下のとおり数ステップでできてしまうので非常に簡単です。

Storage vMotionの操作
移行する仮想マシンを選んで「移行」を選択

「データストアの変更」を変更。ここで「ホストの変更」を選択するとvMotionになります

仮想マシンの移行先を選択します。

「終了」を押せばStorage vMotionが開始されます。

仮想環境では複数のシステムが物理的なリソースを共有している関係上、運用フェーズで仮想マシンの配置変更を実施することが多くなるかと思います。このStorage vMotionでシステムを止めずに仮想マシンの配置を変更できることは、私も通常業務で大変助かっております!

今回はvSphere Standard エディションで提供しているストレージに関する代表的な機能を3つご紹介させていただきました。今回ご紹介した機能、VMFSやシンプロビジョニング機能はエディションに関係なく標準的に実装されている機能です。Storage vMotionに関してはStandardエディションから実装されている機能になりますが、どの機能も仮想環境におけるストレージを下支えする重要な機能となっております。次回「押さえておきたいvSphereの基本」ストレージ編第2回目は、~ストレージと連携しパフォーマンスを最大化~するという題目でお送りします。

VMware青山健二/中村朝之

「押さえておきたいvSphereの基本」
~ストレージ編~
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

~ネットワーク編~
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜

~可用性編~
・物理リソースの有効活用と仮想マシンの最適配置~DRSとリソースプール編~
・システム障害に備える仕組み~vSphere HAとFT編~

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がサポートする仮想マシンストレージポリシーについてご説明します。

vSphere 5.5 の新機能紹介 vSphere Flash Read Cache (vFRC)

このBlogは、製品出荷前のバイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は、vSphere 5.5の新機能である、vSphere Flash Read Cacheをご紹介します。

NAND型のフラッシュメモリを利用した高速なストレージデバイスであるSSDは、既にコンシューマー用途からデータセンター用途まで幅広く利用されています。既存のvSphere5.1では、以下の2つの用途でSSDを利用することが可能でした。

1. 通常のデータストアやRDM (主に仮想マシンファイルを配置)
2. ESXホストのvmkernel swap領域 (ホストメモリ不足の際の待避場所として利用)

一言にSSDと言ってもSANやNAS、iSCSI等のリモートストレージに搭載されたSSDと、個々のServerに搭載されたLocal SSD がありますが、前者は1の目的で利用され、後者は共有ストレージとしての利用が難しいことから主に2の目的で利用されてきました。

vSphere5.5ではこの2つに加え、個々のServerに搭載されたLocal SSDを、仮想マシンのRead Cacheとして利用することが出来るようになります。これが、今回ご紹介するvSphere Flash Read Cache (vFRC)です。これまで限定されていたServer本体に搭載されたSSDの利用が、vSphere5.5からは仮想マシンのパフォーマンス向上のため、より簡単に利用できるようになります。

vFRC概要

vFRCは、仮想ディスク(VMDKファイル)のリードキャッシュとして、Localサーバに搭載したSSDを利用する仕組みを提供します。この機能を利用することにより、下記2つの効果が期待できます。

・仮想ディスクの読み込み速度の向上
・vmdkファイルが配置されたストレージ負荷の軽減

この機能を提供するため、ESXiホストは、自身に搭載されたSSD上にvFlash File System (VFFS)を作成します。このVFFSは仮想マシンへのキャッシュアクセスを提供する専用のDiskリソースで、通常のVMFS領域と異なりデータストアとしては見えません。VFFSが構成されたESXiホスト上の仮想マシンはvFRCの利用が可能となります。

vFRCの特徴

・Localサーバに搭載されたSSDを利用(リモートSSDは利用不可)
・仮想ディスクに対するリードキャッシュ、ライトスルーキャッシュとして機能
・ESXi 5.5以降及び、仮想マシンバージョン 10 以降が必要
・操作はvSphere Web Client でのみ可能(従来のc# 版での操作は不可)
・ホストに搭載したLocalのSSDのみ利用可能
指定可能なデバイスは最大8台
デバイス 1台の最大容量は4TB
ホストあたり最大32TB (4TB x 8台)*
・VFFSに指定したデバイスは、VMFS領域やvSAN領域として利用することは出来ない
・VFFSはホスト毎に1個作成される
・仮想Disk毎にvFRC利用の有無と容量の設定が可能(初期設定はDisable)
ブロックサイズは4KB~1024KBで設定が可能
・各仮想マシンに設定されたvFRC領域はパワーオン時にVFFS領域に対して予約される(VFFS領域のオーバーコミットは不可)
VFFSの容量が足りないと仮想マシンのパワーオンが出来ない
・VFFS はホスト固有であり、ホスト間でのシェアはされない
vMotion時、vFRC領域の同時移行も可能(破棄することも可能)
・vFRCをEnableに設定した仮想マシンは、vFRCがEnable化されたホストでのみ稼働可能
vFRC がDisableとなっているホストへのvMotionやHAは不可
・DRSのリソース管理においてはvFRCのアンバランスは考慮されない
・vFRC設定をされた仮想マシンは、DRSではホストとのSoft Affinity設定(可能な限り移行しない)となる

*ホストあたり管理可能なフラッシュの最大量です。うちvFRCで利用可能な領域は最大2TBとなります。
最新の情報は、構成の上限をご確認下さい。

vFRCの設定方法

vFRCの設定は極めて簡単です。ホスト側にVFFSを定義し、仮想マシン側でvFRCの利用設定を行います。

ホスト側の設定:VFFSの定義

1. vSphere Web Clientに接続
2. 設定を行うホストを選択し、”管理”タブ → ”設定” → ”仮想フラッシュリソース管理” を選択
3. 容量の追加をクリック

4. ホストに搭載されたSSDデバイスのリストが表示されますので、vFRCで利用するデバイスを選択します。

※ホスト側にこの設定を施すことにより、VFFS領域が作成されます。

次は仮想マシンに対する設定です。

仮想マシン側の設定:vFRCの設定

5. vFRC設定を行う仮想マシンを右クリックして”設定の編集”を選択
6. vFRC設定を行う仮想ディスクを展開し、”仮想フラッシュ”の詳細をクリック

7. 仮想フラッシュの有効化にチェックを入れ、キャッシュ容量とブロックサイズを指定します。

以上で完了です。

手順6、7を繰り返す事により、複数の仮想ディスクに対して設定を行うことも可能です。

また、この手順は仮想マシンがパワーオンの状態でも行うことが出来ます。

vFRCとvMotion

VFFSはホスト毎の管理となるため、仮想マシンがvMotionで移行してしまうと旧ホスト上のリードキャッシュは利用できなくなります。このためvSphere5.5のvMotionでは、vFRC設定が施された仮想マシンを移行する際、vFRC領域も同時にコピーを行う仕組みが提供されています。技術的には、vSphere5.1で実装された、XvMotion(Storage vMotionとvMotionの同時実行)の仕組みを利用しています。

リードキャッシュですので、vMotion時にドロップすることも可能です。この際は、移行先のホストで自動的に再作成されます。XvMotionの仕組みを使ってvFRCをコピーするか、ドロップするかは、vMotionウィザードの中で選択可能です。

コピーを選択すると、移行先でも蓄えたリードキャッシュをそのまま利用することが可能ですが、移行時にはvFRCのコピーにまつわる時間と負荷がかかります。

統計情報

vFRCに関する統計情報は、vSphere Web Clientやesxcliコマンドを利用して取得することが可能です。

1. vSphere Web Clientでは、該当する仮想ディスクに対し、以下のパラメータが新たに追加されました。

・vFRCキャッシュIOPs
・vFRCキャッシュスループット
・vFRCキャッシュ遅延

2. esxcliでは、”esxcli storage”に vflash というNamespaceが新たに追加され、例えば、esxcli storage vflash cache list コマンドでは作成されているvFRCのキャッシュファイルリスト、esxcli storage vflash cache stats get -c <Cache File Name> コマンドでは、特定のvFRCに対するキャッシュのヒット率やキャッシュIO数などの統計情報の確認が可能となりました。

まとめ

仮想ディスクへの読み込み速度の高速化とストレージ負荷の削減を実現するvFRC。以下のような環境に利用すると特に効果的です。

・読み込みの多いアプリケーションを仮想マシン上で稼働させる場合
・vmdkファイルを配置するStorageの性能よりも、VFFSを構成するSSDの性能が大幅に高い場合
・vmdkを配置したStorageの読み込み負荷が大きく、この負荷を軽減したい場合

是非ご利用下さい!

また、vFRCのパフォーマンスに関するTechPaperも公開されました。こちらも是非ご一読下さい。

http://www.vmware.com/files/pdf/techpaper/vfrc-perf-vsphere55.pdf