コア・グループのスケーリングについての考慮事項
HA マネージャーが消費する CPU およびメモリーなどのシステム・リソースの量は、コア・グループのサ イズの増加とともに線形的に増加することはありません。 例えば、HA マネージャーが使用する View Synchrony Protocol は、 コア・グループ・メンバー全体の密接な結合を維持するために、これらのリソースを大量に必要とします。 したがって、大きなコア・グループが消費するリソースの量は、かなり多くなる場合があります。
- 実行されているアプリケーションの数。
- 実行されているアプリケーションのタイプ。
- 使用される HA マネージャー・サービス。
コア・グループのスケーラビリティーをセットアップする場合は、以下のことを確認する必要があります。
- セル内のすべてのプロセスが、適切なサイズのコア・グループ内に正しく分散されています。 これらのプロセスを正しく分散することによって、View Synchrony Protocol が消費するリソースの量が制限されます。
- 所定のコア・グループ内のすべてのプロセスが、 コア・グループ内で使用されるハイ・アベイラビリティー・サービスをサポートするように正しく構成されています。
以下のスケーラビリティー技法のうち 1 つ以上を実装して、 システムが正しく稼働している場合であっても、大きなセル内で HA マネージャーを拡大縮小することを検討してください。 以下のような最も基本的な 2 つの技法があります。
- 不要な場合に HA マネージャーを使用不可にします。
- いくつかのコア・グループ全体にプロセスを分散し、コア・グループ・ブリッジを使用して、必要に応じてコア・ グループを接続します。
コア・グループのサイズの調整
- 第 1 の最も重要な点は、一連のアクティブなコア・グループ・メンバー全体での View Synchrony Protocol の確 立です。 このアクティビティーは通常、ビュー変更 と呼ばれます。
- 2 番目の点は、HA マネージャーがバックグラウンドで実行する、定期的にスケジュールされたディスカバリーと 障害の検出タスクです。
- 3 番目の点は、他の製品コンポーネントが HA マネージャー提供のサービスを使用した結果生じるリソースの使用法です。
- ビュー変更
View Synchrony Protocol は、アクティブなコア・グループ・メンバーに変更があったことを検出するたびに、 新しいビューを作成します。 ビュー変更は通常、コア・グループ・メンバーが開始または停止するたびに発生します。 コア・グループ・メンバーは、開始すると、実行中の他のすべてのコア・グループ・メンバーへの接続をオープンします。 コア・グループ・メンバーが停止すると、他のコア・グループ・メンバーによって、 停止したメンバーに対するオープン接続がクローズされたことが検出されます。 いずれの場合も、View Synchrony Protocol はこの変更を考慮する必要があります。 新規に開始したメンバーの場合、View Synchrony Protocol はその新規メンバーを含むビューを確立する必要があります。 停止したメンバーの場合、View Synchrony Protocol は、 存続しているコア・グループ・メンバー用に、停止したメンバーを除いた新規ビューを確立する必要があります。
新規ビューの確立は、重要なアクティビティーですが、特に大きなコア・グループの場合は、 多くのシステム・リソースを使用します。- 実行中の各グループ・メンバーは、その現在の状態を他のコア・グループ・メンバーに通信する必要があります。 通信内容には、現在のビューで送受信したメッセージに関する情報が含まれます。
- 所定のビューで送信されるすべてのメッセージは、新規ビューをインストールする前に、 すべての受信側で受信および確認する必要があります。 通常の操作状態では、これらのメッセージ受信の確認は遅くなります。 ビュー変更の境界でメッセージをタイミングよく完了するには、 積極的な確認通知と再送信が必要です。
- すべてのコア・グループ・メンバーは、アクティブに通信できる他の一連のコア・グループ・メンバーなどの、 現在の状態に関するデータを送信する必要があります。
アクティブなメンバーの数が増えると、新規ビューをインストールする際に、 HA マネージャーの CPU 使用量が大きく、一時的に非線形的に増加しなくてはなりません。 他に 50 個のコア・グループ・メンバーが存在しているときに単一のメンバーを追加または除去すると、 他に 20 個のメンバーが存在しているときに単一のメンバーを追加または除去するよりも、大幅に負荷がかかります。
新規ビューをインストールすると、HA マネージャーを使用する製品コンポーネント内の状態も変更されます。 例えば、開始または停止したメンバーを反映させるようにルーティング・テーブルを更新したり、 新規メンバーについて singleton サービスを再開したりする必要がある場合があります。
新規ビューをインストールした結果、CPU 使用量は一時的に大幅に増加します。 コア・グループのサイズが大きくなりすぎると、ビュー変更の境界で、ネットワーク・タイミングの劣化状態が発生しま す。 これらの状態が発生すると、通常、新規ビューをインストールしようとするときに障害の原因となります。 このような障害からのリカバリーにも、CPU が集中して使用されます。 使用できる CPU が不足していたり、ページングが発生している場合、障害が急速に増大する可能性があります。
- バックグラウンド・タスク
HA マネージャーは、管理している高可用性の singleton サービスの正常性検査などの、 多くのバックグラウンド・タスクを定期的に実行します。 ほとんどの場合、これらのバックグラウンド・タスクが消費する CPU の量はほんの少量です。 例外は、定期的にスケジュールされたディスカバリー・プロトコルと障害検出プロトコルです。
ディスカバリー・プロトコルは、実行されていないプロセスを含め、 現在接続されていないコア・グループ・メンバー間の通信を確立しようとします。 N 個のコア・グループ・メンバー (そのうちの M 個が現在実行中) を含む所定のコア・グループの場合、各ディスカバリー期間内のディスカバリー・メッセージ数は、およそ M x (N – M) 個になります。したがって、逆に開始することのないプロセスを多数作成すると、ディスカバリー・プロトコルの CPU 使用量に悪影 響を及ぼします。
同様に、障害検出プロトコルを実行する場合、 各コア・グループ・メンバーは、他のコア・グループ・メンバーに対して確立された、 すべての接続にハートビートを送信します。 M のアクティブ・メンバーの場合、M x (M-1) のハートビート・メッセージが送信されます。 積極的な障害検出が必要な場合、コア・グループのサイズは、 コア・グループ・メンバー間のハートビートで消費される CPU 使用量に悪影響を与える場合があります。
コア・グループが小さいと、これら 2 つのプロトコルが消費する CPU 使用量に良い影響を与えます。 例えば、コア・グループに 100 個のアクティブ・メンバーが含まれている場合、 各障害検出期間中に 9900 個のハートビート・メッセージが送信されます。 100 個のメンバーを含むコア・グループを、20 個のメンバーを含む 5 個の小さいコア・グループに分割すると、 メッセージ数が 1900 個に減少します。 これは大幅な削減になります。
- 外部使用法
- ワークロード管理 (WLM) およびオンデマンド構成などの、その他の本製品のコンポーネントは、HA マネージャー提供のサービス (ライブ・サーバー状態交換など) を使用して、 ルーティング情報を保守します。 これらのコンポーネントが消費する CPU 使用量は、コア・グループのサイズにリンクします。 例えば、高可用性ルーティング情報を作成するためのライブ・サーバー状態交換の使用は、コア・グループのサイズにリンクします。
複数のコア・グループ間のプロセスの分散
- HA マネージャーが提供するサービスを使用しないプロセスに対して、 HA マネージャーを使用不可にすることができます。
- コア・グループのサイズを小さいままにすることができます。
HA マネージャーの CPU 使用量を制限する場合に重要なことは、 コア・グループのサイズを制限することです。 小さなコア・グループが複数存在するよりも、大きなコア・グループが 1 つ存在する方が、はるかに効率的です。 大きなセルがある場合は、コア・グループを複数作成します。
本製品が稼働しているハードウェアも、環境に適したコア・グループのサイズを決定する要因です。
大きなコア・グループを複数の小さいコア・グループに分割します。 分割したコア・グループがルーティング情報を共有する必要がある場合は、 コア・グループ・ブリッジを使用して、コア・グループをつなぐことができます。
コア・グループ・サイズ
- IBM_CS_WIRE_FORMAT_VERSION コア・グループ・カスタム・プロパティーの値 6.1.0 への設定を有効にすると、コア・グループ内部プロトコルの改善が得られます。この改善は、バージョン 6.1 以降に限って有効です。
- IBM_CS_HAM_PROTOCOL_VERSION コア・グループ・カスタム・プロパティーの値 6.0.2.31 への設定を有効にすると、コア・グループ・ブリッジのメモリー使用率およびフェイルオーバー特性の大幅な改善が得られます。
- トランスポート・メモリー設定を調整できます。コア・グループ・トランスポートに関連して 2 つのメモリーまたはバッファー設定があります。
これらの設定は、50 メンバー以下の小さいコア・グループの場合、デフォルト値で十分です。50 メンバーを超えるコア・グループの場合、これらの設定はデフォルト値よりも大きくする必要があります。注: これらのトランスポート・メモリー設定の値を大きくしても、HA マネージャーが、静的に割り振られたメモリー (つまり長期メモリー) をより多く使用できることに直接つながるわけではありません。
- 100 メンバーまでのコア・グループは問題なく動作するはずです。
- 100 メンバーを超えるメンバーを含むコア・グループは、多くのトポロジーで問題なく動作するはずです。200 メンバーを超えるコア・グループは推奨されません。
アプリケーション混合と使用するサービスに基づく個々のコア・グループの調整
アプリケーション混合とコア・グループ・メンバーが使用する HA サービスに基づいて、 個々のコア・グループをさらに調整しなければならない場合があります。
- デフォルト設定が適切でない場合は、デフォルトのディスカバリー・プロトコルと、デフォルトの障害検出プロトコルの実行頻度を調整します。
- コア・グループ・コーディネーターを構成して、特定のプロセスまたは一連のプロセスで実行します。
- コーディネーター・プロセスによるリソースの消費が顕著な場合は、 複数のインスタンス全体でコーディネーターを分割します。
- 輻輳が検出されたときにネットワーク・メッセージを送信するために、分散および整合性サービス (DCS) と信頼性の高いマルチキャスト・メッセージング (RMM) コンポーネントで使用可能なメモリーの量を構成します。輻輳は、メモリー間の複製を使用していない場合でも、状況によっては発生する場合があります。
一時ポート範囲の調整
コア・グループが使用するソケットの数は、通常は重要な問題ではありません。 各コア・グループ・メンバーは、そのコア・グループの他のすべてのメンバーと接続を確立する必要があります。 したがって接続の数は、指数関数 (n 乗) 的に増加します。 これは、各接続が終端に 1 つずつ、計 2 つのソケットを必要とするためです。 通常は、複数のマシンが関係するため、 コア・グループが使用するソケットの数を気にかける必要はありません。 しかし、単一マシン上で実行されているコア・グループ・メンバーの数が異常に多い場合は、 一時ポート範囲に関連したオペレーティング・システムのパラメーターを調整する必要があります。 ほとんどのオペレーティング・システムでは、一時ポート範囲のデフォルトの動作が異なります。
