WebSphere Application Server Network Deployment for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

コア・グループのスケーリングについての考慮事項

HA マネージャーが消費する CPU およびメモリーなどのシステム・リソースの量は、コア・グループのサ イズの増加とともに線形的に増加することはありません。 例えば、HA マネージャーが使用する View Synchrony Protocol は、 コア・グループ・メンバー全体の密接な結合を維持するために、これらのリソースを大量に必要とします。 したがって、大きなコア・グループが消費するリソースの量は、かなり多くなる場合があります。

View Synchrony Protocol リソースの要件は、同じサイズのさまざまなコア・グループによって大きく異なる場合 があります。 View Synchrony Protocol がコア・グループに対して使用するリソースの量は、以下によって決まります。

コア・グループのスケーラビリティーをセットアップする場合は、以下のことを確認する必要があります。

以下のスケーラビリティー技法のうち 1 つ以上を実装して、 システムが正しく稼働している場合であっても、大きなセル内で HA マネージャーを拡大縮小することを検討してください。 以下のような最も基本的な 2 つの技法があります。

コア・グループのサイズの調整

コア・グループのサイズは、以下のような、リソースの使用法に影響を与える HA マネージャー処理の 3 つの点に直接影響します。
  • 第 1 の最も重要な点は、一連のアクティブなコア・グループ・メンバー全体での View Synchrony Protocol の確 立です。 このアクティビティーは通常、ビュー変更 と呼ばれます。
  • 2 番目の点は、HA マネージャーがバックグラウンドで実行する、定期的にスケジュールされたディスカバリーと 障害の検出タスクです。
  • 3 番目の点は、 他の WebSphere Application Server コンポーネントが HA マネージャー提供のサービスを使用した結果生じるリソースの使用法です。
ビュー変更

View Synchrony Protocol は、アクティブなコア・グループ・メンバーに変更があったことを検出するたびに、 新しいビューを作成します。 ビュー変更は通常、コア・グループ・メンバーが開始または停止するたびに発生します。 コア・グループ・メンバーは、開始すると、実行中の他のすべてのコア・グループ・メンバーへの接続をオープンします。 コア・グループ・メンバーが停止すると、他のコア・グループ・メンバーによって、 停止したメンバーに対するオープン接続がクローズされたことが検出されます。 いずれの場合も、View Synchrony Protocol はこの変更を考慮する必要があります。 新規に開始したメンバーの場合、View Synchrony Protocol はその新規メンバーを含むビューを確立する必要があります。 停止したメンバーの場合、View Synchrony Protocol は、 存続しているコア・グループ・メンバー用に、停止したメンバーを除いた新規ビューを確立する必要があります。

新規ビューの確立は、重要なアクティビティーですが、特に大きなコア・グループの場合は、 多くのシステム・リソースを使用します。
  • 実行中の各グループ・メンバーは、その現在の状態を他のコア・グループ・メンバーに通信する必要があります。 通信内容には、現在のビューで送受信したメッセージに関する情報が含まれます。
  • 所定のビューで送信されるすべてのメッセージは、新規ビューをインストールする前に、 すべての受信側で受信および確認する必要があります。 通常の操作状態では、これらのメッセージ受信の確認は遅くなります。 ビュー変更の境界でメッセージをタイミングよく完了するには、 積極的な確認通知と再送信が必要です。
  • すべてのコア・グループ・メンバーは、アクティブに通信できる他の一連のコア・グループ・メンバーなどの、 現在の状態に関するデータを送信する必要があります。

アクティブなメンバーの数が増えると、新規ビューをインストールする際に、 HA マネージャーの CPU 使用量が大きく、一時的に非線形的に増加しなくてはなりません。 他に 50 個のコア・グループ・メンバーが存在しているときに単一のメンバーを追加または除去すると、 他に 20 個のメンバーが存在しているときに単一のメンバーを追加または除去するよりも、大幅に負荷がかかります。

新規ビューをインストールすると、 HA マネージャーを使用する WebSphere Application Server コンポーネント内の状態も変更されます。 例えば、開始または停止したメンバーを反映させるようにルーティング・テーブルを更新したり、 新規メンバーについてシングルトン・サービスを再開したりする必要がある場合があります。

新規ビューをインストールした結果、CPU 使用量は一時的に大幅に増加します。 コア・グループのサイズが大きくなりすぎると、ビュー変更の境界で、ネットワーク・タイミングの劣化状態が発生しま す。 これらの状態が発生すると、通常、新規ビューをインストールしようとするときに障害の原因となります。 このような障害からのリカバリーにも、CPU が集中して使用されます。 使用できる CPU が不足していたり、ページングが発生している場合、障害が急速に増大する可能性があります。

バックグラウンド・タスク

HA マネージャーは、管理している高可用性のシングルトン・サービスの正常性検査などの、 多くのバックグラウンド・タスクを定期的に実行します。 ほとんどの場合、これらのバックグラウンド・タスクが消費する CPU の量はほんの少量です。 例外は、定期的にスケジュールされたディスカバリー・プロトコルと障害検出プロトコルです。

