Red Hat Training

A Red Hat training course is available for Red Hat JBoss Operations Network

第5章 高可用性とエージェントのロードバランシングの使用

JBoss ON サーバーと高可用性は、同じ中央データベースを使用するすべての JBoss ON サーバーがクラウドで相互作用することを意味します。これにより、サーバーがメンテナンスのためにオフラインにする必要がある場合にサーバー間でシームレスなフェイルオーバーが可能になり、負荷分散エージェントとリソース操作に最適な方法が提供されます。
クラウドで複数の JBoss ON サーバーを使用すると、エージェントは通常の通信に使用するサーバーの設定を定義できます。この優先順位(affinity)は、エージェントサーバー通信を負荷分散し、全体的なパフォーマンスを向上させる方法です。

5.1. エージェントサーバー通信とサーバーの可用性について

5.1.1. エージェントおよびサーバー通信

高可用性を使用するかどうかの計画の一部は、エージェントとサーバーが相互に通信する方法を理解することです。
エージェントとサーバーには双方向通信があります。エージェントは、現在の監視データ、設定設定、リソース、およびその他の現在のデータをサーバーに送信します。サーバーは、設定更新、アラート定義、ドリフト定義、およびその他の設定をエージェントに送信します。
エージェントを最初にインストールすると、エージェントの設定で接続するサーバーのホスト名または IP アドレスの入力が求められます。これは、(JBoss ON デプロイメントにあるすべてのサーバー)登録サーバーです。次に、エージェント登録の一環として、利用可能な JBoss ON サーバーの一覧を受け取ります。その一覧の最初のサーバーは、エージェントが最も定期的に通信を試み、リストの他のサーバーを順番に試行するサーバーです(その後で 「エージェントおよびサーバーフェイルオーバー」)。その最初のサーバーは、登録サーバーであるか、異なるサーバーである場合もありますが、問題はありません。
エージェントが接続するサーバーには、優先度が若干ありますが、エージェントがサーバーに接続するサーバーやサーバーがどのエージェントと通信できるかには制限はありません。すべてのサーバーは任意の時点で任意のエージェントと通信でき、その逆も同様です。
注記
通信は双方向である必要があるため、すべてのサーバーがすべてのエージェントからアクセスできる必要があり、すべてのエージェントがすべてのサーバーからアクセスできるようにする必要があります。サーバーまたはエージェントのインストール時に設定されるサーバーおよびエージェントのホスト名および IP アドレスが解決可能な場合は、重要です。
ただし、サーバーは 相互に通信しないため、サーバー間 で相互のホスト名または IP アドレスを解決することはできません。

5.1.2. サーバーの可用性: 単一クラウドで複数のサーバー

多くのデプロイメントでは、単一の JBoss ON サーバーがあり、すべてのエージェントがそのサーバーと通信します。ただし、複数のサーバーが有益な環境は複数あります。
  • エージェントの負荷を処理する問題があり、メトリクスの評価、アラートまたはイベントの生成、またはリソースの可用性の報告に影響を及ぼします。これは、エージェントの数により必ずしも生じる訳ではありません。ネットワーク品質またはその他の要素に関連する可能性があります。
  • 複数のデータセンターまたはサーバーへのエージェントの論理グループを持つ地理的に分散環境が必要です。
同じデプロイメントの複数の JBoss ON サーバーが同じバックエンドデータベースを使用するように設定されます。新しい JBoss ON サーバーがデータベースに追加されると、そのサーバーは JBoss ON サーバー高可用性クラウド に自動的に追加されます。
高可用性設定は、必ずしも多数の JBoss ON エージェントを意味するわけではありません。複数のサーバー が中央データベースの負荷に影響を及ぼさない ため、パフォーマンスには大きな影響はありません。高可用性の目的は、JBoss ON デプロイメント全体が応答性と可用性、フォールトトレランスを必要とすることです。そのため、複数のサーバーが必要になります。これは、比較的少ないエージェントでも当てはまります。
重要
比較的簡単な高可用性サーバークラウドに JBoss ON サーバーを追加することは可能ですが、バックエンドデータベースに影響する可能性があるため、注意して実行する必要があります。各 JBoss ON サーバーは同時データベース接続を制限しますが、クラウド全体の接続の合計数に制限はありません。2 番目のサーバーを追加すると、エージェントの数は同じでも、潜在的なデータベース接続を 2 倍にできます。サーバーが追加されると、接続が増えると線形になります。
基本的には、高可用性は JBoss ON デプロイメント全体に対して、基本的なフェイルオーバーと冗長性を提供する方法です。すべてのサーバーは同じデータベースバックエンドを使用するため、すべて同じエージェントとインベントリーにアクセスでき、データの監視、リソース履歴、およびその他の情報にアクセスできます。つまり、すべての JBoss ON サーバーが基本的に同じであることを意味します。
JBoss ON サーバーは、高可用性クラウドに簡単に追加および削除できます。また、メンテナンスモードに切り替えてサーバーを一時的に削除することもできます。
高可用性を計画する際に必要となる事項がいくつかあります。
  1. すべてのサーバーは、同じバージョンの JBoss ON を実行している必要があります。
  2. すべてのサーバーに一意な名前を付ける必要があります。この文字列はサーバーのインストール時に定義されます。
  3. 各サーバーは、高可用性サーバークラウドに対して実行される すべて の JBoss ON エージェントによって解決可能な一意のエンドポイント(ホスト名または IP アドレス)を定義する必要があります。
  4. オプション。サーバーで同時実行制限を調整して、データベースへの負荷が過剰に発生し、パフォーマンスを低下させないようにします。

