Junos Space クラスタ内の論理クラスタを理解する

Apache ロードバランサークラスター

mod_proxy ロードバランサーモジュールが有効になっている Apache HTTP サーバーは、クラスター内の 2 つのノードで常に実行されます。これらのサーバーは、アクティブ/スタンバイの論理クラスターを形成します。どちらも TCPポート 443 で GUI および NBI クライアントからの HTTP 要求をリッスンします。すべてのクライアントは、クラスタの仮想 IP (VIP) アドレスを使用して、そのサービスにアクセスします。VIP アドレスは、常にクラスタ内の 1 つのノードによってのみ所有されます。したがって、VIP アドレスを所有するノード上の Apache HTTP サーバは、GUI および NBI クライアントからすべての HTTP 要求を受信し、アクティブロードバランササーバとして機能し、もう一方のサーバはスタンバイとして機能します。ラウンドロビン負荷分散アルゴリズムを使用して、クラスター内のすべてのノードで実行されている JBoss サーバーに要求を分散します。また、ロードバランサーは、セッションスティッキ性を採用して、ユーザーセッションからのすべてのHTTPリクエストがクラスター内の同じノードに送信されるようにします。これを実現するために、サーバーは JSESSIONID という名前の Cookie を設定します。この Cookie の値は、このユーザー セッションに属する要求を処理するクラスター内の特定のノードを識別します。すべての追加リクエストにはこの Cookie が含まれており、ロードバランサーは、この Cookie が識別するノードで実行されている JBoss サーバーにリクエストを転送します。

ノード上の Apache HTTP サーバーがダウンすると、そのノードのウォッチドッグ サービスによってサーバーが自動的に再起動されます。このノードが VIP アドレスを所有している場合、Apache HTTP サーバーが再起動されるまで、GUI および NBI クライアントで短時間のサービス停止が発生する可能性があります。ただし、この停止は数秒(通常は2秒)しか続かず、クライアントが気付くことはほとんどありません。一方、現在 VIP アドレスを所有していないノードで Apache HTTP サーバーがダウンしても、クライアントやその他のコンポーネントは副作用に気付きません。ウォッチドッグ サービスがサーバーを再起動し、サーバーは約 2 秒で復旧します。

JBoss クラスター

JBoss アプリケーションサーバーは、Junos Space クラスター内の専用データベースノードを除くすべてのノードで稼働します。ノードは 1 つのすべてアクティブな論理クラスターを形成し、ロード バランサー サーバー (前述) がすべてのノードに負荷を分散します。クラスター内の 1 つ以上の JBoss サーバーに障害が発生した場合でも、アプリケーションロジックは残りのノードから引き続きアクセスできます。すべてのノード上のJBossサーバーは同じ設定で起動され、UDPマルチキャストを使用して互いを検出し、単一のクラスターを形成します。また、JBoss はすべてのノードでセッションレプリケーションとキャッシングサービスに UDP マルチキャストを使用します。

手記：

JBoss サーバーは、Fault Monitoring and Performance Monitoring (FMPM) ノードおよびホストされた仮想マシンでは実行されません。

ノード上の JBoss サーバーがダウンすると、JBoss クラスター内の他のノードがこの変更を検出し、障害が発生したノードをクラスターから削除するために自動的に再構成されます。障害が発生した JBoss サーバーの検出に他のクラスターメンバーがかかる時間は、JBoss サーバープロセスが異常にクラッシュしたか、応答していないかによって異なります。前者の場合、クラッシュした JBoss サーバーへの TCP 接続がオペレーティングシステムによって閉じられるため、クラスターメンバーは障害を即時 (約 2 秒) 検出します。後者の場合、クラスタ メンバーは約 52 秒で障害を検出します。JBossサーバーがクラッシュした場合、JBossサーバーはノードで実行されているウォッチドッグサービス(jmp-watchdog)によって自動的に再起動されます。JBoss サーバーが復旧すると、JBoss サーバーは他のクラスターメンバーによって自動的に検出され、クラスターに追加されます。次に、JBoss サーバーはクラスター内の他のノードからキャッシュを同期します。JBoss サーバーの一般的な再起動時間は 2 分から 5 分ですが、インストールされているアプリケーションの数、管理対象のデバイスの数、インストールされている DMI スキーマのバージョンの数などによっては、さらに時間がかかる場合があります。

