皆様こんにちは、VMwareの塚田と申します。

今回は、８月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、比較的大きな注目を集めたVMware EVO:RAILに関連するセッションを取り上げ、より詳細な情報をご紹介致します。

VMworldでは、VMware EVO:RAILに関連するセッションが複数提供されました。本ブログ記事ではその中から下記セッションのの内容に沿ってVMware EVO:RAILについて紹介致します。

• SDDC3245 (Software-Defined Data Center through Hyper-Converged Infrastructure)
• SDDC2095 (Overview of EVO:RAIL: The Radically New Hyper-Converged Appliance 100% Powered by VMware）

Hypver-Converged Infrastructure – SDDC導入に最適化されたアプローチ

今年のVMworldにおける弊社からの発表、または発信内容のテーマの一つがSoftware-Defined Data Center（以下SDDC ）の推進です。

SDDCにおいては、サーバ、ストレージ、ネットワーク等のデータセンター内のハードウェア資源は全てソフトウェアによって仮想化および抽象化され、リソースプールとして利用可能になります。また、それら仮想化されたリソースの運用管理はソフトウェアやAPIによって自動化され、ビジネス部門やITサービスの利用者からの要求に迅速に応えられようになります。

お客様が自社のITインフラをSDDCへ移行させたい、あるいは新規に導入したい、と考えられた時、お客様が取りうる導入方法（アプローチ）は下記の3通りのいずれかであるとVMwareは考えます。

Image may be NSFW.
Clik here to view.

1. Build Your Own（アラカルト）
   • サーバやストレージ、ネットワーク機器などのハードウェア、仮想化ソフトウェア、管理ソフトウェアなどを個別に選択して調達し、お客様に合わせて統合する
   • 利点：お客様の要件に沿ったカスタマイズが可能であり、構成上の自由度が最も高い

SDDC実現への3番目のアプローチであるHyper-Converged Infrastructure の特徴は、その用途をSDDC実現のために絞り込み、導入にかかる事前検討や調整の対象を徹底的に削減していることです。その代わり、カスタマイズの自由度が下がったり、拡張性に制限がかかったりするなどのトレードオフが伴いますが、SDDC実現を最優先にしたアーキテクチャであると言えます。

SDDC向け専用アプライアンス – VMware EVO:RAIL

VMware EVO:RAILは、このSDDC向けのHyper-Converged Infrastructureのアーキテクチャに沿ったハードウェア アプライアンスです。

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

VMware EVO:RAILは、2RUのシャーシ内に4台のサーバノードが搭載され、各ノードは次のようなスペックを備えています。

• Intel Xeon E5-2620 v2プロセッサ（6コア）x 2
• 192GBメモリ
• ストレージ
  • 146GB SAS HDD、または32GB SATADOM（ESXiの起動ディスク）
  • 400GB SSD x 1
  • 1.2TB SAS HDD x 3
• ネットワーク
  • 10Gb Ethernet x 2
  • 100Mbps/1Gbps管理用NIC x 1

また、下記のソフトウェアが予め組み込まれています。

• vSphere 5.5（Enterprise Plusエディション）
• VMware Virtual SAN
• VMware vCenter Log Insight
• EVO:RAIL Engine

VMware EVO:RAILはサーバノード間の共有ストレージを持っていません。その代わり、各サーバノードが内蔵しているSSDとHDDをVMware Virutal SANによって共有データストアとして使用します。

SDDCの導入と管理の複雑性を排除した管理ソフトウェア「EVO:RAIL Engine」

Image may be NSFW.
Clik here to view.

また、EVO:RAIL Engineは、VMware EVO:RAILのための管理用ソフトェアです。お客様は、VMware EVO:RAILの最初のセットアップから仮想マシンの作成など毎日の運用までを、このEVO:RAIL Engineで行うことが可能です。

VMware EVO:RAILをセットアップをする際は、PCからHTML5対応ブラウザを使って接続すれば開始可能です。セットアップにあたってESXiやvCenter Server、VSAN等に関する知識やスキルは必ずしも必要ではなく、インフラのことを意識せず、仮想マシンの作成や運用に専念することが可能です。

セッションでは、EVO:RAIL Engineを使うことにより、VMware EVO:RAILの初期化から最初の仮想マシンを作成するまで約15分で完了するデモを紹介していました。

Image may be NSFW.
Clik here to view.

また、EVO:RAIL Engineは最大4台までのVMware EVO:RAILを管理することが可能であり、増設もとても簡単です。2台目以降のVMware EVO:RAILをネットワークへ接続すると、クラスタへ自動的に追加され、コンピュート（CPU, メモリ）とストレージそれぞれの容量が自動的に拡張されます。一般的なサーバ用途の仮想マシンであればVMware EVO:RAIl 1台あたり100台、仮想デスクトップ（VDI）用であれば仮想マシンを同250台まで作成可能です。アアプライアンスを追加することにより、サーバならば最大400台、仮想デスクトップであれば最大1,000台まで拡張することが可能です。

VMware EVO:RAILはOEMパートナーから提供されます

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

ここまでVMware EVO:RAILの説明をして参りましたが、VMwareが「EVO:RAIL」というハードウェア製品を開発し販売するわけではございません。この点はくれぐれもご注意ください。

VMwareはVMware EVO:RAILを構成するためのソフトウェア（vSphereやEVO:RAIL Engine等）を開発し、これのOEM契約を結んだパートナー（以下EVO:RAILパートナー）各社へ提供しています。EVO:RAILパートナーが、このEVO:RAILソフトウェアと各社が開発、または調達したハードウェアを組み合わせ、各社それぞれのVMware EVO:RAILアプライアンスを開発し提供します。

本ブログ執筆時点でのVMware EVO:RAILのOEMパートナーは、Dell, EMC, Fujitsu, Inspur, Super Micro、およびネットワンシステムズの6社です。特にネットワンシステムズは、VMware EVO:RAILに基づくアプライアンス製品「NetOne Integrated System Appliance for VMware EVO:RAIL」を10月1日より販売開始することを発表されました（ネットワンシステムズによる発表資料へのリンク）。他のOEMパートナーからも日本国内でのVMware EVO:RAILアプライアンスの発表が続くと予想されますので是非お待ち下さい。

VMware EVO:RAILはOEMパートナーから提供されます

まとめ – VMware EVO:RAILの利点

ここまで述べてきました通り、 VMware EVO:RAILは、VMwareが推進するアーキテクチャ “Software-Defined Data Center” (SDDC)を実現するために特化したインフラストラクチャ アプライアンスです。これを用いる利点を再度まとめてみます。

SDDCのための基盤を最速で導入、構築することが可能。

VMware EVO:RAILは、SDDCのためのインフラとして求められる性能や信頼性、拡張性を備えながら、複雑性を徹底的に排除しています。セットアップ時に必要な設定項目もIPアドレスや管理者のパスワードなど必要最小限にとどめられています。また、ハードウェア、およびソフトウェアが相互に密に連携しています。それらのため、導入後最短15分で最初の仮想マシンを起動することが可能なくらい、SDDCを最速で構築することが可能です。

基盤構築や運用のために仮想化技術やハードウェアの専門知識は必須でありません

VMware EVO:RAILの運用管理は専用の管理用ソフトウェア”EVO:RAIL Engine”を用います。その操作にあたっては、VMware ESXiやvCenter Server等の仮想化ソフトウェア、そしてサーバやストレージ等ハードウェアに関する知識も必須ではありません。また、それらの技術に精通した専門家を雇用しづらい組織や、専門家が配置されていない拠点においてもSDDCのための基盤を導入することが可能です。

拡張が非常に容易、そのため常に最適な構成で利用可能

VMware EVO:RAILは最大4台（サーバノードは最大16台）まで拡張することが可能です。また、増設も非常に容易です。EVO:Engineが増設されたシャーシを認識すると、追加されたCPU, メモリ、HDDやSDD等のリソースが利用できるよう自動的に再構成します。その間も、仮想マシンを稼働させ続けられます。

このように拡張が非常に容易なので、必要になった時にリソースを追加することが可能です。そのため、お客様は常にジャストサイズの構成のVMware EVO:RAILを利用することが可能であり、過剰なリリースを抱える必要はありません。

以上

こんにちは！ とうとう本連載もラストとなってしまいました。 新卒 SE 社員が贈る vSphere のキソ！ 第７回は私、川崎（ Kawasaki ）が担当致します。 今回は、「仮想環境となが〜くお付き合いをしていく」をテーマといたしまして、 VMware vCenter Operations Manager （以下 vC Ops）という製品をご紹介して参ります。

〜仮想環境と長くお付き合いする為に…〜

はじめに、環境の運用管理とは何ができれば上手く行えていると言えるでしょうか。状況を正確に把握し、効果的なアクションをとり、より少ないコストで効率的にパフォーマンスを高く維持できれば、良い運用が行えていると言えるのではないでしょうか。この「状況を正確に把握する」という部分が、物理環境から仮想環境へ移行した際に少し難しくなるポイントです。

Image may be NSFW.
Clik here to view.

図1．物理環境と仮想環境でのリソース使用の比較

本連載の過去の記事でも触れておりますが、仮想環境ではリソースが仮想化され、複数のOSで同一の物理ホストのリソースを共有します。また、物理ホスト間でもリソースをプール化して、全体としての最適な利用が行える点を紹介して参りました。

仮想環境ではゲストOSから見てリソースの使用率が高くないか、だけではなく、他のOSとはリソースの取り合いによるパフォーマンス低下はどれほどか、物理サーバ間でのリソース融通による最適化の機会はないか、といったことも考える必要があります。実際、既に仮想環境をご利用いただいているお客様の中にも、管理に課題を感じていらっしゃる方は多く、以下のようなお声を頂いております。

公共系 A機関 ご担当者様

「どの物理サーバでどの仮想マシンが稼働しているかをExcelで管理していましたが、何かが起こった際の影響範囲の特定が非常に困難でした。また、一部のシステムでパフォーマンスが落ちてきた場合に、リソースが不足しているのか、アプリケーションに問題があるのかなどの切り分けが困難で、原因究明までにかなりの時間を要していました。」

メディア系B社 ご担当者様

「仮想マシンの配置やキャパシティプランニングはすべてExcelを使って手作業で行っており、非常に手間がかかっていました。さらに仮想マシンで必要となるリソースの割り当てについても、妥当性の基準が明確化されておらず、システムの健全性やリソース配分の効率性を評価できていませんでした。」

これらのお客様には、vC Ops を導入いただき、こういった課題の解決に役立ていただきました。まずは、vCenter と vC Ops での管理方法を比較することで、vC Ops はどのように役に立つのか見ていきましょう。

〜vCenterのみでOK？〜

vCenter のみの場合と vC Ops も利用した場合、どのように変わるか、参考ケースを見ながら比較していきます。

≪参考ケース≫
IT管理者のAさんは、 vSphere をベースとした仮想環境の管理を任されています。担当している物理サーバの数は20台ほどですが、仮想マシンのパフォーマンスが悪い場合には、まずAさんが問題を切り分けて、必要に応じてネットワークやストレージ、アプリケーションの各担当者に連絡して対処をお願いしています。

物理から仮想に移行したことで、追加のハードウェアなしにサーバ数を増加させることができ重宝していますが、最近仮想マシン数の増加とともに環境が複雑になり障害原因の特定に時間がかかるようになってきました。また、来年の予算を考えるにあたって追加リソースの申請が必要ですが、仮想マシンごとに負荷も違うためどう考えればいいかわかりません。

• 障害原因の特定

ここでは、障害原因の特定を行う際を例にとり、管理方法の変化を見てみます。障害の発生を確認した場合の対処までの流れについて、vCenter Server のみを用いた場合と、vC Ops を用いた場合を比較します。全体の流れの一例を示したのが、図2です。

Image may be NSFW.
Clik here to view.

図2．障害対応方法の違い：vSphere Web Client と vC Ops

vCenter Server の管理画面である vSphere Web Client や vSphere Client からもホストや仮想マシンに関する様々な情報を収集することは可能です。しかしながら、その情報は多岐にわたるため、広範囲な参照先から得た情報を管理者が統合して判断に結び付ける必要があります。一方で、vC Ops を用いた場合には、障害の監視、関連オブジェクトの参照、各オブジェクトの詳細情報が一括して得られるような設計となっているため、管理者の判断を助け、対処にとりかかるまでの時間も短縮できます。

• キャパシティ管理

次に、リソースを追加する際の容量計算の流れを例に、キャパシティ管理方法の違いを見ます。同様に vCenter Server のみを用いた場合とvC Ops を用いた場合を比較します。（図3）

Image may be NSFW.
Clik here to view.

図3．キャパシティ管理方法の違い：vSphere Web Client と vC Ops

vCenter Server を用いた場合、多くの状況ではそのデータをExcel等で集計しなおすことが多いのではないでしょうか。ホストや仮想マシンの割り当て容量をExcelに集計し、vCenter Server で得られるパフォーマンス情報とユーザーからのヒアリングを元に適切な容量を考えます。

そして、それをもとにキャパシティ不足の仮想マシンや追加の仮想マシン用のリソースを計算します。このような流れの問題点は、Excelでの管理に時間がかかる点、また、本当に必要な容量を知ることはかなり困難で、結局のところ安全策として必要以上のリソース割り当てとなりがちな点です。

一方で vC Ops を用いた場合には、現状の把握はダッシュボードから一目瞭然で、適切な容量の計算も、ホストとしては残り容量の表示が、仮想マシンとしてはサイジングの過不足に関する表示があり、クリックするだけで、一覧で見ることができます。

また、追加リソースに関しては、推奨されるオーバーコミット率に従って考え、実際に任意のサイズの仮想マシンとリソースを追加して試算を行うことで、必要な容量であることを簡単に知ることができます。最後にこれらの情報をファイルとして出力して説明の根拠とすることができます。

以上まとめますと、vCenter Server のみを用いた仮想環境の管理では、以下の2つの課題がありました。

①  vCenter Server だけでは長年の経験と専門スキルを要する （工数と時間がかかる理由）

② 運用メンバーの管理手法が属人化している （人手で集約・集計している結果）

そしてこれらの課題を vC Ops は次のように解決します。

①  vC Ops 上の表示の確認で済む （工数と時間を短縮）

②  vC Ops が自動で集計・分析する （工数の削減と根拠の明確化）

〜vCenter Operations Managerの概要〜

それでは、 vC Ops自体の説明に入って参ります。はじめに、 vC Ops を導入した場合の環境構成から説明いたします。 vC Ops は２つの仮想アプライアンスが展開され、 vCenter Server から収集したデータを解析し、表示します。（図4） vCenter Server は一つまたは複数を対象とすることができます。

Image may be NSFW.
Clik here to view.

図4．vCenter Operations Manager の構成

集めたデータは、 vC Ops で解析されます。この解析により、各リソースの数値データは単にグラフ化されるのではなく、仮想環境は良いパフォーマンスを発揮しているのか、何かとるべきアクションはあるのか、といった管理者にとって役立つ情報として表示されます。ダッシュボードと呼ばれる vC Ops の基本画面は以下のような見た目となっております。（図5）

Image may be NSFW.
Clik here to view.

図5． vC Ops ダッシュボード画面

このダッシュボード画面は、左から“健全性”、“リスク”、“効率”の縦3列に分かれており、それぞれ以下のような内容を表しています。

• 健全性  ：「現在の状況」    ＝ 障害やパフォーマンス低下について
• リスク    ：「将来の予測」    ＝ 今後のパフォーマンス低下要因はないか、リソースは十分か
• 効率     ：「構成の最適化」         ＝ 構成を変更することで、リソース節約の可能性はあるか

これらの指標（“バッジ”と呼びます）によって、管理者はひと目で環境の特徴を把握できますし、必要であれば詳細な情報も掘り下げて見ていくことも可能です。例えば、ある仮想マシンについて性能劣化の要因を調べる際には、関連するオブジェクトを一括して表示することで、どこに原因があるか突き止める大きな助けとなります。（図6）

Image may be NSFW.
Clik here to view.

図6．関連するオブジェクトを一括表示

また、個別のオブジェクトに関してそれ自体の情報を詳細に見る、という意味では、図7のような画面から確認できます。

Image may be NSFW.
Clik here to view.

図7．個別オブジェクトの詳細情報表示

他にも vC Ops では俯瞰的な見方から、詳細に特化した見方まで、情報の表示のされ方は豊富に用意されています。これにより、実際の運用管理の場面でも、その時々の目的に応じた情報を得ることが可能となります。   このような vC Ops の機能は、評価版を展開して実際にご使用いただくことで、さらによく確認していただけます。評価版のインストールガイドは操作ガイドとともにリンク先の記事にございますので、ぜひご活用ください。

http://blogs.vmware.com/jp-cim/2014/07/vcops_operations_guide.html

〜vC OpsとvSOM〜

vSOM という製品をご存知でしょうか？ vSOM は、「 VMware vSphere with Operations Management 」の略で、 vSphere と vC Ops のスタンダードエディションが合わさったものになっています。（図8）vC Ops のライセンスは通常「25仮想マシン数単位のライセンス」に対し、 vSOM のライセンスは vSphere 同様CPU単位のライセンスとなります。したがって、vC Ops を利用される際に、「仮想マシン数が将来増加する可能性もあるなぁ…」という場合には、vSOM を入手することで仮想マシン数を意識する必要はなくなります。

Image may be NSFW.
Clik here to view.

図8．vSOM は vSphere と vC Ops のセット製品

詳細は弊社ウェブページをご覧ください。（http://www.vmware.com/jp/products/vsphere-operations-management/ ）

〜第7回まとめ〜

vCenter Operations Manager を紹介して参りましたが、いかがでしたでしょうか？本製品のことが少しでも理解され、使うことによるメリットも感じていただけましたら幸いです。こちらの製品は、ハンズオンラボでも体験可能ですので、ぜひお試しください。（http://labs.hol.vmware.com/HOL/catalogs/  ラボ番号：HOL-SDC-1401）

〜本連載まとめ〜

さて、本シリーズは「新卒 SE 社員が贈る vSphere のキソ！」と題しまして、4名の新卒SEにより全7回でお贈りして参りました。”新入社員の目線”として先輩SEの皆様とは多少異なるテイスト？で連載して参りましたがいかがでしたでしょうか？何はともあれ、本シリーズを通じて少しでもVMware製品の理解を深めていただけましたらとても嬉しいです。

私どもは今年の４月に入社しほぼ知識がないところからのスタートでした。VMwareに関する勉強には少なからず苦労しておりますが、わかってくると楽しく、ついつい時間が過ぎてしまうこともしばしばです。今後初めてVMwareを導入されるユーザ様や提案されるパートナー様におきましては、新しい概念や用語で苦労されるかもしれません。

その際は本連載を読み返していただくと幸いです。私たち自身も日々勉強することも多いですが、皆様のご指導も受けながら一緒に盛り上げていけましたらとても嬉しく思います。vForum 2014でもセッションを持ちますので是非お越しください！

最後になりましたが、お読みいただき誠にありがとうございました。
VMware新卒社員 SE 氏田裕次/川崎一青/椨木正博/野田裕二

新卒 SE 社員が贈る vSphereのキソ！
第１回 vSphereを俯瞰する
第２回 仮想環境におけるネットワークとストレージ
第３回 vMotionとvSphere HA/vSphere FTの違いとは？
第４回 仮想マシンの配置管理はDRSにお任せ！
第５回 様々な仮想マシンが混在&混雑しても大丈夫！？ネットワーク と ストレージの帯域を維持する仕組み
第６回 vSphere でココまでできる！データ保護
第７回 仮想環境となが〜くお付き合いしていく

みなさん、こんにちは。

VMware vCenter Operations Manager(vC Ops)にはストレージと連携できる機能が用意されております。今回はデルストレージEqualLogicと連携した機能を vExpert 2014でもあるデル株式会社の中川明美様にご紹介していただきます。それでは中川様よろしくお願い致します。

こんにちは！デル株式会社の中川明美です♪

前回デルストレージCompellentとVMware vCenter Operations Manager(vC Ops)の連携をご紹介させていただきましたが、今回は、私デルの中川明美よりDellのストレージ 「EaualLogic」と連携する｢Dell EqualLogic Adapter for VMware vCenter Operations Manager(EqualLogic vCOPS Adapter)｣についてご紹介します。vC OpsとEqualLogicストレージが連携することにより、EqualLogicストレージの構成コンポーネント(Groups/Members/Pools/Volumes)をvC Opsのオブジェクトとし、関連する他のオブジェクト(ホスト/データストア/仮想マシン)と同じ画面で表示することが可能です。またEqualLogicストレージのパフォーマンス情報から仮想基盤の問題原因分析の一つの手段とすることも可能です。

Dell EqualLogicとvC Opsとの関係

下図は、Dell EqualLogicコンポーネントとvC Opsとの関係を示しています。

Dell EqualLogicが提供するコンポーネントには、「EqualLogic SAN Headquarters」｢Dell EqualLogic Statistics Agent｣「Dell EqualLogic vCOps Adapter」があります。

EqualLogic SAN Headquartersから収集したデータを、SAN HeadquartersサーバーにインストールしたDell EqualLogic Statistics AgentとDell EqualLogic vCOps Adapterが連携し、vC OpsのDell EqualLogicダッシュボードに表示します。SAN Headquarters (SAN HQ) は、EqualLogic標準の監視ツール(フリーツール)です。SAN HQを使用してもEqualLogicのパフォーマンスを監視することはできますが、vSphere環境とは連携していませんので、どの仮想マシンのワークロードが問題に関与しているかを分析するために時間を要する場合も考えられます。

Image may be NSFW.
Clik here to view.

vC Opsのおさらい

vC OPSでは分析結果を、ダッシュボードに「健全性」｢リスク｣「効率」のスコアを｢バッジ｣と｢色｣で表示します。このバッジの色で、緊急性があるのか、将来に問題があるのか、さらに統合率を高めることができるのかを一目で判断できます。緑なら｢現在問題がない｣、オレンジなら｢近い将来に問題が発生する可能性がある｣こと示しています。

Image may be NSFW.
Clik here to view.

Dell EqualLogicダッシュボードにアクセス！

EqualLogic vCOPS Adapterを準備したら、Custom UI(https://UI仮想マシンのIPアドレス/vcops-vsphere/)に接続します。下図が接続後の画面です。｢ダッシュボート｣メニューから、Dell EqualLogic用の4つのダッシュボードに切り替えることが可能です。

Image may be NSFW.
Clik here to view.

EqualLogic & VMware Relationship Dashboard～構成要素のつながりを一目で把握～

最初に、EqualLogicと連携した仮想化基盤を把握できる「EqualLogic & VMware Relationship」ダッシュボードを確認しましょう。このダッシュボードは、vC OpsのvSphere UI(標準UI)と同様のバッジで健全性スコアを表示します。仮想マシン、その仮想マシンのファイルが格納されたデータストア、仮想マシンが配置された ESXi ホスト、それらと関連性のあるEqualLogicの各コンポートを可視化します。

｢EqualLogic-VMware Relationship View｣では各リソースの状態を、｢健全性ツリー｣では、関連したリソースの階層構造と各リソースの健全性とアラート数を表示します。健全性ツリーで表示されたアラートの詳細が｢Alerts」に表示されます。他に画面下部に｢Metric Sparklines｣と｢メトリックグラフ｣が表示されます。

下図では、｢EqualLogic-VMware Relationship View｣で赤色表示されている｢nkgw-vmfs01｣Volumeを選択し、｢健全性ツリー｣で関連するリソースを表示しています。｢Alerts｣にはこのデータストアの｢残り時間｣アラートが表示されています。

Image may be NSFW.
Clik here to view.

残り時間のアラームをドリルダウンすると、健全性の推移やVolumeの詳細情報まで得ることも可能です。

Image may be NSFW.
Clik here to view.

EqualLogic Top-N Reports Dashboard

さらに詳細なパフォーマンス情報を確認したいのであれば、このダッシュボードを使用します。

9つのメトリックに関する、最も高い使用率Top25のVolumeを表示します。最大容量、空き容量、最大遅延などその他パフォーマンスに関する情報を確認するために使用します。

• Total I/Os per second•
• Write I/Os per second•
• Read I/Os per second•
• Total KB per second•
• Write Latency•
• Read Latency•
• Queue Depth•
• CVolume Capacity•
• Least Free Space

Image may be NSFW.
Clik here to view.

EqualLogic Storage At a Glance Dashboard

EqualLogicの全コンポーネントの概要を表示します。

画面左側の「Group Selector」｢Pool Selector｣｢Volume Selector｣ではEqualLogicの各コンポーネントの健全性を色と数値で表示し、画面右側の「Metrics Sparkline」では、画面左側で選択したコンポーネントのメトリックデータを視覚的に表現する小さなグラフ(スパークライン)を使用して表示します。また｢Selected Storage Array Health Tree｣では、EqualLogicの全コンポーネントの健全性をグラフィカルに表示します。｢Alerts」では、EqualLogicグループ内のアラートを表示します。

Image may be NSFW.
Clik here to view.

EqualLogic Storage Metrics Dashboard

選択したリソース(EqualLogicコンポーネント)のメトリックを詳細に表示します。｢Select Resource to View Metrics｣で詳細なメトリックを表示したいコンポーネントを選択します。｢Select Metrics to Graph｣ではグラフ化したいメトリックを選択します。｢Metric Graph｣でグラフ化されたメトリックが表示されます。

Image may be NSFW.
Clik here to view.

FirmwareとSoftwareの必要要件

次が各Productの必要要件となります。

EqualLogic Support Siteから入手可能です。https://eqlsupport.dell.com

ストレージ連携機能はvC Opsの｢Advanced」エディションから提供されます。

おわりに

EqualLogic vCOPS Adapterの概要をご紹介させていただきました。ストレージを含めた仮想基盤を一目で把握し、管理することができるのは便利ですね。EqualLogicをお持ちのお客様は多いので、ストレージと仮想基盤の管理にお困りであれば是非お声がけください!!

インフラストラクチャ・コンサルティング・サービス本部 テクニカルコンサルタント　中川 明美
Image may be NSFW.
Clik here to view.

VMworld 2014 からの注目セッションの第 3 回目は、Software-Defined Data Center 向けの Software-Defined Storage である Virtual SAN （VSAN）を導入する際のシステム構成に関するガイドをご紹介します。

How to Build a Virtual SAN – Virtual SAN のシステム構成について

Virtual SAN を導入するには、現在 3 つのアプローチがあります。

1. Virtual SAN Ready Node で構成
2. VMware Compatibility Guide に掲載されている ESXi + Vitual SAN 対応のハード、コンポーネントで構成
3. コンバージドインフラ（統合インフラ）製品である EVO:RAIL を利用

EVO:RAIL については、本シリーズの第 2 回目に説明がありますので、今回は Virtual SAN Ready Node による構成方法と VMware Compatibility Guide を参照しながらの構成方法について説明します。

1. Virtual SAN Ready Node による構成

Virtual SAN Ready Node とは、サーバ OEM ベンダより提供される Vitrual SAN 推奨構成です。VSAN で必要となるハードウェアコンポーネント、vSphere と Virtual SAN が事前に構成されているので、システム構築時間を大幅に短縮することができます。また、構成のプロファイルとして、サーバワークロード向け（Low, Medium, High）と VDI ワークロード向け（Full Clone、Linked Clone）の 5 つのプロファイルが用意されており、導入するシステムのワークロード、規模に合わせて選べるようになっています。

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

この Virtual SAN Ready Node の構成詳細は、VMware Virutal SAN Ready Nodes  で確認可能で、8/15/2014 版のガイドでは、8 社のサーバ OEM ベンダから 40 種類の構成が Virtual SAN Ready Node として登録されています。

Image may be NSFW.
Clik here to view.

Virtual SAN Ready Node としては、将来以下のようなコンフィグレーションもリリースされる計画があります。

• Ready Nodes for Blade Servers with Direct Attached Storage
• Ready Nodes with High Density Storage From Factors
• Ready Nodes with Hardware Checksum Protection
• Ready Nodes with Hardware Encryption
• Ready Nodes with end to end 12G support
• Ready Nodes with NVMe devices for super-charged performance
• Ready Nodes with All Flash

2. VMware Compatibility Guide で Virtual SAN 対応のハード、コンポーネントを確認して構成

Virtual SAN は、Virtual SAN Ready Node に掲載されている機器だけでなく、Virtual SAN 動作認定されているコンポーネントを組み合わせて自由に構成することも可能です。Virtual SAN を利用するには、ホストが最小 3 台、内蔵 HDD と SSD とクラスタを構成するためのネットワークが必要となりますので、要件に合わせる形で構成していきます。

Image may be NSFW.
Clik here to view.

基本的には、導入する ESXi バージョンに対応したハードウェアで構成しますが、SSD、HDD、SAS/SATA コントローラ（ストレージコントローラ）については Virtual SAN 用の VMware Compatibility Guide  がありますので、ここに掲載のあるコンポーネントで構成します。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

それでは、この VMware Compatibility Guide に沿って構成していきます。

1. I/O Controller

I/O Controller セクションで、Virtual SAN でサポートされる I/O Controller （ストレージコントローラ）と対応しているデバイスドライバが確認可能です。

Image may be NSFW.
Clik here to view.リストに出てくるコントローラの詳細を確認すると、そのカードでサポートされている RAID モード（Pass-Through モードか RAID0）、ESXi やデバイスドライバのバージョンを確認することができます。

2. HDD

Virtual SAN は、SAS、NL SAS、SATA HDD をサポートし、大容量向けの 7,200 RPM、パフォーマンス向けの 10,000 RPM、より高いパフォーマンス向けの 15,000 RPM のドライブの中から構成します。

3. SSD

SSD についても、HDD 同様に Virtual SAN 対応しているもので構成する必要があります。SSD については Performance Class という項目があり、構成時に SSD のパフォーマンスを考慮する事が出来るようになっています。

Performance Class:
 Class B: 5,000-10,000 writes per second
 Class C: 10,000-20,000 writes per second
 Class D: 20,000-30,000 writes per second
 Class E: 30,000+ writes per second

4. その他のパーツ

サーバ本体（3 台以上 32 台まで）、NIC、ESXi 起動用デバイスについては、お使いになる ESXi のバージョンでサポートされているもので構成します。

Hardware Solution Guidance

ここでは Virtual SAN 用のハードウェア構成上の注意点について説明します。

起動用デバイス

ESXi 起動用デバイスについては、ESXi ホストに搭載されているメモリ容量に依存します。

• メモリ容量が 512GB 未満
  Virtual SAN 領域とは別の磁気ディスクや SSD、容量 4GiB 以上の容量を持った SD/USB
• メモリ容量が 512GB 以上
  Virtual SAN 領域とは別の磁気ディスクや SSD

フラッシュデバイス

Virtual SAN において、全てのリード・ライト処理は、フラッシュ階層に直接渡されます。また、Virtual SAN では、フラッシュベースのデバイスは 2 つの目的に利用されます。

1. 不揮発性のライトバッファ（容量の 30%）
2. リードキャッシュ（容量の 70%）

Virtual SAN においては、フラッシュデバイスの選択は、最もパフォーマンスに影響するので、製品の選択には注意を払う必要があります。

磁気ディスク (HDD)

SSD の選定と、SSD:HDD の比率は、クラスタの性能を左右します。大まかなガイドラインでは、10% となります。

ストレージコントローラ

SAS/SATA ストレージコントローラに関するガイドは以下のものがあります。

• Pass-Through モードと RAID0 モードをサポート
• ストレージ コントローラーのキュー深度が重要
  より深いストレージコントローラーのキュー深度はパフォーマンスを向上させる
  参考：キュー深度は、VMware Compatibility Guide で確認可能
• ストレージコントローラがサポートするドライブ数を確認する必要がある
• RAID0 モードを利用する場合の SSD の性能は、ストレージコントローラに依存
• RAID0 モードの場合、ESXi はフラッシュベースのデバイスと磁気ディスクを区別できない場合がある
  その場合は、esxcli コマンドを使用し、デバイスを SSD とするフラグを立てる
  参考：Enabling the SSD option on SSD based disks/LUNs that are not detected as SSD by default (2013188)

ネットワーク

ネットワークに関するガイドは以下のものがあります。

• 1Gb / 10Gb をサポート（10Gb を強く推奨）
  1Gb の場合は、Virtual SAN 専用のネットワークとすることを推奨
• ジャンボフレームにより僅かながら性能向上する可能性あり
  新規デプロイの場合は有効にする
• Virtual SAN は仮想スイッチと分散仮想スイッチをサポート
  備考：Virtual SAN のライセンスに分散仮想スイッチのライセンスも含まれます
• ネットワーク帯域の性能は、通常のワークロードよりも、ホストの待機やリビルドに対して大きな影響を与える

最後に

VMware Compatibility Guide は、比較的頻繁にアップデートされていますので、Virtual SAN 環境を構成/構築される場合は、その都度サポート状況を確認するようにして下さい。

皆様こんにちは、VMware の町田と申します。 今回は、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、日本でも注目が高まってきている DevOps  に関連するセッションの内容を取り上げながら、VMware のクラウド管理ソリューションを Dev(開発)とOps(運用)の協調という視点から前編・後編の二回に分けてご紹介します。

はじめに

VMworld 2014 では、多くのエンタープライズ環境がソフトウェアデリバリプロセスにおいて抱える 「安定かつ継続した、ビジネスのスピードにあわせた俊敏なリリース」「コスト削減」「変更への柔軟な対応」などの課題に対して、VMware  のクラウド管理ソリューションの導入がもたらす価値について、特に DevOps の視点から複数のセッションが提供されました：

• MGT3210-S (Management Product Overview and Glimpse into the Future)
• OPT2668 (DevOps Demystified! Proven Architectures to Support DevOps Initiatives)

この中で筆者が特に注目する内容としては、MGT3210-S セッション内で [Tech Preview] として紹介された「Continuous Delivery for DevOps」 があります。こちらについては、本記事の[後編]でご紹介します。

Image may be NSFW.
Clik here to view.

※ 補足：　最新情報

～～～

VMworld 2014 EUROPE の開催に合わせて、日本でも2014年10月15日（日本時間）付けでクラウド管理プラットフォームの最新版「VMware vRealize Suite 6」を含む、新たなクラウド管理製品群と機能群を発表しました。この中で、DevOps における継続的デリバリーを実現する「VMware vRealize Code Stream」という製品も発表されています。この製品が、VMworld 2014 US で[Tech Preview]として紹介された Continuous Delivery for DevOps の正式名称となります。

～～～

また、その他で DevOps と関連するものとしては、以下に挙げるセッションがありました。

• HBC2371 (HBC2371 – Stick a Knife in IT! Chef + vCloud Hybrid Service = A Well Done Cloud)
• MGT2650 (Streamline Infrastructure Management with VMware and Puppet)
• MGT3095 (vCloud Automation Center and Pivotal Cloud Foundry – Better PaaS Solution)
• SDDC3281 (A DevOps Story: Unlocking the Power of Docker with the VMware platform and its ecosystem)
• SDDC3350 (VMware and Docker – Better Together)

vCloud Air 環境での”Infrastructure as Code” の実現や、VMware vCloud Automation Center (vCAC)と Puppet の連携、vCAC と PaaS (Pivotal CF) の連携、今ホットな Docker といった、さまざまなテーマで DevOps と絡めた話題が出ていました。

余談

いきなり話が逸れますが、企業が 大変な労力とコストをかけてアプリケーションを開発/テストして、さらなる労力をかけてリリースして運用、保守しているのは、（当然のことですが）ビジネスの価値を高めるためであり、それらは間接的にはアプリケーションを使うことによる業務効率の向上であったり、直接的には売上の増加であったりします。ITシステムに対する要求管理は、今も昔もアプリケーション開発における最も難しいテーマの一つです。

ところで、皆様の組織では、 アプリケーションに対するたった一行のソースコードの変更を本番環境に反映させる（リリースする）までに、どれぐらい時間がかかるでしょうか？また、そのプロセスは安定かつ繰り返し可能なものでしょうか？

サイクルタイム

この問いは、リーンソフトウェア開発有名なポッペンディーク夫妻の書籍で投げかけられているものです。

“How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis? “

(Mary Poppendieck; Tom Poppendieck, “Implementing Lean Software Development, Addison-Wesley Professional, 2006”)

ITシステムがビジネスの要求に対していかに「俊敏」に対応できているか常に振り返るためのきっかけとして、非常に示唆に富んでいます。ITによるビジネスの俊敏性向上とは、サイクルタイムをいかに短く、かつ安定したもにできるかにかかっていると言えるからです。「ビジネス」と言ってしまうと新規アプリケーション開発をイメージして、Ops(運用)の方々にはあまり関係のない話に思われるかもしれませんが、ここでの「変更」とは、リリース後の機能追加や、バグの緊急修正及びリリースなど、システムを利用する多くの利害関係者からの、継続的な要求への対応を含んでいます。

より技術的な観点からは、「継続的デリバリ」のバイブルである書籍の著者であるジェズ・ハンブル氏らが書いている言葉が心に響きます。

“Release your software at the push of a button.” 

(Jez Humble; David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison-Wesley Professional, 2010”)

ソフトウェアのリリースは、（究極的には）ボタンを一回押すだけで完了できてしかるべきもの、ということでしょうか。

変えないで済む、そして大きな成果を生む

脱線ついでに、もう一つ余談を。

ハイパーバイザーが実現する仮想化には、1つの美学があると思っています。それは

• OSより上で動作するものや、それに関連するものに対して、これまでとまったく変わっていないという幻想を与える

ことです。Docker などのコンテナ技術が注目を集めている今では時に過小評価されるかもしれませんが、新しい技術を組織に導入して浸透させていく際には極めて重要な性質です。変わっていないということは、大部分において、これまでのやり方をそのまま踏襲できるということです。ITの世界ではとにかく目新しく、革新的な（に見える）技術が目を引きがちですが、VMware はそういった中長期的な将来のIT基盤のあり方を変えるようなテクノロジーにも注視する一方で、物理環境から仮想化基盤、そしてその上で従来のアーキテクチャに基づいて作成されたアプリケーションを展開して運用しているような環境から、漸進的にSDDC、そしてハイブリッドクラウド環境へと移行していけるようなソリューションに力を注いでいます。

IT業界で話題になるテクノロジや手法は、 エンジニアを多く抱えたWeb系の最先端IT企業が中心になって推進しているケースが多く、エンタープライズのITでそのまま導入しようとした場合にまったく新しいやり方や、高度な技術的スキルが要求されることも多いです。やり方が新しければ新しいほど、組織構造や業態、技術者のスキルセットと照らし合わせた場合に、採用のための障壁が高くなります。

これから構築していく新しいアプリケーションに対しては、新しいやり方を試すのはそれほど難しくないかもしれません。

では、すでに構築して運用・保守しているアプリケーションのライフサイクルを、これからどうやって管理していけばよいでしょうか？今やモバイル・クラウド時代に突入し、ビッグデータやサービス指向のアーキテクチャも Web サービスの普及とともに広がってきています。

アプリケーション開発チーム

アジャイルソフトウェア開発宣言が公開されたのは2001年のことですが、それから13年、欧米ではすっかり主流の開発手法となっています。

Image may be NSFW.
Clik here to view.

VMworld 2014 のセッションでも、Facebook、LinkedIn などの先端的な Web 系企業では1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイしているような例も語られていました（これは極端な例かもしれませんが）。

Image may be NSFW.
Clik here to view.

アジャイル開発の考え方の最大の特徴の一つは、要求管理の方法にあります。アジャイルは「変化に対応する」ための開発方法とも言えますが、それはひとえに「要件に優先順位をつけて、必要な時に必要なものをジャスト・イン・タイムで計画して作る」「最初に想定していても、必要ないとわかった時点で作らない」点にあります。つまり、ウォーターフォールのようにプロジェクトの最初期で時間をかけて「計画」された要件に縛られるようなことはありません。

アジャイル開発では、従来からの「スコープ」「コスト」「スケジュール」というソフトウェア開発における「鉄の三角形」に代わり、「（リリースされるソフトウェアによって実現される）価値」「品質」を変動できないものとしてとらえ、プロジェクトの制約となる要素のうち「スコープ」を調整することで、変化に対応しながらも安定かつ継続したリリースを実現します。

Image may be NSFW.
Clik here to view.

ここで、頻繁にリリースされるソフトウェアの品質を支えるのが、ソースコードのバージョン管理、テスト駆動開発(TDD)及びテスト自動化、継続的統合(CI)といった、ツールを活用した自動化及び各種のプラクティスとなります。

ただし、仮にアジャイル開発を採用し、うまく現場でまわすことができていたとしても、それだけでは開発チームの悩みは尽きることはないでしょう。

従来からのクライアント-サーバ、あるいはWeb 3階層モデルなどに従ってアプリケーションを設計した場合、デプロイ可能な成果物が完成した後のリリース作業はコストのかかる、骨の折れる作業であることには変わりありません。この要因としては、多くの人員や手作業が必要なケースが多いことや、構成管理が大変なこと、インフラの準備のための時間と工数、また（特にエンタープライズでは通常だと思いますが）「開発チーム」と「運用チーム」をはじめとする複数の組織が関わっていることなどが挙げられます。リリース対象の環境自体も、オンプレの物理環境から仮想化基盤、プライベートクラウド、パブリッククラウドといったように様々な選択肢を検討する必要がでてきており、複雑さとそれに伴うコストは増す一方です。特に、インフラのことについては開発チームだけではなかな手も足もでません。

そのため、AWS などのパブリック IaaS を（シャドーITとしてIT部門を通さずに）利用したり、また最近では PaaS （例えば Pivotal CF など）の検討や、Docker のようなコンテナ技術を活用した新しいアプリケーションの構築、パッケージ化、配布、実行のモデルに注目するケースが増えてきているのでしょう。

これらの根底には、常にアプリケーションリリースのサイクルタイムへの意識があります。

インフラ運用チーム

ここ数年来、仮想化技術が広く普及したこともあり、物理サーバを仮想化基盤に統合してコストを削減するという考え方は、ごく普通のことになりました。VMware では、（VMware の考える） エンタープライズのIT基盤及び組織が進むべき道として、最近では次のようなスライドを使って説明しています。

Image may be NSFW.
Clik here to view.

Ops (運用)の視点から見た場合、例えばエンドユーザのPC利用環境（仮想ワークスペースも含む）の整備などは、アプリケーション開発が絡まない、ITを活用したビジネス生産性向上のための投資といえます。

アプリケーション開発ライフサイクルにおける開発チームの課題と最近の動向については先ほど触れましたが、そこで

特に、インフラのことについては開発チームだけではなかなか手も足もでません。

と書きました。SDDC、ネットワークの仮想化、ストレージの仮想化、ハイブリッドクラウド、クラウド運用管理・・・、インフラ管理者にとって新しい技術や概念が目白押しです。そのような中、競争の激しいビジネスからの要求に応えるため、一秒でも早いサイクルタイムの実現のため、多くの課題を抱えながらアプリケーション開発を続ける開発チームに対して、インフラ及びOps (運用)チームは今何が求められるでしょうか？

Dev と Ops を隔てる壁

特にエンタープライズではその傾向が強いと思いますが、システム開発のライフサイクルにおいては、一般にDev(開発) と Ops (運用) には高い壁があるケースが多いです。

次のスライドは、VMworld 2014 の複数のセッションで使われていたものです。

Image may be NSFW.
Clik here to view.

端的に言うと、両者の利害は一致していません。

開発チームはインフラやアプリケーションのリリースに対するスピードを求め、一方で運用チームはその職務上、安定した運用及びトラブルの予防のためにできるだけ変化がないこと、そして厳しく管理することを求めます。

開発チームはビルドしてデプロイ可能になった成果物を運用チームに渡します。開発チームが掌握できるローカルのテスト環境はまだしも、ユーザ受け入れテスト環境、負荷テスト環境、ステージング環境、そして本番環境・・。開発チームの手を離れてから、実際にアプリケーションが利用可能になるまでに、どれぐらいの時間がかかるでしょうか。アジャイル開発を導入している組織で、デプロイ可能な成果物は1週間に1回リリースできても、インフラ側で環境にデプロイして運用に持っていくまでのスピードが対応できないため、結局実際にアプリケーションが本番環境にリリースされるのは3ヶ月～半年に1回、という例もあるようです。

この壁は、もし存在するのであれば今後もずっと存在していてよいものでしょうか？

DevOps とは？

実は、この壁は先ほどご紹介したような1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイするような環境の企業には存在していません。

Wikipedia によると、DevOps とは

DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。ただし2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。

とあります。

物事を最適化する方法として、holistic approach (全体論的アプローチ) という言葉が使われることがありますが、アジャイル開発における「チーム」もこのようなアプローチであり、DevOps も開発と運用が連携して協調することで、これまで（誰もがうすうす感づいていながら）システム開発ライフサイクルにおいて非効率であった部分（特にサイクルの後半）に対応していこうとするものです。

Image may be NSFW.
Clik here to view.

ただ、注意点としてこのような取り組みは、ややもすると「組織論」に偏りがちです。体制を変えていく必要があるのは大前提なのですが、複雑さを増す一方のクラウド時代の今、手作業と人間によるコミュニケーションでの改善には限界があります。是非、ツールには適切に投資し、最大限活用することをご検討ください。これはベンダーの立場での都合の良い意見とも取れますが、ITが魔法のような速度で世の中やビジネスを変えているのはソフトウェアの力(とそれを支える強力なインフラ)であり、ツールは特定の目的を最適に実現することを目指して作られたソフトウェアです。

[今できること] SDDC と IaaS++

DevOps のような開発と運用が交わるような領域において、作業の協調、高度な自動化、ハイブリッドクラウド環境への対応、といった技術的にも複雑な取り組みを着実に推進していくためには、そのインフラとなるしっかりとした土台が欠かせません。その中で、VMware がご提供可能なものとしては、SDDC のビジョンを実現する VMware のクラウド運用管理製品を中心としたソリューションになります。

Image may be NSFW.
Clik here to view.

開発チームはこれまでも、開発・テスト環境の準備という観点で非常に苦労してきました。例えば開発者のPC環境のセットアップもその一つです。VMware Workstation などの仮想化製品を使って、PC上にテンプレートから展開した開発・テスト環境を用意するケースも多いと思います（最近では Vagrant がよく話題に上りますね）。

SDDC をベースとする強固な土台を導入していくことで、クラウド環境を使ってこれらの作業を支援し、さらなる効率化を進めることが可能です。

例：

• NSX によるネットワーク仮想化によって、テスト環境の仮想マシン群に対して隔離された論理(L2)ネットワークを個別に提供
• vSAN によるストレージ仮想化によって、ストレージのコスト及び管理工数を削減しつつ、必要に応じてリソースをスケールアウトできる、開発環境に最適なクラスタを構成
• vCAC のポータルを通して仮想マシンの提供を含む各種のサービスを統合していくことで、管理性を保ちながらも、必要なリソースがセルフサービスですぐに手に入る環境を開発者に対して提供

これらは一例ですが、開発、テストにおける作業効率の向上、そしてサイクルタイムの短縮につながります。

ここまでは、システム開発ライフサイクルにおける「ビルド」「テスト」といった主に開発チームの作業をインフラとして支援する範囲となりますが、DevOps という観点から見た、VMware ソリューションとしての 最初のターゲットは、アプリケーションのデプロイ作業の最適化です。

Image may be NSFW.
Clik here to view.

VMware では、仮想化基盤あるいは IaaS 上への仮想マシンのプロビジョニング及び構成に加えて、アプリケーションのデプロイ及び構成管理を含めた部分を簡素化及び自動化するためのソリューションをご提供しています（VMware ではこれを IaaS++ と表現することもあります）。

このソリューションは、以前は VMware vFabric Application Director という名称でしたが、vCAC の一部として統合され、さらに vCAC 6.1 では Application Services と名称が変わっています。

Application Services のクラウド管理製品としての特徴は、ｎ階層の構成を含むアプリケーションをGUIツールを使ってブループリントとしてモデル化し、同一のブループリントから AWS、vCloud、vCAC といった様々なクラウド環境に対してアプリケーションをデプロイできることです。これにより、開発環境、テスト環境、本番環境といった、要件によって異なる環境に同じ構成のアプリケーションを何度もデプロイしなければいけないケースで、一貫性を確保した、安定したデプロイ環境を構築することができます。このような要件は、今後は前提として検討しなければならなくなるでしょう。

Image may be NSFW.
Clik here to view.

アプリケーションのブループリントは、使用するOSの仮想マシンテンプレートを指定する「Logical Templates」、そのOS上で動作するDBなどのミドルウェアを指定する「Services」、そしてさらにミドルウェア上にデプロイされるアプリケーションを指定する「Application Components」などで構成されます。これらの要素は、GUIパレット上でドラッグ&ドロップして、要素を積み重ねることで関係を表現します。また、仮想マシンのプロビジョニングやアプリケーションのデプロイの順番は、依存関係を表すラインで要素間を結ぶことで表現します。

Image may be NSFW.
Clik here to view.

「Services」や「Application Components」などの要素は、ミドルウェアやアプリケーションを仮想マシン上にインストールして構成する動作を指定する、重要な役割を担っています。「Services」を例にとると、これらは「Apache v.2.2.0」「vFabric RabbitMQ v2.4.1」「MySQL v5.0.0」といった個々のミドルウェア毎に管理され、それぞれがApplication Services におけるアプリケーション展開のライフサイクル（INSTALL, CONFIGURE, START, UPDATE, ROLLBACK, TEARDOWN）において行うべき動作を、スクリプトとして記述しています。これらの要素は、スクリプト及び（デプロイ時にカスタマイズ可能な）プロパティからなるテンプレートに過ぎません。なお、このスクリプトですが、Windows では「Windows CMD」「PowerShell」「BeanShell」が、Linux では「Bash」及び「BeanShell」がサポートされています。

Image may be NSFW.
Clik here to view.

Application Services ではブループリントで定義された依存関係から個々の要素の実行順序が導き出され、仮想マシンのプロビジョニング後にそれぞれのスクリプトが順番に呼び出されることによってアプリケーションの展開が実行されていきます。

また、Application Services ではアプリケーション展開後にも、同一のインスタンスに対して一部の構成を変更した上での「Update」や、変更後にエラーが見つかった際の「Rollback」、アプリケーションの取り壊しを行う「TEARDOWN」、そして削除といったライフサイクル管理を行うことができます。

Image may be NSFW.
Clik here to view.

“Infrastructure as Code” を実現する Puppet や Chef などのツールを使ったことのある方なら、例えば次のような DSL 定義を思い浮かべられたかもしれません（これは Puppet のマニフェストの一例です）。

Application Services は、まさに同じようなことを、異なるアプローチで実現するツールといえます。

Image may be NSFW.
Clik here to view.

 Application Services はクラウド環境における “Dev” と “Ops” の協調作業プラットフォーム

IaaS++ として Application Services についてご紹介してきましたが、DevOps という視点でまとめると、Application Services とは「クラウド環境における “Dev” と “Ops” の協調作業プラットフォーム」です。仮想化基盤やクラウドの管理者は環境毎の仮想マシンテンプレートやテナントを準備し、カタログ管理者はスクリプトの作成などで開発者、運用者と連携しながら「Services」や「Application Components」のカタログを管理し、アプリケーションアーキテクトはアプリケーションブループリントを作成します。各環境へのリリース段階では、デプロイヤがブループリントを利用し、環境毎のプロパティ値をカスタマイズした上でデプロイし、その後も連携しながらライフサイクルを管理する。このような、クラウドインフラを含めたアプリケーション展開の構成管理を、一つのツールを使って実現することができます。

Image may be NSFW.
Clik here to view.

なお、開発者とは「成果物」の管理を通して連携しています。例えば、開発チームが CI ツール (Jenkins) でビルドして作成するアプリケーションのモジュールを Application Services 側に登録して、ブループリントで指定された「Application Components」が実行時にそのモジュールをダウンロードしてインストールする、といった連携が実現できます。

Image may be NSFW.
Clik here to view.

Puppet Integration

Bash などのスクリプトを使うと聞いて、「うげっ」と思われた方もいるかと思います。時代は DSL ではないのか、宣言的な、あるべき状態の記述ではないのかと。ご安心下さい。Application Services では Puppet とのインテグレーションもサポートしています。これにより、アプリケーションの展開プロセス全体のオーケストレーションや仮想マシンのプロビジョニングは Application Services が行いますが、各仮想マシン上の構成は Puppet Master 及び Agent におまかせする、ということも可能です。vCAC 6.1 ではインテグレーションもさらに強化されています。

Image may be NSFW.
Clik here to view.

個人的には、Bash / PowerShell などの良く使われているツールを使うことができるもの、既存資産の有効活用や、今までと大きくやり方を変えないで済む点で、特にエンタープライズ環境ではメリットの一つだと考えます。

最後に

本記事が、これまで主にインフラの観点から VMware に触れていただいている方々が、DevOps という観点から VMware のクラウド運用管理製品や周辺技術に対して目を向けていただける一つのきっかけになりましたら、大変うれしく思います。

なお[後編]では、先日発表された新製品である VMware vRealize Code Stream を中心に、VMware が今後視野に入れている DevOps 関連のソリューションについて、VMworld 2014 でのセッション内容を交えてご紹介する予定です。

皆様こんにちは、VMware の町田と申します。 今回は、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、日本でも注目が高まってきている DevOps  に関連するセッションの内容を取り上げながら、VMware のクラウド管理ソリューションを Dev(開発)とOps(運用)の協調という視点からご紹介する記事の [後編]となります。

はじめに

[前編]の記事はこちらになります：

• VMworld 2014 からの注目セッション 第4回 – DevOps (前編) – SDDCとIaaS++

また先日発表された、 DevOps における継続的デリバリー ソリューションである VMware vRealize Code Stream について、[前編]の内容もここでおさらいしておきます。 ～～～ VMworld 2014 EUROPE の開催に合わせて、日本でも2014年10月15日（日本時間）付けでクラウド管理プラットフォームの最新版「VMware vRealize Suite 6」を含む、新たなクラウド管理製品群と機能群を発表しました。この中で、DevOps における継続的デリバリーを実現する「VMware vRealize Code Stream」という製品も発表されています。この製品が、VMworld 2014 US で[Tech Preview]として紹介された Continuous Delivery for DevOps の正式名称となります。 ～～～

リリースパイプライン管理とアーティファクト管理

「VMware vRealize Code Stream」 は、[前編]で紹介した Application Services のアプリケーション展開を管理するという考えをもう一歩進めて、開発チームの継続的統合(CI)環境と連携することで、各環境へのアプリケーション展開を含めたリリースパイプライン全体の自動化の実現（継続的デリバリー）を目指すものです。

Image may be NSFW.
Clik here to view.

次の図は、「Dev (開発)」、「Test (テスト)」、「UAL – Load (ユーザ受け入れ、負荷テスト)」、「SIT – Staging (システム統合テスト – ステージング）」、「Production (本番)」という5つのステージをもつリリースパイプラインをあらわしており、ステージによって AWS、プライベートクラウドといった別の環境にアプリケーションが展開されることが想定されています。

Image may be NSFW.
Clik here to view.

このような環境で、各ステージ内では「プロビジョニング」「テスト」「デプロイ」「カスタム」「アーティファクト」といった個々のタスクを外部のツール(例えば Jenkins や Artifactory、vCAC、vCO のカスタムワークフローなど)と連携しながら実行してアプリーションをクラウド環境上に展開していきます。各ステージ間には「ゲート」が存在し、例えば「前のステージのテスト実行結果が100%のときだけ次のステージに進む」「前のステージで人手による受け入れテストの実行結果が90%以上の時に、管理者が承認をすることで次のステージに進む」といった自動化が可能になります。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

継続的デリバリを実現するリリースパイプラインの管理ツールとしては、アジャイル開発における Thought Reader である ThoughtWorks 社の Go などがありますが、VMware がこのカテゴリのツール開発に力を入れている背景には、SDDC 環境への移行を推進されているお客様からの声として、IaaS を超えた、クラウド環境におけるアプリケーションのリリース作業全体の管理を実現できる製品に対するご要望が多くなってきたことがあります。

その他のトピック

ここからは、 DevOps に関連するセッションの中から、個人的に気になったものを簡単にご紹介します。

1. VMware vCloud Air

VMware がグローバルで提供するハイブリッドクラウドサービスである vCloud Air （日本でも2014年7月にに、日本での提供が開始される予定であることをアナウンス）ですが、VMworld のセッションスライド内でも 「DevOps」 がうたわれています。

Image may be NSFW.
Clik here to view.

vCloud Air の文脈でも、アプリケーションのリリースにかかる時間について言及されています。

Image may be NSFW.
Clik here to view.

“Infrastructure as Code” を実現するツールとして Chef のプラグインが紹介されていました。

Image may be NSFW.
Clik here to view.

また、DevOps サービスとして「CI – as-a-Service」 を提供予定であるというアナウンスもありました。今後、開発者と運用者の生産性を向上させるためのツールが vCloud Air 上にサービスとして展開されていくという期待ができます。

Image may be NSFW.
Clik here to view.

2. Pivotal CF

開発者の目線で言うと、IaaS++ 、つまりApplication Services が提供する機能を使って頑張るというのは、結構面倒に感じます。開発者が欲しいのは、究極的には API を提供する黒箱と、アプリケーションを監視するためのツール そんなことを、VMworld 2014 のあるセッションのスライドは語っています。

Image may be NSFW.
Clik here to view.

これはまさに PaaS の世界です。 Pivotal CF と vCAC、[Tech Preview] Continuous Delivery for DevOps がインテグレーションする世界についても語られていたのですが、これが中々面白いです。 vCAC のカタログ管理とセルフサービスポータルの機能とインテグレーションすることで、 Pivotal CF のサービスなどの管理性が非常に向上します。 また、Continuous Delivery for DevOpsのようなツールからすると、vCAC も Pivotal CF もアプリケーションのプロビジョニング先、つまりエンドポイントとして見えるようになります。リリースパイプライン管理の対象となるクラウド環境に、Pivotal CF のような PaaS がインテグレーションされるというのは夢が広がります。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

なお、冒頭で「開発者の目線でいうと結構面倒」といいましたが、これまでのやり方をできるだけ変えないで、物事を漸進的に進めていくために、多くのエンタープライズにとって IaaS++ のアプローチはとても重要だと考えています。

3. Docker / Fargo(VMfork)

VMworld 2014 のセッションでは、VMware の DevOps ソリューションを Docker と組み合わせた場合に取りうるアプローチについて、3つの方面からまとめていました。

Image may be NSFW.
Clik here to view.

この図の中で、Docker コンテナが実行する箱として「VMfork」と書かれているのが興味深いです。VMfork とは VMworkd 2014 で「Project Fargo」として紹介されていた仮想マシンの超高速クローニング技術のことで、実行中の親仮想マシンから 子仮想マシンを fork させる時に、仮想ディスクのリンククローン+メモリも差分管理することで、ms のオーダーで新しい仮想マシンを用意できるようにするものです。

Image may be NSFW.
Clik here to view.

コンテナ技術は仮想化を使わなくても良いという話も聞きますが、コンテナをホストするリソースが足りなくなれば、物理か仮想かは置いておいても新しいリソースを追加する必要はあります。コンテナをサポートするSDDC 上で、Docker コンテナをサポートする仮想マシンが超高速で展開される、そういった組み合わせも面白いと思います。

Image may be NSFW.
Clik here to view.

最後に

[前編][後編]の2回にわたって、VMware のクラウド管理ソリューションをDevOps の視点からご紹介しましたが、いかがでしたでしょうか？繰り返しになりますが、本記事が、これまで主にインフラの観点から VMware に触れていただいている方々が、DevOps という観点から VMware のクラウド運用管理製品や周辺技術に対して目を向けていただける一つのきっかけになりましたら、大変うれしく思います。

皆さんこんにちは。VMware高木です。

8月末に米国サンフランシスコにて開催されましたVMworld 2014の注目セッション5回目は、セッション番号HBC1534、Recovery as a Service (RaaS) with vCloud Airについてご紹介します。

Image may be NSFW.
Clik here to view.

日本ではサービス提供予定をこの夏に発表したばかりの『vCloud Air』は、VMwareが提供するクラウドサービスの総称です。そのクラウドサービスの1つとしてDisaster Recovery(RaaS)が提供されています。※日本ではQ4(10月〜12月)中にDisaster Recoveryサービスが開始される予定です。

それでは、本セッションの紹介に入って行きたいと思います。画面左側のデータセンターは、既にvSphereを使ってサーバ仮想化を実現しているユーザ環境を示しています。そのvSphere環境の災害対策として、vSphere上の仮想マシンを、右側のvCloud Air上のDisaster Recovery(RaaS)専用リソースに保護する、というサービスです。

ちなみにユーザ環境のAD/DNSは、vCloud Air上のIaaSサービスのVPC(Virtual Private Cloud=共有型クラウド)リソース上のADと連携していますので、AD/DNSも保護されていることが分かります。

Image may be NSFW.
Clik here to view.

以下、vCloud Air Disaster Recoveryの主な特徴です。

・Disaster Recoveryサイトを自前で用意する事なく、vSphere上の仮想マシンの災害対策が行えるため、コスト効果が高いクラウドベースのDisaster Recoveryサービス。

・vSphereの基本機能である非同期レプリケーション、vSphere Replicationを使って仮想マシンを保護、フェイルオーバーする。

Image may be NSFW.
Clik here to view.

その他の特徴は以下の通りです。

・仮想マシンごとにレプリケーション、フェイルオーバーを任意に設定。

・レプリケーションでは、15分〜24時間のRPOを設定。

・最初の同期では、ディスクを配送しオフラインで移行する事も可能。

・1年間に2回までのフェイルオーバーテストが可能。※1回のテストは7日間まで。

・実際にvCloud Air側にフェイルオーバーした際には、30日間まで本番稼働することが可能。

Image may be NSFW.
Clik here to view.

このDisaster Recoveryサービスは、Disaster Recovery(RaaS)用のVDC(Virtual Data Center)リソースを購入する事により使用出来ます。

まず、ベースとなるVDCリソースを購入頂きます。

□10GHz vCPU

□20GB vRAM

□1TBストレージ

□10Mbpsの帯域

□2つのパブリックIP

□2回のフェイルオーバーテスト

期間は1ヶ月、12ヶ月、24ヶ月、36ヶ月から選択出来ます。

Image may be NSFW.
Clik here to view.

ベースとなるVDCリソースでは足りない場合、それぞれオプションで追加する事が出来ます。

ストレージ、帯域〜フェイルオーバーテスト等、幅広いリソースをオプションとして追加できます。

Image may be NSFW.
Clik here to view.

最初の同期では、オフラインでデータを移行する事が出来ます。

vCloud ConnectorのODT(Offline Data Transfer)機能を使って、保護対象の仮想マシンをexport、vCloud Air側にimportする事により、最初の同期で帯域を圧迫させる心配はありません。特に保護対象の仮想マシンの容量が大きい場合には効果的です。

Image may be NSFW.
Clik here to view.

vCenter Web Clientとフルに連携しているため、普段お使い頂いているvCenterから操作が可能です。

Image may be NSFW.
Clik here to view.

vSphere Repliationのトラフィックは、SSLでセキュリティが担保されますので、安心してお使い頂けます。

Image may be NSFW.
Clik here to view.

vCloud Air Disaster Recoveryを使用する上での要件は以下の通りです。

・vSphere 5.1以上

・vSphereは、Essential Plus以上のエディション※Essential ではvSphere Replicationが使用できない

・vCenter 5.1以上

・vSphere Replication仮想アプライアンス5.6以上※最新のvSphere Replication 5.8では設定画面等日本語化されています

・インターネット環境に出られる事

Image may be NSFW.
Clik here to view.

次に、実際にvCloud Air Disaster Recoveryを使って仮想マシンを保護する設定方法を見て行きましょう。まず、vSphere Replicationを使うので、vSphere Replication 5.6の仮想アプライアンスを展開し、vCenterに登録します。このvSphere Replication 5.6にはセキュアにvCloud Air Disaster Recoveryへのレプリケーションを実現出来る機能が含まれています。

Image may be NSFW.
Clik here to view.

そして、レプリケーション先となるvCloud Air側のVDCのAPIを確認します。確認は、vCloud AirのWeb UIから行います。

Image may be NSFW.
Clik here to view.

確認したら、vCenterから、vSphere Replicationのターゲットサイトの登録を行います。確認したVDCのAPIをコピーしたら、その内容をターゲットサイト先情報として入力します。

Image may be NSFW.
Clik here to view.

ターゲットサイトとしてVDCを登録したら、次にターゲットとなるネットワークを設定します。テスト用には、外部との疎通が取れないIsolatedネットワーク。リカバリ用には外部との疎通が可能なRoutedネットワークを設定します。※vCloud Air側には、予め内部通信用のIsolatedネットワーク、外部通信用のRoutedネットワークの2つが準備されています。

Image may be NSFW.
Clik here to view.

続いて、保護対象の仮想マシンごとに、vSphere Replicationの設定を行います。レプリケーション先としては新しいメニューとなる”Replicate to a cloud provider”を選択します。

Image may be NSFW.
Clik here to view.

すると既にターゲットサイトとして登録したVDCが表示されますので、そちらを選択。後は、通常のvSphere Replication同様にVSSを使う or 使わない、RPOは何分(15分〜1,440分)という設定をするだけです。

Image may be NSFW.
Clik here to view.

通常のvSphere Replication同様にvCenterからvSphere Replicationのモニタリングや操作が行えます。

最後にvCloud Air Disaster Recoveryのメリットをもう一度お伝えして、第5回注目セッション『HBC1534、Recovery as a Service (RaaS) with vCloud Air』のご紹介を終わりたいと思います。

・災害対策用として、自前でDisaster Recoveryサイトを建てる必要がない。=コストを抑えてvSphere環境の災害対策が始められる。

・vSphere Replication機能を使って仮想マシンを保護するため、既存のvSphere環境に別途製品を購入する必要がない。SANベースのレプリケーションも不要です。

・普段お使い頂いているvCenterから操作ができる。

・仮想マシン単位で簡単に保護できる。=アプリケーションの保護要件に応じて、個々の仮想マシンに別々のポリシーを適用できる。

・初回の同期で帯域を消費しない様、オフライン移行が可能。

・vCloud Air Disaster Recoveryリソースは柔軟に追加が出来る。＝保護対象の仮想マシン数に応じて、スケールアップ、スケールアウトが可能。

引き続き、VMworld 2014の注目セッションブログにご期待下さい。

みなさん、こんにちは。

今回の記事では、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、vCenter Operationsマネージャーを利用して、仮想環境上でアプリケーションの運用をより効率的に行う方法をご紹介します。

仮想環境上で稼働するアプリケーションを監視する方としては「Hyperic」（http://www.vmware.com/jp/products/vfabric-hyperic）を利用する方法があります。
Hypericを利用してゲストOS上にHypericエージェントをインストールすることにより、プロセスやWindows Serviceをはじめ、様々なアプリケーションのメトリックを収集することが可能となります。

さらにHypericで収集された情報をvCenter Operationsと連携することによりアプリケーションの稼働監視や分析を行うことが可能となります。
Image may be NSFW.
Clik here to view.

VMworld 2014では下記のアプリケーションとの連携について将来バージョンにおける
連携が発表されております。

1.MSSQL

Image may be NSFW.
Clik here to view.
ソリューションの特徴は以下です。
・自動検知による、MSSQLサービスとインスタンスの登録
・クラスタ構成の可視化
・デフォルトKPIによる静的および動的な監視
・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

2.Microsoft Exchange

Image may be NSFW.
Clik here to view.

ソリューションの特徴は以下です。
・メールボックスとCASロールの自動検知
・DAGの検知
・関連する全サイトの情報伝搬
・デフォルトKPIによる静的および動的な監視
・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

3.vCAC

Image may be NSFW.
Clik here to view.

4．SAP HANA
Image may be NSFW.
Clik here to view.
ソリューションの特徴は以下です。
・エージェント不要でデータ収集
・SAP HANAシステムへは負荷は軽微
・Out-of-the-box ダッシュボードの提供（トラブルシューティング、診断法と分析）
・300以上は、SAP HANA Studioの中で入手不可能300以上の判断基準
・SAP HANAとvSphereの間の関係マッピング

まとめ
仮想環境上で稼働する様々なアプリケーションの管理・監視のソリューションについてご紹介いたしましたが、如何でしたでしょうか。

11/5（水）～6（木）にプリンスタワー東京でvForum2014が開催されます。

こちらでも、今回のVMworldと同様のセッションが数多く講演されますので、ぜひご来場ください。

こんにちは、パートナー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” というクラスタへの移行を示しています。）

Image may be NSFW.
Clik here to view.

図１．クロス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

Image may be NSFW.
Clik here to view.

図２．クロス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

Image may be NSFW.
Clik here to view.

図３．長距離vMotion移行の実施イメージ

■vMotion ネットワーキング

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

Image may be NSFW.
Clik here to view.

図４．vMotion専用TCP/IPスタックの設定

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

Image may be NSFW.
Clik here to view.

図５．vMotion ネットワークの構成例

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

Image may be NSFW.
Clik here to view.

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

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

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

①UUID

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

Image may be NSFW.
Clik here to view.

②MACアドレス

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

Image may be NSFW.
Clik here to view.

③HA/DRS ルール

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

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

Image may be NSFW.
Clik here to view.Image may be NSFW.
Clik here to view.

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

• アフィニティルール
  • VM ごとのオーバーライドルールが設定されている場合
    Image may be NSFW.
    Clik here to view.
• VM ごとのオーバーライドルール
  • 移行先のクラスタの設定と同じ設定がされている場合
    Image may be NSFW.
    Clik here to view.
    

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

④リソース設定

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

Image may be NSFW.
Clik here to view.

⑤タスクデータ

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

Image may be NSFW.
Clik here to view.

⑥パフォーマンスデータ

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

Image may be NSFW.
Clik here to view.

⑦vRealize Operations Manager 上のデータ

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

Image may be NSFW.
Clik here to view.

■終わりに

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

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

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

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

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

第１回　トラブル発生時に役立つ 4 つのリソース　←This Post
第２回　サポートリクエスト（SR）と情報採取
第３回　応用編

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

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）トップ画面の [サポート] からアクセスできます。
設計・構築時にご利用いただいているものもあるかと思いますが、今回はトラブル発生時にどのようなポイントを確認したらいいかという観点でご説明したいと思います。
はじめての方も、まずは手を動かしながら色々調べてみましょう！

Image may be NSFW.
Clik here to view.

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

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

そして2つ目、製品ドキュメントやリリースノートをはじめ各種ドキュメントが公開されています。
Image may be NSFW.
Clik here to view.
まずは 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/）」各ガイド欄にリンクされています。
Image may be NSFW.
Clik here to view.
確認してもらいたいポイントに沿ってご紹介します。

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

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

次に確認していただきたいのがリリースノートです。
リリースノートには新機能の紹介だけでなく、既知の問題とその回避策も公開されています。
Image may be NSFW.
Clik here to view.
「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）のリリースノートを見てみます。
既知の問題の欄をご参照下さい。
ここで紹介されている問題にあてはまりそうな場合、回避策を試してみて下さい。
Image may be NSFW.
Clik here to view.

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

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

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

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

Image may be NSFW.
Clik here to view.

出ましたっ！

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

* 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 Matrixes（http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php）

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

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

チェックが付いているのが互換性ありのしるしです。
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 問題解決までのヒント！
第１回　トラブル発生時に役立つ 4 つのリソース
第２回　サポートリクエスト（SR）と情報採取
第３回　応用編

はじめに

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

VVol 概要とメリット

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

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

Image may be NSFW.
Clik here to view.

　

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

Image may be NSFW.
Clik here to view.

　

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

Image may be NSFW.
Clik here to view.

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台がストレージコンテナとなります。

Image may be NSFW.
Clik here to view.

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 は各ボリュームのコンプライアンスを監視
  • 仮想マシンに紐づけたストレージが機能要件を十分に満たしているかを監視していく役割も担っている

Image may be NSFW.
Clik here to view.

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プロバイダの準備はサービスの確認と開始のコマンドを実行するだけで完了です。

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

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

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

Image may be NSFW.
Clik here to view.　

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

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

Image may be NSFW.
Clik here to view.

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

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

Image may be NSFW.
Clik here to view.

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

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

 

仮想マシンの作成

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

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

 

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

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

Image may be NSFW.
Clik here to view.

仮想マシンのパワーオンを実行するとSwap 用のボリュームが自動的に作られます。Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

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

Image may be NSFW.
Clik here to view.

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

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

 

最後に

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

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

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

■はじめに

こんにちは、パートナーSEの川崎です。本シリーズでは、前回に引き続きネットワーク仮想化をネットワークの基本から理解するという姿勢で、物理環境と比較しながら進めます。第3回となる今回はレイヤ3のルーティングに関して見ていきます。

■はじめに

データセンターにおけるネットワークでは、East-West トラフィックと呼ばれるサーバ間の水平方向の通信が、トラフィック量全体の約7 割を占めていると言われています。分散ルーティングは、ハイパーバイザ内でルーティングの処理を行うことで、この East-West トラフィックを最適化します。

Image may be NSFW.
Clik here to view.

従来のルーティングテーブル（左）と分散ルーティング（右）

分散ルーティングの設定は、VMware NSX の管理画面から行います。物理サーバや物理ネットワーク機器数十台にまたがるような分散ルーティング環境を構成する際も、個々の物理コンポーネントに設定を行う必要はありません。

分散ルーティング環境を構成するためには、論理ルータコントロールVMと呼ばれるコンポーネントを作成します。論理ルータコントロールVM は、 NSX Edge の構成ウィザードから、インストールタイプを「論理（分散）ルータ」として構成します。

Image may be NSFW.
Clik here to view.

論理ルータコントロールVM の作成

論理ルータコントロールVM に設定したインターフェイスやルーティングの情報は、各 VMware ESXi ホストに展開されます。例えば論理ルータコントロールVM にルーティング設定を追加すると、その情報が各 ESXi ホスト内の論理ルータカーネルモジュールに展開されることになります。

Image may be NSFW.
Clik here to view.

ルーティング情報の展開

上述の通り分散ルーティングに関する設定はGUI から簡単に行うことができますが、APIを介した設定も可能であり、CMP（クラウドマネジメントプラットフォーム）と連携することで設定作業を自動化できます。

■物理ネットワーク環境におけるルーティング

分散ルーティングの説明に入る前に、物理ネットワーク環境でのルーティングの説明を行います。

Image may be NSFW.
Clik here to view.

物理ネットワーク環境におけるルーティング

ネットワーク環境において、異なるネットワークセグメント内に存在する端末間で通信を行なう場合を考えます。端末A と端末C はそれぞれ、172.16.10.0/24, 172.16.20.0/24のネットワークに存在し、物理ルータ（L3SW）に接続されています。異なるネットワークセグメント間の通信では、ルータによるルーティング処理が行なわれます。

ルーティングを行うのは、ネットワーク機器だけではありません。端末A（172.16.10.11/24） が端末C（172.16.20.11/24） と通信を行うとき、最初に端末A は端末C が異なるサブネットにいることを認識します。端末A は、自身のルーティングテーブルを参照し、デフォルトGW であるルータにトラフィックを転送します。

ルータはそれぞれのネットワークセグメントにインターフェイスF0, F1 を持ち、受信した通信を、別のインターフェイスから送信します。送信するインターフェイスを決定する際にルーティングテーブルを参照します。実際にルータのルーティングテーブルを確かめてみましょう。

> show ip route
C 172.16.10.0/24 is directly connected, F0
C 172.16.20.0/24 is directly connected, F1
S 0.0.0.0/0 via <外部ルータIP>

端末C（172.16.20.11）の所属する172.16.20.0/24 は、ルータのインターフェイス F1 に直接接続していることが確認できます。ルータは、インターフェイス F1 から端末C にパケットを転送します。

物理ネットワーク環境では、物理ルータがルーティングテーブルを持ち、単一のポイントでルーティング処理を実施します。また、複数の物理デバイスがある場合は、個々のデバイスに対して設定作業を行うことになります。

ルーティングの考え方及び、端末側の動作はネットワーク仮想化環境になっても変わりませんが、ネットワーク仮想化環境では物理ルータの持つルーティング機能を、分散ルーティングとしてハイパーバイザに実装することができます。分散ルーティングのアーキテクチャについて、「ルーティングテーブル」に注目する形でこの後見ていきます。

■ネットワーク仮想化環境における分散ルーティング

ネットワーク仮想化環境でのルーティングを見ていきます。サーバ仮想化環境であっても通常の構成であれば、ルーティング処理は外部のルータで行われることになります。これに対し、分散ルーティングが有効な環境では、各 ESXi ホスト内に論理ルータカーネルモジュールが配置され、ホスト内でルーティング処理を行うことが可能になります。

Image may be NSFW.
Clik here to view.

ネットワーク仮想化環境における分散ルーティング

上記は、2台の ESXi ホストが存在し、ネットワーク仮想化と分散ルーティングが有効となった環境を表しています。各 ESXi ホスト内に論理ルータカーネルモジュールが構成され、2つのネットワークが接続されています。論理ルータカーネルモジュールはルーティングテーブルを持ち、異なるL2ネットワーク間の通信が行なわれる際にルーティング処理を行ないます。

Image may be NSFW.
Clik here to view.

分散ルーティングの動作

実際に分散ルーティングが行なわれる状況を見てみましょう。上記は同一の ESXi ホスト上に存在する2つの仮想マシン VM-A、VM-C が通信を行なう様子を示しています。VM-A は VXLAN 5001 (172.16.10.0/24) に接続、VM-C はVXLAN 5002 (172.16.20.0/24) に接続しているため、2つの仮想マシン間で通信するためにはルーティングが必要です。VM-A から送信されるパケットは ESXi ホスト内の論理インターフェイス（LIF）を宛先とする L2 ヘッダがつけられて送信され、論理ルータカーネルモジュールに届きます。論理ルータカーネルモジュールは受け取ったパケットをルーティング処理し VM-C  に届けます。

では、実際に分散ルーティング環境のルーティングテーブルを確認しましょう。ここではテーブルの情報がどこから共有されてくるか、という点を確認するために、論理ルータコントロールVM、NSX コントローラ、各 ESXi ホスト内の論理ルータカーネルモジュールそれぞれについてルーティングテーブルを確認します。

論理ルータカーネルモジュールの持つルーティング情報は、論理ルータコントロールVM に設定した論理インターフェイス（LIF）情報、静的に設定されたルーティング情報、動的に得られたルーティング情報が基になっています。論理ルータコントロールVM の論理インターフェイスと静的なルーティングは vSphere Web Client から設定することができ、この情報は NSX Manager を介して論理ルータコントロールVM に伝えられます。動的ルーティングについては、論理ルータコントロールVM が外部のルータとダイナミックルーティングプロトコル（OSPF, BGP）を介して情報を交換します。

Image may be NSFW.
Clik here to view.

分散ルーティング環境でのルーティング情報の伝達

このようにして得られた論理ルータコントロールVM の持つルーティングテーブルを示します。

> show ip route
S      0.0.0.0/0      [1/1]  via <外部ルータIP>
C      172.16.10.0/24 [0/0]  via 172.16.10.254
C      172.16.20.0/24 [0/0]  via 172.16.20.254

ルーティングテーブル（論理ルータコントロールVM）

論理ルータコントロールVM が得たルーティングテーブル情報は、NSX コントローラクラスタを介して各 ESXi ホストに伝えられます。コントローラクラスタは役割を分担しており、ある論理ルータコントロールVM のルーティングテーブルはその管理を担う NSX コントローラ のみが持ちます。該当 の NSX コントローラ から、ルーティングテーブル情報を確認できます。

# show control-cluster logical-routers routes 0x570d4554
LR -Id      Destination      Next-Hop[]      Preference
0x570d4554  0.0.0.0/0        <外部ルータIP>   1

ルーティングテーブル（NSX コントローラ）

# show control-cluster logical-routers interface-summary 0x570d4554
Interface                        Type   Id           IP[]
570d455400000002                 vxlan  0x1388       172.16.10.254/24
570d45540000000a                 vxlan  0x138d       172.16.20.254/24

論理インターフェイス（NSX コントローラ）

 NSX コントローラが持つルーティング情報が各 ESXi ホスト内に存在する論理ルータカーネルモジュールに配信されます。

# net-vdr --route default+edge-2 -l
Destination      GenMask         Gateway        Flags   Ref Origin  Uptime     Interface
-----------      -------         -------        -----   --- ------  ------     ---------
0.0.0.0          0.0.0.0         外部ルータIP    UG      1   AUTO    1960358    570d455400000002
172.16.10.0      255.255.255.0   0.0.0.0        UCI     9   MANUAL  1971591    570d45540000000a
172.16.20.0      255.255.255.0   0.0.0.0        UCI     1   MANUAL  1971560    570d45540000000b

ルーティングテーブル（ESXi ホスト）

（補足）上図「分散ルーティング環境でのルーティング情報の伝達」の構成では、論理ルータコントロールVM が、外部ルータに対し、OSPF 経由で内部ネットワーク情報（172.16.10.0/24 及び172.16.20.0/24）を通知しています。これにより、外部ネットワークと内部ネットワーク間の通信が可能になります。

■物理ネットワーク環境とネットワーク仮想化環境の比較

物理ネットワーク環境とネットワーク仮想化環境について、ルーティングの面で比較します。

Image may be NSFW.
Clik here to view.

物理と仮想の比較

物理ネットワーク環境では、ルーティングテーブルは物理ルータが持ち、単一のポイントでルーティング処理を実施していました（集中処理）。また、複数の物理ルータがあるような構成では個々のハードウェアに対して設定作業を行うことになります（分散管理）。

一方でネットワーク仮想化環の分散ルーティングは、ハイパーバイザ内でルーティングテーブルを分散して持つことで、複数のポイントでルーティング処理を実施します。

ポイント1 ハイパーバイザでルーティング情報を持ち、同一 ESXi ホスト上の仮想マシン間のルーティングはホスト内で処理することができるため、East-West トラフィックを最適化できる（データプレーンにおける分散処理）

各ハイパーバイザの持つルーティングテーブルの制御は、論理ルータコントロールVM 及び NSX コントローラクラスタで集約して行います。

ポイント2 論理ルータコントロールVM 及び NSX コントローラクラスタでルーティング情報を集中して制御することにより、複数のハイパーバイザ間でルーティングテーブルを共有することができる（コントロールプレーンにおける集中制御）

分散ルーティング環境のセットアップは、NSX Manager を介して、GUI もしくはAPI 経由で簡単に行うことが出来ます。

ポイント3 NSX Manager から一括して設定管理を行うことで、運用管理性を損なうことなく容易に実装できる（マネジメントプレーンにおける集中管理）

ネットワーク仮想化環境における分散ルーティングは、分散処理、集中制御、集中管理のアプローチをとることで、運用管理性を維持しつつ、効率よく East-West トラフィックを処理することを可能にしています。

■ 補足情報 分散ルーティングを提供する VMware NSX のコンポーネント

分散ルーティング環境で、NSX を構成する各コンポーネントがどういった役割を果たしているのか解説を行います。

Image may be NSFW.
Clik here to view.

NSX を構成するコンポーネントの役割

・NSX Manager（マネジメントプレーン）

NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時の ESXi ホストへのカーネルモジュールのインストールや、論理ルータコントロールVM やNSX Edge といった仮想アプライアンスの払い出しを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。

・NSX コントローラクラスタ（コントロールプレーン）

NSX コントローラクラスタは、現時点で3台の仮想アプライアンスで構成することを推奨しており、分散ルーティング環境において、各種情報（論理インターフェイス、ルーティングテーブル）を集中管理するポイントになります。後述の論理ルータコントロールVM 毎に担当するコントローラが決められ、例えば2つのテナントがある場合、論理ルータコントロールVM （テナントA）はコントローラ1番、（テナントB）はコントローラ2番というように役割が割り当てられます。テーブル情報は、担当するコントローラのみが保持します。

Image may be NSFW.
Clik here to view.

マルチテナント環境でのルーティングテーブルの扱い

3台のコントローラ（192.168.110.201,192.168.110.202,192.168.110.203）で構成されている環境で、論理ルータの情報を確認する手順は下記のとおりです。

# show control-cluster logical-routers instance all
LR-Id      LR-Name            Hosts[]         Edge-Connection Service-Controller
0x570d4554 default+edge-2     192.168.210.51                  192.168.110.201
192.168.110.52
192.168.110.51
192.168.210.52
192.168.210.56
0x570d4553 default+edge-3                                     192.168.110.202

この出力結果から、論理ルータコントロールVM のインスタンスが2つあることが分かります。default+edge-2（0x0x570d4554）は、192.168.110.201 が管理し、default+edge-3（0x570d4553）は、192.168.110.202 のコントローラが管理していることが分かります。論理ルータの情報を見るためには該当のコントローラにログインする必要があります。（192.168.110.201 のコントローラで情報を出力しているため、自身の担当しているインスタンス default+edge-2 に関連する ESXi ホストの IP 情報が出力されています）

論理ルータ default+edge-2（0x0x570d4554）の管理するルーティングテーブルの確認

# show control-cluster logical-routers routes 0x570d4554
LR-Id       Destination        Next-Hop[]         Preference
0x570d4554  0.0.0.0/0          192.168.10.1       1

論理ルータdefault+edge-2（0x0x570d4554）の管理する論理インターフェイスの確認

# show control-cluster logical-routers interface-summary 0x570d4554
Interface                        Type   Id           IP[]
570d455400000002                 vxlan  0x1388       192.168.10.5/29
570d45540000000a                 vxlan  0x138d       1.1.1.254/24

・論理ルータコントロールVM（コントロールプレーン）

論理ルータコントロールVMは分散ルーティング環境において、ルーティングの処理を集中して行うための仮想アプライアンスです。設定したスタティックルーティング情報や、ダイナミックルーティングプロトコル（OSPF, BGP）経由で外部のネットワーク機器から学習したルーティング情報を、コントローラクラスタ経由でESXi ホストに配信します。

論理ルータdefault+edge-2（0x0x570d4554）の管理するルーティングテーブルの確認

>　show ip route
S      0.0.0.0/0        [1/1]    via 192.168.10.1
C      192.168.10.0/29  [0/0]    via 192.168.10.5
C      1.1.1.0/24       [0/0]    via 1.1.1.254

論理ルータコントロールVM はテナント単位（ルーティングテーブルの管理単位）で複数たてることができます。

・論理ルータカーネルモジュール（データプレーン）

NSX 環境を構築する際、ホストの準備のステップで各 ESXi にインストールされるカーネルモジュールとなります。VIB(vSphere Installation Bundle)ファイルとしてインストールされ、カーネルモジュール（vdrb）としてロードされます。カーネルモジュールは、ハイパーバイザ内で論理ルータのテーブルの管理とルーティング処理を行います。

論理ルータ default+edge-2（0x0x570d4554）の管理するルーティングテーブルの確認

# net-vdr -l --route default+edge-2
VDR default+edge-2 Route Table
Legend: [U: Up], [G: Gateway], [C: Connected], [I: Interface]
Legend: [H: Host], [F: Soft Flush] [!: Reject] [E: ECMP]

Destination      GenMask          Gateway          Flags    Ref Origin   UpTime     Interface
-----------      -------          -------          -----    --- ------   ------     ---------
0.0.0.0          0.0.0.0          192.168.10.1     UG       1   AUTO     1724       570d455400000002
1.1.1.0          255.255.255.0    0.0.0.0          UCI      1   MANUAL   1832038    570d45540000000a
192.168.10.0     255.255.255.248  0.0.0.0          UCI      1   MANUAL   2701981    570d455400000002

ハイパーバイザからは、NSX コントローラクラスタと、NSX Manager にコネクションを張り、情報のアップデートを行います。NSX コントローラクラスタへのコネクションはハイパーバイザ内の UWA (User World Agent) netcpa (TCP/1234) を介して確立し、NSX Manager へのコネクションは UWA vsfwd (TCP/5671) を介して確立します。

Image may be NSFW.
Clik here to view.

ハイパーバイザと NSX コンポーネント間のコネクション

コントローラクラスタとの接続確認

# esxcli network ip connection list | grep 1234
Proto   Local Address           Foreign Address State           World Name
-----   --------------------    --------------------    -----------     ----------
tcp     192.168.210.51:59453    192.168.110.201:1234    ESTABLISHED     netcpa-worker
tcp     192.168.210.51:61471    192.168.110.202:1234    ESTABLISHED     netcpa-worker
tcp     192.168.210.51:61397    192.168.110.203:1234    ESTABLISHED     netcpa-worker

上記出力より、ESXi ホストの管理用 IP アドレスから3台のコントローラ（192.168.110.201,192.168.110.202,192.168.110.203）に、netcpa を介して接続していることが確認できます。コントローラとの間で各種テーブル情報の交換を行います。

NSX Manager との接続確認

# esxcli network ip connection list | grep 5671
Proto   Local Address           Foreign Address         State           World Name
-----   --------------------    --------------------    -----------     ----------
tcp     192.168.210.51:23251    192.168.110.42:5671     ESTABLISHED     vsfwd

上記出力より、ESXi ホストの管理用IP アドレスから NSX Manager に、vsfwd を介して接続していることが確認できます。NSX Manager からはコントローラのIP アドレス情報を取得します。

なお、論理ルータコントロールVM をホストしているESXi は、VMCI （Virtual Machine Communication Interface） と呼ばれる仮想マシン-ハイパーバイザ間専用のパスを使用し、ルーティング情報を論理ルータコントロールVM から取得、ESXi が取得した情報をコントローラに netcpa 経由で通知します。コントロールプレーンの通信に論理ルータコントロールVM の管理インターフェイスは使用しません。

Image may be NSFW.
Clik here to view.

ルーティング情報の取得と配布

・NSX Edge （データプレーン）

仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能（ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等）を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。外部ネットワーク機器として論理ルータコントロールVM とダイナミックルーティングプロトコルを使用しルーティング情報を交換する場合がありますが、論理ルータの提供する分散ルーティングの機能そのものには直接関与しません。

■コラム

新卒から見たネットワーク仮想化

当初ネットワーク仮想化と聞いて非常に難しそうに感じました。サーバ仮想化もまだ勉強中であり、ネットワークについてはさらに知っていることが少ない状態です。しかしながら、いざ勉強を進めていくと、中心となる L2、L3 の通信はテーブルを参照してパケットが流れていくという点では物理環境とほとんど変わりませんでした。実際、物理ネットワークと比較して抑えていくことで、ネットワーク仮想化が物理ネットワークの再現であり、仮想マシンや流れるパケットからすれば同様に動作できる環境が作られていることがわかってきました。NSX には Manager やコントローラ、論理ルータコントロールVM など複数のコンポーネントがありますが、それぞれの持つ役割を把握することで、スムーズに理解していけるように感じます。皆様もぜひご一緒にネットワーク仮想化を学んでいきましょう。

■関連リンク

今回ご紹介した内容をオンラインのハンズオン環境上で確認することができます。コマンドラインの出力はハンズオン環境をベースに作成しています。

http://labs.hol.vmware.com/HOL/

VMware HOL Online

HOL-SDC-1403 - VMware NSX Introduction

NSX の機能全般及び、ネットワーク仮想化環境の設計に興味のあるかたは下記テックペーパーを参照ください。

http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide

ネットワーク仮想化をネットワークの基本から理解する

第1回：理解するために必要なことを整理する

第2回：論理スイッチ（VXLAN）–Layer2 の世界

第3回：分散ルーティング –Layer3 の世界（本稿）

第4回：分散ファイアウォール -Layer4 の世界

昨年のVMworld 2014で発表した、VMware 初のHyper Converged Infrastructure Appliance (HCIA) EVO:RAIL 。発表から約10ヶ月が経ち、日本でも多くのお客様に、ご興味を持っていただくようになりました。また、お寄せいただいた様々なお客様の声を踏まえ、EVO:RAIL 自体も機能拡張を行い、進化してきました。この記事では今一度EVO:RAIL の特徴をお伝えするとともに、EVO:RAIL 発表から現在までのアップデートをまとめて紹介したいと思います。

ところで、EVO:RAIL 等のConverged Infrastructure は、なぜ今注目されているのでしょうか？ 読者のみなさまの中には、企業のIT部門でITインフラを担当されている方も多いかと思いますが、限られたIT予算の下、管理者不足、遠隔地の管理者不在などで、できるだけサーバーやストレージなどIT インフラのコストを削減し、運用管理を簡単したいと思われている方も多いのではないでしょうか？　また、今まで以上にシステムの構築にかけられる時間を短縮する必要性に直面されていませんか？　これらは、まさにEVO:RAIL が解決できる課題です。　こちらに、Converged Infrastructure を選択した場合のベネフィットについて、お客様の声が紹介されています。上位から３つ取り上げると、以下のようになります。

1. プロビジョニング時間の短縮
2. サービス、サポートの向上
3. 管理が容易

Converged Infrastructure を選択いただくことにより、このようなベネフィットを享受いただくことはできますが、EVO:RAIL はこれらをさらに高いレベルで提供できます。たとえば、初期構築作業は電源を投入してからたった15分間で完了し、すぐに仮想環境をご利用いただく事ができるようになります。仮想スイッチや、ストレージの設定、vCenter Server のインストール等、通常仮想環境を構築する際に必要な作業も、お客様は初期段階で、いくつかの必要なパラメータを入力いただければ、後は全自動でEVO:RAIL エンジンが最適なvSphere 環境を構築してくれます。これは時間短縮だけではなく、仮想環境構築の手間を大幅に削減できるとともに、あまりノウハウをお持ちでない方でも簡単に環境構築ができるようになります。

EVO:RAIL は複数のEVO:RAIL 認定パートナー様から提供されますが、サポートに関しても提供元の認定パートナー様からハード、ソフト一括して提供されます。障害原因がどこにあるかわからないような複雑なケースでも、コンポーネントごとに、複数の問い合わせ窓口とやり取りする必要は無く、仮想環境からハードウェアまで、一本の窓口で解決するまで対応できます。障害の切り分け作業などやっかいな事柄も、お客様は気にしていただく必要はありません。  また、運用管理は仮想環境からハードウェアまで、EVO:RAIL エンジンが用意するシンプルなUIから行う事ができるため、日々の運用管理も容易になります。

ご紹介しましたように、EVO:RAIL は、構築時間を短縮し、日々の運用管理を容易にし、サポートレベルの向上させるというベネフィットを高いレベルで提供できます。実際いままでに、EVO:RAIL をご採用いただいた、またはご検討いただいているお客様の多くは、TCO削減とともに、これらのポイントに課題をお持ちの方が多いようです。こういった課題を感じていらっしゃるお客様は、是非一度EVO:RAIL をご検討いただければと思います。

では、主なアップデートをご紹介します。

EVO:RAIL 機能拡張、ライセンスアップデート

• vSphere Loyalty Program の開始
EVO:RAIL をご検討いただいている多くのお客様から、既にお持ちのvSphere ライセンスをEVO:RAIL で利用したいという声を頂きました。この度、既にvSphere のライセンスをお持ちのお客様は、そのライセンスをEVO:RAIL でご利用いただける購入方法の提供を開始しました。お持ちのvSphere Enterprise Plus のライセンス８本を、新規購入するEVO:RAIL でご利用いただくことができ、EVO:RAIL はその分お安く購入いただけます。本家の紹介blogはこちらです。

Image may be NSFW.
Clik here to view.

•  最大８アプライアンスまで拡張可能
当初4アプライアンス、16ノードまで同一クラスター、同一vCenter Server 下に配置する事ができましたが、ソフトウェアアップデートにより、最大8アプライアンス、32ノードまで拡張可能になりました。多くのユースケースにおいては充分大規模な構成を組む事ができるようになりました。

• 異なるCPUタイプのアプライアンスを同一のクラスターに配置可能
Intel Ivy Bridge CPUを搭載するアプライアンスと、Haswell CPUを搭載するアプライアンスが同じクラスターに共存できるようになりました。

• 簡単なノード交換の手順
障害などでノードを交換する際の手順が簡単になります。どれくらい簡単か、一度ご体験いただく事をお勧めします。後述のEVO:RAIL ハンズオンラボでご体験いただけます。

EVO:RAIL ハンズオンラボ

ところで、EVO:RAIL を実際に試してみたい、どれくらい簡単に操作できるか体感してみたいと感じでいる方も多いと思います。EVO:RAIL の実物を試していただく事が一番良いのですが、より手軽にEVO:RAIL の操作をVMware がオンラインで提供する、ハンズオンラボで体験していただく事ができます。こちらをご利用いただくと、アプライアンスの初期導入だけではなく、アプライアンスの追加、ノード交換も試していただく事ができるようになっています。さらに、このハンズオンラボは実際のEVO:RAIL エンジンが動作していますので、ハンズオンラボのラボガイドに載っていない事でも、ハードウェアに依存しない事に関しては手軽に試していただく事が可能です。ご興味のある方は、是非ご利用ください。ドキュメントは既に日本語翻訳済みですし、UIもラボ内のブラウザーの設定を日本語に設定するか、EVO:RAIL のUIで日本語設定にする事により、日本語表示可能になります。ハンズオンラボは http://labs.hol.vmware.com/HOL/catalogs/　こちらからログインいただき、HOL-SDC-1428 Introduction to EVO:RAIL を選択ください。もしくは、http://labs.hol.vmware.com/HOL/catalogs/lab/1724　をアクセスする事により、EVO:RAIL のラボに直接接続できます。ハンズオンラボの実施手順はこちらから参照できます。

EVO:RAIL Day Osaka 6月18日開催

最後にEVO:RAIL に特化したイベントをご紹介します。来る6月18日に、大阪で国内2度目となるEVO:RAIL Dayを開催します。国内で展開するEVO:RAIL 認定パートナー様とともに、EVO:RAIL の最新情報、事例、各認定パートナー様のEVO:RAIL のご紹介やデモンストレーションなどをご覧頂けますので、お近くの方は是非お越し下さい。お申し込み、イベントの詳細はこちらからどうぞ。

本日、EVO:RAIL の特徴と現状のアップデートを簡単にご紹介いたしましたが、さらに詳細のご紹介も当blogで行っていく予定です。またEVO:RAIL は引き続きさまざまなエンハンスを予定しておりますので、是非ご期待ください。

はじめに

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

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

Image may be NSFW.
Clik here to view.

確認している問題

　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/

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

みなさま、こんにちは。
NEC iStorage により、国内最速でVMware vSphere Virtual Volumesにご対応頂きました。今回は、Virtual VolumesとiStorageによる対応機能及びメリットについて  日本電気株式会社  ＩＴプラットフォーム事業部  猪鹿倉 知広様  にご執筆頂きましたので御紹介させて頂きます。

VMware vSphere Virtual Volumesで変わる仮想化環境

＜ はじめに ＞

現在の仮想化環境が抱えるさまざまな問題を解決する、画期的な技術として注目されているVMware vSphere Virtual Volumes(以下、Virtual Volumes)。
2015年2月3日にVMware vSphere 6.0の新機能として正式発表され、仮想マシンとサーバ・ストレージのより緊密な連携によるパフォーマンス上昇、効率的な運用の実現が期待されています。NECはVMwareのパートナーとして、Virtual Volumesの実装に向けて早期から協調し、対応ストレージをいち早くお届けすることができました。

Virtual Volumesの概念自体は非常にシンプルです。仮想マシンが使用するデータ領域を、新たな共通単位『仮想ボリューム（VVOL）』として、ストレージ側とサーバ側で共通認識させようという試みです。

仮想マシンとVVOLが1対1の対応になるので、サービスレベルに従い、ポリシーを選択して仮想マシンが利用するストレージを決めることができます。さらに、ストレージ製品で提供している多様な機能が仮想マシン単位で利用可能になることで、簡単運用が実現されます。

今回の記事では、Virtual VolumesとNEC iStorageによって実現するソリューションを簡単にご紹介します。

＜ Virtual Volumesを利用している環境でのNEC iStorageソリューション ＞

NEC ストレージ iStorage Mシリーズ ではVirtual VolumesとしてVMwareが提唱する機能だけでなく、Virtual Volumesを利用している環境をより効果的に利用するためのソリューションを準備しております。“NECならでは”と言えるVirtual Volumes連携機能の一部をご紹介いたします。

Image may be NSFW.
Clik here to view.

ストレージポリシーによる仮想マシンの簡単運用

Virtual Volumesを利用している環境におけるストレージが、仮想マシンごとに設けられた仮想ボリューム（VVOL）を個別に認識できることにより、仮想マシン単位で仮想ボリュームの運用・管理を行うことができます。サーバ管理者は新規仮想マシンを作成する際に、『ストレージポリシー』を選択するだけで、簡単にVVOLを生成することができます。このストレージポリシーとは、「GOLD」、「SILVER」などの名称で、ストレージの性能、重要度、各種機能の使用有無などの情報を設定し、あらかじめ数種類用意しておくテンプレートです。

Image may be NSFW.
Clik here to view.

この、「GOLD」や「SILVER」などのストレージポリシーとして、ストレージの持つ様々なVirtual Volumes連携機能を紐付けることができます。

1)    仮想マシン単位での「I/O流量制御」機能　　　iStorage IO Load Manager

サーバ仮想化、ストレージ仮想化を進めていくことにより、１つのストレージに複数の仮想マシンがアクセスすることになります。このような環境において、高負荷をかけた仮想マシンの影響で、重要度の高い業務レベルの仮想マシンの処理を滞らせるようなことを防ぐために、一定以上の性能を担保する機能が「I/O流量制御機能」です。一般的なI/O流量制御は、I/O流量の“上限値”を設定します。そして上限以上の負荷がかけられた場合に、その過剰負荷をかけた仮想マシンのI/O流量を制限することで、他の仮想マシンへの影響が出ないようにします。さらにNECのI/O流量制御では、“下限値”を設定することができます。重要度の高い仮想マシンのI/O流量が一定値以下にならないように、他のマシンのI/O流量を制御し、重要度の高いマシンの性能を担保します。こうしてシステム全体を安定稼働させるために、重要度に応じた、より一層きめ細かい対応を採ることができます。

Image may be NSFW.
Clik here to view.

2)   仮想マシン単位でデータの自動最適配置　　iStorage PerforOptimizer

ストレージは、SSD、SAS HDD、ニアラインSAS HDDなどのように、いくつかの性能の異なる物理ディスクから構成されています。頻繁にアクセスされるデータと、まれにアクセスされるデータが、同じ高性能･高価格のデバイスに格納されていては非効率です。そこで、アクセス頻度に応じてデータを最適なディスク領域に自動配置するのが、「データ自動最適配置」機能です。各データファイルは、単純なアクセス回数だけでなく、転送量やアプリケーション特有のアクセスパターン（ランダム/シーケンシャル、リード/ライト）を時間単位で分析し、NEC独自のアルゴリズムにより自動的に再配置される仕組みです。ここにもNECならではのノウハウが生かされています。

Image may be NSFW.
Clik here to view.

I/O流量制御機能の上限値／下限値や自動最適配置の物理ディスクの容量比を、「GOLD」や「SILVER」などのストレージポリシーとしてあらかじめ登録しておくことができます。VVOL領域作成時には、お客様はストレージポリシーを選択するだけで、同一のストレージプールから用途に応じた最適なデータ領域を割り当てることができます。そして、お客様は特に意識しなくても、ストレージ性能の最大化の追求と、ストレージコストの最適化が、自動的に実現できるのです。

バックアップ/リストア機能の活用

1)   DirectDataShadow（DDS）

