ヘルス・ポリシーは、ご使用の WebSphere Extended Deployment にプロテクトさせたい特定のヘルス基準
の定義です。 ヘルス管理機能は、アプリケーション・サーバー環境でソフトウェアの誤動作を検索する際に、定義されたポリシーを使用します。
Why and when to perform this task
このタスクのステップに従ってください。スクリプトを使用してヘルス・ポリシーを作成および
保守することもできます。詳しくは、
スクリプトによる
ヘルス・ポリシーの管理を参照してください。
- 管理コンソールで、「動作ポリシー」>
「Health policies」>「新規」とクリックしてください。
- ヘルス・ポリシーの一般プロパティーを定義してください。
- ヘルス・ポリシーに名前を指定してください。 名前は、すべてのヘルス・ポリシーの中で固有であり、
一定のネーミング基準に準拠していなくてはなりません。
ネーミング基準の概要を、ヘルス・ポリシー・コンソールのヘルプ・パネルで説明しています。
- OptionalColonSymbol ヘルス・ポリシーの記述の提供
- ヘルス条件を選択してください。 使用可能な
条件はすべて、リアクションとしてサーバーの再始動をサポートします。経過日数とワークロードの条件は
予防ポリシーで、その他は検出ベースのポリシーです。
- 経過日数ベースの条件はこのポリシーに関連したメンバーが一定の経過日数に達すると、
起動します。
- 過度の要求タイムアウト条件は、関連したメンバーに送信した要求がタイムアウトになったとき、
およびタイムアウト比率が指定値を超えたときに起動します。この条件は、サーバー再始動リアクションのほか、
スレッド・ダンプもサポートします。
RestrictionColonSymbol 過度の要求タイムアウト条件は、JMS および IIOP トラフィックには適用されません。
- 過度の応答時間条件は、この検出ベースのポリシーに関連したメンバーの、
要求に対する平均応答時間が一定の時間数を超えた
場合に起動します。
- メモリー条件: 過度のメモリー使用率は、この検出ベースのポリシーに関連したメンバーのメモリー使用率が、
一定時間内の最大ヒープ・サイズの比率を超えた
場合に起動します。
- メモリー条件: メモリー・リークは、Java ヒープのサーバーが使用可能できる空きメモリー
の一貫した減少傾向を探します。このような傾向が検出される基準は、
検出レベル設定によります。低速設定では、ほとんどのヒストリカル・データが
必要になります。通常設定と高速設定では、同じ量のヒストリカル・データが必要ですが、
高速設定では、Java ヒープが最大構成サイズに拡大する前に
分析が可能です。これにより検出機能が高速化されますが、間違って正になる傾向が強まります。この条件は、
リアクションとしてのサーバー再始動のほか、ヒープ・ダンプもサポートします。
- ストーム・ドレーン条件は、低速応答時間を通知する障害クラスター・メンバーへ向けて
要求をシフトする状態を検出します。ストーム・ドレーンは、
指定された時系列データにおける変更ポイント検出に依存します。変更ポイントを検出するため、
指定されたポイントの左方平均と右方平均が計算されます。そのポイントで、
左方平均はこのサンプルより早く到着した N サンプルの平均からなり、
右方平均はこのサンプルより遅く到着した N サンプル (このサンプル自体を含む) の
平均です。左方平均と右方平均の差は保管され、N に設定されたウィンドウの他の差と比較され、
N に対して指定したウィンドウで他の差と比較して、この差が極大
かどうかを判別します。最大差の場合、この差が対応するポイントは
変更ポイント と宣言されます。
ストーム・ドレーンの検出に使用される 2 つのメトリックは、サーバーのために監視される
応答時間と、動的ワークロード・マネージャーのウェイトです。
偽アラームの確率が高い高速検出ポリシーは、
応答時間と動的ワークロード・マネージャーのウェイトの両方
に対して、より少ないサンプル (N=10) を使用し、サンプル・セットを基にしたそれぞれのメトリックで
変更ポイントを検出します。その結果、
平均の差を計算し、極大を探すために、
左方平均に 10、右方平均に 10、合計 20 のサンプルを待つので、
より早く結論に達します。サンプルは、15 秒間隔で
収集されます。従って、ストーム・ドレーンは出現後 5 分以内に検出
できます。しかし、サンプルが少ないので、
サンプルに一時的ピークや下落が多数ある場合、
偽アラームの可能性が高まります。
偽アラームの確率が低い低速検出ポリシーは、
応答時間と動的ワークロード・マネージャーのウェイトの両方に対し、より多いサンプル (N=15) を
使用します。その結果、平均の差を計算するために、
30 サンプル (左方平均に 15、右方平均に 15) を待つので、
より遅く結論に達します。検出時間は 7 分 30 秒です。しかし、
より多くのサンプルがあるので、一時的ピークや下落のあるサンプルが少しあっても、
平均にはあまり影響しません。従って、偽アラームの確率は
低くなります。
RestrictionColonSymbol ストーム・ドレーン条件は、JMS および IIOP トラフィックには適用されません。
- ワークロード条件は、このポリシーに関連したメンバーが、
ユーザー定義の要求数を果たした場合に起動します。
- 「次へ」をクリックします。
- ヘルス・ポリシーのヘルス条件プロパティーを定義してください。 表示するヘルス条件プロパティーは、
選択したヘルス条件により異なります。
- ヘルス条件プロパティー
- 最大経過日数
- このフィールドを使用して、経過日数ベースのヘルス条件に応じて経過日数値を設定します。
経過日数ベースの条件ポリシーは、経過日数が一定の値に達すると、
これに関連したメンバーを再始動します。許容値は、1 時間から 365 日までの、日または時間単位の
正の整数です。小数はサポートされていないので、1.5 日のような値を入力するには、
36 時間を使用します。
- 条件不履行の原因になるタイムアウト要求の比率
- このフィールドは、タイムアウト要求比率のしきい値を設定します。
このフィールドの許容値は 1 から 99 までの整数です。
- 応答時間
- 過度の応答時間条件ポリシーは、完了要求の平均数が指定した期間を超えた場合、
メンバーを再始動します。このフィールドの
許容値は 1 ミリ秒から 60 分までです。メッセージ駆動型 Bean (MDB) の場合、応答時間は、onMessage メソッドにより取得された時間に基づきます。同期クライアントの場合、応答時間は、同じセッション・オブジェクト上のクライアントからの受信呼び出し間の時間間隔です。応答時間には、オートノミック要求フロー・マネージャーのキュー内で要した時間も含まれます。
- 以下をモニターする最大 JVM ヒープ・サイズの比率。
- 過度のメモリー使用率条件ポリシーは、メモリー使用率が長時間にわたりご使用のヒープ・サイズを
超えた場合、メンバーを再始動します。このフィールドの許容値は 1 から 99 までの整数です。
- JVM ヒープしきい値が不履行となる時間枠
- 過度のメモリー使用率条件ポリシーは、メモリー使用率が長時間にわたりご使用のヒープ・サイズを
超えた場合、メンバーを再始動します。合計使用メモリー比率は、
メンバーを再始動する時を判別する百分率値と共に使用
されます。このフィールドの許容値は 1 秒から 60 分までです。
- 要求合計
- このフィールドは、選択したヘルス・ポリシーがワークロードの場合に使用可能です。
ワークロード条件ポリシーは、一定のユーザー定義数の要求が処理されると、
メンバーを再始動します。許容要求値は、
1000 から 9223372036854775807 までの整数です。
- 条件の検出レベル。
- 以下から選択してください。
- 迅速に潜在的メモリー・リークを検出するものの、間違って正を出す可能性の大きい
偽アラームの確率が高い高速検出
- より低速で潜在的メモリー・リークを
正確に検出する偽アラームの確率が標準的な標準検出
- 潜在的メモリー・リークを最も正確に検出する
偽アラームの確率が低い低速検出
- ヘルス管理モニター・リアクション
- リアクション・モード
- 「監視」または「自動」を選択します。リアクション・モードは、
修正アクションが必要であるとヘルス条件が判断したときに、
ユーザー対話のレベルを定義します。監視モードでは、アクションの推奨計画は、
実行前に承認できます。自動モードは、アクションのすべての推奨計画を
承認なしで実行します。自動リアクションを慎重に使用してください。
特にサーバーを再始動させるときは注意が必要です。サーバーが再始動するとき、サービスの連続可用性が
中断することがあります。
- ヘルス条件不履行時に取るべきアクションの選択
- ヘルス条件が不履行のとき、ヘルス条件によって、取るべきアクションを 1 つ以上
選択できます。
- サーバーの再始動
- スレッド・ダンプの取得
- IBM Java Development Kit (JDK) でのみ JVM ヒープ・ダンプを取得
- 「次へ」をクリックします。次のパネルが、ご使用のポリシーの
ターゲットを選択するようプロンプトを出します。
- メンバーシップを選択し、ご使用のヘルス・ポリシーをモニターします。「Available for membership」リストでメンバー・タイプを表示し、
モニターしたいタイプを選択し、「追加」をクリックします。
- アプリケーション・サーバーとノード
- クラスター
- 動的クラスター
- セル
論理のレイヤーはモニターされたメンバーシップに適用できます。例えば、
クラスターのすべてのメンバーと、クラスターの外側のアプリケーション・サーバーに、
特定のヘルス・ポリシーを適用できます。クラスターのすべての既存アプリケーション・サーバーと
潜在的なアプリケーション・サーバーを含むアプリケーション・サーバー・パネルから、
単一のアプリケーション・サーバーとクラスターを選択して
ください。クラスター・メンバーが追加論理を適用し、サービス中のリアクションのインパクトを
最小化します。
- 「次へ」をクリックします。
- お客様の新規ポリシーを検討し、「終了」をクリックします。コンソール・ウィンドウのヘッダーは
保管オプションを表示します。
- 「保管」をクリックしてください。保管と破棄のオプションを持つウィンドウが表示されます。
「保管」を再度クリックし、お客様の新規ポリシーをコミットしてください。
Result
これでヘルス・ポリシーが作成され、ターゲット環境に適用されました。
What to do next
次のステップは、ヘルス管理を使用可能にすることです。使用可能になると、
ご使用のヘルス・ポリシーは賢い決定を行い、ご使用のアプリケーション配置機能とともに動作して、
再始動を保証する条件が処理中の作業に影響を与えないようにします。 詳しくは、
ヘルス管理の使用可能化と使用不可化を参照してください。