クラスター内の 1 つの JBoss サーバーは、常にクラスターのプライマリとして機能します。主な指定の主な目的は、クラスター全体のシングルトン (HA シングルトン) として展開されるサービス (たとえば、クラスター内の 1 つのサーバーにのみ常に展開する必要があるサービス) をホストすることです。Junos Space は、クラスタ全体のジョブをスケジューリングするための単一のタイマーを提供するジョブポーラーサービスや、クラスタ内のノードを監視および管理する分散リソースマネージャ(DRM)サービスなど、このタイプの複数のサービスを使用します。これらのサービスは、プライマリとして指定されている JBoss サーバーにのみデプロイされます。

手記：

これは、プライマリが他のサービスをホストしないという意味ではありません。クラスタ以外のシングルトン サービスもプライマリ サーバーでホストされます。Junos Space は、クラスター内で最初に起動した JBoss サーバーがプライマリになるように構成されています。プライマリーサーバーがダウンすると、JBoss クラスター内の他のメンバーがこれを検出し、新しいプライマリーを選択します。

MySQLクラスタ

MySQL サーバーは、常に Junos Space クラスター内の 2 つのノードで稼働しています。これらのノードは論理アクティブスタンバイクラスターを形成し、両方のノードが JBoss サーバーからのデータベース要求を TCPポート 3306 でリッスンします。デフォルトでは、JBoss サーバーはクラスターの仮想 IP (VIP) アドレスを使用してデータベースサービスにアクセスするように設定されています。VIP アドレスは、常にクラスタ内の 1 つのノードによってのみ所有されます。したがって、VIP アドレスを所有するノード上の MySQL サーバーは、アクティブデータベースサーバーとして機能し、他のサーバーがスタンバイとして機能する JBoss サーバーからすべてのデータベースリクエストを受信します。

Junos Spaceネットワーク管理プラットフォームとJunos Spaceアプリケーションのパフォーマンスを向上させたい場合は、2つのJunos Spaceノードを追加して、専用データベースノードとして実行することができます。任意の 2 つの Junos Space ノードをプライマリおよびセカンダリ データベース ノードとして追加すると、MySQL サーバは 2 つの専用データベース ノードに移動され、Junos Space クラスタの最初の 2 つのノードでは無効になります。これにより、Junos SpaceアクティブVIPノード上のシステムリソースが解放され、ノードのパフォーマンスが向上します。

JBoss サーバーは、専用のデータベースノード上のデータベースサービスにアクセスするために、別のデータベース仮想 IP (VIP) アドレスを使用します。Junos Spaceクラスタに専用データベースノードとしてノードを追加する場合は、データベースのVIPアドレスを指定します。この VIP アドレスは、1 次データベース・ノードとして指定されたノードが所有します。プライマリデータベースノード上の MySQL サーバーはアクティブデータベースサーバーとして機能し、セカンダリデータベースノード上のサーバーはスタンバイとして機能します。 図 2 は、Junos Space クラスターの一部として専用データベース ノードがある場合に、Junos Space クラスター内に形成される論理クラスター(Apache Load Balancer クラスター、JBoss クラスター、MySQL クラスター)を示しています。