DDSは、iStorage HSシリーズとiStorage Mシリーズを直接接続し、サーバレスでの多世代バックアップを可能にする技術です。

仮想化環境では高速なバックアップが求められるうえ、多世代のバックアップを保存しておく必要もあります。それには、iStorage HSシリーズのように、バックアップに特化した安価・大容量のストレージを活用することが効果的です。しかし、通常のバックアップシステム構成では、バックアップサーバとバックアップソフトが必要なため、その導入／運用コストがかかってしまいます。このDDSソリューションではそれを解決するため、バックアップサーバ／ソフト不要のシンプルな構成でのバックアップ環境を実現しました。データ圧縮のための重複削除機能も備えており、クローン作成時などではバックアップ容量を削減できるほか、差分バックアップも可能です。バックアップ用のiStorage HSシリーズは、近接地にも遠隔地にも設置可能なので、低価格で簡便に災害対策用のバックアップシステムを構築できるうえ、運用管理コスト、通信コストを削減することができます。

Image may be NSFW.
Clik here to view.

もっと詳しくという方は

詳しくはNECのサイトでホワイトペーパーを公開しておりますので、こちらにも是非お越しください。
http://jpn.nec.com/istorage/whitepaper/index.html

NECの仮想化への取り組み

最後に、NECの仮想化への取り組みをご紹介します。
Image may be NSFW.
Clik here to view.
NECは、2002年より他社に先駆けて業界最大手であるVMwareとパートナーシップを結び、仮想化に最適なPCサーバ製品Express5800シリーズやストレージ製品iStorage Mシリーズなどの製品・ソリューション開発をしてきました。世界で最も広く導入されているサーバ仮想化ソフトウェアVMware vSphereとの親和性を高める連携機能開発にも注力し、2009年以降、Storage Replication Adapter、VMware vSphere APIs-Array Integration機能などを提供しております。今回リリースされたVMware vSphere 6.0での新機能Virtual Volumesも、開発中のβ（ベータ）版より先行評価を開始^※1し、VMware社のVMware vSphere 6.0リリースに併せて対応ストレージとして認証を取得しました。^※2

