Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: 可用性

タグ別アーカイブ: 可用性

vSphere App HA 1.1について

vSphere App HA (以下App HA)を使用すると、環境内の仮想マシンで実行中のアプリケーションの高可用性を定義できます。

先日、App HA 1.1がリリースされましたので、今バージョンで強化されたポイントについてご紹介します。

  • vSphere App HA には vSphere Web Client 5.1 U2 との下位互換性があります。
  • デフォルト以外のプラグインを管理するカスタムのサービスを作成することができます。
  • ポリシーを編集することができます。サービスに割り当て済みのポリシーでも編集可能です。
  • 監視対象として、OracleとPostgreSQLが追加されました(監視可能なバージョンはドキュメトを参照下さい)
  • App HA 1.1で利用するVMware® vFabric™ Hyperic®(以下 Hyperic  Server)のバージョンは5.8.1となります。(App HA 1.0ではVMware® vFabric™ Hyperic®の対応バージョンは5.7.xとなっております。) その他のソフトウェア要件につきましては、インストールマニュアルを参照下さい。

1.カスタムのサービスの作成と、登録について

・・・App HAで標準としてサポートされていないプラグインを使用するための、カスタムサービスを定義することができます。

カスタムサービスの設定手順について、ご紹介します。

1-1. App HA仮想マシンにログインします、認証情報はインストール中に設定した「root」認証情報を使用します。
AppHA-1
※vSphere App HA へのリモート アクセス
SSH プロトコルを使用して vSphere App HA VM へリモートでアクセスすることができます。SSH を有効にするには、VM 上でコンソールを開き、 sshdサービスを開始します。
デフォルトでは、 root認証情報を使用してリモートでログインすることはできません。 root認証情報によるログインを有効にするには、VM 上でコンソールを開き、 sshd_configファイルの permitRootLoginエントリを yes に変更した後、 sshdサービスを再開します。
AppHA-2
1-2. /opt/vadm-engine/bin/custom_service.sh addを実行します。
プロンプトが表示されたら、追加するサービスの名前を指定します。
サービス名は、 2~128 文字の ASCII 文字である必要があります。
# /opt/vadm-engine/bin/custom_service.sh add
Enter service name: JBoss7.1

サービス名(Enter service name:)は、Hyperic Server側の「Server Type」で定義されている名前と同じ名前を指定する必要があります。

1-3. サービスが追加されたら、App HA サービスが自動的に再起動します。

サービスの再起動には 1~2 分かかります。


Adding custom service 'JBoss7.1'

2014-04-16 15:51:03,260 [main] INFO  c.v.v.d.service.ConfigurationService - Configuration:
        DB Host:        127.0.0.1
        DB Port:        5432
        DB Name:        apphadb
        DB Username:    appha
        Config schema:  dbconfig
        Postgres bin:   /var/lib/pgsql/bin

2014-04-16 15:51:03,264 [main] INFO  c.v.v.dbconfig.service.FacadeService - Validating configuration

Operation succeeded.
Restarting vSphere App HA ...

1-4. App HAの再起動後、vSphere Web Clientから[管理]-[vSphere App HA]-[ポリシー]より「構成詳細>サービスの選択」で追加したサービスが表示されます。

AppHA-5

1-5. vCentre Hyperic Serverにログイン後、カスタム定義されたサービスと関連付ける「サーバ」を登録します(監視対象のプラットフォームに既にサーバが登録されている場合は、こちらの手順は必要ありません)

  • vSphere App HA で使用される用語の “仮想マシン” は、vCenter Hyperic ではプラットフォームと呼ばれます。
  • vSphere App HA で使用される用語の “サービス” は、vCenter Hyperic ではサーバと呼ばれます

1-6. 「プラットフォーム」に対して、[Tools Menu]-[New Server]を選択して、「サーバ」を追加します。

設定の詳細についてはマニュアル(About vCenter Hyperic 5.8 Configuration and Metrics Guide)を参照ください。

AppHA-6

1-7. 「プラットフォーム」に「サーバ」を追加後、Hypericエージェントからのメトリックの収集が実行されるとvCenter側でクラスタ-[監視]-[アプリケーション可用性]にカスタム定義された「サーバ」が表示されます。

AppHA-9