各ノード上の MySQL サーバーは、一意のサーバー ID で構成されます。プライマリとバックアップの関係もノード上で対称的に構成されるため、最初のノードのサーバーは 2 番目のノードをプライマリとして構成されます。2 番目のノードのサーバーは、最初のノードを 1 次ノードとして構成されます。したがって、両方のノードが他のノードのバックアップとして機能し、VIP アドレスを所有するノードで実行されているサーバーがいつでもプライマリとして機能するため、VIP 所有権が 1 つのノードから別のノードに切り替わると、プライマリとバックアップの関係が動的に切り替わります。アクティブ (プライマリ) サーバーでコミットされたすべてのトランザクションは、バイナリロギングメカニズムに基づく MySQL が提供する非同期レプリケーションソリューション [2] を使用して、ほぼリアルタイムでスタンバイ (バックアップ) サーバーに複製されます。プライマリ(データベース変更のソース)として動作するMySQLサーバーは、更新と変更を「イベント」としてバイナリログに書き込みます。バイナリログの情報は、記録されるデータベースの変更に応じて、異なるロギング形式で保存されます。バックアップサーバーは、プライマリからバイナリログを読み取り、バックアップのローカルデータベースでバイナリログ内のすべてのイベントを実行するように構成されています。

ノード上の MySQL サーバーがダウンすると、そのノードのウォッチドッグサービスによってサーバーが自動的に再起動されます。再起動すると、MySQL サーバーは 20 秒から 60 秒以内に起動します。このノードが VIP アドレスを所有している場合、JBoss ではこの 20 秒から 60 秒間、短時間のデータベース停止が発生する可能性があります。この期間中は、データベース・アクセスを必要とする要求はすべて失敗します。一方、現在 VIP アドレスを所有していないノードで MySQL サーバーがダウンしても、JBoss が気づく副作用はありません。ウォッチドッグ サービスはサーバーを再起動し、サーバーは 1 分以内に復旧します。サーバーがバックアップされると、バックグラウンドでプライマリと再同期され、再同期時間は停止中に発生した変更の数によって異なります。

Cassandra クラスター

リリース15.2R2以降、Cassandraクラスターは、Junos Spaceクラスター内に含めることができるオプションの論理クラスターになりました。Cassandra クラスターは、Junos Space ファブリック内で 2 つ以上の専用 Cassandra ノードまたは 2 つ以上の JBoss ノードがあり、Cassandra サービスが実行されている場合、あるいはその両方の組み合わせがある場合に形成されます。Cassandra サービスは、専用データベース ノードと FMPM ノードを除くファブリック内のすべてのノードで実行しないことを選択できます。Junos Spaceノードで実行されるCassandraサービスは、Junos Spaceアプリケーション(Service Nowで生成されたジュニパーメッセージバンドル[JMB]やNetwork Directorで生成されたRRDファイルなど)からのデバイスイメージとファイルを格納するための分散ファイルシステムを提供します。ファブリックにCassandraノードがない場合、デバイスイメージファイルとJunos SpaceアプリケーションファイルはMySQLデータベースに保存されます。 図 3 は、Junos Space クラスターの一部として Cassandra ノードがある場合に、Junos Space クラスター内に形成される論理クラスター (Apache Load Balancer クラスター、JBoss クラスター、MySQL クラスター、Cassandra クラスター) を示しています。

Cassandra サービスは、Cassandra データベースのリアルタイム レプリケーションを使用して、アクティブ/アクティブ構成のすべての Cassandra ノードで実行されます。Cassandra データベースにアップロードされたすべてのファイルは、Cassandra クラスター内のすべてのノードにコピーされます。JBoss サーバーは、Cassandra クラスター内の Cassandra ノードにラウンドロビン方式で要求を送信し、それぞれの Cassandra ノードの IP アドレス (eth0 インターフェース) を使用してノードにアクセスします。

いずれかの Cassandra ノードがダウンした場合、Junos Space プラットフォームは、ダウンしたノードがファブリックから削除されるまで、Cassandra データベースにファイルをアップロードしたり、Cassandra データベースからファイルを削除したりすることはできません。既存の Cassandra ノードがすべて削除されると、Cassandra データベースに格納されているファイルは失われます。