※1. vSphere Virtual Volumesのβ認証テストを取得した企業は、グローバルでNECを含めた6社のみ。
※2. 2015年3月12日、NECは国内最速でVMware vSphere Virtual Volumes認証を取得。

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

前回はトラブル発生時に役に立つリソースを紹介しました。
今回はサポートリクエスト（SR）と、調査に必要な情報採取についてお話していきます。

第１回　トラブル発生時に役立つ 4 つのリソース
第２回　サポートリクエスト（SR）と情報採取　←This Post
第３回　応用編

VMware vSphereは、単なるサーバー仮想化ソフトではありません。
仮想化環境の包括的な管理・運用に対応した仮想化基盤であり、いわば仮想的なデータセンターです。
ストレージ、ネットワーク、ハードウェア、OS…　全てと関わりがありますのでトラブルシューティングが難しく感じるかもしれません。
しかし、状況をすばやく切り分け・整理して、必要な情報を揃えることができれば、調査はスムーズに進みます。
今回はそのために押さえていただきたいポイントをお話します。

まず「どのような事象を問題だと考えているのか」をサポートエンジニアに伝える必要があります。
これが基本にしてとても難しい…のですが、いくつかのポイントを意識するだけでぐっとわかりやすい説明になります。

例えば以下の説明、とてもぼんやりしていますね。
私がこのSRを担当するとしたら、調査にとりかかる前にかなりのヒアリングが必要だと感じます。