ディスカバリー・プロトコルは、実行されていないプロセスを含め、 現在接続されていないコア・グループ・メンバー間の通信を確立しようとします。 N 個のコア・グループ・メンバー (そのうちの M 個が現在実行中) を含む所定のコア・グループの場合、 各ディスカバリー期間内のディスカバリー・メッセージ数は、およそ M x (N - M) 個です。 したがって、逆に開始することのないプロセスを多数作成すると、ディスカバリー・プロトコルの CPU 使用量に悪影 響を及ぼします。

同様に、障害検出プロトコルを実行する場合、 各コア・グループ・メンバーは、他のコア・グループ・メンバーに対して確立された、 すべての接続にハートビートを送信します。 M のアクティブ・メンバーの場合、M x (M-1) のハートビート・メッセージが送信されます。 積極的な障害検出が必要な場合、コア・グループのサイズは、 コア・グループ・メンバー間のハートビートで消費される CPU 使用量に悪影響を与える場合があります。

コア・グループが小さいと、これら 2 つのプロトコルが消費する CPU 使用量に良い影響を与えます。 例えば、コア・グループに 100 個のアクティブ・メンバーが含まれている場合、 各障害検出期間中に 9900 個のハートビート・メッセージが送信されます。 100 個のメンバーを含むコア・グループを、20 個のメンバーを含む 5 個の小さいコア・グループに分割すると、 メッセージ数が 1900 個に減少します。 これは大幅な削減になります。

外部使用法
ワークロード管理 (WLM) およびオンデマンド構成などの、その他の WebSphere Application Server コンポーネントは、HA マネージャー提供のサービス (ライブ・サーバー状態交換など) を使用して、 ルーティング情報を保守します。 これらのコンポーネントが消費する CPU 使用量は、コア・グループのサイズにリンクします。 例えば、高可用性ルーティング情報を作成するためのライブ・サーバー状態交換の使用は、コア・グループのサイズにリンクします。

複数のコア・グループ間のプロセスの分散

以下の 2 つの基本的な技法を使用して、 ビューの同期性および関連するプロトコルが消費するリソースの量を最小化することができます。
  • HA マネージャーが提供するサービスを使用しないプロセスに対して、 HA マネージャーを使用不可にすることができます。
  • コア・グループのサイズを小さいままにすることができます。

HA マネージャーの CPU 使用量を制限する場合に重要なことは、 コア・グループのサイズを制限することです。 小さなコア・グループが複数存在するよりも、大きなコア・グループが 1 つ存在する方が、はるかに効率的です。 大きなセルがある場合は、コア・グループを複数作成します。

WebSphere Application Server が稼働しているハードウェアも、 環境に適したコア・グループのサイズを決定する要因です。

現在お勧めしているのは、コア・グループのサイズを 50 程度のメンバーに制限することです。 大きなコア・グループを複数の小さいコア・グループに分割します。 分割したコア・グループがルーティング情報を共用する必要がある場合は、 コア・グループ・ブリッジを使用して、コア・グループをつなぐことができます。

アプリケーション混合と使用するサービスに基づく個々のコア・グループの調整

アプリケーション混合とコア・グループ・メンバーが使用する HA サービスに基づいて、 個々のコア・グループをさらに調整しなければならない場合があります。

一時ポート範囲の調整

コア・グループが使用するソケットの数は、通常は重要な問題ではありません。 各コア・グループ・メンバーは、そのコア・グループの他のすべてのメンバーと接続を確立する必要があります。 したがって接続の数は、指数関数 (n 乗) 的に増加します。 これは、各接続が終端に 1 つずつ、計 2 つのソケットを必要とするためです。 通常は、複数のマシンが関係するため、 コア・グループが使用するソケットの数を気にかける必要はありません。 しかし、単一マシン上で実行されているコア・グループ・メンバーの数が異常に多い場合は、 一時ポート範囲に関連したオペレーティング・システムのパラメーターを調整する必要があります。 ほとんどのオペレーティング・システムでは、一時ポート範囲のデフォルトの動作が異なります。




関連概念
コア・グループ View Synchrony Protocol
コア・グループのディスカバリー・プロトコル
コア・グループ障害検出プロトコル
コア・グループ・コーディネーター
コア・グループ (高可用性ドメイン)
関連タスク
コア・グループ・コーディネーター数の変更
コア・グループ優先コーディネーターの構成
新規コア・グループ (高可用性ドメイン) の作成
HA マネージャーの使用不可化と使用可能化
コア・グループに対するディスカバリー・プロトコルの構成
コア・グループに対する障害検出プロトコルの構成
関連資料
HA マネージャーを使用する時期
コア・グループ・メンバーの移動
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 8:28:52 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/info/iseriesnd/ae/crun_ha_cgscale.html