Comments
Description
Transcript
1
Continuous Availability and Application Versioning Software Group 上野亜紀子 この章ではWebSphere XD V6が提供するContinuous Availability（連続稼動）を実現 する機能を中心に説明します。また、Continuous Availabilityを実現するエディション・ コントロール・センターのもう1つの機能であるApplication Versioning機能について紹 介します。 1 本日お話する内容 XD V6でのシステム管理機能概要 Continuous Availability関連機能 保守モード・スマートストップ エディション・コントロール・センター Application Versioning機能 HA デプロイメント・マネージャー ヘルスモニタリング 2 WebSphere XD V6 システム管理トポロジー ノード AS セル 構成ファイル アプリケーション プロファイル 管理コンソール wsadmin NA 動的 クラスター ノード 構成ファイル ODR ノード AS プロファイル NA 構成ファイル アプリケーション プロファイル NA 構成ファイル アプリケーション ノード DM プロファイル ノード･グループ サーバー･ノード Web Plugin 構成ファイル Web Server NA or admin server ノード AS AS 構成ファイル アプリケーション プロファイル NA DM : Deployment Manager NA : Node Agent AS : Application Server ODR : On Demand Router Continuous Availability 関連機能はWebSphere XD （以後XD）のシステム管理機能と 関連が深く連携して稼動します。このページでは、XD V6のシステム管理のトポロジー およびフローを紹介しています。WebSphere XD V6はWebSphere Application Server V6 Network Deployment (以後WAS ND) へのadd-onとして導入され、システ ム管理機能は基本的にWAS NDをベースとしており、WAS NDのシステム管理基盤の 上にXD特有の機能が追加・拡張されています。 WebSphere XD環境ではデプロイメント・マネージャー（以後DM）はXD が導入されて いる必要があり、管理者はXDのDMに対してアクセスして管理・構成を行います。これか らご説明するContinuous Availability関連機能も管理コンソールやスクリプトを使って DMにアクセスして使用します。 3 WebSphere XD V6システム管理機能 V5.1からの機能 WAS ND管理コンソールへの拡張 リソース・グループ、動的クラスターによる構成の容易化 Extended Manageability Non-stop computingを実現するための運用管理機能 Continuous Availability WebSphere XD環境では前頁でご説明したように、WAS NDのシステム管理基盤を ベースとしています。さらにXDでは大規模かつ仮想化されたWebSphere環境を効率よ く管理したり、可用性をあげるための機能などで追加または拡張されています。 １つはExtended Manageabilityとして大規模または仮想化された環境を管理しやすく するための機能です。詳細は「Enhanced Extended Manageability」のセッション資料 をご参照ください。もう１つはContinuous Availabilityとしてノンストップ・サービスを実現 するための機能です。このセッションではこのContinuous Availability関連機能をご紹 介します。 4 WebSphere XD Continuous Availability 機能 アプリケーション・サーバー・プロセス障害 ハードウェア障害 WebSphere XD環境でのシステムの停止の要因 メンテナンス時の計画停止 H/W、S/Wメンテナンス 保守モード/スマートストップ アプリケーション更新 エディション・コントロール・センター プロセス・ハングなどの非正常な状態 動的(静的)クラスタによる冗長化とHAマネージャーによるモニタリング ヘルスモニタリング シングルトン・リソースの排除 HA マネージャー、Highly Available デプロイメント・マネージャー WebSphere XD環境においてシステム停止の要因の基本例をここにあげています。1 つは障害による停止です。これはに、アプリケーション・サーバー・プロセスの障害やア プリケーション・サーバーが稼動するOS、ハードウェアなどの障害が含まれます。障害 によるサービス停止を防ぐためには、サーバー・プロセスおよびサーバー・プロセスが稼 動するハードウェアの冗長化を行います。WebSphere XDでは、動的クラスターまたは 静的クラスターをノードにまたがって構成することで、冗長構成が可能となります。 2つ目の要因としてメンテナンス時などの計画停止が挙げられます。計画停止にはH/W、 S/Wのメンテナンスおよび稼動しているアプリケーション自体のメンテナンスが含まれま す。WebSphere XDではH/WおよびS/Wのメンテナンス時用に保守モード、スマートス トップという機能を提供しています。また、アプリケーションの更新用にはエディション・コ ントロール・センターという機能がV6で新規にサポートされています。 その他のシステム停止の要因としては、サーバー・プロセス自体は稼動しているものの、 プロセスがハングしている状態などの非正常な状態で稼動し続けているケースが挙げら れます。このような状態もクライアントから見れば応答がないという意味ではシステム停 止の要因の１つといえます。このような状態を検知するためにWebSphere XDではヘル スモニタリング機能を提供しています。 その他、WebSphere XDではさまざまなシングルトン・リソースに関してHA マネー ジャーの管理下に置くことで可用性を高めています。また、デプロイメント・マネージャー のHA可もV6で新たにサポートしています。 このセッションではこれらの機能についてご説明します。 5 保守モード 計画停止時などに使用 アプリケーション配置の対象から外す ノード上のサーバーのDWLMウェイトが0に設定される 2つの保守モード設定 保守モードの設定、即時停止 保守モードにした上で、アプリケーション・サーバー・プロセスを停止する 保守の設定 保守モードに設定のみでアプリケーション・サーバー・プロセスは起動したまま ノード単位で設定可能なモード ノードの管理画面およびランタイム・トポロジーから設定可能 保守モードの設定 まずはじめに、計画停止時に使用する保守モードについて説明します。保守モードとは XD特有の機能で、ノード単位で設定可能なモードです。保守モードに設定されると、 •そのノード上で稼動しているアプリケーション・サーバーのウェイトが0に設定され DWLMの対象外となる •そのノードがアプリケーション配置の対称ノードから除外される という2つの状態の変更が起こります。 なお、保守モードには、2つの設定があります。「保守モードの設定、即時停止（保守 モードの設定）」を実行すると、ノードは保守モードに設定され上記2つの状態が変更さ、 さらにノード上の全てのアプリケーション・サーバー・プロセスが自動的に停止されます。 ノード・エージェントも同様に停止されます。 「保守の設定（保守モードの設定。プロセスを実行中のままにする）」を実行すると、ノー ドは保守モードに設定されますが、アプリケーション・サーバー・プロセスおよびノード・ エージェントは稼動したままです。 保守モードの設定は管理コンソールの「システム管理」→「ノード」から保守モードに設 定するノードを選択していずれかの保守もモード設定ボタンを押下するか、「ランタイム 操作」→「ランタイム・トポロジー」画面からもノードを左クリックして表示されるメニューか ら設定可能です。 保守モードに設定されたノードは、ノード・エージェント（およびアプリケーション・サー バー・プロセス）の再起動後も保守モードに設定されたままです。保守モードを解除する には設定する際と同様の画面から行います。 6 スマート停止 アプリケーション・サーバー・プロセス単位のグレースフル・シャットダウ ンを実行 ランタイム・トポロジーから実行 DWLMウェイトを0に設定 しかかり中のリクエストは処理続行 停止したいアプリケーション・サーバーを選択 左クリックのメニューから「サーバーのスマート停止」を実行 保守モードと組み合わせることでノードのグレースフルな停止が可能 ノードを保守モードにする アプリケーション・サーバーをスマート停止する ノード・エージェントを停止する スマート停止は、個々のアプリケーション・サーバー・プロセスに対してグレースフル・ シャットダウンを実行する機能です。スマート停止を実行すると、アプリケーション・サー バーのDWLMウェイトが0に設定され新規のリクエストの割り振り対象から外されます。ス マート停止実行時にしかかり中のリクエストがあればその処理の完了を待ってサー バー・プロセスが停止されます。 スマート停止は管理コンソールの「ランタイム操作」→「ランタイム・トポロジー」から停止し たいアプリケーション・サーバーを選択して左クリックし、メニューから「サーバーのス マート停止」を選択します。 個々のノードをメンテナンス時より安全な方法で停止するには、以下の手順で行います。 ① メンテナンス対象ノードを保守モードに設定する ② 保守モードに設定したノード上で稼動するアプリケーション・サーバー・プロセスをス マート停止する ③ 全てのアプリケーション・サーバー・プロセスの停止を確認してからノード・エージェン トを停止する 7 エディション・コントロール・センターとは Interruption-freeなアプリケーション更新（ロールアウト）機能の提供 システム管理インターフェースからの一元管理 アプリケーション・バージョン単位でのデプロイメント機能の提供 サービスを停止せずに更新を自動実施 ODRとの連携によるリクエスト制御 セル内への同一名を持つJ2EEアプリケーションの複数デプロイメントを許可 “エディション“として管理 エディションの活動化に関して複数のパターンをサポート エディション単位での活動化 複数エディションの同時活動化 テスト使用での活動化 （妥当性検査： Validation mode) Concurrent Activation ロールアウト 特定のエディションからエディションへのInterruption-freeな置き換え（更新） グループ・ロールアウト アトミック・ロールアウト 次にエディション・コントロール・センターとその機能を説明します。 エディション・コントロール・センターはWebSphere XD環境において以下の機能を提供します。 •interruption-freeなアプリケーション更新 •同一アプリケーションの異なるエディション（バージョン）の複数デプロイ •同一アプリケーションの異なるエディション（バージョン）の同時活動化パターンの提供 アプリケーションの更新（ロールアウト）機能は、クラスター全体としてはサービスを停止せずに、アプリケー ションの更新を自動的にかつ安全に実施する機能で、ODRと連携して、更新前、更新中、更新後のサー バーへのクライアントリクエストの制御を同時に行います。これらのオンライン中での自動更新を管理コン ソールまたはwsadminスクリプトを使って簡単に実施することが可能です。 WebSphere XD V6では既存のシステム管理機能を拡張し、セル内に同一名を持つJ2EEアプリケーショ ンを複数デプロイすることを許可します。個々のデプロイの単位はエディションとして扱われます。 WebSphere XD では新たに「エディションの活動化」という概念が導入されています。複数デプロイされ た同一アプリケーションはエディション単位で活動化し、開始稼動状態となります。活動化の操作はエディ ション・コントロール・センターを使って行います。 またWebSphere XDでは同一アプリケーションの複数エディションを同時に活動化することをサポートしま す。複数エディションの活動化の方法は、 •新エディションのテスト使用などテンポラリー使用を目的とする妥当性検査機能 •複数のエディションを同時に長期間活動化させることができるConcurrent Activation の2つの方法があります。また、あるエディションからあるエディションへの更新をオンライン中にサービスを 停止せずに実施する場合は、 •グループ・ロールアウト •アトミック・ロールアウト の2つの方法があります。 以降のページでは、これらの詳細についてご説明します。 8 アプリケーション・エディション アプリケーション・エディションとは 同じ名前を持つJ2EEアプリケーションのインスタンス インスタンスごとにユニークな”エディション“名を付けて管理 エディション･コントロール･センターで管理 4 任意のエディション番 号または名前で識別・ 管理 ここでエディションに関してもう少しご説明します。WebSphere XDでは前述のように、 同じアプリケーション名を持つJ2EEアプリケーション（同一コンテキストルートを持つ J2EEアプリケーション）のインスタンスを同一セル内に複数デプロイすることを許可しま す。これらは、同一アプリケーションの異なるエディション（バージョン）として扱われ、そ れぞれユニークな「エディション名」を付けて識別、管理が可能です。エディションの管 理はエディション・コントロール・センターで行います。 エディション・コントロール・センターは管理コンソールからアクセス可能です。エディショ ン・コントロール・センターを使って現在インストールされているアプリケーションとそれぞ れのアプリケーションのインスタンス（＝エディション)を管理することが可能です。 9 エディション･コントロール･センター エディションの管理 活動化 エディションを開始可能状態（活動中）にする 異なるターゲットにデプロイされたエディションは同時に活動化可能 妥当性検査 同一ターゲットにデプロイされたエディションのテスト使用モード ロールアウト Interruption-freeなエディションの更新 非活動化 エディションを使用不可能状態（活動停止）にする エディションは同じまた は異なるターゲットにデ プロイすることができる エディション・コントロール・センターでは個々のエディション単位で管理をすることがで きます。エディションはearファイルの単位でインストールされ、インストール時に付けた 名前で登録されます。エディション・コントロール・センターではエディション名とデプロイ されているターゲットのクラスター名および現在の状態を確認することができます。 活動化とは、エディションを活動中状態にし、アプリケーションを開始できる状態にしま す。同一ターゲットに複数のエディションがデプロイされている場合は、1時点で1つのエ ディションのみが活動化可能です。最初にインストールされたエディションは自動的に 活動化され、追加で同じターゲットにマップされたエディションは活動停止状態でインス トールされます。エディションは上記の図のように異なるターゲットに対してインストール することも可能です。 妥当性検査とは、同一ターゲットにデプロイされたエディションを本番の擬似環境でテス トする目的で活動化する機能です。 ロールアウトは、動的または静的クラスターで稼動中の特定のエディションから他のエ ディションへのinterruption-freeな更新を実行する機能です。ロールアウトの方法には2 種類あります（詳細は後述）。エディションはさらに非活動化することもできます。エディ ションは非活動化されると、そのエディションのアプリケーションは自動的に停止されま す。また、ロールアウトを実施すると、旧エディションは活動停止状態に変更されます。 10 ロールアウト機能① グループロールアウト OLTP_DC1 AS1 1.0 1.1 ODR AS2 1.0 1.1 更新中のサーバーへ の割り振りを自動的に 制御 1.1 1.1 非活動化 活動化 AS3 1.0 クラスター内のサー バーを順番に更新 新エディション自体は デプロイされているが 活動停止状態 更新時は新エディショ ンが活動化され旧エ ディションが非活動化 される 1.1 動的クラスター/ 静的クラスター 更新中は新旧バージョンが混在 次にロールアウトについて説明します。ロールアウトとは、特定のエディションから特定 のエディションに更新（リプレース）をアプリケーションのサービスを停止することなく、ク ライアントから透過的に行う機能です。更新の対象はシステムは、WebSphere XDが導 入されたノードで構成された動的クラスターまたは静的クラスターになります。また、ロー ルアウトの対象はエディション（EAR単位）での更新となり、WAS V6がサポートするFine Grained Application upgradeを使った差分の更新などはサポートしていません。 また、ロールアウトには2つの方式がサポートされます。 1つ目は「グループ・ロールアウト｣方式です。 これはクラスター内のメンバー・サーバーを順番に更新する機能です。メンバー・サー バーであるアプリケーション・サーバーを1サーバーずつ更新するため、クラスター全体 としてはサービスを中止することなく、アプリケーションの更新を実施することができます。 また更新中は一時的にアプリケーションが中断するため、On Demand Router (ODR) は更新中サーバーを認識し、そのサーバーにはリクエストを振らないようにします。これ により、クライアントはメンテナンス中であることを意識せずに継続的にサーバーにアク セスすることが可能です。ロールアウト処理中は、それぞれのサーバーにおいて、現在 稼動中の旧エディションであるアプリケーションを停止し、非活動化して、新エディション を活動化し、該当するアプリケーションを開始するという処理が発生します。 グループ・ロールアウトの特徴としては、更新中にクラスター内に新旧エディションが混 在する時間が存在することです。したがって、一時的に新旧エディションの混在が可能 な場合に使用可能なロールアウト方式となります。 新旧エディションが混在できない場合は次のページで説明する「アトミック・ロールアウ ト」方式を使用します。 11 ロールアウト機能② アトミック・ロールアウト OLTP_DC1 AS1 1.0 1.1 AS2 クラスター内のサー バーを半分ずつ更新 1.0 1.1 ODR から1.1へ切り替 えるタイミングで到 着したリクエストは キューイングされる AS3 1.0 1.1 1.0 新旧エディションが同 時に稼動はしても同時 に割り振り対象になる ことはない 1.0 AS4 動的クラスター/ 静的クラスター 1.1 一時点で必ず1つのエディション しか活動しないことを保証する 更新 もう1つのロールアウト方式は「アトミック・ロールアウト｣方式です。この方式では、動的 （または静的）クラスターのメンバーを半分にわけて、半分ずつ更新する機能です。上記 の例では2サーバーずつが更新されます。グループ・ロールアウト方式同様にロールア ウト中のサーバーにはクライアント・リクエストは割り振られません。更新処理もグループ・ ロールアウト同様に旧エディション・アプリケーションが停止されてから非活動化され、新 エディション・アプリケーションが活動化されてから開始されます。 アトミック・ロールアウトでは新旧エディションが混在しないことが保証されることが特徴と なっています。新エディションがロールアウトされて活動化され開始（上記の図の例で行 くとAS1とAS2でのエディション1.1）された後、ODRはまずAS3、AS4への割り振りを停 止し、その後はじめてAS1、AS2上の新しいエディションにリクエストの割り振りを再開し ます。この仕組みによりクライアントから見ると、同時に新旧エディションが混在すること はありません。 ただし、切り替えのタイミングでクラスター全体として寸断が発生します。そこで、この間 に到着したクライアントからのリクエストをODRはキューイングし、新エディションに割り振 り可能になった時点でリクエストの割り振りを再開します。 12 ロールアウト機能② On-demand routers quiesce & stop Edition 2.0 1.0 Edition 2.0 1.0 リクエスト restart request request quiesce & stop Edition 2.0 1.0 Edition 2.0 1.0 request 動的クラスター restart 上の図はアトミック・ロールアウト方式をアニメーションで説明している図になります。 13 ロールアウトの実行 エディションの戻しも同じ手順 でサポート ロールアウトの実行は、エディション・コントロール・センターから行います。 管理コンソールから「アプリケーション」→「エディション・コントロール・センター」→「＜ア プリケーション名＞」を選択すると、上記画面が表示されます。これからロールアウトした いエディションをチェックして「グループ・ロールアウト」または「アトミック・ロールアウト」を クリックすると、ロールアウトが開始され、管理コンソール上に経過のメッセージが表示さ れます。 ロールアウトは、「活動停止」または「妥当性検査」状態になっているエディションに対し て実行することができます。また、新エディションから旧エディションへの戻しも同様に ロールアウト機能を使ってノンストップで実行することができます。 14 ロールアウト処理の仕組み ① 更新対象サーバーのノードが保守 モードに設定される ② ODRがアプリケーション･サー バーに対する割り振りを停止する アプリケーション配置、 ヘルスモニタリングの 対象外になる 1.0 AS 1.1 によるQuiesce の実施 リクエストの処 理は続行 ODR stop in-flight 1.0 AS 1.1 ③ アプリケーションが停止される ④ 構成、状態の変更と同期 AS 1.0 1.0 1.1 1.1 エディションの状 態の変更と同期 処理の実施 ⑤ アプリケーションの再起動 ⑥ 保守モードの解除 1.0 AS 1.1 からの割り 振り再開 通常モードに戻 る ODR ここで、ロールアウトが実行される間に実際に行われる処理を簡単にまとめます。 グループ・ロールアウトまたはアトミック・ロールアウトが開始されると、それぞれの方式に 従って1つのサーバーまたは複数のサーバーに更新処理が発生します。この際に、 ① まず更新対象のアプリケーション・サーバーが稼動しているノードが保守モードに設 定されます。これにより、このノードはアプリケーション配置の対象から外されます。また アプリケーション・サーバー・プロセスのウェイトが0にセットされます。 ② DWLMウェイトが0になったため、ODRからアプリケーション・サーバーへのリクエスト の割り振りが停止されます。In-flightのリクエストはそのまま処理されます。 ③ 更新対象のアプリケーションが停止されます。 ④ 旧エディションが非活動化され、新エディションが活動化されます。妥当性検査状態 （後述）からのロールアウトの場合、ここでアプリケーションがマップされるターゲットが妥 当性検査用クラスターから本番クラスターに変更されます。また、これらの構成情報の変 更がセル内で同期化されます。 ⑤ 活動化された新エディション・アプリケーションが開始されます。 ⑥ ノードに対する保守モードが解除され、アプリケーション配置およびDWLMの対象と して復活します。ここで、ODRからの割り振りが再開されます。 なお、ロールアウトの実施にはデプロイメント・マネージャーとノードエージェントが稼動 している必要があります。 15 複数エディションの同時稼動をサポート 妥当性検査モード Concurrent Edition 新エディションを一時的にテストアクセス用に稼動 同一デプロイメント・ターゲットにインストールした異なるエディションを同時に活動化 異なるデプロイメント・ターゲットにインストール 同時に複数のエディションを活動化することが可能 エディションごとに異なるターゲットで稼動させ異なるサービス・ポリシーで運用可能 ルーティングポリシー リクエスト・タイプに応じてルーティング先のエディションを変更 複数エディションの同時稼動について次に説明します。 WebSphere XDではエディションという概念を追加し、同一アプリケーションの複数エディションのデプロ イをサポートしますが、これらのエディションを同時に複数起動することが可能となっています。複数エディ ションを同時に稼動（活動化）させるには2つの形態がサポートされています。 •妥当性検査モード 新エディションの公開前にテスト用途で、本番の擬似環境（Validation用クラスター）で稼動させ るためのモードです。同一ターゲット（OLTP_DC1動的クラスター）にデプロイされた活動停止中 のエディションに対して設定可能です。図の例では、OLTP_DC1動的クラスターにマップされた エディション1.0の新エディション1.1が妥当性検査モードに設定されています。妥当性検査に設 定すると、エディションの状態が「妥当性検査｣状態になります。 •Concurrent Edition では、異なるターゲットにインストールされた複数のエディションを同時に活 動化させることができます。妥当性検査モードと異なり、同時に活動化させるエディションは別々 のターゲットにデプロイされている必要があります。Concurrent Editionではエディションごとに異 なるサービス・ポリシーを定義し、別々のQoSを適用させて運用することが可能です。 いずれの場合も、同時に起動する各エディションは同じアプリケーション名で同じコンテキスト・ルートを持 ちます。どのエディションにどのリクエストをルーティングするかはルーティング・ポリシーに定義します。 ODRは複数エディションが稼動している場合、ルーティング・ポリシーに定義されたルールに従ってクライ アント・リクエストをしかるべきエディションを稼動しているサーバーに対してルーティングします。 ルーティング・ポリシーの使用例はこのセッション資料の後半で説明します。またルーティング・ポリシーの 実際の設定方法は、「Dynamic Operations and Scale out」のセッション資料を参照してください。 Concurrent Edition 16 妥当性検査 本番適用前のテスト用モード 本番構成を複製した環境で動作確認ができる メンバー・サーバーは2サーバーまで始動可能 OLTP_DC1 OLTP_DC1-Validation OLTP_DC1 1.0 AS1 1.1 1.1 V-AS1 ルーティン グ・ポリシー AS1 1.0 1.1 の本番への ロールアウト ODR ルーティン グ・ポリシー 1.0 特定のリクエスト・タイ プ（例： テストメンバー からのリクエスト）のみ Validationサーバーへ 送信 一般ユーザー テストチーム AS2 AS2 1.1 1.0 V-AS2 クローン作成 1.1 が非活動化される オリジナル・ターゲットに対して1.1がマッピン グされ活動家される •クローンが削除される •1.0 • 妥当性検査モードとは、新エディションを更新し公開する前に本番環境に近い環境で 稼動確認をすることを可能にするモードです。エディションを妥当性検査モードに設定 すると、同一デプロイメント・ターゲットにインストールした新エディションが、現在本番エ ディションが稼動している環境から作成されたクローン・クラスター上にマップされ、状態 は「妥当性検査｣状態になります。これは、活動中状態と同様にそのエディションのアプ リケーションが開始可能状態であることを表しますが、そのエディションはテスト用に特 別に本番クラスターをクローン化したValidation用クラスター上に一時的にマップされ稼 動することを意味します。 妥当性検査モードでは、本番環境のクラスター（OLTP_DC1)のクローンとして妥当性検 査用クラスターが自動的に作成され、オリジナルのクラスター名に”-Validation”が追加さ れた名前になります。妥当性検査に設定されたエディションはこのValidationクラスター にマップされることによって、一時的にオリジナルの構成を複製した環境の中で稼動さ せることができます。どちらのエディションにルーティングするかは、あらかじめアプリ ケーションに対してルーティング・ポリシーを定義しておきます。 また検証が完了し、新エディションを本番構成に移したい場合は、いずれかのロールア ウトを実施することで、妥当性検査用クラスターから本番クラスターに対してエディション の更新が可能です。この際、更新が終了すると、妥当性検査用サーバーは自動的に停 止され、妥当性検査用クラスターは自動的に削除されます。 なお、妥当性検査用に作成されるクラスターは、元のクラスターが動的クラスターの場合、 同じノード・グループ内で動的クラスターとして作成され、ノード・グループ内の全ての ノードにメンバー・サーバーが作成されますが、妥当性検査モードでは、同時にメン バー・サーバーは最大2つまでのみ始動可能となっています。したがって、サービス・ポ リシーを定義してもサービス・ポリシーが基本的には適用されないモードであるといえま す。 17 妥当性検査用サーバー構成 自動的にValidation用クラスターとメン バーがオリジナルのクラスターの複製 として作成され、Validationに設定され たエディションがマッピングされる 前述のように、妥当性検査に設定すると自動的にオリジナルのターゲットであるクラス ターからクローンが作成され妥当性検査中のエディションがマップされます。上記はそ の状態を管理コンソールで確認した例になります。 まずエディションコントローラーでは、妥当性検査に設定したいエディションをチェックし て「妥当性検査」をクリックします。そうすると、状態が「妥当性検査」に変更されターゲッ トが新しく作成された妥当性検査用サーバーに変更されます。この状態では、妥当性用 クラスター（OLTP_DC01-Validation）は作成され、その上でEdition1.1が開始可能な状 態になりますが、まだアプリケーションは開始されていません。 妥当性検査用に作成されたクローン・クラスターはデフォルトでは「手動」に設定されま す。実施にエディションの検証を実施する前に、妥当性検査用サーバーを起動する必 要があります。妥当性検査用クラスターのメンバーは<クラスター名>－Validation_＜ ノード名>という名前で作成されます。 管理コンソールを使用する場合は、他のサーバー同様に「サーバー」→「アプリケーショ ン・サーバー」から妥当性検査用に作成されたサーバーを選択して「始動」をクリックしま す。このとき、XD V6の仕様では同時に２つまでの妥当性検査用サーバーが開始可能 となっています。 18 Concurrent Editionサポート 同一アプリケーションを同時に複数稼動 エディションごとに異なるサービス･ポリシーで運用できる OLTP_DC1 OLTP_DC2 1.0 グループ・メンバー・リクエスト Goldグループ・メンバー・リクエスト Platinum Edition 1.0 サービス・ ポリシー AS1 重要度： 非常に高 目標応答時間： 800ms ODR 1.0.1 V-AS1 ルーティン グ・ポリシー サービス・ ポリシー 1.0 各エディションに振り分ける ためのルーティングの条件を 記述 AS2 Edition 1.0.1 1.0.1 V-AS2 重要度： 高 目標応答時間： 1200ms 妥当性検査モードが、一時的にテスト目的に使用するモードであるのに対し、 Concurrent Editionは、長期的に複数のエディションを同時に活動させたい場合に使 用します。Concurrent Editionでは、各エディションは異なるターゲットに対してデプロイ します。WebSphere XD V6環境では、このように異なるターゲットにデプロイされたエ ディションは同時に活動化し別々のサーバー上で稼動させることが可能となっています。 図の例では、エディション1.0はOLTP_DC1動的クラスターに、エディション1.0.1は OLTP_DC2動的クラスターにインストールされています。クライアント・リクエストをどちら のエディションに割り振るかはあらかじめルーティング・ポリシーに定義しておきます。 また、サービス・ポリシーは各エディションごとに設定するため、エディションとにQoSを 変えたい場合には異なるサービス・ポリシーを持たせることができます。たとえば、中身 は同じアプリケーションでも、ユーザーが属する会員グループ別にエディションとして分 けることで、特定の会員グループに対するQoSを高く設定し、運用することが可能となり ます。 19 エディションへのルーティングの制御 ルーティング・ポリシー 複数のエディションが同時に稼動する場合に必須 条件とルーティング先エディションに関するルールを記述 アプリ StockTrade ケーション Platinum Group のリクエスト Gold Group ODR 用ルーティング・ポリシー PL StockTrade GL If <Platinum Group Member> permit routing to Edition PL If <Gold Group Member> permit routing to Edition GL If <Silver Group Member> permit routing to Edition SL DC_01 のリクエスト DC_02 Silver Group のリクエスト SL DC_03 アプリ StockQuery 一般ユーザーのリクエスト DC_04 ODR テストチームのリクエスト DC_04Validation ケーション 1.0 1.1 用ルーティング・ポリシー StockQuery If <General users> permit routing to Edition 1.0 If <Test team Member>permit routing to Edition 1.1 妥当性検査モード中やConcurrent Editionによる複数のエディションが同時に稼動して いる場合に、各エディションに対するリクエストの割り振り制御はあらかじめルーティン グ・ポリシーに記述しておきます。ルーティング・ポリシーはアプリケーションに1つ作成さ れ、そのアプリケーションのエディションが複数稼動している際には必須となります。 ルーティング・ポリシーにはリクエストを識別するための条件とその条件にマッチした際 のルーティング先のエディションを定義します。 たとえば、上記のConcurrent Editionの例では、ユーザーが属するグループ別にエディ ションを用意し、異なるクラスター上で稼動しています。ユーザーが属するグループ別に ユーザー・リクエストを識別し、しかるべきエディションにリクエストをルーティングすること ができます。リクエストを識別するルールの定義方法や定義に使用できる条件について はDynamic Operations and Scale outのセッション資料を参考にしてください。 上記の妥当性検査の例でも同様に、テストチーム（あるいはテストチームのクライアント IP)からのリクエストは妥当性検査状態のエディションへ送信し、一般ユーザーのリクエス トは本番エディションにルーティングするなどの記述をルーティング・ポリシーに定義す ることで、本番環境の中で本番エディションを稼動しつつ同時に新エディションをテスト することが可能となります。 20 【参考】アプリケーション・エディションのリポジトリー構造 DMGR のマスターリポジトリ インストール済アプリケーション アプリケーション エディション workclasses 作業クラス名 workclass.xml workclasses 作業クラス名 エディション名 ： <アプリケーション名>-<エディション名>となる workclass.xml 上記はWebSphere XD V6のアプリケーションに関するリポジトリー構造です。ここから わかるように、ルーティング・ポリシー(workclass.xml)はアプリケーションに1つ存在する ためアプリケーション名のディレクトリ配下に配置され、エディションごとに作成される サービス・ポリシー(workclass.xml)は各エディションごとのディレクトリの配下に配置され ています。 21 シナリオ ① 妥当性検査モードの使用 動的（静的）クラスターの作成 ベース・エディションの導入 サービス・ポリシーの定義 ステップ1 ベース・エディションの稼動 ステップ2 新エディションの導入 ステップ3 ルーティング・ポリシーの定義 新エディションの妥当性検査の設定（テスト環境へのデプ ステップ4 ロイ） ステップ5 妥当性検査用クローン・サーバーの起動 新エディションの本番構成へのロールアウト ステップ6 次にエディション・コントロール・センターを使用するシナリオとして、① 妥当性検査を行 う手順と、②Concurrent Edition環境を構築する手順の概要を説明します。 このページの手順は妥当性検査モードを使用する際の手順です。上記の各ステップの 設定内容の詳細は以降のページで説明しています。 22 シナリオ② Concurrent Editionでのアプリケーション運用 動的（静的）クラスターの作成 ステップ1 エディション1の導入 エディション2の導入 サービス・ポリシーの定義 サービス・ポリシーの定義 ステップ2 ルーティング・ポリシーの定義 ステップ3 ステップ4 エディション2の活動化 サーバー起動 ステップ5 このページの手順はConcurrent Edition環境を構築する際の手順になります。サービ ス・ポリシーの定義の手順はこのセッションでは省略しています。サービス・ポリシーの定 義方法については「Dynmic Operations and Scale out」のセッション資料を参照してく ださい。 23 ステップ1 Baseエディションの導入 Baseアプリケーション・エディションのインストール アプリケーション・インストール・ウィザードにエディション名を指定する項目 が追加 アプリケーション名： アプリ ケーションの名前を指定。エ ディション間で共通 アプリケーション・エディショ ン：同じアプリケーション名を 持つ異なるエディションを識 別するためのエディション名 を指定 ステップ1はアプリケーションの最初のエディションの導入手順です。エディションは通常 のエンタープライズ・アプリケーションとしてインストールします。管理コンソールで「アプ リケーション」→「新規アプリケーションのインストール」を選択し、アプリケーションのイン ストール・ウィザードを使ってインストールします。手順は通常のエンタープライズ・アプリ ケーションのインストールとほぼ同じですが、WebSphere XD V6環境では上記のように、 途中でアプリケーションのエディション名を指定する画面が表示されます。 アプリケーション名はすべてのエディションで共通の名前になりますが、個々のエディ ションごとに異なるエディション名をつける必要があります。 24 ステップ2 次エディションの導入 新アプリケーション・エディションのインストール エディションごとにデプロイ先を指 定 シナリオ①の場合旧エディションと 同じターゲットを指定 シナリオ②の場合は異なるクラス ターを指定 サービス・ポリシーを他のエディ ションから複製する場合に複製元 のエディションを指定 （通常シナリオ①で使用） ステップ2は2つ目以降のエディションのインストール手順です。2つ目以降のエディショ ンもBaseエディション同様に「新規アプリケーションのインストール」ウィザードを使って インストールします。「インストール・オプションの選択｣画面ではBaseエディションのイン ストール同様に、アプリケーション名とこのエディションを識別するためのエディション名 を指定します。 「サーバーにモジュールをマップ｣画面では、このエディションをマップするサーバーを 指定します。妥当性検査を使ってこのエディションをテストし、その後既存のエディション を更新する（シナリオ①の場合）には、現在の稼動中のエディションと同じターゲットに マップします。シナリオ②のようにConcurrent Edition環境を構築する際には異なるター ゲットにマップします。 2つ目以降のエディションをインストールする際には最後に「既存作業クラスの複製」を 設定する画面が表示されます。サービス・ポリシーはエディションごとに異なる定義をも たせることが可能ですが、既存のエディションにすでに定義されているサービス・ポリ シーをコピーして使用する際には、この画面で、コピー元のエディションを指定します。 上記の画面キャプチャーはステップ１でインストールしたBase エディションであるエディ ション1.0に対してすでに定義済みのサービス・ポリシー（作業クラス）をコピーするように 設定している例です。ここで選択したエディションに定義されたサービス・ポリシーがそ のまま新しいエディションにも定義されます。また、ここで何も選択しないと、デフォルト の作業クラスで定義されているサービス・ポリシーのみが定義されます。 ここで複製したサービス・ポリシーは後で追加編集することも可能です。 25 ステップ3 ルーティング・ポリシーの定義 アプリケーション単位で作成 複数エディションを同時に稼動 する場合に使用される ルールの条件式と条件にマッチし た場合のルーティング先のエディ ションを指定（またはその他のアク ションを指定） ルールはルール・ビルダーを使っ て作成 ステップ３はルーティング・ポリシーの定義です。シナリオ①、②いずれの場合でも、複 数エディションが同時に稼動するため、ルーティング・ポリシーを使ってリクエスト・タイプ ごとにルーティング先エディションを制御します。 ルーティング・ポリシーの定義についての詳細は「Dynamic Operations and Scale out」のセッション資料を参考にしてください。ここでは概略を説明します。ルーティング・ ポリシーは「アプリケーション」→「エンタープライズ・アプリケーション」からいずれかのエ ディションのアプリケーションを選択します。アプリケーションの設定画面から「ルーティ ング・ポリシー｣タブを開くと、上記のような設定画面が表示されます。ルーティング・ポリ シーはエディション（エディション自体も実際には1つのearファイルでエンタープライズ・ アプリケーションとしてインストールされるため）ごとに設定画面がありますが、ルーティン グ・ポリシー・ファイル自体はエディションではなくアプリケーションごとに1つ作成され、 各エディションで共有されるため、どのエディションの定義画面で定義を作成しても実体 は1つとなっています。 ルーティング・ポリシーではルーティングの条件（ルール）と条件にマッチした際のルー ティング先エディションを設定します。ルールはルールビルダーを使って定義します。 26 ステップ4 複数エディションの活動化 妥当性検査の場合 オリジナル・ターゲットからクローン・クラスターが作成される 自動的に新エディションがクローンにマッピングされる クローン・サーバーおよびクローン上のエディションが開始可能状態になる Concurrent Editionの場合 エディションを活動化すると、そのアプリケーション・エディションが開始可能状態になる ステップ4では複数エディションの活動化を行います。 シナリオ①の妥当性検査を行う場合には、妥当性検査に設定したいエディションを チェックして「妥当性検査」をクリックします。シナリオ②のConcurrent Edition環境を構 築する際にはエディションをチェックして「活動化」ボタンをクリックします。妥当性検査の 場合は、エディションの状態が「妥当性検査」に変更され、Concurrent Edition環境の 構築の場合には、「活動中」になります。この「妥当性検査｣と｢活動中」という状態は、い ずれもエディションが開始可能状態になったことを意味しますが、この状態ではまだア プリケーションは開始されていません。次のステップ5に進んでアプリケーション・サー バーを開始する必要があります。 27 ステップ5 サーバーの開始 該当するサーバー・プロセスを起動 する ステップ4までの手順で新たにインストールした新しいエディションは始動開始状態には なりますが、実際のサーバー・プロセスは起動してないため、このステップ５でサーバー を起動してアプリケーションを開始します。 シナリオ①の妥当性検査の場合には、自動的に作成された妥当性サーバーのいずれ かを起動します。Concurrent Editionの場合は、動的クラスターを自動に設定するか、 動的クラスターまたは静的クラスターの個々のメンバーを個別に起動します。 28 ステップ6 妥当性検査からの更新 妥当性検査用クローンで稼動しているエディションを本番 （オリジナルのターゲット）にロールアウト 手順は通常のロールアウトと同じ ロールアウトが完了すると、自動的にクローンが削除され る エディションを選択してロールアウ トボタンを実行 ロールアウト後は1.0が活動停止状 態になり、1.1が活動中になる ステップ6は、シナリオ①の妥当性検査を使用する際の手順です。ステップ5までで、新 しいエディションを妥当性検査モードに設定し、妥当性検査用に作成されたサーバー 上で稼動します。ここで新エディションはテスト可能状態になります。ルーティング・ポリ シーに定義されたルールにしたがって、一般ユーザーのリクエストは現状のエディション に割り振りつつ、テストチームのリクエストのみを妥当性検査中の新エディションに割り 振ることができます。 検証が終了し、現状エディションを新しいエディションで置き換える際は、前述のロール アウト機能を実行します。ロールアウト機能を使うことで、クラスター全体としてはサービ スを停止せずに更新が可能です。 ロールアウトする際には、妥当性検査中のエディションをチェックしていずれかのロール アウトボタンをクリックします。ここで旧エディションは新エディションに置き換えられます。 ロールアウトの手順や仕組みは通常のロールアウトと同じです。 ロールアウトが完了すると、旧エディションは活動停止状態に変更され、新エディション は活動中状態になります。この時、新エディションは元のエディションがマップされてい たターゲット（ここではOLTP_DC1）に再マップされ起動されます。ロールアウトが無事 完了すると、妥当性検査用のクローン・クラスター（およびそのメンバー・サーバー）は自 動的に削除されます。 このように、妥当性検査を使用すると、エディションの管理、テスト、テスト構成の作成、 ロールアウト、テスト構成の削除を自動的に行うことができます。 29 FAQ ① アプリケーション・エディション・ロールアウトが使用できる環境は？ WebSphere XDが導入されたノードのみが対象 動的クラスターおよび静的クラスターをサポート ODRからの割り振り対象である必要がある Interruptive-freeなロールアウトにはオンデマンド・ルーターが必須 ODRの背後のサーバーに対するロールアウトをサポート V6.0ではHTTPおよびHTTPSプロトコルのみサポート ロールアウト時の再起動の単位はアプリケーション ロールアウトにはノードエージェントが起動している必要がある ロールアウト中に停止しているメンバー・サーバーに対しても更新は正しく行われる 複数エディションを同時に活動化できる環境は？ 異なるクラスターへデプロイした場合は複数エディション同時に活動化（起動）が可 能 妥当性検査モードに設定したエディションは、オリジナルのターゲットから作成され たクローン･クラスター上で稼動 異なるエディションを同じクラスター上で同時に活動化はできない メンバー・サーバーごとにエディションを変えることはできない （グループ・ロールアウト中を除く） 複数のエディションが同時に活動化される場合はルーティング･ポリシーの定義が 必須 エディション・コントロール・センターを使用したノンストップでのアプリケーション更新が できるのは、上記の条件を満たしている場合のみです。また、WAS V6が提供するFine Grained Update機能との連携はできません。更新するアプリケーションはEAR単位に なります。 またWebSphere XDが導入されていないノードは対象外となります。さらに、ロールアウ トはODRと連携するため、ロールアウトの対象となるノードはODRの背後のノードとなり ます。ロールアウト実施時には、デプロイメント・マネージャーと各ノード上のノードエー ジェントが稼動している必要があります。InfoCenterには、ロールアウトにはアプリケー ション・サーバー・プロセスとノード・エージェントが稼動している必要があると記述されお り、実際にロールアウト中にWarningメッセージが表示されますが、ロールアウト後の次 回起動時には正しいエディションのアプリケーションを起動しますので、更新自体は正 しく行われています。 また、複数エディションを同時に活動化できるのは、妥当性検査モードかConcurrent Edition環境のみです。異なるエディションを同時に同じクラスター上で活動化させること はできません。 30 FAQ ② ルーティング･ポリシーはどう使用される？ ルーティング･ポリシーはアプリケーションに１つ作成される 各エディションに対する振り分けルールを記述 サービス･ポリシーはどう使用される？ サービス･ポリシーはアプリケーション・エディションごとに作成される 妥当性検査モード中のクローン･クラスターはテンポラリーのテスト用環境 を提供することが目的のため、サービス･ポリシーを定義しても実際には適 用されない 妥当性検査用動的クラスターのメンバー・サーバーは、ノードグループ内の全 ノード上に作成されるが、2サーバーまでしか起動できない Concurrent Edition環境を使用時には、エディションごとにサービス・ポリ シーを定義することで異なるQoSを適用できる ルーティング・ポリシーはエディションごとに作成されるのではなく、アプリケーションに対 して1つ作成され、すべてのエディションで共有されます。逆に、1つのルーティング・ポ リシーで全てのエディションに対するルーティング制御を網羅する必要があります。 サービス・ポリシーはエディションとに作成されます。サービス・ポリシー自体は、 Continuous Availabilityにはあまり関係がないためこのセッションでは詳細にはふれて いませんが、Concurrent Edition環境では異なるエディションごとに異なるサービス・ポ リシーを定義して異なるQoSの基に稼動させることが可能です。 妥当性検査モードに設定した場合、エディションに定義されたサービス・ポリシー定義 はそのまま残ります。ただし、妥当性検査モードはそもそもテンポラリーなテスト環境を 本番環境の中に作成して使用するという用途で提供されており、サービス・ポリシーによ る運用の対象としてはデザインされていません。妥当性検査用サーバーは最大2プロセ スまでしか同時に始動できない仕様となっており、事実上妥当性検査中はサービス・ポ リシーは適用されないと考えたほうがよいでしょう。 31 High Availability Deployment Manager デプロイメント・マネージャーのHA構成をサポート DMGRのプラットフォームは同一である必要はない 常に1台がActive (Primary)として稼動 DMGR上のHAコンポーネントが互いに通信してActive DMGRを決定 残りはStandbyとして稼動 Active DMGR障害を検知し、いずれかのStandbyがテークオーバー ODRをフロントに置くことで、Active DMGRを意識することなくアクセス 可能 管理コンソール Active DMGR ノード DM ノード 構成ファイル プロファイル 構成ファイル アプリケーション ODR wsadmin プロファイル NA Standby DMGR DM ノード プロファイル SAN FS DFS V4 次にデプロイメント・マネージャーを冗長化するHigh Availability Deployment Manager （以下DMGR)機能についてご紹介します。 WebSphere XD V6では新たにDMGRの冗長構成をサポートします。同一セル内には 1台のアクティブDMGRが常に稼動し、残りのDMGRはスタンバイとして稼動します。 DMGRはHAコンポーネントにより監視・管理され、アクティブDMGRに障害が発生する とただちに検知されスタンバイDMGRのいずれかが次のアクティブDMGRに選ばれ、処 理を引き継ぎます。 ODRをHA DMGR用に構成することで、ODRは常にどのDMGRがアクティブかを把握 し、管理コンソールなどの管理系リクエストを常にアクティブなDMGRに送信することが 可能となります。これにより、管理者はどのDMGRが現在アクティブかを意識することな く常にODR経由で正しいDMGRにアクセスすることが可能となります。 32 High Availability Deployment Manager xd_hadmgrAdd.sh(.bat)で構成 共有ファイル・システムの使用 ODRは常にどのDMGRがアクティブかを把握 ODR上に管理用のHTTP、HTTPS、SOAP Connectorポートを別途定義する JMX RMIのサポートはなし（JMX SOAP Connectorのみ） スタンバイDMGRはプロセスは稼動しているが管理機能は使用できな い 各DMGRノードは共有ファイル・システム上のマスター構成情報を共有 ワークスペースも共有ファイル・システム上に置く On Demand RouterがActive DMGRへのルーティングをサポート 2台目以降のDMGRノードから実施 オリジナルDMGRが管理するセルに新規DMGRをスタンバイとして追加 構成情報に対して複数のDMGRが同時に操作できない スタンバイDMGRに対するログインやJMXリクエストは拒否される Historical Stats Loggingを使用している場合はHA DMGR構成を検討 ログはDMGRが取得して保管しているため HA DMGRはxd_hadmgrAdd.sh(.bat) スクリプトを使って構成します。2台目以降の DMGRノードのプロファイルから実行します。このスクリプトにより、セル内に新しい DMGRを現在のDMGRのスタンバイとして構成して追加します。 HA DMGRを使うには、DMGR間で共有ファイル・システムを使用する必要があります。 セルのマスター・リポジトリーおよびワークスペース（テンポラリー・スペース）はDMGR間 で共有されます。したがってこれらは、SANなどの共有ファイル・システム上に保管する 必要があります。 ODRには管理用のHTTP,HTTPSおよびSOAP Connectorポートを追加定義し、管理 者はこれらのポートを使ってODR経由で現在アクティブなDMGRにアクセスすることが できます。 スタンバイDMGRではDMGRプロセス自体は稼動していますが、複数のDMGRから同 時に構成リポジトリーを操作することはできません。スタンバイDMGRに対するログイン やJMXリクエストは自動的に拒否されます。 WebSphere XD環境において、DMGRはHistorical Statsのログを取得しログファイル に保管したり、タスク管理サービスが稼動してヘルスモニタリングによるヘルス管理など を行っています。これらの機能を使用している場合は、DMGRの可用性を考えてHA構 成をとることが推奨されます。 なお、DMGRノードは同じコアグループに所属させることが推奨されます。 33 ヘルスモニタリング XDランタイムの健康状態を判断するためのポリシー 管理者が事前に条件を設定する ヘルス・ポリシー XDランタイムの非正常状態を検知し、アクションを実行 ヘルス管理コントローラーがヘルス･ポリシーに基づいてモニタリング ヘルス管理機能とは ヘルス管理機能を担うオートノミック・マネージャー セル内に１つ、いずれかのプロセス上で稼動 HA Manager管理下で稼動し可用性を確保 定義されたヘルス・ポリシーに基づきモニタリングを実施 サーバーの再起動などをアクションとして実行または通知 異常を検知すると、 「タスク管理サービス」にタスクが生成される ヘルス管理コントローラー WebSphere XDのヘルスモニタリングは、XDランタイムをモニタリングして非正常な状 態を検知し、必要なアクションを実行する機能および環境を提供します。ヘルス管理コ ントローラーというオートノミック・マネージャーの1つがいずれかのノードで稼動し、あら かじめ管理者によって定義されたヘルス・ポリシーに従ってセル内のXDランタイムをモ ニタリングし、ポリシーに反する状態を非正常状態と認知して、タスク管理サービスに通 知しタスクを生成したり、ポリシーに定義されたアクションを実行します。 ヘルスポリシーとはXDランタイムの健康状態を判断するための条件で管理者によって 定義されます。 この機能自体はV5.1からサポートされており、仕組み自体は変更されていません。V6 ではヘルス・ポリシーにいくつか新しいヘルス条件が追加されています。 34 ヘルスポリシーの定義 7つのタイプのヘルス条件から設定 条件によっては閾値などを設定 アクションはサーバー再起動 条件によってはメモリーダンプやヒープダンプの取得を アクションとして設定可能 モニタリング対象の設定 セル全体/動的クラスター/クラスター/アプリケーションサーバー モードの設定 監視 － 状況の監視とタスクの通知。タスクではアクションを提案。 アクションの実行にはユーザーの承諾が必要。 自動 － 状況の監視からアクション実行まで自動 ポリシーの変更は動的に反映される ヘルスポリシーはあらかじめ管理者が定義するもので、ここで記述された条件に応じて ヘルス管理マネージャーがセル内のXDランタイムを監視します。 ヘルスポリシーでは、XDランタイムの健康状態を判断する条件として7つのヘルス条件 を使って定義します。条件によってはモニタリングの閾値などを設定します。（設定する 内容は次のページの表を参考にしてください） またそれぞれのポリシーにはアクションとしてサーバーの再起動とヘルス条件によって は V6からはメモリーダンプやヒープダンプの取得を設定できるようになっています。 モニタリング条件とアクションを定義し、さらにその条件を監視する対象を設定します。ま た、ヘルスモニタリングには、アクションまで自動実行する「自動」モードとアクションの実 行には管理者の受諾が必要な監視モードの2つを設定できます。 35 【参考】 ヘルスポリシー条件 ヘルス条件 期間ベース条件 説明 モニタリング対象サーバーの開始時からの最大存続 時間を設定。時間または日で設定。 要求タイムアウト超 モニタリング対象サーバーが処理する要求の中でタイ 過条件 ムアウトが発生する比率の閾値（%)を設定。 応答時間超過条件 モニタリング対象サーバーからの平均応答時間の閾 値を設定。 メモリー条件：メモ モニタリング対象サーバーのメモリー使用量の最大 リー使用量超過 ヒープサイズに対する比率の閾値と、その閾値を超え ている時間の閾値を設定。 メモリー条件：メモ メモリー・リーク検知のための条件。検出のレベルとし リー・リーク て3段階から選択。低速検出ではより長い時間での過 去データが使用されるため検出の精度は高くなるが検 出には時間がかかる ストーム・ドレイン条 エラーを返しているようなケースで、応答時間が正常 件 時に比べて著しく短くなっている状態を検知するため の条件。検出のレベルは2段階から選択。 ワークロード条件 モニタリング対象サーバーが開始してから処理可能な 合計リクエスト数の閾値を設定。 指定可能なアクション サーバーの再始動 スレッド・ダンプの取得 サーバーの再始動 サーバーの再始動 サーバーの再始動 JVMヒープ・ダンプの取 得 サーバーの再始動 サーバーの再始動 サーバーの再始動 上記の表は、WebSphere XD V6のヘルスモニタリング機能で使用可能なヘルス条件 とそれぞれの設定値および指定可能なアクションの一覧です。 36 ヘルスポリシーの定義例 メモリー・リークを検知するポリシー ポリシーの名前設定とヘルス条件の選択 ヘルス条件によって閾値やオプションを 指定する。またアクションもヘルス条件に よって異なる。メモリーリークの場合、 サーバーの再始動の前にヒープダンプを 取得するアクションを指定可能 この他にモニタリング対象 などを指定する 上記画面はヘルスポリシーの定義例です。ヘルスポリシーを定義するには、管理コン ソールの「動作ポリシー」→「ヘルスポリシー」から「新規作成」をクリックします。各ヘルス ポリシーには名前とヘルス条件およびヘルス条件ごとのプロパティーを設定します。上 記はメモリー・リークを検知するためのポリシーになります。リアクション・モードにはアク ションの実行を自動モードで行うか監視モードで行うかの設定をします。また、アクション としてサーバーの再始動を選択することができます。メモリーリーク条件の場合、さらに アプリケーション・サーバーの再始動の前にメモリーダンプを取得することをアクションと して指定することができます。 この他にモニタリング対象を設定してヘルスポリシーの定義を完了します。 37 タスクの通知とアクションの実行 タスクの通知 ヘルス管理コントローラーがランタイム・タスク管理画面にタスクを生成 監視モードの場合はアクションを受諾→実行 自動モードの場合は自動的にアクションが実行される ランタイム・トポロジーでアイコン表示 Sick Server表示 前頁で定義したヘルスポリシーにしたがってヘルス管理コントローラーは、XDランタイム を監視します。ポリシーに反した状態を検知するとヘルス管理コントローラーは、ランタイ ム・タスク管理画面にタスクを生成します。 監視モードの場合は、検知した状況に対するアクションが提案されます。管理者は「受 諾」また「拒否」をすることができます。「受諾」してはじめてアクションが実行されます。自 動モードの場合は、管理者の介在なしに、アクションが自動実行されます。 なお、V5.1まではヘルスポリシーに反したイベントはランタイム・タスク画面を開かないと 確認できませんでしたが、V6からはヘルス管理コントローラーによって非正常状態と認 識されたモニタリング対象は、ランタイム・トポロジーでSick Serverのアイコン表示が追 加されます。（上記下右の図） このようにヘルスモニタリング機能は、XDランタイムの非正常状態を検知し、障害を未然 に防ぐことをサポートします。 38 まとめ WebSphere XD Continuous Availability 機能 XDではノンストップ・サービスを実現する様々な機能をサポート 保守モード/スマート停止 エディション・コントロール・センター 同一アプリケーションの異なるバージョンを“エディション”として管理 Interruptive-freeなエディションの更新/戻し機能を提供 本番環境でのテスト使用環境をサポート 同時に複数のエディションを稼動可能 ODRと連携して、更新中、本番/テスト環境間、エディション間の割り振りの制御が可能 Highly Available デプロイメント・マネージャー H/WおよびS/Wのメンテナンスを行う際に使用 ノード/アプリケーション・サーバーの停止をクライアントから透過的に行う デプロイメント・マネージャーのHA化をサポート アクティブDMGRに障害が発生するとスタンバイにフェールオーバー 常にアクティブなDMGRにODR経由でアクセスが可能 ヘルスモニタリング ヘルスポリシーに基づきWebSphere環境をモニタリング 非正常な状態を検知すると定義されたアクションを実行 障害になる前の異常な状態を検知し、障害を未然に防ぐ V6ではメモリーリークなどの新ヘルスポリシーをサポート アクションとしてメモリーダンプやヒープダンプの取得が可能 このセッションのまとめです。 おつかれさまでした。 39