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 が識別するノードで実行されている JBoss サーバーに要求を転送します。

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

JBoss クラスター

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

手記：

JBoss サーバーは、障害監視およびパフォーマンス監視 (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 は、クラスタ全体でジョブをスケジュールするための単一のタイマーを提供する Job Poller サービスや、クラスタ内のノードを監視および管理する分散リソース マネージャー (DRM) サービスなど、このタイプの複数のサービスを使用します。これらのサービスは、プライマリとして指定された JBoss サーバーにのみデプロイされます。

手記：

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

MySQL クラスタ

MySQL サーバーは、常に Junos Space クラスタ内の 2 つのノードで実行されます。これらのノードは論理的なアクティブ/スタンバイクラスターを形成し、両方のノードが TCP ポート 3306 で JBoss サーバーからのデータベース要求をリッスンします。デフォルトでは、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 アドレスは、プライマリ データベース ノードとして指定されたノードによって所有されます。プライマリデータベースノード上の MySQL サーバーはアクティブなデータベースサーバーとして機能し、セカンダリデータベースノード上のサーバーはスタンバイとして機能します。 図 2 は、Junos Space クラスターの一部として専用のデータベース ノードがある場合に、Junos Space クラスター内で形成される論理クラスター (Apache Load Balancer クラスター、JBoss クラスター、および MySQL クラスター) を示しています。

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

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

カサンドラ星団

リリース15.2R2以降、Cassandraクラスタは、Junos Spaceクラスタ内に含めることができるオプションの論理クラスタです。Cassandra クラスターは、Junos Space ファブリック内に、Cassandra サービスが実行されている 2 つ以上の専用 Cassandra ノードまたは 2 つ以上の JBoss ノード、またはその両方の組み合わせがある場合に形成されます。Cassandra サービスは、専用データベースノードと FMPM ノードを除くファブリック内のノードのいずれでも実行しないか、すべてで実行するかを選択できます。Junos Spaceノードで実行されるCassandraサービスは、Junos Spaceアプリケーション(Service Nowで生成されたJuniper Message Bundle[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 ノードの (eth0 インターフェイスの) IP アドレスを使用してノードにアクセスします。

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