これをもう少しわかりやすく、状況が伝わりやすい説明に変えてみたいと思います。
サポートリクエスト発行ガイドという資料の中でテンプレートの使用をおすすめしておりますので、これも活用します。

VMware サポートリクエスト発行ガイド
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/support-SR_guide.pdf

※ポイント1
「サーバ」だと ESXi なのか vCenter Server なのか仮想マシンなのかはっきりしませんね。
仮想マシン名も特定できているので具体的に明記しました。

※ポイント2
どのような事象を「ハング」だと言っているのか、どのように確認したのかを説明しました。
今回の場合は「 RDP している時に画面が動かなくなった」ということと「監視ツールからの ping に応答が無かった」ということを「ハング」だと言っています。

※ポイント3
事象が発生している対象と、発生していない対象の違いについてわかることを説明しました。
この情報だけで「GuestOS 依存の問題ではなさそう」「ESXi-データストア間の接続に問題がありそう」ということが推測できます。

※ポイント4
詳細はわからないながらも、トリガーと考えられる情報を共有しました。
データストアが NFS や iSCSI 接続のストレージで構成されていればこのメンテナンスの影響があるかもしれませんね。

※ポイント5
現在の状況を説明しました。
何をしたら直ったのかという情報が、問題箇所を絞り込むヒントになることがあります。
今回は何もしなくても復旧したので「設定や構成の問題というよりは一時的な問題ではないか」ということが推測できますね。

