Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2015年5月

月別アーカイブ: 2015年5月

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 の進化に追従していく予定ですので、是非今からご利用のご検討をスタート頂ければと思います。

vSphere 問題解決までのヒント!- 第1回 トラブル発生時に役立つ 4 つのリソース

テクニカルサポートエンジニアのMarieです。

みなさん、VMwareのサポートにどのような印象をお持ちでしょうか。
職人のようなサポートエンジニアがログを見てさくさくっと回答していると思われるかもしれませんが、
技術的な調査に取りかかる以前に 「何が出来なくてどうお困りなのか」 をお伺いするのに苦労していたりもします。

私が日々お仕事をしていて感じるのは「事象や構成が整理されているお問い合わせは、解決までのスピードが早い!」ということです。
長引いているケースが技術的に難しくて複雑であるとは限らなくて、事象や構成がはっきりしないために技術的な調査が進められないということもあるのです。

この連載では、スムーズな問題解決のためのヒントになるようなお話しをしていきたいと思います。
技術的な話が少なくて拍子抜けかもしれませんが、「サポートエンジニアも結構地道な作業をしているのね!」と感じていただけるかと思います。
徐々にステップアップしていきましょう!

第1回 トラブル発生時に役立つ 4 つのリソース ←This Post
第2回 サポートリクエスト(SR)と情報採取
第3回 実践編