1-9. vCenter側でポリシーの割り当てすると、監視している「サーバ」が停止した場合、ポリシーで定義したアクショに従い、処理が実行されます。下図の例ではvCenter側にアラートが表示されています。

2. Oracleの監視について
2-1.   vCentre HypericServerにログイン後、監視対象となる「プラットフォーム」に対して、[Tools Menu]-[New Server]を選択して、「サーバ」を追加します。(監視対象のプラットフォームに既にサーバが登録されている場合は、こちらの手順は必要ありません)
AppHA-6
2-2. 「プラットフォーム」に「サーバ」を追加後、Hypericエージェントからのメトリックの収集が成功するとvCenter側でクラスタ-[監視]-[アプリケーション可用性]にカスタム定義された「サーバ」が表示されます。
AppHA-12   AppHA-11
2-3. 登録が完了後、Hypericエージェントからメトリックが収集されると、vCenterの[アプリケーション可用性]画面のサービス一覧に表示されます。
2-4.  vCenter側でポリシーの割り当てすると、「サーバ」が停止した場合、ポリシーで定義したアクショに従い、処理が実行されます。下図の例ではvCenter側にアラートが表示されています。
App HAを利用するには、Hyperic Server側でも設定が必要になりますが、是非活用して仮想環境の効率的な運用にお役に立ててください。
以前、本Blogで紹介したハンズオンラボを利用すると、App HAを体感することが出来ますのでご利用下さい。
(ラボ名:HOL-SDC-1317 – vCloud Suite Use Cases – Business Critical Applications)

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

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

vSphere HA

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

HA-FT-3

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

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

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

押さえておきたいvSphere の基本」の可用性編として、2回に分けてvSphereのリソースコントロールの機能と可用性を高める機能のご紹介をしたいと思います。

1回目の今回は、vSphere上でゲストOSを運用する際、特定のESXiホストの負荷が高くなった場合、柔軟なリソースコントロールと稼働ホストの分散により、ゲストOSへの稼働に影響を最小限に抑える機能をご紹介します。

利用ケースとして、複数のESXiホストが稼働している状況で、各ホストのリソースを効率よく活用することにより、ゲストOS間のパフォーマンス劣化を防止することやより高い統合率での仮想環境の運用が可能になります。

その他、サーバリソースを追加した場合、新たに追加されたサーバのリソースの効率的な利用などもあります。

仮想マシンが増えてきた場合、それらの仮想マシンの負荷を想定して、どのサーバー上で稼働させればパフォーマンス最適化が図れるかを設計することは困難ですし、仮に設計が出来たとしても、時間の経過と共に負荷状態は変化していきますので常に最適な状態で運用し続けることは困難です。

そこで、非常に強力な機能としてvSphereにはDRS(vSphere Distributed Resource Scheduler)があります。

DRS5

どのエディションで利用可能かについては「vSphere のエディションの比較」サイトを参照ください。注意点としてDRS機能を有効にするにDRS利用可能なエディションでクラスタを作成する必要があります。

DRSには以下の役割を持っています。

  • ユーザーによる、VMパフォーマンス要件の最適化。
  • VMのリソースの分離と共有を提供。
  • 効率的なインフラストラクチャ活用とリソース管理。
  • 包括的なクラスタ管理。

上記役割を満たすためのメカニズムとして以下の機能があります。

  • 初期配置/ロードバランシング
  • QoSの施行:共有、予約、制限、リソースプール
  • ポリシーの施行:アフィニティルール、アンチアフィニティルール
  • ホストメンテナンス時の退避

1.初期配置/ロードバランシング

DRSの「初期配置/ロードバランシング」を利用する際に、一番重要な考え方となるのが「VM の要求を満たす」つまり「VMやアプリケーションが問題なく稼働する」と言うことです。

1つ例を示します。

図1のようにクラスタ内の特定ホストのリソース(CPU・メモリ)が不足した結果、そのホスト上で稼働するVMが十分な要求リソースを確保出来なくなった場合、DRSにより不均衡解消に働きます。一方、図2のようにクラスタ内のホストが十分にリソースが確保されている場合、ホスト上で稼働しているVM数に少々のバラつきがあっても、DRSは発動されません。

図1.クラスタ内の特定ホストのリソースが不足した場合

図2.クラスタ内のホストは十分にリソースが確保されている場合