---

いかがでしょうか。
元々の説明よりも、調査のヒントになる情報が増えたと思います。
文章だと書きづらいという場合は箇条書きでもかまいませんので、なるべくポイントを押さえて整理してみて下さい。

・事象の概要
・事象をどのように確認したか
・事象が発生/復旧したタイミング、事象発生のトリガー
・事象が発生している対象と発生していない対象の違い
・ESXi名、仮想マシン名など
・時系列や作業手順

時系列や作業手順については、説明に加えて時間の見えるスクリーンショットも送付いただけると、とてもわかりやすくて助かります。

事象を整理することができたら、調査に必要なログを採取します。
情報採取を依頼されてからログを取得したらすでにローテートされていた…ということもありますので、なるべく早めに取得しておくことをおすすめします。
vSphereのトラブルでは基本的に以下のログを取得していただいています。

・ESXiのログバンドル（vmsupport）
・vCenter Server のログバンドル（vcsupport）
・vCenter Serverのイベントログ

色々な採取方法があるのですが、今回は以下の方法について説明します。
ログをエクスポートし、操作している端末のデスクトップに持ってくることがゴールです。

・ESXi、vCenter Serverのログバンドルの採取方法（Web Client経由）
・vCenter Serverのイベントログの採取方法（Web Client経由）
・ESXiのログバンドルの採取方法（SSHクライアント経由）

