Home > Blogs > Japan Cloud Infrastructure Blog

EMCストレージ EMC Storage Analytics と vRealize Operations Manager の連携をご紹介!

みなさんこんにちは。
VMware vRealize Operations Manager (vR Ops) のストレージとの連携機能について、今回は EMC Storage 「EMC Storage Analytics」と連携した機能を vExpert であります EMC ジャパンの吉田 尚壮様にご紹介いただきます。
それでは吉田様、よろしくお願いいたします。


こんにちは。EMC ジャパンの吉田です。

今回は、vR Ops と EMC ストレージを連携させる「EMC Storage Analytics」(以下 ESA)をご紹介いたします。 ESA は、vR Ops 向け EMC ストレージアダプターの名称です。現時点では、下記 EMC ストレージ製品( VMAX、VNX、VNXe および VPLEX)からそれぞれ専用のアダプターが提供されています(図 1)。それらのアダプターを vR Ops にロードすることで、ストレージ内部の情報が vR Ops のダッシュボードに表示できるようになります。

図1 EMC が提供しているストレージアダプター EMC1

※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

 

ESA のダッシュボード

ESA のアダプターを vR Ops にロードすると、vR Ops のダッシュボードに ESA のタブが現れます(図2)。これらのタブには、予めトポロジーマップやヒートマップ、メトリックグラフなどが仕込まれています(図3)。その後、監視対象のストレージを登録すると、ストレージ内部の様々な情報が vR Ops 上に表示されます。

 

図2 そのまま利用できる ESA のタブ EMC2

※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

 

図3 直感的に状態が把握できるヒートマップ

EMC3

※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

 

ESA の活用例

システムで性能問題が発生した場合、素早く原因を特定する必要があります。一般的に、ストレージ装置において性能のボトルネックになり易いコンポーネントは、ハードディスクドライブとコントローラーです。ESA を使えば、それらのボトルネックも直感的に識別できるので、短時間で問題の切り分けができます。 例えば、VNX のコントローラー(Storage Processor と呼びます)をスコアボード ウィジェットに登録すると、CPU と Write キャッシュメモリの利用状況が色と数値で判別できたり、Read と Write I/O の数値も表示できます(図4)。もし、Write I/O の比率が高く、且つ Write キャッシュメモリの利用率(厳密には Write Cache Page の値)も高ければ、そこがボトルネックとなっている可能性が高いと判定できます。また、冗長化されている2台のコントローラーのうち、どちらかに I/O が片寄ってしまい、ストレージ全体として想定通りの性能が出ないケースも稀に発生します。ESA であれば、そのような状態も一目で判別できます。

 

図4 VNXコントローラーの稼働状況

EMC4

※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

 

VM からストレージ内部の各コンポーネントまでの関連性が把握できれば、問題の切り分けと影響範囲の特定に役立ちます。ESA を使って VNX を見てみると、LUN や RAID Group、ディスクドライブだけではなく、FAST Cache (SSDベースの2次キャッシュ機能)や FAST Pool (ストレージ階層化プール)、Tier (ストレージ階層化タイプ)などの情報まで全てアイコンで表示でき、かつ関連性も直感的に見分けられるので、短時間で全体の構成が把握できます(図5)。

図5 トポロジーマップ EMC5

 

また、各種コンポーネントの情報は、メトリックを選択すればオンディマンドでグラフ化できます。使用率の高いディスクドライブだけ赤く表示させるようにヒートマップウィジェットを構成しておけば、そこから動的に知りたい情報をグラフ化するということもできます(図6)。仮に、ディスクドライブの負荷が高くなっていれば、ヒートマップ上のタイル(個々の四角い枠)が赤く変化します。その赤くなっているアイコンをクリックして、詳しく調べたいメトリックを選択すれば、それがグラフとして表示されます。グラフのタイムスケールも自由に調整できるので、問題発生前後の変化を視覚的に把握できます。同時に、トポロジーマップを利用して、そのディスクドライブに関係しているLUNや仮想マシンを追跡すれば、影響範囲の特定も短時間で行うことができます。

 

図6 ヒートマップとメトリックグラフ

EMC6

※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

 

EMC ストレージはメトリックが豊富

EMC のストレージは、管理者のために非常に多くの構成情報や容量情報、性能情報などが取得できる仕組みを備えています。例えば、VNX のブロックストレージ機能だけでも、150種を超える値が取得できます。通常は、VNX 専用のツールを使ってこれらの値を取得し分析に利用しますが、ESA でも同等の情報が収集できるので非常に便利です(図7)。さらに、ESA であれば、分析に必要なメトリックをピックアップしてグラフ化し、タイムスケールなどを動的に調整できるので、ストレージ管理者の作業効率は確実にUPします。

 