では、どのような方法でホストの「負荷」と「ばらつき」を評価するかというと、構成するホストの負荷(ホストの負荷 = (VMの負荷の合計) / (ホストのキャパシティ))のばらつきを標準偏差として管理し、この標準偏差の値が、設定されたしきい値(保守的~積極的の5段階で設定)を超えた場合、vMotionを利用して仮想マシンをほかのサーバーに移行させます。

また、vMotionの実行も自動でVMがホスト間を移動するのではなく、管理者側に判断を仰ぐということも可能となっています(可用性ガイド参照)。

2.QoSの施行:共有、予約、制限、リソースプール

各VMの要求リソースリソースのコントロールをうまく行うことにより、VMの稼働を安定させることが可能となります。その方法としてリソースプールという機能がDRSでは設定可能となっています。

リソースプールの主な特徴は以下となっています。

  • リソースの分離のための、強力なリソース抽象化機能
  • ビジネス要件に応じて、リソースプールを作成可能
  • プール内でのリソース共有と、プール間でのリソース隔離

リソースプールをうまく活用することにより、ホスト毎のリソース管理ではなく、クラスタ単位でリソースの管理が行えます。

このリソースプールは「予約」「制限」「シェア値」の設定により柔軟なリソース管理が可能です。

また、それぞれの設定項目に関しては、次のガイドライン(リソース割り当て設定の推奨事項)に従うことにより、仮想マシンのパフォーマンスを向上させるのに役立ちます。
合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません (同じシェア数のままです)。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください (10% 以上を未予約にしてください)。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。次のガイドラインは、仮想マシンのパフォーマンスを向上させるのに役立ちます。

合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません (同じシェア数のままです)。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください (10% 以上を未予約にしてください)。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。

3.ポリシーの施行

DRSでは仮想マシン間の依存性を、ルール設定により制御が可能となっています。

それぞれの動きの特徴と利用シーンを下表でまとめます。

まとめ

以上のように、DRSをうまく活用していただき、効率よい仮想環境の構築・運用をしていただければと思います。

 

 

vSphere 5.5 の新機能紹介 vSphere Data Proteciton Advanced(VDPA)

今回は、vSphere のバージョン5.1 より導入されているバックアップとリカバリソリューションvSphere Data Protection Advanced(VDPA) に焦点を当て、先日発表されましたバージョン5.5 で追加された新機能・特徴の概要をご紹介します。

VDPA は、先日ご紹介させていただいたおりますVDP を機能拡張させたバックアップソリューションになります。VDP は、vSphere Essential Plus および上位エディションにバンドルされておりますが、VDPA はバックアップ対象の仮想マシンをホストしているCPU 単位のライセンス購入が必要となります。
ライセンスの追加や割り当ては、”構成”タブより実施します。

図1. ライセンスの登録と割り当て
VDP とVDPA の機能比較は、以下のようになります。

(1) 平均的な仮想マシンサイズおよび日次更新率をもとに60 日間保持として算出
(2) アプライアンスあたりのサポートされる保護対象仮想マシン数の上限数は、VDP 100 VMs, VDP Advanced 400 VMs

図2. VDP とVDP Advanced の比較
バージョン5.5 で追加されたVDPA の主な新機能は以下となります。(VDP と共通される新機能はこちらをご参照ください)

1. バックアップ データ レプリケーション
2. Microsoft SharePoint 対応エージェント
3. EMC Data Domain システムへのバックアップ
4. 自動バックアップ検証機能

それぞれの機能について見ていきましょう。

1. バックアップ データ レプリケーション
VDP 5.5 では、レプリケーション機能が新たに追加されましたが、送信先としてEMC Avamar のみをサポートしております。VDPA 5.5では、EMC Avamarだけではなく、VDPAも送信先として利用いただけるようになります。

VDPA へのレプリケーションジョブは、”レプリケーション”タブで作成します。レプリケーションジョブは、バックアップジョブに含まれるクライアント(仮想マシン)すべてもしくは、個々に選択することが可能です。

図3. レプリケーションジョブの作成ウィザード
レプリケーションが完了すると、送信先に設定しているVDPA の”リストア”タブにクライアント名が表示され、レプリケーション先でクライアントのリストアが可能になります。

図4. 送信先のVDPA での”リストア”タブ
2. Microsoft SharePoint 対応エージェント