今回はトラブル発生時に役立つリソースとその使い方をご紹介いたします。

  1. ナレッジベース(http://kb.vmware.com/
    障害の発生事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
  2. 各種ドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/
    製品マニュアルやリリースノートなど、各種ドキュメントが公開されています。
  3. コンパチビリティガイド(http://www.vmware.com/resources/compatibility/search.php
    VMware製品とハードウェアやOSの互換性をチェックすることができます。
  4. VMware製品間の相互運用性マトリックス(http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php
    VMware製品間の互換性をチェックすることができます。

これから紹介するページは、弊社のサイト(http://www.vmware.com)トップ画面の [サポート] からアクセスできます。
設計・構築時にご利用いただいているものもあるかと思いますが、今回はトラブル発生時にどのようなポイントを確認したらいいかという観点でご説明したいと思います。
はじめての方も、まずは手を動かしながら色々調べてみましょう!

supportblog_index

1. ナレッジベースKnowledge Base(http://kb.vmware.com/supportblog_kb1
まずはここ、1つ目はナレッジベース(Knowledge Base)です。
障害の事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
エラーメッセージやコンポーネント名、ハードウェア名などで検索してみて下さい。
最近は日本語に翻訳された記事も増えてきているのですが、英語で書かれた記事をベストエフォートで翻訳していますので、最新情報ではない可能性もあります。
例えば、日本語版では回避策なしと案内されている場合も、オリジナルの英語版では回避策や修正についての情報がアップデートされているかもしれません。
日本語版の記事にはオリジナルの英語版へのリンクがありますので、必ずこちらも合わせて確認するようにして下さいね。


2. 各種ドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/

そして2つ目、製品ドキュメントやリリースノートをはじめ各種ドキュメントが公開されています。
supportblog_doc1
まずは html 版の vSphere 5.5 の製品マニュアルである「VMware vSphere 5.5 ドキュメント センター(http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/Welcome/welcome.html)」を見てみます。
上記のページ「VMware vSphereのドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/)」各ガイド欄にリンクされています。
supportblog_doc2
確認してもらいたいポイントに沿ってご紹介します。

・構成(システム要件、インストール方法など)
要件を満たしていないシステムでは予期せぬトラブルが発生することがあります。
ご利用いただいている環境がシステム要件を満たしているか、インストールや設定方法に問題が無かったか確認してみましょう。
お客様のシステムはお客様が一番よく知っているはずなので、ここは頑張っていただきたいポイントです!

システム要件を見てみます。
vSphere のインストールとセットアップから展開できます。
supportblog_doc3
例えば、vCenter Server, Web Client, Inventory Service, Single Sign-On すべて同じマシンの構成だと 12GB 以上のメモリが必要ですが、この条件を満たしていないマシンをたまに見かけますね。
基本的なことではありますが、念のためひとつひとつ確認してみて下さい。
supportblog_doc4・トラブルシューティングガイド
トラブルシューティングガイドでは、よくあるトラブルについて、問題・原因・解決方法が説明されています。
このガイドに記載の無い問題であったとしても、類似の問題から何かヒントを得られるかもしれませんので目を通してみて下さい。
supportblog_doc5

次に確認していただきたいのがリリースノートです。
リリースノートには新機能の紹介だけでなく、既知の問題とその回避策も公開されています。
supportblog_rn1
「VMware vSphereのドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/)」ページに戻り、vCenter Server 5.5.x の一番新しいバージョン(5.5 Update 2d)のリリースノートを見てみます。
既知の問題の欄をご参照下さい。
ここで紹介されている問題にあてはまりそうな場合、回避策を試してみて下さい。
supportblog_rn2

トラブル時の確認という観点でいうと製品ドキュメントとリリースノートあたりですが、他にも色々なドキュメントが公開されています。
製品への理解を深めるのにお役立てください。


3. コンパチビリティガイドVMware Compatibility Guide http://www.vmware.com/resources/compatibility/search.php

3つ目、少しレベルアップして構成にあわせた確認をしていきましょう。
ストレージやネットワークなど問題が絞りこめている場合は、改めてハードウェアのコンパチビリティを確認してみて下さい。
項目によっては互換性の有無だけではなく、推奨設定なども確認できます。

supportblog_hcl1

試しに私が使っているマシンのHBAのコンパチビリティを確認してみましょう。
vmhba0として認識されているIntel Corporation Avoton AHCI Contorollerにポイントします。

supportblog_hcl3

esxcfg-infoコマンドで詳細を確認してみます。

supportblog_hcl4
supportblog_hcl5

ESXi のバージョンも確認しましょう。
Buildは1892794 なので、ESXi 5.5U1 とのコンパチビリティを確認することになります。

supportblog_hcl6

Web Clientからもハードウェアの情報を確認できます。
インベントリツリーで [ホストおよびクラスタ] – [該当のホスト] – [管理タブ] でネットワークやストレージアダプタを確認できます。

supportblog_wc1

詳細な情報を確認したい場合は、[管理タブ] の右隣 [監視タブ] の [ハードウェアステータス] から該当のアダプタを選択して下さい。

supportblog_wc2

ESXiのバージョン、Buildは [サマリタブ] の [構成] から確認できます。

supportblog_wc3

では、確認した情報を元に検索してみます。

調べる対象はSATA controller なので [What are you looking for] は [IO Device] 、[I/O Device Type] は [SATA] に設定しました。
[Brand Name] や [VID] や [DID] も esxcfg-info や ハードウェアステータスタブ の内容を参考に選択し、 [Update and View Results] で検索を実行します。

supportblog_hcl7

出ましたっ!

supportblog_hcl8

ESXi 5.5U1とIntel Corporation Avoton AHCI Contorollerには互換性があることが確認できました。

supportblog_hcl8

ドライバのバージョンも問題ありませんね。
最新のドライバがあればアップデートしておくとベストです。

supportblog_hcl10

手順やよくある質問についてはこちらをご覧下さい。

* VMware KB: Identifying correct driver for ESXi/ESX host PCI devices (HBA) using VMware Hardware Compatibility Guide (HCL) (1031534)
http://kb.vmware.com/kb/1031534
* VMware KB: Identifying and downloading the appropriate driver for your adapter: Process and FAQ (2050194)
http://kb.vmware.com/kb/2050194


4. VMware製品間の相互運用性マトリックスVMware Product Interoperability Matrixeshttp://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php

見落としがちな4つ目、VMware製品間の相互運用性マトリックス(VMware Product Interoperability Matrixes)では製品同士の互換性を確認することができます。
バージョンアップや旧環境からの移行の後に問題が発生したなんていう時は、念のため確認してみて下さい。supportblog_iom1

では私の使っているマシンにインストールされている ESXi とそれを管理している vCenter Server の互換性を確認してみます。
ESXi はBuild 1892794 なのでESXi 5.5U1、vCenter Server はBuild 2183111 なので 5.5U2 に該当します。
[Select a Solution] で [ESX/ESXi] を選択し、[Version] を指定するとESXi5.5.U1の列が追加されました。

supportblog_iom2

今回確認したいのは vCenter Server との互換性です。
[Add Plat form/Solution] には [vCenter Server] を選択し [Add] すると [vCenter Server] の行が追加されました。

supportblog_iom3

チェックが付いているのが互換性ありのしるしです。
ESXi 5.5U1 と vCenter Server 5.5U2 は互換性に問題が無い組み合わせであることが確認できました。
手順は以下のKBが参考になります。

* VMware KB: Using the VMware HCL and Product Interoperability Matrixes (2006028)
http://kb.vmware.com/kb/2006028

ここまで調べてみて、いかがでしたでしょうか。
問題は解決しましたか?

どれにもあてはまらない…
案内されている方法を試してみたけど直らない…

という場合はサポートリクエスト(SR)を発行してみましょう。
「それなら最初から問い合わせすればよかった!」と思っているかもしれないみなさまに、
ここまで手を動かした努力は決して無駄ではない!」ということをお伝えしたいです。

最初にお話したように、スムーズな問題の解決のためには、問題に対するお客様のご理解がとても大切です。
コンパチビリティを確認してみて、普段ご利用いただいている環境のことがより理解できたのではないでしょうか。
また、ナレッジベースやドキュメントを検索しているうちに、発生している事象が整理されてきたのではないかと思います。

次回はサポートリクエスト(SR)の発行と情報採取についてお話したいと思います。

連載 vSphere 問題解決までのヒント!
第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取
第3回 実践編

VMware vSphere 6.0 の新機能 vMotion編

こんにちは、パートナーSEの川﨑です。今回は VMware vSphere 6.0 のリリースに伴う、VMware vSphere vMotion の機能アップデートについてご紹介いたします。vMotion の機能拡張は今回のアップグレードの目玉の一つとなっておりますので、ぜひご注目ください。

 

■クロス vCenter vMotion( vCenter Server システム間のvMotion )

クロス vCenter vMotion とは、異なる vCenter Server の配下にある ESXi ホスト間で vMotion を可能にする機能です。これまで、vSphere 5.5 まででは、vMotion は同一の vCenter 下でしか行うことができませんでした。今後は、図1のイメージのように、異なるvCenter に所属するホストやクラスタを移行先として vMotion で移行することが可能です。(図1では、”CentOS2” という仮想マシンを ”172.16.119.132” の vCenter 下の ”Cluster2” というクラスタから、”172.16.119.131” の vCenter 下の ”VSAN” というクラスタへの移行を示しています。)

図1.クロスvCenter vMotion での移行イメージ
図1.クロスvCenter vMotion での移行イメージ

クロス vCenter vMotion の実施方法は通常の vMotion となんら変わらず、図2のように仮想マシンを選択して、アクションとして”移行”を選択し、”計算リソースのみ変更します”または”計算リソースとストレージの両方を変更します”を選択してウィザードを進めることで、通常の vMotion 同様に移行を行うことが可能です。

なお、異なる vCenter 間での移行時の要件については弊社ドキュメントの下記ページをご参照ください。

http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-897E10D6-A413-4699-B3C6-498AA80CB9ED.html

 

図2.クロスvCenter vMotion の実施方法

図2.クロスvCenter vMotion の実施方法

クロス vCenter vMotion が可能となったことで、これまで vCenter の管理範囲ごとに区切られていた仮想基盤が vCenter の縛りを超えて一つの共通プラットフォームとして扱えるようになります。データセンターごとに vCenter を分けていたケースなどでは、今回初めて vMotion での移行が可能になり、嬉しい機能拡張ではないでしょうか。

vCenter Server を超えた際に気になる点の一つとして、仮想マシンに関する様々な情報は引き継がれるのか、といった点があります。実際には多くの情報は引き継がれ、仮想マシンの MAC アドレスや、タスクの履歴、シェアや予約値といったリソース設定、HA・DRS の設定等は引き継がれますが、パフォーマンスデータは引き継がれない仕様となっております。詳細は補足として、記事の最後に記載いたします。

■長距離 vMotion 移行

長距離 vMotion 移行は、長距離に離れたデータセンター間など、遅延が大きい環境間での vMotion を可能にします。通常の vMotion で許容される RTT (=round trip time) は 5ms ですが、これが Long Distance vMotion では 150ms まで許容されます。これにより、アメリカであれば大陸の東西、日本であればシンガポールまでの距離であっても、vMotion で仮想マシンを移動させることができます。 (*レイテンシは実際に利用する回線の品質にも依存します。上記はあくまで一例とお考え下さい。)

http://kb.vmware.com/kb/2106949

 

図3.長距離vMotion移行の実施イメージ

図3.長距離vMotion移行の実施イメージ

■vMotion ネットワーキング

vMotion のネットワーク周りについてもアップデートがあります。一つは、TCP/IP スタックが複数構成できるようになったことにより、vMotion についても専用のTCP/IP スタックが構成可能となりました。VMKernel アダプタの作成時に、TCP/IP スタックとして ”vMotion” を選択することで設定することができます。(図4)

 

図4.vMotion専用TCP/IPスタックの設定

図4.vMotion専用TCP/IPスタックの設定

TCP/IP スタックが vMotion 専用で構成できるようになったことに伴い、vMotion 用ネットワークが異なる L2 セグメントに跨る場合にも柔軟に構成できるようになりました。従来は vMotion 用トラフィックが有効化された VMKernel アダプタ も管理ネットワークと同一の TCP/IP スタックを利用しましたが、vSphere 6.0 では個別にデフォルトゲートウェイやルーティングテーブルの構成を持つことが可能です。なお、仮想マシンの接続されるネットワークについては同一のL2ネットワークセグメントへの接続が必要です。(図5では青線が vMotion 用ネットワーク、緑線が仮想マシン用ネットワークを示しています)

図5.vMotionネットワークの構成例

図5.vMotion ネットワークの構成例

次に、クロス vSwitch vMotion について触れます。vSphere 5.5 まででは、vMotion 時には接続前後で接続する標準仮想スイッチ(vSS)、または分散仮想スイッチ (vDS) の仮想マシンポートグループを選択することはできず、移行前後で同じ仮想マシンポートグループ(vSS の場合は同じラベルのポートグループ)に接続する必要がありました。vSphere 6.0 では、移行後に接続する仮想マシンポートグループの選択が可能となり、例えば vSS の仮想マシンポートグループに接続されていた仮想マシンを vDS の仮想マシンポートグループに接続することも可能となりました。ただし、vDS から vSS への移行は選択できない点と、移行前後で IP アドレスの変更はされないため、仮想マシンのネットワーク接続確保のためには同一の L2 ネットワークに接続し続けることが必要な点には注意が必要です。

 

図6.vMotion移行ウィザード中でのネットワーク選択

図6.vMotion 移行ウィザード中でのネットワーク選択

■補足:クロス vCenter vMotion で引き継がれる情報、引き継がれない情報について

下記で、クロス vCenter vMotion での移行前後で、引き継がれる情報と引き継がれない情報を整理いたします。内容については、一部検証結果に基づく情報であることをご承知ください。

①UUID

uuid.bios と vc.uuid は保持され、uuid.location は変更されます。これらは vmx ファイルを参照することで確認可能です。

x-vc_uuid

②MACアドレス

MACアドレスの変更はありません。また、移行元の vCenter Server では、 MAC アドレスをブラックリストに追加して、新しく作成された仮想マシンにその MAC アドレスが割り当てられないようにします。

x-vc_mac

 

③HA/DRS ルール

基本的には下記ルールはクロス vCenter vMotion 後も保持されます。

  • アフィニティルール
  • VM ごとのオーバーライドルール
    • 自動化レベル
    • 起動優先順位
    • ホスト分離時の対応

x-vc_affinity_ok1x-vc_affinity_ok2

ただし、下記の場合は例外的に保持されないことが社内の検証で確認されています。(判定は VM ごとに行われます)

  • アフィニティルール
    • VM ごとのオーバーライドルールが設定されている場合
      x-vc_affinity
  • VM ごとのオーバーライドルール
    • 移行先のクラスタの設定と同じ設定がされている場合
      x-vc_override

*アフィニティルールは VM 間で設定している場合、適用には双方の VM でルールが保持される必要があります

 

④リソース設定

仮想マシンに対する CPU、メモリリソースのシェア、予約、制限値は保持されます。

x-vc_resource

 

⑤タスクデータ

タスクデータは引き継がれます。

x-vc_task

 

⑥パフォーマンスデータ

パフォーマンスデータは移行の前後で引き継がれません。

x-vc_performance

 

⑦vRealize Operations Manager 上のデータ

vRealize Operations Manager 上のパフォーマンスデータは移行前後で引き継がれません。

x-vc_vROps

 

■終わりに

vSphere の基本的な機能の一つである vMotion ですが、vSphere 6.0 では更なる機能拡張がなされました。上記のアップデートを踏まえて、更に vMotion を使いこなしていただけたらと思います。最後までお読みいただきありがとうございます。

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 vRealize Operations Manager (vR Ops)の主な得意分野は、仮想基盤のキャパシティ管理や健全性管理ですが、他社の運用管理製品と連携することによって、vR Ops単体では不十分な機能を相互に補完し合う事が可能です。

今回は株式日立製作所の運用管理製品「JP1」、およびストレージ管理製品と連携してクラウド基盤全体、およびその上で動くサービスや業務を安定的に運用する方法について、株式会社日立製作所の坂川博昭様と同 長江亮介様にご紹介していただきます。それでは坂川様、長江様よろしくお願い致します。

 

hitachi_apr2015_sakagawa_banner

こんにちは。株式会社日立製作所 ITプラットフォーム事業本部 JP1ビジネス推進センタの坂川(さかがわ)(以下、坂川)です。私は、JP1のモニタリング製品を中心に拡販活動をしています。今回は、最近よく話題になっているクラウド環境についてお話をさせて頂きます。特に、さまざまなクラウド環境でも、一つにまとめて管理できる統合運用管理製品JP1のご紹介をしたいと思います。

hitachi_apr2015_nagae_banner

皆さん、こんにちは。同じく日立製作所 プロダクトビジネス推進部の長江(ながえ)です(以下、長江)。僕は、プラットフォーム製品、サーバ・ストレージ含めた装置周りの運用管理ソフトウェアの拡販に従事しています。これまでは特にストレージ運用管理を担当していましたので、その観点で最近のマルチクラウド環境のストレージ運用まわりの課題への新しい解決案をご説明したいと思います。

専用ツールがネックになる?マルチクラウド運用管理の落とし穴

hitachi_apr2015_sakagawa_icon (坂川)最近クラウドって言葉がはやっていますけど、さまざまな会社がクラウドサービスを提供しています。それぞれのクラウドを管理する時には、それぞれ専用ツールを使って管理をするのが一般的です。それだと、それぞれのツールの使い方を覚えないといけないですし、UIも異なるので、管理者には負担が大きいという問題があります。

日立の統合運用管理製品JP1を使いますと、複数のクラウド管理が、一つの製品でまとめて管理できるというメリットがあります。運用コストも低減できますし、管理者も運用が楽になるというメリットがあります。

hitachi_apr2015_nagae_icon

(長江)確かにそういう負担はありますよね。それぞれのクラウド環境で用意されたツールを使わないといけないですし、使いやすさの面で、ネックになることが多いですよね。ですから、そこを統合的に管理できるツールがあれば、ぐっと楽になりますよね。

 

hitachi_apr2015_sakagawa_icon(坂川)そうですね。JP1を使いますと、マルチクラウド環境の一元管理ができます。構成情報に関しては、JP1/Integrated Management(以下JP1/IM)でさまざまなクラウド環境の構成情報を取得することができます。

hitachi_apr2015_jp1-vrops_rev2

稼働監視については、JP1/Performance Management(JP1/PFM)を使うと、さまざまなクラウド基盤が混在していても情報を一つの画面で確認することができます。今どうなっているのか、リソースの使用状況はどうなのかを俯瞰することができます。

クラウド上で稼働している業務については、ジョブ管理製品であるJP1/Automatic Job Management System 3(JP1/AJS3)を使うことによって、クラウド上での業務を自動化できます。

クラウド種別を問わずに、監視や業務で発生するイベントをJP1コンソール画面で一元管理をすることができます。この画面では、マルチクラウド環境で発生するイベント、それから監視で発生するイベント、業務で発生するイベントを「統合監視」できます。

hitachi_apr2015_nagae_icon

(長江)最近はお客さまがクラウド管理をされることが多いですし、例えば、従来ではストレージは管理していなかったのに、今はサーバ・ストレージを含めた全体的な管理の必要にせまられているお客さまが増えてきています。クラウドの実績が豊富なVMwareとストレージ間での課題もありますよね。

 

hitachi_apr2015_sakagawa_icon

(坂川)そうですね。他にも、クラウドを利用していて動作が重くなった時に、どこに問題があるのかを分析するのも結構大変になってくるのかなと。そういう時に、ツールを使って仮想のリソースが足りないのか、それともサーバなどのハードウェアのリソースが足りないのか、もしくはストレージに何かボトルネックがあるのかとか、そういう分析をする作業もすごく大変ですよね。

VMware社の管理ソフトであるvRealize Operations Manager(以下vR Ops)を使うと、どこに問題があるのかをヒートマップで表示してくれて、「ストレージのどこどこの箇所でI/Oネックが発生している」といった事象がわかる仕掛けになっています。このvR OpsとJP1を連携させると、管理者にとってさらにやさしい運用ができるようになります。例えば「リソースが足りなくなっているよ」というイベントをJP1で検知して、じゃあその問題はどこにあるのかをvROpsで分析するといった感じですね。

ストレージの観点でも、いろいろと課題はありますよね?

hitachi_apr2015_nagae_icon

(長江)そうですね。VMware製品を使われている方は、管理対象をVM単位とすることが多いと思いますが、やはり従来のストレージだと、LUN(Logical Unit Number、ストレージの論理ユニットを識別するための番号)単位、ボリューム単位の管理になってしまうので、ストレージとサーバで管理したい粒度が異なったりと、課題はありますね。

例えば、従来の環境だと「VMがなんだか遅いなあ」という時に、まずはVMを構成しているデータストアを調べて、そのデータストアがどこのストレージにつながっているかを調べて、そのデータストア上に乗っているVMのどれが影響を与えているかを調べなきゃいけなかったので、非常に大変でした。

それに、LUNの上に載っているVMが複数あれば、どのVMに原因があるかの特定も難しいですし。やはり、ストレージはLUN単位、サーバはVM単位で管理しているところに、管理対象のギャップがあり実運用上で課題となりますね。

hitachi_apr2015_sakagawa_icon

(坂川)仮想基盤のVMware製品の部分は、vR Opsと連携することによって、検知したイベントも一元管理ができるようになります。これにより、vR Opsでとらえたストレージまわりの異常や、仮想環境で発生するイベントも合わせて見られるようになります。

vR OpsとJP1/Base間の連携に関してはクラウド連携設計支援のための商品をご用意していますので、それを組み込むことによって、シームレスにイベントが通知されるようになります。

hitachi_apr2015_nagae_icon

(長江)さきほどもお話しましたが、ストレージで管理したい単位と、サーバで管理したい単位とでギャップがあるので、そこが運用管理のネックとなっています。

具体的にいうと、一つのLUNに、複数のVMがくくりついています。これがどういう問題を生むかと言うと、例えばLUNでバックアップを取って、一つのVMだけを戻したいとします。でも、LUNの単位でのバックアップなので、すべてのVMが昔の状態に戻ってしまいます。そこで、これまではサーバ側から、スナップショットやクローンを作って対処していました。

それを変えてしまうのが、2015年3月にリリースされたVMware vSphere 6 のVirtual Volumes(以下VVOL)です。VVOLを使うことで、これまでサーバ側でやっていたスナップショットやクローン処理を、ストレージにオフロードできますので、性能が早くなるとか、管理の単位が楽になるという大きなメリットがあります。

そして、VMが遅くなった時でも、どこで遅くなっているのかが特定できますので、分析の精度が向上し、管理者の負担も減るというメリットがあります。将来的にはVVOLの情報もvROpsに表示されるようになり、ユーザの使い勝手がよくなればよいな、と思っています。

また、これまでは、こういう管理をしたい場合はVMとLUNを1対1で構築するケースもありました。その場合だと数が増えてしまって管理が大変だったり、1つのサーバに割り当てられるLUNの数にも制限がありました。

こういった問題にも、VVOLを使いますと、プロトコルエンドポイント(サーバとストレージ間のアクセスポイント、以下PE)と呼ばれるLUNをサーバに割り当てて、それ以外のLUNはすべてPE経由でアクセスすることで数の制限もなくなりました。

今までは、ストレージの管理者がLUNの割り当てまでを担当していたのですが、サーバの管理者がLUNを割り当てたり、スナップショットを操作したりすることができるようになりますので、ストレージ管理者とサーバ管理者のやりとりも減りますし、VMが必要になった時に、すぐに構築できるので機敏性が増しますね。

こういったVVOLに対して、日立ではHitachi Command Suite(以下、HCS)を使って、VVOLを使うために必要なストレージの設定や、ストレージコンテナの作成、ケーパビリティ(Capability、ストレージを管理するためのパラメータやルールのセット)を作ったり、VM単位の性能分析を実行したりと、運用管理を楽にする工夫をしています。

実際にはこのような画面で管理します。

hitachi_apr2015_storagecontainer

※開発中の画面のため予告なく変更となる場合があります。

詳しくは、2015年5月14日にセミナーを開催予定ですので、そちらでご紹介します。(セミナーの詳細はページ下部をご覧ください。)

日立が目指す運用管理

hitachi_apr2015_nagae_icon (長江)長々とお話してしまいましたが、最後に一つだけ。

VVOLにおけるストレージ側の実装については、ストレージベンダの依存になるところが大きいので、そこでいろいろな独自性を出していけるのかなと思っています。ですから、日立ではより使いやすくなるようにエンハンスを行っていく予定です。マルチクラウド運用に対して、ユーザは使い勝手を意識しなくても、楽に使えるようなものを順次提供していけたらなと。

hitachi_apr2015_sakagawa_icon

(坂川)そうですね。JP1もそうです。JP1はおかげさまで20周年を迎えることができました。今後も皆様のご要望を受けつつ、より使いやすく、皆様の役に立てるような運用管理製品を目指して、エンハンスをしていく所存です。

 

hitachi_apr2015_nagae_icon

(長江)それでは、今回ご紹介した内容を2015年5月14日に予定しているセミナーでご紹介します。 ぜひお越しください~!

 

 

hitachi_apr2015_sakagawa_icon

(坂川)浜松町で僕と握手!

無料セミナー開催のご案内

いかがでしたか?マルチクラウド運用管理、おわかりいただけたでしょうか? もっと詳しく知りたい!という方に、坂川と長江が今回ご紹介しきれなかった運用管理のコツを詳しくご説明いたします。

マルチクラウド運用にお困りの方へ ~最新の運用管理のご提案~

  • 日時:2015年 5月 14日(木) 14:00 – 17:00 (受付開始 13:30)
  • 会場:ヴイエムウェア株式会社 本社(東京都港区浜松町1-30-5浜松町スクエア13F)
  • 参加費:無料(事前登録制)
  • お申込み:http://info.vmware.com/content/APAC_JP_ev_joint_ht

皆様のご参加を心よりお待ち申し上げております。

関連リンク