図7 豊富なメトリック

EMC7

※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

 

まとめ

ESA を利用することで、ストレージに関連する詳細な情報が収集できるようになり、仮想マシンの視点からストレージを含めた統合的な管理が可能となります。特に、性能問題が発生した際、ボトルネックの切り分けが短時間で行える点は、大きなメリットだと言えます。ESA は、評価ライセンス(期間限定の無償ライセンス)も提供していますので、EMC ストレージをお使いの方は、是非一度お試しください。

尚、EMC のコミュニティーサイト(EMC Community Network)では、ESA に関する詳しい情報(活用例やセットアップ方法など)を公開しています。そちらも併せてご覧ください。

VMworld 2014 からの注目セッション 第7回 – SRM と VR について

皆様こんにちは。VMware の北村と申します。VMworld 2014 からの注目セッションの最終回 (7回目) は、「BCO2629: Site Recovery Manager and vSphere Replication: What’s New Technical Deep Dive」のセッション内容についてご紹介します。

 
BCO2629-7
VMware vCenter™ Site Recovery Manager™ (以下、SRM) は、約 6年前の 2008年の 12月に最初のバージョン (1.0) をリリースしましたが、今回の 5.8 は 7回目の大きなリリースとなります (注: スライドでは SRM 4.0.x と 4.1.x が 4.x として記載されていますので、今回の 5.8 が 6回目のリリースに見えますが実際は 7回目です)。
また、vSphere Replication (以下、VR) は、2011年の 9月に SRM との同時利用のみをサポートした最初のバージョン 5.0 (5.1 以降から VR 単体での利用をサポート) をリリースし、今回の 5.8 は 4回目の大きなリリースとなります。

 
BCO2629-10
初めに SRM のおさらいになりますが、SRM は、vSphere 環境のための災害対策を自動化する業界トップのソリューションとして、次の主な機能を提供しています。

  • 数千の仮想マシンのリカバリ プランを集中的に管理
  • 無停止でのリカバリ テスト
  • 自動化された DR ワークフロー
  • VMware の製品スタックに統合

これらの機能により、次のようなメリットを得る事が可能です。

  • 50% 以上の DR 管理のコストを低減
  • マニュアル操作のリスクと複雑性を排除
  • 迅速で容易に予測可能な RTO を実現
  • 仮想化されたアプリケーションに対しポリシー・ベースの DR コントロールを提供

 
BCO2629-11
SRM の典型的なユースケースとしては、こちらのスライドにある様に、災害対策、災害回避、計画移行、などがあげられます。

 
BCO2629-14
今回の SRM 5.8 の新機能ですが、次の 3つのカテゴリでそれぞれ機能拡張が行われています (※はアレイ・ベースのレプリケーション使用時)。

    1. SDDC のための DR
  • セルフ・サービス、ポリシー・ベースのアプリケーションの DR 保護として、vCO プラグインを利用した vCAC ブループリントとの統合 (※)
  • DR に対応した SDS として、SRM と VR と Virtual SAN との統合
    1. スケーラビリティの強化
  • 5 倍のスケールの保護:vCenter Server (※) あたり 5,000 までの保護された VM
  • 2 倍のスケールのリカバリ:vCenter Server (※) あたり 2,000 VM まで同時にリカバリ
  • 性能改善:ストレージスタックを改善し、RTO を削減
    1. 運用の簡素化
  • vSphere と UI を統合:vSphere Web Client プラグイン
  • 簡素化された IP アドレス管理:サブネット・レベルでのルール・ベースのカスタマイズ
  • より迅速なインストール:組み込みデータベースのオプション (vPostgre)

 
BCO2629-33  BCO2629-34
次に VR です。SRM 同様、最初に VR のおさらいからお伝えします。VR は、vSphere Essentials Plus Kit、および、vSphere Standard Edition 以上で利用可能な、vSphere プラットフォームに統合されたホスト・ベースで仮想マシンをレプリケーションする機能を提供します。主な特徴には以下があります。

  • 仮想アプライアンスとして提供される為、容易なデプロイ
  • UI は vSphere Web Client に統合
  • OS やアプリに関係なく仮想マシンを保護
  • 柔軟な RPO ポリシー (15分から 24時間)
  • 個々の仮想マシンの迅速なリカバリ
  • SRM 為のレプリケーション・エンジン (アレイ・ベースのレプリケーション未使用時)
  • 様々な形態のストレージ (SAN、NAS、ローカル、および、VSAN) とのコンパチビリティ

 
BCO2629-35
次に、VR のユースケースとしては以下があります。

  • データ保護、および、災害対策
  • データセンター移行での利用
  • SRM 為のレプリケーション・エンジン
  • VR 単体でのレプリケーション
  • 同じサイト内でのレプリケーション