VDPA 5.5 では、5.1 で提供していたExchange やSQL エージェントに加え、SharePoint のエージェントも追加されました。
各アプリケーションのエージェントは、”構成”タブよりダウンロードが可能になっており、アプリケーションを実行する仮想マシンにインストールします。

図5. 各アプリケーションエージェントのダウンロードリンク
各アプリケーションエージェントをインストールする際、VDPA の仮想アプライアンスのホスト名を入力して、アプリケーションのバックアップを取得できるようにします。
アプリケーションのバックアップジョブは、イメージバックアップ同様に”バックアップ”タブから、”新しいバックアップジョブの作成”ウィザードを利用します。

図6. “新しいバックアップジョブの作成”ウィザード
3. EMC Data Domain システムへのバックアップ

VDPA 5.5 では、バックアップデータを仮想ディスクファイル(vmdk) だけではなく、EMC Data Domain システムへ保存することが可能になりました。Data Domain と連携させることで、VDPA にさらなるスケールとパフォーマンスを提供します。
VDPA からData Domain へのバックアップデータの転送効率を最大化するためにDD Boost を利用することが可能です。また、バックアップデータは、Data Domain アプライアンス内でグローバルに重複排除されるため、VDPA が複数あるような環境では、非常に有効です。

 

図7. Data Domain とVDPA の連携
Data Domain をバックアップデバイスとして追加するには、VDPA のWeb コンソールの”ストレージ”タブから実施します。VDPA のWeb コンソールにアクセスするためには、ブラウザより次のURL にアクセスします。
https://<VDPA のIP アドレス もしくは ホスト名>:8543/vdp-configure/

図8. VDPA のWeb コンソール
Data Domain を追加すると、バックアップジョブ作成時に保存先として、Data Domain Storage を選択できるようになります。

図9. バックアップジョブ作成時の保存先の選択
4. 自動バックアップ検証機能

取得されたバックアップデータが有効なものか、本当にリストアが必要になる前に確認しておくことは、RPO やRTO の観点で非常に重要になります。
VDPA 5.5 では、取得されたバックアップデータが有効かを、自動的に検証する機能を提供しております。

デフォルトでは、ゲストOS とのハートビートが検証のために使用され、オプションでゲストOS 上に配置されたスクリプトを実行させることが可能です。
この機能を利用するためには、仮想マシンに最新バージョンのVMware Tools がインストールされていることが必要になります。

バックアップ検証ジョブは、”リストア”タブの”バックアップ検証”より作成します。

図10. バックアップ検証ジョブの作成ウィザード
自動バックアップ検証では、以下のような一連の動作が自動で実行されます。
1. テンポラリの検証用仮想マシンが作成され、バックアップデータがリストアされます。
2. リストアされた仮想マシンが起動されます。起動前に仮想マシンのNIC は無効化されています。
3. OS 起動後、VMware Tools とのハートビートが検証されます。
4. オプションでスクリプトの実行が検証されます。
5. テンポラリで作成された検証用仮想マシンの電源がOFF され、削除されます。

自動バックアップ検証の結果は、vCenter の”タスク”や”イベント”、VDP プラグインの ”レポート”タブ、Email レポートなどで確認可能です。

図11. “レポート”タブでのバックアップ検証結果の確認
まとめ
VDP Advanced は、VDP からのアップグレードが可能であり、お客様の環境に応じた導入が可能になっております。中規模程度のvSphere 環境に理想的なバックアップおよび、リカバリソリューションを提供します。

vSphere 5.5 の新機能紹介 vSphere Data Proteciton (VDP)

今回は、vSphere のバージョン5.1 より導入されているバックアップとリカバリソリューションvSphere Data Protection(VDP) に焦点を当て、先日発表されましたバージョン5.5 で追加された新機能・特徴の概要をご紹介します。

バージョン5.5 で追加されたVDP の主な新機能は以下となります。

1. 柔軟なバックアップ データの配置
2. 仮想ディスク単位のバックアップに対応
3. 粒度の高いバックアップ スケジューリングにより、顧客のニーズに対応
4. vCenter Server に依存せずに任意の仮想マシンをリストア
5. オフサイトへのバックアップ データの保管と、長期保管への対応

それぞれの機能について見ていきましょう。

