レベル: 初級 太田 智之, ワークプレース, ISE
2009年 6月 15日 Webシステムにおける障害対処の方法として、従来の障害発生時の事後対処に替わるWebSphere Virtual Enterpriseヘルス・モニタリング機能を用いた障害発生の未然防止、および保守モード機能を使用した柔軟な保守方法をご紹介します
はじめに
現在の社会の中で、ITインフラは生活と切り離せないものになっています。このような状況の中では、システムの停止が与える影響は非常に大きなものになります。システムの停止は、障害により「止まってしまうもの」と、保守などの目的で「止めないといけないもの」に大別できますが、WebSphere Virtual Enterprise（WVE）はこれら双方に対して有効なソリューションを提供しています。この文書ではそれらのソリューションを実現する機能である、「ヘルス・モニタリング」機能と「保守モード」機能を中心にご紹介します。
Webシステム運用上の課題点
これまでのWebシステムの運用では、以下の事項が一般的な課題として挙がっていました。
アプリケーション・サーバーのスムースな縮退
稼動中のサーバーに対してメンテナンスを行う際には、該当サーバーへリクエストが割り振られるのを停止し、縮退する必要があります。
リクエストの割り振りを停止する手段としては、ロードバランサーから割り振りを停止する方法、Webサーバーからアプリケーション・サーバーへの割り振りを停止する方法などいくつか考えられますが、その際にはサービスに影響を与えないということが重要なポイントになります。
ロードバランサーによる割り振り停止については、アフィニティへの考慮が必要になります。ロードバランサーで割り振りを停止する場合、アプリケーションで保持しているセッションの状態とは無関係に強制的にリクエストの割り振りが停止されてしまいます。セッションの複製・共有がされており、かつ適切なタイミングで複製の更新が行われている場合は良いのですが、そうでない場合は新しいセッションを生成することになってしまいます。ユーザーから見ると、再ログインが必要になったり、前画面で入力したデータ（セッションへ書き込んだデータ）が古いままであったり、といった現象が発生してしまいます。
また、Webサーバーからアプリケーション・サーバーへの割り振りを停止する場合、WAS ND版ではアプリケーション・サーバーを停止して、IHS/Plug-inがそれを検知し割り振りが停止されるのを待つという方法が一般的でした。（plugin-cfg.xmlファイルを書き換えてリロードを待つ、という方法もありますが、現実的な対応策ではないと思われます。）
いずれにしろ、リクエストの割り振りは強制的に停止されてしまい、停止手順についても煩雑になりがちである、というのが課題となります。
障害発生による影響の最小化
これまでのシステムでは、システム障害は検知後の事後対応にならざるを得ませんでした。
この方法だと検知→解析→対処→サービス再開となるため、サービスの再提供に非常に時間と労力がかかる上、障害が発生した後なのでダンプ等の解析に必要な資料取りができていないなど、運用に与えるインパクトが非常に大きくなってしまいます。
もし、障害の予兆を検知して事前に対処することができれば、サービスに与える影響、運用負荷ともに最小化することができます。
WVE機能を使用した解決策
これらの課題に応えるのが、WVEが提供する、「保守モード」機能と「ヘルス・モニタリング」機能です。それぞれの機能がどのような場合にどう役立つのか見てみましょう。
保守モードを使用したスムースな縮退運用
先に述べたとおり、従来の縮退の方法としては、ロードバランサーから強制的に割り振りを停止するというものが一般的でした。
保守モードはOn Demand Router（ODR）と呼ばれるインテリジェントなプロキシー・サーバーが、割り振り先該当サーバーを稼動させたまま、リクエストの割り振りを停止する機能です。（割り振り先サーバー側で受付を拒否する訳ではなく、ODRからの割り振りを停止します。）
この保守モード機能を利用することで、以下のことが出来る様になります。
- アプリケーション・サーバーを稼動させた状態のまま縮退できる
- アフィニティの維持が必要な場合は、アフィニティを維持しながら縮退できる
- ノード単位で縮退できる
システム管理者はサーバーを保守モードに設定しておいて、プロセスを稼動させたまま問題判別を行ったり、ダンプファイルなどの資料取得を行ったり、必要なチューニングを施したり、といったメンテナンス作業を行うわけです。（図1）
また、縮退の際にはアフィニティの管理が重要なポイントとなりますが、保守モード機能を使用するとアフィニティを維持しながら縮退する事も可能です。保守モード設定対象のアプリケーション・サーバーに有効なセッションが存在している場合には、このセッションを使用するユーザーからのリクエストは継続して対象のアプリケーション・サーバーに割り振りを行います。新規ユーザーからのリクエストは他のアプリケーション・サーバーへ割り振りがされますので、保守モード設定対象のサーバーからは徐々に有効なセッションが無くなっていきます。全てのセッションが無くなった時点でサーバーは保守モードに移行します。
保守モードの設定は、個々のアプリケーション・サーバーの他に、ノード単位で行うことも可能です。例えば、1台のサーバー上で数十のアプリケーション・サーバープロセスが稼動している様な環境があるとします。この環境で、サーバーのOS設定変更等、サーバー全体へ影響を与える作業を行う場合には、数十のアプリケーション・サーバープロセスを全て停止する必要がありますが、このような時にノード単位での保守モード設定は非常に便利です。
また、WVEには動的クラスターというポリシーに沿った自律的なサーバーの起動終了を行う機能があります。あるサーバーを保守モードに設定することで、この動的クラスター内の最低稼動アプリケーション・サーバー数を維持できなくなるようなケースでは、自動的にアプリケーション･サーバーを起動します。
図1 保守モードを使用した縮退運用イメージ
ヘルス・モニタリング機能を使用した、障害予兆検知と自動対処
従来の障害対策としては、考えられる障害発生箇所、パターンを洗い出し、障害発生時にどのような対応をとるか検討するというのが主な方策でした。
WVEヘルス・モニタリング機能を利用することで、障害の予兆を検知して、予め定義した対応策を自動で実行することが可能となります。
従って、障害対策を考える際には、障害発生時にどのように対処するのではなく、障害に繋がる予兆としてどのような事象が考えられるか、また、その予兆に対してはどのような対応を取ればよいか、という事を中心に考える事になります。
例えば、メモリー障害を想定したとすると、メモリー使用量の異常を障害予兆と想定することができます。この障害予兆が発生した際の対応としては、まずサービスへの影響を極小化するために割り振りを停止し、予兆を検知したことを通知、解析に必要な資料取りなどを行った後にプロセスを再起動し、割り振りを再開する、というシナリオが考えられます。
これをヘルス・モニタリング機能に当てはめると、「メモリー使用量の異常」がヘルス・ポリシーに相当し、「これへの対応策として実行する一連のシナリオ」が、ヘルス・アクションということになります。（実装のイメージとして、図2を参照してください。）
図2 ヘルス・モニタリング機能の実装例
ヘルス・モニタリング機能の実装を考える際には、以下の4点がポイントになります。
- ポリシー：どのような現象を障害予兆として捉えるか、をポリシーとして定義します。
- ターゲット：障害予兆を監視する対象をターゲットとして定義します。
- アクション：障害予兆を検知した際に何を実行するか、をアクションとして定義します。
- リアクション・モード：ポリシーが適用された場合に、定義されたアクションを自動で実行するのか（自動モード）、それとも管理者が介入して実行指令を出してから実行するのか（監視モード）を指定します。ミドルウェア機能を使用してシステムの自動化を行う場合、初めから全て自動化してしまうのは抵抗があるものです。暫くは監視モードで運用し、ある程度実績を積んでから自動モードに切り替える、という運用が現実的と考えられます。もちろん十分なテストを行い初めから自動モードで運用しても全く構いません。デフォルトは監視モードになっていますが、以降は便宜上自動モードで動作するものとして記述していきます。
機能詳細
ここからは、「保守モード」と「ヘルス・モニタリング」機能がどのように動作しているのか、内部的な仕組みを説明します。
保守モード
アプリケーション・サーバーを保守モードに設定する際には、以下の中から保守レベルを選択することになります。
- 保守モード：対象のアプリケーション・サーバーに有効なセッションがある場合には、そのセッションが終了もしくはタイムアウトするまではアフィニティを維持して該当リクエストを割り振ります。（新規のリクエストは保守モードに設定されていないサーバーに割り振られます。）すべてのセッションが終了した後に、保守モードへ移行します。
- 保守モード – アフィニティ中断：セッションの状態に関わらず、該当サーバーへの割り振りを中断して即時に保守モードに移行します。
- 保守モード – 即時停止：アプリケーション・サーバープロセスを即時に停止した後に保守モードに移行します。
- 標準：保守モードを解除する場合に選択します。
保守モード設定の対象は、アプリケーション・サーバーもしくはノードとなります。ノード単位で保守モードを指定した場合にはそのノードに含まれる全てのアプリケーション・サーバーが保守モードに設定されます。
また、保守モードの設定はサーバーを停止・再起動した後でも継続されますので別途保守モードの解除が必要になります。
保守モードの設定・解除はコマンドでも行うことが可能です。
以下は、サーバーを保守モードに設定するコマンドです。
/wsadmin.sh -user <username> -password <password> -lang jython –c
AdminTask.setMaintenanceMode ('<nodename>','[-name <server_name> -mode <mode>]') |
保守モードの解除は以下のコマンドで行います。
/wsadmin.sh -user <username> -password <password> -lang jython –c
AdminTask.ussetMaintenanceMode ('<nodename>','[-name <server_name>]') |
パラメーターには以下を指定します。
username：DMに接続するユーザー名
password：DMに接続するユーザーのパスワード
nodename：保守モード設定対象のサーバーが存在しているノード名
server_name：保守モード設定対象のサーバー名
mode：保守モードのモードを break, affinity, stop から選択して指定します。それぞれ、「保守モード-アフィニティ中断」、「保守モード」、「保守モード – 即時停止」を意味しています。
ここからは、保守モード設定時の内部的な動作について説明します。
あるサーバーを保守モードに設定すると、主要な2つの動作が行われます。
- まず、アプリケーション・サーバーの情報が書き込まれているserver.xmlファイルに変更が加えられます。このファイル中には、name="server.maintenancemode" という項目があり、通常時はvalue="false"となっていますが、これがvalue="affinity"と書き換えられます。（通常の保守モードの場合）このファイルが書き換わるため、システムの再起動を行った後も保守モード設定が持続する訳です。
- 保守モードの設定はDeployment Manager（DM）プロセス上で行われますが、実際にリクエストの割り振りを制御しているのはODRです。このDM上で「保守モード」に設定した、という情報は次に述べる仕組みによってODRに伝えられます。WVEには、ODC（On Demand Configuration）と呼ばれる機構があります。ODCはサーバー/アプリケーションの状態や仮想ホスト設定、アプリケーション・サーバーのエンドポイント、その他ランタイムの情報をノード間でシェアするための内部コンポーネントです。ODCの情報は関連コンポーネントの状態に応じて動的に変更されます。ODRに、IHS Plug-inで使用される様なplugin-cfg.xmlファイルが必要ないのは、このODCコンポーネントのお陰なのです。DM上で保守モードに設定した、という情報もこのODCによってODRに伝えられます。それを受け取ったODRは動的に内部ルーティング情報を書き換え、該当サーバーへの振り分けを抑止している訳です。
また、例えば処理中のリクエスト（大量検索など処理に数十秒から数分かかるような処理）がある状態で保守モードを設定した場合にどうなるのでしょうか。
DMでの保守モード設定の情報は、即時にODC経由でODRに伝えられます。その際に処理中のリクエストは、保守モードに設定している状態であっても処理が終わるまで待機してレスポンスを返します。ただし、保守モード-即時停止を選択した場合は、保守モード発動までの待機に限度があり、リクエスト処理完了まで60秒（デフォルトのタイムアウト値※）は待機しますが、60秒を過ぎるとタイムアウトとみなし、504 Gateway Timeout の応答を返します。
※ヘルス・ポリシーの「要求タイムアウト超過条件」と同じ設定が適用されます。
保守モード設定時の考慮点
保守モードを設定時には、保守モードに設定したサーバーへのリクエスト割り振りが停止される事になります。通常の保守モードの場合はアフィニティが維持されますのでセッションの終了までは割り振りが継続されますが、それ以外の保守モードを選択した場合には即時に他方のサーバーへ割り振りが寄せられることになります。この時、セッションを共有していないと、他方のサーバーへ寄せられたリクエストは新規セッションとみなされてしまいます。
つまり、保守モード（セッション維持以外）を使用する場合にはセッションの共有が必須ということになります。
ヘルス・モニタリング
ヘルス・モニタリング機能は、ヘルス・コントローラーとセンサーが協調して動作することで実現されます。
センサーは、ヘルス・ポリシー毎に存在しています。センサーの役割は、ヘルス・ポリシーに応じて応答時間やメモリー使用率などの具体的な値を取得し、設定値と比較して違反がないか検査する事です。違反があった場合は該当するヘルス・ポリシーを違反しているとマークします。（センサーはマークするのみで、アクションの実行は行いません。）各センサーは10秒から15秒の比較的短いサイクルで検査を行っています。（ヘルス・ポリシーによってサイクルが異なります）
ヘルス・コントローラーの役割は、センサーによって違反とマークされたポリシーを検知してランタイム・タスクにアラートを挙げ、その後のアクションの実行を司ります。ヘルス・コントローラーはデフォルトでは5分という比較的長いサイクルでポリシーの違反を検査しています。（図3）
図3 ヘルス・コントローラーとセンサーのサイクル長の関係
ヘルス・コントローラー
このヘルス・コントローラーは、WVEの動的なオペレーションを司るオートノミック･マネジャーと呼ばれるサービスの一つで、セルの中のNode Agent（NA）もしくはDMプロセス上、どこか一箇所で稼動しています。
（ヘルス・コントローラーが稼動している場所がどこであるか確認するには、管理コンソール・メニューの「ランタイム操作」⇒「Extended Deployment」で表示される画面の「コア・コンポーネント」タブを開くことで確認できます。Health Controller の「現在の位置」列に稼動しているコンポーネントが表示されます。（図4）
図4 ヘルス・コントローラーの稼動箇所の確認
ターゲットのサーバー・タイプがWebSphereかnon-WebSphereかで使用できる条件やアクションに差があります。メモリー超過条件、およびメモリー・リークはWebSphereサーバーでなくてはなりませんが、それ以外はnon-WebSphere全てのサーバーで利用可能です。
ヘルス・コントローラーには、以下の設定項目があります。順に説明します。
- コントロール・サイクル長：指定したターゲットが、ヘルス・ポリシー条件に違反していないかどうかを判別するための確認間隔を指定します。値は分単位で、1 分から 60 分までの範囲で指定します。（デフォルトは5分です。）つまり、前述のようにセンサーによってヘルス・ポリシー違反が検知されたとしても、次のヘルス・コントローラーのコントロール・サイクルまではランタイム・タスクにポリシー違反が上げられない、という事になります。コントロール・サイクルを長くすると、ヘルス・モニターの負荷が減少しますが、ポリシー違反の精度が下がりますので、監視要件に合わせてデフォルトの5分を基準とし微調整を行ってください。
- 最大連続再始動：ヘルス・アクションとしてサーバー再起動が設定されている場合に有効な設定項目です。アプリケーション・サーバーの再起動の試行回数を指定します。指定した回数再起動を試みて成功しなかった場合に、再起動が失敗したとみなされます。デフォルト値は3で、1 から 5 までの整数を指定します。
- 再始動タイムアウト：サーバーの再起動が正常に完了するまでに待機する時間を指定します。再起動にこの時間以上かかる様であれば、その再始動の試行は失敗とみなされます。通常、サーバーの再起動は、サーバーの停止アクションと開始アクションのシーケンスで構成されています。 導入しているアプリケーション数や使用している機能が多い場合は再起動にも時間がかかることになります。このような場合は再起動にかかる時間が設定したタイムアウト値を越えないように注意する必要があります。値は分単位で指定し、1 分から 60 分までの範囲の整数となります。デフォルト値は1分です。
- 最小再始動間隔：再起動のリトライを行う場合に、次の試行までどれくらいの間待機するかを指定します。また、アプリケーション・サーバーのヘルス条件をこの期間中に複数回違反した場合、2回目以降の再始動は保留状態になります。最小再始動間隔を経過した時点で再始動が行われます。例えば、同一のヘルス・ポリシーに連続して違反している場合など、違反の度に同じアクションが実行されてしまいますが、初回検知時のみアクションを実行させたい場合などに時間を長めにして設定することで、時間内の2回目以降のアクションは保留になる訳です。値は 15 分から 365 日までの範囲となります。値が 0 の場合、再始動最小値は無効です。
- 再始動禁止時間：アプリケーション・サーバー・インスタンスの再始動が禁止される期間 (曜日と時刻) を指定します。運用上、どうしてもこの期間は操作を行いたくない、という期間がある場合に指定します。例えば、障害予兆を検知してはいても、ピーク時間には止めたくない、等の要件がある場合に有効な設定です。この期間中にヘルス条件に違反があった場合、アクションは禁止時間が過ぎるまでは発生しません。
ヘルス・ポリシー
ここでは、ヘルス・ポリシーとして設定可能な項目の詳細についてご説明します。
期間ベース条件：このポリシーは、サーバーが起動してからの期間をポリシーとして設定しておくものです。例えば、週次で再起動を行いたい、といった場合に期間を7日と設定しておくと、起動後7日経った時点でポリシー適用と認識されます。しかしながら、障害や保守等で週半ばに停止した場合などはサイクルが大幅にずれてしまう事になりますので注意が必要です。
要求タイムアウト超過条件：このポリシーでは、タイムアウトリクエストのパーセンテージ（%）を指定します。性能要件によってアプリケーション毎に個別のタイムアウト値が決められていたりする場合に便利なポリシーです。通常タイムアウト値というのは、応答時間許容値を大幅に超えてエラーみなされる比較的大きい値が設定されていることが多いと思われますので、性能の劣化というよりは無応答の検査という意味合いで使用される事になるかと思います。以下の条件に当てはまる場合に適用されます。
- オートノミック要求フロー・マネージャー（ARFM）の1コントロール・サイクル中（デフォルト59秒）に割り振りを行った総リクエスト数に占める、タイムアウトと認識されたリクエスト数のパーセンテージが、設定したパーセンテージを上回った場合。
- 「ポリシーに設定した割合 = タイムアウトした割合」の場合、ポリシーは適用されません。「ポリシーに設定した割合 < タイムアウトした割合 」の場合に適用されます。
- ヘルス･ポリシーのターゲットを「クラスター」とした場合でも、リクエスト数/タイムアウト数のカウントは、個々のJVM（アプリケーション・サーバー）単位に行われます。
要求タイムアウト超過条件に適用されるタイムアウト値は、単純に応答時間の値で決定されるのではなく、タイムアウトの設定の仕方によって柔軟に対処することが可能です。しかし、タイムアウトの設定は少々複雑で、以下のような複数のパラメーターが影響するため、ここで整理します。
最終的にタイムアウト値は、これらのパラメーターの設定状況に従い図5に示すフローによって決定されます。デフォルトでは、赤線で示す60秒が適用されます。
図5 「要求タイムアウト超過条件」のタイムアウト値決定フロー
拡大図
応答時間超過条件：このポリシーは、ターゲットへの全リクエストの平均応答時間が、定義した応答時間リミットを超過した場合に発動されます。単純に応答時間の平均値によってポリシー違反の検査が行われますので、応答時間目標が均一に定められている場合、性能の劣化を検知したい場合などに適用します。
内部的には、10秒間隔で起動されるセンサーが、サイクル中に処理したリクエストの数と応答時間をカウントし、平均の応答時間を算出しています。これと、定義した応答時間を比較して閾値を超えていればポリシー条件適用とみなされ、次回のヘルス・コントローラーの確認タイミングでランタイム・タスクにアラートが上がります。
メモリー条件：メモリー使用量超過：このポリシーは、X 分/時間、JVMヒープ・サイズがY%使用されていたらポリシーを適用する、という様にXとYの部分の定義を行います。ヒープ・サイズは現行のヒープ・サイズではなく、最大のヒープ・サイズを元に計算されます。ヒープ・サイズの確認は15秒間隔で行われます。
メモリー条件：メモリー・リーク：このポリシーでは、メモリーの使用率の増分をセンサーが監視します。設定としては、検出の精度のレベルとして、高・中・低の一つを指定します。各レベルでどのようにメモリーの使用率および閾値を算出しているかという内部ロジックは公開されていませんが、トレースからの観察においてはメモリー・ヒープの使用率（高：70％、中：80%、低：90%）と空きメモリーの容量(30％)をもとに、ポリシー適用を判断しているようです。
また、高ではJava ヒープが最大構成サイズに拡張する前にメモリー使用率の分析が行われるのに対して、中・低では、Javaヒープが最大ヒープ・サイズに達してから分析が行われるという差異からも、検出の精度の違いが伺えます。
ストーム・ドレーン：このポリシーは、何らかの理由で急激に応答時間が変化してしまったものを検知するポリシーです。
例えば、2～3秒で応答を返していたアプリケーションが、何らかの理由でエラーページを返すようになってしまった場合、通常エラーページの応答時間は1秒に満たない大変短い時間で応答するようになってしまうわけです。このような変化は、エラーが発生しているサーバーの割り振りの重み付けを非常に大きくしてしまい、結果的に障害影響を拡大してしまいます。
ストーム・ドレーンはこの変化を検出してサーバー/アプリケーションの異常を検知しようというものです。雨水が排水路に吸い込まれて行く様を、リクエストが障害サーバーに大量に割り振られる（=吸い込まれる）様に例えているわけです。
ストーム・ドレーンポリシーは、以下の条件に合致した際にポリシーが適用されます。
- 起動直後の不安定な時期での誤検知を避けるため、8分のウォームアップ・タイムかつ500リクエストの処理が必要（最初のリクエストを送信してから8分間かつ500リクエストを処理していない場合は下記変化がおきても検知しない）
- 15秒サイクルで取得したデータ間において、40%のレスポンスタイム低下と、15%のweight増加が同時に見られた場合
検出の精度のレベルとして、標準および低速から選択します。両者の違いは、サンプリングするデータ数にあります。標準の場合は判断の前後10のデータをもとに増減割合を算出しますが、低速の場合は15のデータをもとに算出します。したがって、標準の場合は10（データ数）×15（センサーのインターバル）×2（判断の前後）の300秒で検知されるのに対して、低速の場合は検知に、15×15×2=450秒かかる計算になります。
ワークロード条件：このポリシーでは、サーバーが起動指定から処理したリクエストの数を定義します。サーバーのリクエスト処理数が定義した数を超えるとポリシーが適用されます。
カスタム条件：ここまでで説明してきた7つのポリシーはデフォルトで適用可能なものですが、ここにないパラメーターを指定しカスタム条件として設定することで独自のポリシーを作成することができます。まず、監視対象とすることができるパラメーター項目は以下の4つに大別できます。
- WebSphere Extended Deployment supported PMI モジュール
- ODRメトリクス
- MBean
- URLリターンコード
順に詳細を確認します。
- WebSphere Extended Deployment supported PMI モジュール：PMI（Performance Monitoring Infrastructure）が提供する情報をカスタム条件として指定可能です。時系列的なスコープとしては、サーバー起動後から現時点まで、とヘルス・コントローラーの前回のレポートから現時点まで、の2つを選択可能です。これを利用することで、servlet単位の更に細かい応答時間をポリシーとして設定したり、Webコンテナーのスレッド数を監視して、設定の妥当性を確認したり、各データソースのコネクションの使用率を監視してDB接続異常を検知したり、と様々な応用が可能です。
- ODRメトリクス：ODRに関連する種々のメトリクスを指定することが可能です。項目のスコープとしては、セル・レベルもしくはサーバー・レベルを指定することができます。セル・レベルの指定の場合は、ARFMが保持している情報を抜き出し、特にキューに関連する情報を監視対象のパラメーターとして指定することができます。サーバー・レベルの指定の場合は、個々のARFMゲートウェイから指定したサーバーに関する情報のみを取得して監視対象にできます。（ARFMの詳細については、連載第3回を参照ください。）用法としては、例えば、セル・レベルでキューの長さを監視することで、データベースがボトルネックとなって同一のアプリケーションのキュー長が増加している現象を検知することが可能になったりします。
- MBean：MBeanでは、情報の種類としてオペレーションタイプと属性タイプを選択できます。また、情報の型としてはLong型とString型を区別する必要があります。オペレーションタイプのものは、オブジェクトを特定するクエリーと、メソッドの名前を指定して情報を取得します。また、属性タイプのものはオブジェクトを特定するクエリーと、属性名を指定して情報を取得します。MBeanの一覧は、WAS/XDインストールディレクトリ下のwebディレクトリにmbeandocsとしてまとめられていますので、こちらを参照してどのような項目が取得できるか確認してください。MBeanは設定情報を取得したり、各コンポーネントの起動や停止を行ったりと非常に便利なフレームワークではあるのですが、カスタム・ヘルス・ポリシーで監視したいのは設定情報ではなくてサーバーの稼動状況ですので、あまり要件にマッチする使い方はできないかもしれません。
- URL リターンコード：このポリシーは、指定したURIのページが定められたリターンコードを返しているか確認するために使用します。言わば、アプリケーションの正常稼動を確認するためのポリシーと言えます。これは、ロードバランサー等でよく行われている生死確認のリクエストと同様の機能を提供します。このポリシーでは、アクセス対象を特定するためのターゲットのポートとURI、および期待するリターンコードを指定します。ヘルス・コントローラーは、指定されたターゲットに対して、ポリシーとして設定されたポート番号とURIを使用してアクセスを試みます。応答が指定したリターンコードで返ってこない場合にポリシーが適用されます。また、設定の仕方には少々注意が必要です。リクエストはヘルス・コントローラーが行いますので、リクエストの送信元はヘルス・コントローラーになります。また、ヘルス・コントローラーがリクエスト元ということは、確認のインターバルもヘルス・コントローラーの確認インターバルと同一（デフォルト5分）ということになります。5分間はエラーのまま稼動し続けるというのは、余り精度が高いとはいえませんので、このポリシーを適用する際には合わせてヘルス・コントローラーのサイクル短縮も検討した方が良いでしょう。さらに、リクエスト先のポートが固定になるので、確認のターゲットのスコープをセルや動的クラスターなど複数のアプリケーション・サーバーが含まれる設定にした場合は、これらのアプリケーション・サーバーのListenポート、仮想ホストが、全てこのポートでリクエスト処理可能な設定になっている必要があります。（このようになっていない場合は、スコープを分けて個別に設定するしかありません。）
アクションの説明
ここまではヘルス・ポリシーの説明をしてきましたが、ここからはポリシーが適用された場合に実行するアクションについてそれぞれ説明します。
- サーバーの再始動：単純にポリシーが適用されたアプリケーション・サーバー プロセスを再始動します。
- スレッド・ダンプの取得：ポリシーが適用されたサーバーJVMのスレッド・ダンプを取得します。
- JVMヒープ・ダンプの取得：ポリシーが適用されたサーバーJVMのヒープ・ダンプを取得します。
- サーバーを保守モードに設定する：ポリシーが適用されたサーバーを、保守モードの項で説明した、アフィニティを維持した保守モード に設定します。
- サーバーを保守モードおよびアフィニティ中断に設定する：ポリシーが適用されたサーバーを、保守モードの項で説明した、アフィニティを中断する保守モード に設定します。
- サーバーを保守モードから外す：ポリシーが適用されたサーバーの保守モードを解除して、標準 状態に戻します。
- カスタム・アクションを実行：上記以外のアクションとして、任意のスクリプト等を実行することができます。
通常は、これらのアクションを組み合わせて最適なアクションを構成します。
例えば、メモリー・リークを検知するようなポリシーを設定した場合は、メモリー・リークの予兆を検知した段階で、更なる状況の悪化とサービスへの影響を防止するために、いずれかの保守モードで割り振りを停止した上で継続のアクションを行うとよいでしょう。
障害予兆を検知したことを管理者が検知する必要があるので、この段階でカスタム・アクションとして監視システムにアラートをあげるアクションを組み込む方法も考えられます。
次に、このメモリー・リークの原因を特定するために必要な資料を取得する必要があります。ここで、「スレッド・ダンプの取得」や「JVMヒープ・ダンプの取得」を行います。必要な資料取りが終わったら、現象を解消するために、「アプリケーション・サーバー プロセスを再始動」します。再始動が終了した段階で、正常な状態に戻る事になりますので「保守モードを解除」してサービスを再開します。
ヘルス・モニタリング機能使用時の考慮点
既存監視コンポーネントとの共存方法
通常、システム構築時には監視システムと連携して、システムで発生した障害を検知・通知します。
ヘルス・モニタリング機能を使用してアプリケーション・サーバーの再起動等を行っている場合には、プロセスが一旦停止することになりますがこれがヘルス・モニタリング機能によるものなのか、障害で停止したのか監視システムからは判断ができません。従って、ヘルス・モニタリング機能による再起動を行う場合には、監視システム側でそれとわかるような仕組みを構築しておく必要があります。例えば、アクションで再起動を実施する前に監視の抑止を行い、再起動後にヘルス・ポリシー適用により再起動を行ったことを通知するシェルをカスタム・アクションとして実行する、等の対応が考えられます。
まとめ
これまでメンテナンスを効率よく、システム停止時間をできるだけ短くするための機能として「保守モード」と「ヘルス・モニタリング」を紹介してきました。
それぞれのシステムによって適用する方式はバリエーションがあるかもしれませんが、どれも運用の手間を軽減させ、サービスレベルも向上させる大変有用な機能です。
縮退の方法論や障害検知とそれへの対処は、多くのシステムの運用設計において必ず「悩みの種」となるポイントです。これまでは、WVEが提供している様な機能を実現するために、複雑な運用手順をとったり、運用シェルを作成して代替したり、等の対応をとっているケースが殆かと思います。
「保守モード」は稼動しながらのメンテナンス作業に非常に有用であり、「止めないといけない」時間をゼロ、もしくは最小化してくれます。
「ヘルス・モニタリング」は、障害の予兆および軽微な障害は半ば自動で復旧作業を行ってくれるため、「止まってしまう」時間を最小化するための強力な運用ツールとして使用頂ける筈です。是非皆様のシステムへの導入をご検討ください。
著者について  | | | 太田 智之, ワークプレース, ISE |
記事の評価
| 