VR 5.8 の新機能として、次の 2点の機能拡張がありました。
BCO2629-36

  • 仮想マシンの vCloud Air へのレプリケーションが追加されました (実は、この機能は VR 5.6 から実装されていますが、UIがローカライズされたのは今回の 5.8 からになります)

BCO2629-42  BCO2629-43  BCO2629-44

  • vSphere Replication レポーティング機能が強化されました

BCO2629-48
新機能ではありませんが、VR の現実のレプリケーション・トラフィックを生み出さずに、仮想マシンのレプリケーションによるネットワークへの影響をモデル化する事を可能にするアプライアンスとして、VMware Labs の Flings に公開されている vSphere Replication Capacity Planning Appliance についての紹介がありました。

VR の対象としたい仮想マシンをレプリケーションする為に必要なネットワーク・トラフィックをグラフで表示する事が可能で、実際に必要となるネットワーク・トラフィックを計算するのに参考となるツールだと思いますので、ご興味がある方は以下の参考情報を元に是非お試し下さい。

参考情報:

  • https://labs.vmware.com/flings/vsphere-replication-capacity-planning-appliance
  • http://blogs.vmware.com/vsphere/2014/04/vsphere-replication-capacity-planning-appliance.html

 
全7回でお伝えしてきました VMworld 2014の注目セッションブログも今回で最終回となります。

 
最後に、11月5日(水) ~ 11月6日(木) にプリンスタワー東京で vForum 2014 が開催されます。こちらでも、今回の VMworld 2014 と同様のセッションが数多く講演されますので、ぜひご来場ください ( お申し込みはこちらから )。

 
今後も皆様にとって有益な情報を本ブログ上でお伝えしていきたいと思いますので、是非、お楽しみに!

VMworld 2014からの注目セッション第6回 – vC Ops の物理環境への拡張 & Hypericによる基幹系

みなさん、こんにちは。

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

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

さらにHypericで収集された情報をvCenter Operationsと連携することによりアプリケーションの稼働監視や分析を行うことが可能となります。
P12-Slide

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

1.MSSQL

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

2.Microsoft Exchange

P27-Slide

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

3.vCAC

P32-Slide

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

 

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

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

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

VMworld 2014からの注目セッション第5回 – Recovery as a Service (RaaS) with vCloud Air

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

 

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

001

日本ではサービス提供予定をこの夏に発表したばかりの『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も保護されていることが分かります。

002

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

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

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

003

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

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

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

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

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

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

004

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

 

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

□10GHz vCPU

□20GB vRAM

□1TBストレージ

□10Mbpsの帯域

□2つのパブリックIP

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

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

005

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

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

006

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

 

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

007

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

008

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

009

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

・vSphere 5.1以上

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

・vCenter 5.1以上

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

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

010

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

011

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

012

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

013

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

014

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

015

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

016

通常の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の注目セッションブログにご期待下さい。

VMworld 2014 からの注目セッション 第4回 – DevOps (後編) – 継続的デリバリーと VMware vRealize Code Stream

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

はじめに

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

また先日発表された、 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)環境と連携することで、各環境へのアプリケーション展開を含めたリリースパイプライン全体の自動化の実現(継続的デリバリー)を目指すものです。

vmworld2014-4-devops-7-0

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

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

vmworld2014-4-devops-7-5

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

その他のトピック

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

1. VMware vCloud Air

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

vmworld2014-4-devops-8-3-0

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

vmworld2014-4-devops-8-3-1

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

vmworld2014-4-devops-8-3-2

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

vmworld2014-4-devops-8-3-3

2. Pivotal CF

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

vmworld2014-4-devops-8-1-0

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

vmworld2014-4-devops-8-1-2

vmworld2014-4-devops-8-1-3

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

3. Docker / Fargo(VMfork)

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

vmworld2014-4-devops-8-2-1

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

vmworld2014-4-devops-8-2-3

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

vmworld2014-4-devops-8-4

最後に

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

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

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

はじめに

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

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

vmworld2014-4-devops-0-1

※ 補足: 最新情報

~~~

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 と関連するものとしては、以下に挙げるセッションがありました。

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年、欧米ではすっかり主流の開発手法となっています。

vmworld2014-4-devops-2-1-2

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

vmworld2014-4-devops-2-1

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

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

vmworld2014-4-devops-2-2

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

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

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

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

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

インフラ運用チーム

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

vmworld2014-4-devops-3

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

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

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

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

Dev と Ops を隔てる壁

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

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

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

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

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

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

DevOps とは?

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

Wikipedia によると、DevOps とは

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

とあります。

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

vmworld2014-4-devops-5-2

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

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

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

vmworld2014-4-devops-6-1

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

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

例:

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

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

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