1. 柔軟なバックアップ データの配置
vSphere 5.1 で導入されたVDP のアプライアンスは、容量毎(0.5 TB /1.0 TB / 2.0 TB) に仮想アプライアンスを提供しておりました。使用したい容量の仮想アプライアンスをデプロイすれば、必要な容量の仮想ディスクが接続されいるので、非常に簡単にセットアップすることが可能です。しかしながら、このデプロイ方法では、仮想アプライアンスのOSとバックアップを取得するための領域が同じ仮想マシンフォルダ内に配置されてしまうため、バックアップ領域(仮想ディスク)をOSとは異なるデータストアに配置するような構成をとることができませんでした。

5.5 では、容量別に仮想アプライアンスは提供されず、1つのアプライアンスのみが提供され、VDP のWeb コンソールを通じて容量(仮想ディスク)を構成します。

下の画面のようにVDP 仮想アプライアンスの容量は、初期セットアップ画面で構成するようになりました。また、既存にあるVDPのバックアップデータを新規にデプロイしたVDPアプライアンスで利用することも可能になっています。

図1. VDP 仮想アプライアンスの初期セットアップ画面1
バックアップ データを保存するための仮想ディスクを任意のデータストアに配置することができるようになりました。下の画面は、容量0.5 TB を選択した場合に、構成に必要な256 GB の仮想ディスク3 個をどのデータストアに配置するかを選択する画面になります。

図2. VDP 仮想アプライアンスの初期セットアップ画面2
2. 仮想ディスク単位のバックアップに対応
vSphere 5.1 で導入されたVDP のバックアップ対象の最小単位は、それまで提供されていたVMware Data Recovery の仮想ディスクとは異なり、仮想マシンとなりました。お客様によっては、これまでのバックアップ単位とは異なる可能性がありました。
5.5 からは、仮想ディスクを個別に選択することができるようになり、バックアップが必要な仮想ディスクのみをバックアップする、粒度の高いバックアップが可能になりました。

下の画面のようにバックアップジョブ作成時には、仮想マシンの”フル イメージ” もしくは”個々のディスク” を選択することができるようになりました。

図3. バックアップジョブ作成時のデータ タイプの選択
“個々のディスク”を選択することで、仮想マシンに構成されている仮想ディスクを個別に選択することができるようになります。

図4. バックアップジョブ作成時のバックアップ ターゲットの設定
3. 粒度の高いバックアップ スケジューリングにより、顧客のニーズに対応
VMware Data Recovery やVDP は、これまでバックアップを開始する時刻を指定することができませんでした。
5.5 では、より多くのアプリケーションやビジネス ニーズに対応するため、分単位でバックアップスケジュールを指定することが可能になりました。

図5. バックアップジョブ作成時のバックアップ スケジュールの設定
4. vCenter Server に依存せずに任意の仮想マシンをリストア
通常VDP による仮想マシンのリストアはvCenter Server に接続されたvSphere Web Client のプラグインを利用して実施しますが、vCenter Server が何らかの理由で利用できない場合、VDP の仮想アプライアンスの Web コンソールを利用して、直接ホストへリストアすることが可能になりました。
素早く仮想マシンをリカバリすることで、サービスのダウンタイム削減を図ることが可能になります。

図6. vSphere Web Client を利用したリストア

図7. VDP 仮想アプライアンスのWeb コンソールを利用した非常時のリストア
5. オフサイトへのバックアップ データの保管と、長期保管への対応
VDP および VDP Advanced は、EMC Avamar をベースとしております。
5.5 では、新たにバックアップデータを外部保管するソリューションとして、”レプリケーション” 機能が提供されます。これによりサービスプロバイダは、Avamar を利用して、VDP からレプリケーションされたバックアップデータをアーカイブするサービスをお客様に提供することができるようになります。また、既にAvamar を実装されているお客様も、同様にAvamar をVDP のバックアップデータをレプリケーションするターゲットとして、指定することができるようになります。
レプリケーションのスケジュールと保持ポリシーは、カスタマイズ可能であり、バックアップジョブのスケジュールと保持ポリシーとは、別に構成することが可能です。

図7. レプリケーションジョブ作成時のデスティネーションの設定