vCenter Server にログインします。

Image may be NSFW.
Clik here to view.

ホーム画面から [vCenter Server] を選択します。
[vCenter Serverホーム] 画面に遷移します。

Image may be NSFW.
Clik here to view.

[インベントリリスト] から [vCenter Server] を選択します。

Image may be NSFW.
Clik here to view.

[該当のvCenter Server] を選択します。
今回は vc55.mylab.local というvCenter Server からログを取得します。

Image may be NSFW.
Clik here to view.

[該当のvCenter Server] 画面に遷移したら、[監視]タブ – [システムログ] を選択し、[システムログのエクスポート] を押下して下さい。
ここからログバンドルをエクスポートすることができます。

Image may be NSFW.
Clik here to view.

[ログのエクスポート] 画面がポップアップされます。
[フィルタ] タブにはこのvCenter Server が管理しているESXiが表示されますのでログが必要なESXiにチェックを入れて下さい。
今回は、vCenter Server、このvCenter Serverが管理しているの192.168.1.3というESXi、Web Clientのログを取得する設定になっています。
チェックができたら [次へ]　で先に進みます。

Image may be NSFW.
Clik here to view.

[ログバンドルの生成] を選択します。

Image may be NSFW.
Clik here to view.

生成中…少し待ちます。

Image may be NSFW.
Clik here to view.