5.1.3. エージェントおよびサーバーのパーティション: エージェントロードの配布

1 台のサーバーしかない場合、エージェントディストリビューションは非常にシンプルです。すべてのエージェントがその 1 つのサーバーと通信します。

図5.1 単一のサーバー上にすべて

単一のサーバー上にすべて
ただし、高可用性が導入されると、エージェントはサーバーと通信するサーバーを選択できます。すべてのサーバーは、エージェントに送信される利用可能なサーバーの一覧に含まれますが、エージェントは常にリスト内の最初のサーバー(その プライマリーサーバー)への接続を試みます。
この一覧はラウンドロビンパターンで生成されるため、サーバーリストはエージェントごとに若干異なります。例:
A1: S1, S2, S3
A2: S2, S3, S1
A3: S3, S1, S2
これにより、サーバー全体でエージェントが非常に均等に分散されます。ディストリビューションは パーティション です。

図5.2 partitions: エージェントが分散された複数のサーバーを読み込む

partitions: エージェントが分散された複数のサーバーを読み込む
サーバーが高可用性クラウドに追加されると、agent-server リストが更新されます。エージェントロードディストリビューションの変更は、パーティションイベントと呼ば れます

5.1.4. エージェントおよび推奨サーバー: アフィニティーおよびロードバランシング

エージェント負荷の性質的な分布は、非常にランダムで、均等のディストリビューションを作成します。ただし、一部のネットワーク環境では、無作為の分布が妥当ではないり、最適な効率が得られる場合もあります。たとえば、同じリージョンまたはファシリティーにあるサーバーおよびエージェントは、はるかに距離にあるサーバーおよびエージェントよりも早く通信できます。この場合、管理者はランダムなサーバーエージェント関係ではなく、明示的な適切なサーバーエージェント関係を優先します。
JBoss ON には server-agent affinity の概念があります。アフィニティーは、エージェントが通信するサーバーに対する定義された優先順位です。アフィニティーグループは基本的に手動パーティションです。これはサーバーおよびエージェントのグループであり、エージェントは最初にアフィニティーグループでサーバーと選択的に通信します。

図5.3 エージェントロードのアフィニティー設定

エージェントロードのアフィニティー設定
アフィニティーグループは、どのサーバーと通信するかについてエージェントに対して緩やかな優先順位を作成します。ハードルールが作成されたり、エージェントが通信できるサーバーを制限するサーバーも制限されます。
注記
アフィニティーグループは、エージェントからサーバーへの 一方向の優先 度を定義します。アフィニティー設定に関係なく、サーバーは JBoss ON トポロジーのすべてのエージェントに接続できます。
エージェントのプライマリーサーバーが利用できない場合、エージェントはアフィニティーグループ内の他のサーバーを通過してラウンドロビンを試みます。これらのサーバーがない場合や、アフィニティーグループに他のサーバーがない場合、フェイルオーバーのリストに従って JBoss ON の高可用性クラウドのすべてのサーバーを繰り返し処理します。これは、アフィニティーグループのすべてのエージェントで当てはまるため、最終的にあるグループ内のエージェントは他の JBoss ON サーバー間で均等に分散されます。

図5.4 アフィニティーによるフェイルオーバー

アフィニティーによるフェイルオーバー
アフィニティーグループは、以下の 3 つの利点を提供します。
  • 物理またはネットワーク効率。一般的に、特定のエージェントサーバー接続が他よりも明確に効率的に実行される場合は、これらの接続を優先するようにアフィニティーを定義することが理にかなっています。これには、同じデータセンター、地理的なグループ化、またはネットワークトポロジーに同じサーバーとエージェントを共存させる可能性があります。
  • 論理組織。運用効率以外に、管理責任やビジネスユニットの割り当てなど、特定のエージェントとサーバーをグループ化する組織上の理由が考えられます。
  • ホットバックアップ。特定のマシンがフェイルオーバーの目的で特に必要でない限り、エージェント負荷を割り当てない必要がある場合があります。この場合、すべてのエージェントを利用可能なサーバーのサブセットにアフィニティーを割り当てる必要があります。一部のサーバーは、通常の操作で関連付けられたエージェントなしで残す必要があります。

5.1.5. エージェントおよびサーバーフェイルオーバー

そのエージェントで利用可能なサーバーを特定するために各エージェントに提供されるサーバーの中央リストがあります。これは フェイルオーバーの一覧 です。新しいサーバーがクラウドに参加すると、そのサーバーがリストに追加され、リストがエージェントに更新されます。
エージェントの一覧にあるサーバーが、その プライマリーサーバー と最も頻繁に通信します。エージェントがそのサーバーに接続できない場合は、利用可能なサーバーを見つけるまで、リスト内の次のサーバーへの接続を試みます。
エージェントは定期的に(時間ごとに)定期的にチェックし、プライマリーサーバーがオンラインに戻るかどうかを確認し、復元するとすぐにそのサーバーに切り替えます。
エージェントの定期的なディストリビューションでは、エージェントは、提供されたフェイルオーバーリストに応じて、利用可能なすべてのサーバーを(比較的)ランダムな順序で実行します。エージェントがアフィニティーグループに属する場合は、最初にそのアフィニティーグループ内のすべてのサーバーを試行し、フェイルオーバー一覧で設定される順序でアフィニティーグループ外のサーバーに移動します。