まとめ
VDP のバージョン5.5 では、VMware Data Recovery で提供されていた機能の多くを使用できます。また、これまで提供されていないバックアップジョブの時刻指定やレプリケーション機能が加わわったことにより、より多くのニーズに応えられるバックアップソリューションになっています。

VMware vSphere 5.5 AppHAについて

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

今回は、VMware vSphere 5.5のAppHAの機能を紹介します。

VMware vSphere 5.5より、ゲストOS内で稼働するアプリケーションの状態監視を行えるようになりした。

監視対象アプリケーションのサービスが停止した際、「サービスの再起動」または「仮想マシンのリセット」が実行されます。また、同時にvCenterへのアラート通知と管理者へのメール通知を行うことも可能です。

従来、VMware vSphere HAではアプリケーションの監視を有効にするには、適切な SDK を入手し、これを使用して監視対象となるアプリケーションのハートビートの開発/設定する必要がありました。AppHAでは、特別な開発を必要とせず、仮想マシン内で稼働するサービスに対しての保護が可能となります。

AppHAは従来のvSphere HA機能と連携して、ホスト障害から仮想マシン内で稼働するアプリケーションの保護まで可能となりました。



 

 

 

現行バージョンで監視対象と出来る、アプリケーションは下記となります。
※ 2013/9/25追記:アプリーショーンの最新のサポート状況に関しては弊社マニュアルを参照ください。

  • Microsoft SQL Server2005
  • Microsoft SQL Server2008
  • Microsoft SQL Server2008R2
  • Microsoft SQL Server2012
  • Microsoft Internet Information Services6
  • Microsoft Internet Information Services7
  • Microsoft Internet Information Services8
  • VMware vFabric tc Server6
  • VMware vFabric tc Server7
  • Apache Tomcat6
  • Apache Tomcat7
  • Apache HTTP Server1.3
  • Apache HTTP Server2.0
  • Apache HTTP Server2.2

 1.稼働コンポーネントについて

AppHAを設定するには、下記のコンポーネントの導入が必要となります。

各コンポーネントの稼働要件については、弊社ドキュメントでご確認ください。

1.vCenterサーバ

2.AppHAサーバ(仮想アプライアンス)

3.vFabric Hyperic Server(仮想アプライアンス)

4.vFabric Hyperic Agent(監視対象となる仮想マシン内で稼働)

2.AppHAの設定について

仮想マシン内で稼働する、アプリケーションの監視方法はすべて、ユーザーが事前に定義するポリシーにより決定されます。

AppHAを利用して、監視対象アプリケーションの登録方法とポリシー設定について紹介します。

AppHAは、vFablic Hyperic Serverと連携して稼働するため、AppHAのデプロイ後、vFabric HQ Serverと監視対象となる仮想マシンにvFabric Hyperic Agentの登録が必要となります。vFablic Hyperic ServerとvFabric Hyperic Agentの導入方法については、マニュアルを参照ください。

1.AppHAの初期設定として、AppHA Plug-InよりvFablic Hyperic Serverの接続情報を指定します。

2.監視ポリシーを追加します。

3.ポリシー名とコメントを設定します。

4.監視対象となるサービスの種類を選択します。

5.監視対象のサービスが停止した場合の対処方法について設定をします。

6.vCenter Serverに対してアラートの設定とメール通知の設定をします。

7.すべての設定が完了後、仮想マシン内で稼働するサービスに対して作成したポリシーを割り当てます。

また事前に、vFabric Hyperic ServerにvCenterの登録をしておく必要がありますので、登録をしていない場合、名前を「VC」としてNew Server登録を行ってください。

設定の詳細に関してはマニュアル「Fabric Hyperic Resource Configuration and Metrics」の「vSphere」の章を参照ください。

8.設定が完了して、ステータスが「Available」となると監視が開始されます。

なお、VMware vSphere HAの設定は「仮想マシンとアプリケーションの監視」で設定する必要があります。

まとめ

仮想環境において仮想マシン内で稼働するアプリケーションの監視が容易に行えるようになりましたので、是非 ご利用ください。

vSphere 5.5 の新機能紹介 vSphere Replication (VR)

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

今回は、vSphere のバージョン5.1 より導入されているvSphere Replication に焦点を当て、先日発表されましたバージョン5.5 で追加された新機能・特徴の概要をご紹介します。(vSphere 5.0 では、vCenter Site Recovery Manager 5.0 を使用することでvSphere Replication の機能を利用可能でした。)