ログが生成されました。
[ログバンドルのダウンロード] を選択して端末にダウンロードします。

Image may be NSFW.
Clik here to view.

あとはブラウザで、お好きな場所に保存すれば完了です。
今回はデスクトップに置くことにします。

Image may be NSFW.
Clik here to view.

できました！

Image may be NSFW.
Clik here to view.

続けてイベントログを取得してみます。
ログバンドルを取得した [該当のvCenter Server]画面 - [監視]タブで、今度は [イベント] を選択します。
[ホーム]画面 – [イベントコンソール] からでも同じことができます。
画面右下のマークを押下して下さい。

Image may be NSFW.
Clik here to view.

[イベントのエクスポート]画面がポップアップします。
[タイプ：] は [システム] に設定していますが、同じ手順で [ユーザー] でも取得して下さいね。
[開始時間] [終了時間] は事象が発生した時間帯を含まれるように設定します。
[CSVレポートの生成] を押下します。

Image may be NSFW.
Clik here to view.

生成できました。
[保存] で先に進みます。

Image may be NSFW.
Clik here to view.

あとはブラウザで、お好きな場所に保存しましょう。

Image may be NSFW.
Clik here to view.

できました！

Image may be NSFW.
Clik here to view.

ESXiに直接ログインしてESXiのログバンドルを取得する方法を説明します。
ESXiのログだけ取得したい時や、vCenter Serverから管理できない状態になっている時などはこの方法がよいと思います。

今回はESXiにSSHでログインしてログを取得します。

ESXiにSSHで接続しログインし、vm-supportコマンドを実行します。

Image may be NSFW.
Clik here to view.

ログバンドルの生成が完了しました。

Image may be NSFW.
Clik here to view.

var/tmp 以下にファイルが作成されています。

Image may be NSFW.
Clik here to view.

今回はSSHクライアントのSCP機能を使用して端末のデスクトップに送りました。
完了です！

Image may be NSFW.
Clik here to view.

「1.事象の伝え方」の内容と重複しますがログと一緒に必ず送っていただきたいのが、「ログを調査するための情報」です。
「ログがあれば何でもわかるでしょ！」と思われるかもしれませんが、vSphereのログは膨大ですのでこれを全て精査するのは人間には難しい作業です。
時間帯やコンポーネントを絞って確認する必要がありますので、是非ご協力をお願いします。

・作業手順（文章による説明やスクリーンショットで）
・時刻、時系列（文章による説明やスクリーンショットで）
・事象が発生しているESXiや仮想マシンの名前

■参考になるKB

* VMware KB: Collecting diagnostic information for VMware vCenter Server 4.x, 5.x and 6.0 (1011641)
http://kb.vmware.com/kb/1011641
vCenter Serverのログの取得方法がまとめられています。

* VMware KB: Collecting diagnostic information for ESX/ESXi hosts and vCenter Server using the vSphere Web Client (2032892)
http://kb.vmware.com/kb/2032892
Web Clientを使用してログを取得する方法が説明されています。

* Collecting diagnostic information using the vm-support command in VMware ESX/ESXi (1010705)
http://kb.vmware.com/kb/1010705
ESXiからコマンドでログを取得する方法が説明されています。

---

長くなりましたが、ひとつひとつの作業はそれほど難しくないと感じていただけたのではないかと思います。
ここまできちんと揃えていただければ、スムーズに調査が進むはずですので、お問い合わせの際ご活用下さい。

弊社サポートセンターへはMyVMwareからお問い合わせいただけます。

MyVMware
https://my.vmware.com/web/vmware/login

SRの発行方法やデータのアップロード方法については、以下のガイドが公開されております。

VMware サポートリクエスト発行ガイド
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/support-SR_guide.pdf

「なるべく早く、正確に、問題を解決したい」という気持ちは、お客様もサポートエンジニアも同じです。
うまくコミュニケーションを取って問題を解決しましょう！

第１回　トラブル発生時に役立つ 4 つのリソース
第２回　サポートリクエスト（SR）と情報採取
第３回　応用編

第１回ではトラブル発生時に確認しておきたい情報と、確認の方法についてお話しました。
お客様自身で解決できる問題もあったかと思いますし、解決まではたどりつけなくても問題がどこにあるのかの切り分けや状況の整理ができたかと思います。
第２回、今回はお問い合わせいただくときに意識していただきたいポイントや情報採取についてお話しました。
ここまでで、トラブル発生～お客様自身でのトラブルシューティング～お問い合わせ の基本的な流れをイメージしていただけましたでしょうか。
次回は具体例を上げながら、実際問題が発生した時にはまりやすいポイントについてお話します。

「ネットワーク仮想化」をセールスやマーケティングではなく、エンジニアとしてアーキテクチャを正しく理解することが、今回のブログシリーズ「ネットワーク仮想化をネットワークの基本から理解する」のテーマです。最終回「第4回：分散ファイアウォール -Layer4 の世界」では、ネットワーク仮想化環境でのセキュリティを見ていきます。

■ 目次
・はじめに
・物理ネットワーク環境におけるセキュリティ
・ネットワーク仮想化環境におけるセキュリティ
・物理ネットワーク環境とネットワーク仮想化環境の比較
・補足情報

■ はじめに
仮想化環境でのセキュリティを検討するとき、適用するポイントには、仮想マシン、ハイパーバイザ、物理ネットワークと3つのポイントが考えられます。この中で管理性とセキュリティの粒度を考えたとき、最も適したポイントはどこになるでしょうか。

Image may be NSFW.
Clik here to view.