vmworld2014-4-devops-6-1-2

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

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

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

vmworld2014-4-devops-6-4

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

vmworld2014-4-devops-6-5

「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」がサポートされています。

vmworld2014-4-devops-6-8

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

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

vmworld2014-4-devops-6-9

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

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

vmworld2014-4-devops-6-6

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

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

vmworld2014-4-devops-6-7

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

vmworld2014-4-devops-6-11

Puppet Integration

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

vmworld2014-4-devops-6-10

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

最後に

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

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

VMworld 2014 から第 3 回 – Virtual SAN Ready Node と Hardware Guidance

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 つのプロファイルが用意されており、導入するシステムのワークロード、規模に合わせて選べるようになっています。

VSAN-Rdy-Step1 VSAN-Rdy-Step2

 

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

VSAN-Rdy-Node

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 とクラスタを構成するためのネットワークが必要となりますので、要件に合わせる形で構成していきます。

VSAN-Req

 

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

VSAN Build Your Own

VSAN-BYO-VCG

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

1. I/O Controller

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

VSAN-BYO-IOcontrollerリストに出てくるコントローラの詳細を確認すると、そのカードでサポートされている 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 環境を構成/構築される場合は、その都度サポート状況を確認するようにして下さい。

 

デルストレージEqualLogicと VMware vCenter Operations Managerの連携をご紹介!

みなさん、こんにちは。

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環境とは連携していませんので、どの仮想マシンのワークロードが問題に関与しているかを分析するために時間を要する場合も考えられます。

eql_1

 

vC Opsのおさらい

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

eql_2

 

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

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

eql_3

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」にはこのデータストアの「残り時間」アラートが表示されています。

eql_4

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

eql_5

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

eql_6

 

EqualLogic Storage At a Glance Dashboard

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

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

eql_7

 

EqualLogic Storage Metrics Dashboard

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

eql_8

 

FirmwareとSoftwareの必要要件

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

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

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

Product Revision
EqualLogic vCOPS Adapter VMware vCenter Operations Manager 5.7.1 以降
Dell EqualLogic Statistics Agent PS Series firmware 6.0.7 以降
SAN Headquarters 3.0, 3.0 1

 

おわりに

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

インフラストラクチャ・コンサルティング・サービス本部 テクニカルコンサルタント 中川 明美
eql_9

 

 

新卒 SE 社員が贈る vSphere のキソ! 第7回 ~ 仮想環境となが〜くお付き合いしていくために ~

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

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

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

 

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

図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です。

 

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

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

 

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

  • キャパシティ管理

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

 

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

図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 は2つの仮想アプライアンスが展開され、 vCenter Server から収集したデータを解析し、表示します。(図4) vCenter Server は一つまたは複数を対象とすることができます。

図4.vCenter Operations Manager の構成

図4.vCenter Operations Manager の構成

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

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

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

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

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

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

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

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

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

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

図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 を入手することで仮想マシン数を意識する必要はなくなります。

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

図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製品の理解を深めていただけましたらとても嬉しいです。

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

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

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

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

VMworld 2014 からの注目セッション 第2回 – Software-Defined Data Center と Hyper-Converged Infrastructure他

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

今回は、8月末に米国サンフランシスコで開催された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は考えます。

evorail_fig01

  1. Build Your Own(アラカルト)
      • サーバやストレージ、ネットワーク機器などのハードウェア、仮想化ソフトウェア、管理ソフトウェアなどを個別に選択して調達し、お客様に合わせて統合する
      • 利点:お客様の要件に沿ったカスタマイズが可能であり、構成上の自由度が最も高い
  2. Converged Infrastructure(統合インフラストラクチャ)
    • サーバ、ストレージ、およびネットワーク機器が単体シャーシ、またはラック内に工場出荷時に構成済み。ソフトウェアはオプションとして選択可能。
    • 利点
      • パッケージ済みなので購入が容易
      • お客様に合わせてカスタマイズが可能
      • 一本化されたサポート窓口
  3. Hyper-Converged Infrastructure(高度な統合インフラストラクチャ)
    • 仮想化ソフトウェアとハードウェア(サーバ、ストレージ、ネットワーク)がSDDCを前提として統合済み
    • それらのために最適化された管理ソフトウェアも同梱
    • 利点
      • 購入が容易
      • ハードウェアとソフトウェアがSDDC向けに設計済み
      • より短時間で導入可能
      • 一本化されたサポート窓口

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

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

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

evorail_fig02 evorail_fig03

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」

evorail_fig04

また、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分で完了するデモを紹介していました。

evorail_fig05

また、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パートナーから提供されます

evorail_fig08 evorail_fig09

ここまで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を利用することが可能であり、過剰なリリースを抱える必要はありません。

以上