バージョン5.5 で追加されたvSphere Replication の主な新機能は以下となります。

1. レプリケーション先は、vCenter Server 1 台あたり最大10 か所
2. 複数の復帰ポイントの保持可能
3. Storage DRS との互換性

それぞれの機能について見ていきましょう。

1. レプリケーション先は、vCenter Server 1 台あたり最大10 か所
vSphere Replication では、レプリケーション先を複数登録することが可能です。
例えば、Site A の仮想マシン1 は、Site B へレプリケーションし、 Site A の仮想マシン2 は、Site C へレプリケーションをすることが可能です。(fan-out)
本バージョンでは、Site B やC のようなレプリケーション先のサイトを最大10か所登録することが可能になっております。
さらに、Site B の仮想マシン3 をSite A へレプリケーションし、Site C の仮想マシン4 をSite A へレプリケーションするような構成をとっていただくことも可能です。(fan-in)
これにより図1 のような柔軟な構成をとっていただくことが可能になります。

 

図1. vSphere Replication のトポロジー
2. 複数の復帰ポイントの保持可能
vSphere 5.1 で導入されたvSphere Replication では最新のレプリケーションが完了すると過去のレプリケーションは上書きされてしまうため、復帰可能なポイントは1 つしかありませんでした。レプリケーション元の仮想マシンが論理障害やウィルス感染してしまい、タイミングによっては、その状態がレプリケーションされてしまうことも想定されるため、復帰可能なポイントは複数あることが望まれます。それによりリカバリ時間を早めることが可能になります。
本バージョンでは、レプリケーション先に最大24 の復帰ポイントを保持することが可能になりました。

設定は、レプリケーションの構成ウィザード内の ”特定の時点のインスタンス” という項目で可能になりますが、この項目はWeb Client でのみ表示されます。Site Recovery Manager を導入している環境であっても、 vSphere Client では表示されませんので、ご注意ください。(図2)

 

図2. Web Client を使用したvSphere Replication の構成ウィザード画面
Web Client では、過去レプリケーションされた保持されている復帰ポイントを確認できます。(図3)

 

図3. Web Client を使用したvSphere Replication 監視画面
リカバリが完了した仮想マシンで、”スナップショットの管理”を確認すると、保持されている復帰ポイントがスナップショットとして表示されます。(図4)この時点では、最新のレプリケーションが完了した時点にリカバリしているので、希望する復帰ポイントを指定して、その時点に戻します。

 

図4. 仮想マシンのスナップショット管理画面
3. Storage DRS との互換性
vSphere 5.1 までは、Storage vMotion 実施後、前回のレプリケーションからの更新情報が維持されず、Storage vMotion 実施後の最初の同期が完全同期になっておりました。
(この時の完全同期は、すべてのデータが送られるのではなく、ソースとターゲットディスクの比較検証が実行されるため、レプリケーション完了まで時間が掛かっておりました。)
そのような理由から、vSphere Replication で保護している仮想マシンは、Storage vMotion をサポートしておらず、Storage DRS との互換性がありませんでした。

本バージョンより、Storage vMotion がサポートされ、Storage DRS との互換性を持ちますので、vSphere Replication 導入した環境におけるストレージの集約率向上及び、メンテナンス性の向上を図ることが可能になります。

図5 の画面はStorage DRS を有効にしているデータストアクラスタにて、あるデータストアをメンテナンスモードへ切り替えを実施した際に表示される移行の推奨画面になります。
移行の推奨の対象と表示された仮想マシン(w2k8r2-srm2)は、vSphere Replication 構成済みの仮想マシンになります。
vSphere 5.5 では、Storage DRS との互換性を持ちますので、推奨の適用を実施します。

 

図5. Storage DRS メンテナンスモード移行による推奨
データストア移行直後の仮想マシン(w2k8r2-srm2)を手動で同期させた際の結果が以下の画面になります。Storage vMotion が実行された後も更新情報を維持できているため、レプリケーション間での更新が少なければ、非常に短い所要時間でレプリケーションが完了していることが確認できます。(図6)

 

図6. Web Client を使用したvSphere Replication 監視画面
次回は、vSphere 5.5 で追加されたネットワークの新機能・特徴をご紹介いたします。