一般的に、よりサービスに近い方が粒度の細かいセキュリティポリシーの適用が可能になります。仮想マシンは最もサービスに近いポイントとなりますが、個々の仮想マシンにセキュリティを適用していくのは運用管理上のオーバヘッドが大きいことに加え、ゲストOSが乗っ取られた場合はセキュリティ機能そのものを停止されてしまう可能性があります。

一方で物理ネットワークではどうでしょうか。物理ネットワークでのセキュリティは、L2 のネットワークセグメント境界を通るトラフィックにかけることになります。この方式では、セキュリティの適用ポイントが仮想マシンから離れることで、同一L2 ネットワークセグメント内における仮想マシン間の通信制御は困難です。

パイパーバイザでセキュリティを適用することで、従来のL2 ネットワークセグメント境界にとらわれない柔軟なセキュリティの実装が可能になります。しかしながら個々のハイパーバイザにセキュリティを適用することで運用管理上のオーバヘッドが大きくなってしまっては意味がありません。

VMware NSX の提供する分散ファイアウォール（FW）は、ハイパーバイザ上でセキュリティを提供します。分散FW の設定はNSX Manager から行うことができます。従来のFW と同じように送信元、宛先、サービスと、アクションを指定することができます。各項目は、vCenter のオブジェクト単位（仮想マシン、クラスタ、リソースプール等）で指定することが可能で、従来のIPアドレス単位の管理と比べた際に運用管理の負担を大きく軽減することができます。

Image may be NSFW.
Clik here to view.

また、GUIからだけではなくAPIを介した設定が可能となり、クラウドマネジメントプラットフォームと連携させることで設定作業そのものの自動化が可能になります。例えば、仮想マシンを展開すると同時にセキュリティポリシーを適用するといった運用が可能になります。

分散FW は、第2回の論理スイッチ（VXLAN）、第3回の分散ルーティングと同様にハイパーバイザを活用することで、仮想化環境に最適なセキュリティを提供します。前回と同様に、物理の世界との比較を「テーブル」の観点から見ていきたいと思います。

■ 物理ネットワーク環境におけるセキュリティ
物理ネットワーク環境でのセキュリティは、FW やL3スイッチ（ルータ） といった物理ネットワーク機器に実装します。FW は外部ネットワークとの境界に設置され、フィルタリングのルールを記載したフィルタリングテーブルを持っています。また、L3スイッチやルータの セキュリティ機能として、ACL（Access Control List）があります。

Image may be NSFW.
Clik here to view.

L3スイッチでは、専用のコマンドラインからACL の設定を行い、設定の確認もコマンドラインから実施します。例えばL3スイッチのACL を確認するには、以下のコマンドを実施します。

# show access-list
 permit ip	host “送信元IPアドレス”	host “宛先IPアドレス”
 permit tcp	host “送信元IPアドレス”	host “宛先IPアドレス”	eq “ポート番号”
 permit udp	host “送信元IPアドレス”	“宛先ネットワークアドレス”	eq “ポート番号”
 permit icmp 	any any

出力から送信元、送信先のアドレス、及びプロトコルタイプを指定したテーブルを確認できます。このフィルタリングテーブルにより、L3 スイッチを経由するトラフィックに対してセキュリティをかけることが可能になります。ACL はステート情報を管理しない、ステートレスなセキュリティ機能となるため、フィルタリング情報は双方向の通信に対して明記します。

一方、FW の提供するステートフルなセキュリティ機能では、フィルタリングテーブルとは別に、通信のフロー情報を管理するためのステートテーブルを持ちます。通信が発生した際にステートテーブルがダイナミックに作成されます。

例えばTCP ステートテーブルでは、送信元IPアドレス、ポート番号、宛先IPアドレス、ポート番号、TCPステート情報、タイムアウト値等が含まれます。この情報を基に、対応する戻り方向の通信を自動的に許可し、適合しない不正な通信をブロックすることができます。

フィルタリング及びステート管理の考え方 はネットワーク仮想化環境になっても変わりませんが、ネットワーク仮想化環境では物理ネットワーク機器の持つセキュリティ機能を、分散FW としてハイパーバイザに実装することができます。分散FW のアーキテクチャについて、「テーブル」に注目する形でこの後見ていきます。

■ ネットワーク仮想化環境におけるセキュリティ
分散FW は、L2 - L4レベルのステートフルなFW 機能をハイパーバイザで提供します。個々のハイパーバイザ内でセキュリティ機能を提供することで、処理を分散して行うことのできるスケールアウト型のアーキテクチャになります。

Image may be NSFW.
Clik here to view.

分散FW も、従来の物理環境のセキュリティ製品と同様に内部にフィルタリングテーブル（ルールテーブル）を持っています。フィルタは、仮想マシンの仮想NICとハイパーバイザの間にあるdvfilterと呼ばれるポイントに適用されます。これにより、L2 ネットワーク境界にとらわれない粒度の細かいセキュリティの実装（マイクロセグメンテーション）が可能になります。

Image may be NSFW.
Clik here to view.

ハイパーバイザ上で、dvfilterに適用されているフィルタリングテーブルを確認することが出来ます。ESXi ホストにログインし、仮想マシン（web-sv-01a）に適用されているフィルタリング情報を確認します。

# summarize-dvfilter

# summarize-dvfilter
world 145244 vmm0:web-sv-01a vcUuid:'50 26 c7 cd b6 f3 f4 bc-e5 33 3d 4b 25 5c 62 77'
 port 50331662 web-sv-01a.eth0
  vNic slot 2
   name: nic-145244-eth0-vmware-sfw.2
   agentName: vmware-sfw
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  vNic slot 1
   name: nic-145244-eth0-dvfilter-generic-vmware-swsec.1
   agentName: dvfilter-generic-vmware-swsec
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Alternate Opaque Channel

上記出力から、仮想マシン（web-sv-01a）に対応したフィルタ（nic-145244-eth0-vmware-sfw.2）を確認し、仮想マシンに適用されているフィルタリングテーブル（ルールテーブル）を下記コマンドで確認します。

# vsipioctl getrules -f フィルタ名

# vsipioctl getrules -f nic-145244-eth0-vmware-sfw.2
ruleset domain-c25 {
  # Filter rules
  rule 1006 at 1 inout protocol tcp from addrset ip-vm-33 to addrset ip-vm-36 port 22 accept with log;
  rule 1005 at 2 inout protocol any from any to addrset ip-ipset-2 accept;
  rule 1004 at 3 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1004 at 4 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1003 at 5 inout protocol udp from any to any port 67 accept;
  rule 1003 at 6 inout protocol udp from any to any port 68 accept;
  rule 1002 at 7 inout protocol any from any to any reject with log;
}

ruleset domain-c25_L2 {
  # Filter rules
  rule 1001 at 1 inout ethertype any from any to any accept;
}

分散FW は、vCenter のオブジェクト単位（仮想マシン、クラスタ、リソースプール等）で設定することができます。オブジェクトに含まれる仮想マシンは、仮想マシンにインストールされたVMware Tools によりIP アドレスに変換して適用されます。オブジェクトとIPアドレスの対応は下記で確認ができます。なお、オブジェクト名（ip-vm-33 等）はvCenter のMoRef（Managed Object Reference）に対応しています。

# vsipioctl getaddrsets -f フィルタ名

# vsipioctl getaddrsets -f nic-145244-eth0-vmware-sfw.2
addrset ip-ipset-2 {
ip 192.168.110.10,
}
addrset ip-vm-33 {
ip 172.16.10.12,
}
addrset ip-vm-36 {
ip 172.16.10.11,
}

また、分散FW はフロー情報を管理するステートフルなファイアウォール機能を提供します。ステート情報は、ステートテーブル（コネクショントラッカーテーブル）で管理されています。コネクショントラッカーテーブルを表示させる際はFlow Monitoring を有効にします。下記の例では、SSHを許可するルールに対応したステート情報が管理されていることが分かります。

# vsipioctl getflows -f フィルタ名

# vsipioctl getflows -f nic-145244-eth0-vmware-sfw.2
Count retrieved from kernel active(L3,L4)=3, active(L2)+inactive(L3,L4)=0, drop(L2,L3,L4)=0
558a796d00000000 Active tcp 0800 1 1006 0 0  172.16.10.12:Unknown(44194) 172.16.10.11:ssh(22) 2413 EST 3017 2957 19 18

テーブル情報は、仮想マシンがvMotion で異なるESXi ホスト上に移動した際も仮想マシンに追従して適用されます。これによりvMotion 後もサービスを継続することが可能です。

■ 物理ネットワーク環境とネットワーク仮想化環境の比較
物理ネットワーク環境では、フィルタリングテーブルは物理ネットワーク機器が持ち、単一のポイントでフィルタリングの処理を実施します（集中処理）。また、複数のポイントでセキュリティを適用するような構成では、個々の物理ネットワーク機器に対して設定作業を行うことになります（分散管理）。

Image may be NSFW.
Clik here to view.

分散FW は仮想化環境のセキュリティを、適切なポイントで、運用管理性を損なわずに実現しています。各テーブルの情報を確認してみると、従来の物理ネットワーク環境で物理ネットワーク機器が持っているのと同等の情報をハイパーバイザの中で管理していることが分かります。

ポイント1 ハイパーバイザでテーブル情報を持つことで、ネットワークセグメント境界にとらわれない粒度の細かいセキュリティを実装できる（マイクロセグメンテーションの実装）

また、サーバが増えるのに比例して処理するポイントも増えるスケールアウト型のアーキテクチャになります。

ポイント2 ホストの増加に比例して処理するポイントが増える、拡張性のあるスケールアウト型のアーキテクチャを取ることができる（データプレーンにおける分散処理）

分散FW 環境のセットアップは、NSX Manager を介して、GUI もしくはAPI 経由で簡単に行うことが出来ます。

ポイント3 NSX Manager から一括して設定管理を行うことで、運用管理性を損なうことなく容易に実装できる（マネジメントプレーンにおける集中管理）

ネットワーク仮想化環境における分散FW は、分散処理、集中管理のアプローチをとることで、運用管理性を維持しつつ、ネットワークセグメント境界にとらわれない粒度の細かいセキュリティ（マイクロセグメンテーション）を実装することを可能にしています。

ネットワークサービスは、トラフィックのフローと、フローを制御する「テーブル」から成り立ちます。この「テーブル」にフォーカスして見ていくと、物理ネットワーク環境で管理していたテーブルと同じ情報が、ネットワーク仮想化環境では異なるレイヤー（ハイパーバイザ）で管理されていることが分かります。ハイパーバイザを活用するアプローチは、今までの物理ネットワーク環境でユーザが得られなかった利便性を提供することを可能にします。

シリーズを通して、「ネットワーク仮想化」は既存のテクノロジーと断絶したものではなく、従来の仮想化及びネットワークテクノロジーの延長線上にあることを説明してきました。「ネットワークエンジニア」も「仮想化エンジニア」も、それぞれのバックグラウンドを活かしつつ、「ネットワーク仮想化」を通して新しい分野のスキルを身につけることができます。従来の役割分担にとらわれない、新しい世界に入る一つのきっかけとして本シリーズを活用いただけますと幸いです。

■ 補足情報 分散FW を提供するVMware NSX のコンポーネント

分散FW 環境で、NSX を構成する各コンポーネントがどういった役割を果たしているのか解説を行います。

Image may be NSFW.
Clik here to view.

・NSX Manager（マネジメントプレーン）
NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時に ESXi ホストへのカーネルモジュールのインストールを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。

・NSX コントローラクラスタ（コントロールプレーン）
NSX コントローラクラスタは分散FW に関与しません。分散FW はコントロールプレーンのコンポーネントを使用しません。

・論理ルータコントロールVM（コントロールプレーン）
論理ルータコントロールVM は分散FW に関与しません。分散FW はコントロールプレーンのコンポーネントを使用しません。

・ハイパーバイザ カーネルモジュール（データプレーン）
NSX 環境を構築する際、ホストの準備のステップで各ESXi にインストールされるカーネルモジュールとなります。VIB(vSphere Installation Bundle)ファイルとしてインストールされ、分散FW ではカーネルモジュール（vsip）としてロードされます。カーネルモジュールは、ハイパーバイザ内で分散FW のテーブルの管理とフィルタリング処理を行います。

Image may be NSFW.
Clik here to view.

ハイパーバイザからは、NSX Manager にコネクションを張り、NSX Manager からフィルタリングテーブル（ルールテーブル）を受け取ります。 NSX Manager へのコネクションはUWA vsfwd(TCP/5671)を介して確立します。

# esxcli network ip connection list | grep 5671
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:23251	192.168.110.42:5671	ESTABLISHED	vsfwd

上記出力より、ESXi ホストの管理用IP アドレスからNSX Manager に、vsfwd を介して接続していることが確認できます。NSX Manager からは分散FW の設定情報（ルールテーブル）を取得します。

ルールテーブルは、仮想マシンがvMotion で異なるESXi ホスト上に移動した際も仮想マシンに追従して適用されます。これによりvMotion 後もサービスを継続することが可能です。

補足情報：NSX 6.1.2 以前のバージョンで、vMotion 実行後にコネクションが切断される事象が報告されています。オンラインのハンズオン環境（バージョン6.1.1）で動作確認される場合この不具合が該当します。詳細は下記KBを参照ください。

Performing VMware vMotion migration when using VMware NSX for VMware vSphere 6.1.2 and earlier Distributed Firewall causes virtual machines to lose network connectivity for 30 seconds (2096529)

・NSX Edge（データプレーン）
仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能（ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等）を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。分散FW 機能には関与せず、アプライアンス単体でFW 機能を提供します。

■関連リンク
今回ご紹介した内容をオンラインのハンズオン環境上で確認することができます。コマンドラインの出力はハンズオン環境をベースに作成しています。
http://labs.hol.vmware.com/HOL/
VMware HOL Online
HOL-SDC-1403 - VMware NSX Introduction

NSX の機能全般及び、ネットワーク仮想化環境の設計に興味のあるかたは下記テックペーパーを参照ください。
http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf
VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide

ネットワーク仮想化をネットワークの基本から理解する
第1回：理解するために必要なことを整理する
第2回：論理スイッチ（VXLAN）–Layer2 の世界
第3回：分散ルーティング –Layer3 の世界
第4回：分散ファイアウォール -Layer4 の世界（本稿）

皆さんこんにちは。VMware高木です。

今回はVMware vCloud Air Disaster Recoveryでも利用されている、vSphere Replicationの動作概要についてお話します。

vSphere Replicationは仮想マシンの災害対策でも使用される、ホストベースのレプリケーション機能です。簡単に申し上げますと、定期的に仮想マシンの更新データを遠隔地に送る機能ですが、vSphere Replicationってそもそも簡単に設定出来るの？とか、こんな時はどんな動作になるの？という様な質問を良く頂きますので、ご質問頂いた内容に沿ってvSphere Replicationの動作を説明したいと思います。構成としては稼働サイトのvSphereから、DRサイトのvSphereに仮想マシンを保護する想定です。

Q1.『vSphere Replicationって簡単に使えるの？』

A1.『はい。簡単に使えます。しかもvSphereのEssentials Plus以上のライセンスをお持ちであれば、直ぐに始められます。』Image may be NSFW.
Clik here to view.

『まずは、vSphere Replicationの仮想アプライアンスをVMwareのHPからダウンロードして、vCenterからデプロイを実行します。デプロイ時に指定する内容も以下のみです。』

・    ダウンロードしたファイルを指定

・    仮想アプライアンスの名前とデータセンターを指定

・    デプロイ先のリソースを指定

・    デプロイ先のデータストアを指定

・    デプロイ先のネットワークを指定

・    仮想アプライアンスのIPアドレスとパスワードを指定

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

『デプロイ後、再度vCenterにログインし直して頂ければ、既にvCenterから使える状態になっています。DRサイト側にも同じ様にvSphere Replicationの仮想アプライアンスをデプロイすれば、後は実際に保護対象の仮想マシンを右クリックし、vSphere Replicationの設定をするだけです。』

Image may be NSFW.
Clik here to view.

『vSphere Replicationの設定も簡単です。主に以下を設定すれば直ぐに仮想マシンのレプリケーションが開始します。』

・    (DR先となる)ターゲットサイト

・    (保存先となる)データストア

・    RPO(目標復旧時点)

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Q2.『サーバのメンテナンスがあるんだけど、vSphere Replicationが動いたままで大丈夫かなぁ。サーバ再起動後に仮想マシンのフル同期が走ったりしないか不安です。』

A2.『大丈夫です。仮想マシンのフル同期は行われません。』

Image may be NSFW.
Clik here to view.

『通常、保護対象の仮想マシンを構成する仮想ディスクへ更新が入った際、更新されるブロックアドレスをメモリに保存する事で、指定されたRPO(目標復旧時点)ごとに、更新データを作り出して送る動作となります。』

Image may be NSFW.
Clik here to view.