Junos Space クラスタ内の論理クラスタについて
複数の Junos Space 仮想アプライアンスを接続して、Junos Space クラスターを形成できます。 図 1 は、各 Junos Space クラスタ内で形成される論理クラスタ(Apache Load Balancer クラスタ、JBoss クラスタ、MySQL クラスタ)を示しています。
Apacheロードバランサクラスター
mod_proxyロードバランサーモジュールが有効なApache HTTPサーバーは、クラスタ内の2つのノードでいつでも実行されます。これらのサーバーは、アクティブスタンバイ論理クラスターを形成します。両方とも、GUI と NBI クライアントからの HTTP 要求に対して TCP ポート 443 でリッスンします。すべてのクライアントは、クラスターの仮想 IP(VIP)アドレスを使用して、そのサービスにアクセスします。VIP アドレスは、いつでもクラスター内の 1 つのノードだけが所有します。したがって、VIP アドレスを所有するノード上の Apache HTTP サーバーは、GUI および NBI クライアントからすべての HTTP 要求を受信し、アクティブなロード バランサー サーバーとして機能します。もう一方のサーバーはスタンバイとして機能します。ラウンドロビンロードバランシングアルゴリズムを使用して、クラスタ内のすべてのノードで実行されているJBossサーバーにリクエストを配信します。また、ロードバランサーは、ユーザーセッションからのすべてのHTTPリクエストがクラスタ内の同じノードに送信されるように、セッションの貼り付け性を採用します。これを実現するために、サーバーは JSESSIONID という名前の Cookie を設定します。この Cookie の値は、このユーザー セッションに属する要求を提供するクラスター内の特定のノードを識別します。追加のリクエストにはこのCookieが含まれており、ロードバランサーはこのCookieが識別するノードで実行されるJBossサーバーにリクエストを転送します。
ノード上の Apache HTTP サーバーがダウンすると、そのノードのウォッチドッグ・サービスによってサーバーが自動的に再始動されます。このノードが VIP アドレスを所有している場合、GUI および NBI クライアントは Apache HTTP サーバーが再起動されるまでサービス停止が少し発生する可能性があります。ただし、この障害はほんの数秒(通常は 2 秒)しか続かないため、クライアントはほとんど気づき得ない。一方、Apache HTTP サーバーが、現在 VIP アドレスを所有していないノード上でダウンした場合、クライアントやその他のコンポーネントによって副作用は発生しません。ウォッチドッグ・サービスはサーバーを再起動し、サーバーは約2秒でバックアップします。
JBoss クラスタ
JBoss アプリケーション・サーバーは、Junos Space クラスター内の専用データベース・ノードを除くすべてのノードで実行されます。ノードは単一の全アクティブな論理クラスターを形成し、負荷分散サーバー(前述)はすべてのノードに負荷を分散します。クラスター内の 1 つ以上の JBoss サーバーに障害が発生しても、アプリケーション ロジックは存続ノードから引き続きアクセスできます。すべてのノード上の JBoss サーバーは同じ設定で起動され、UDP マルチキャストを使用して互いを検出し、1 つのクラスタを形成します。JBoss では、すべてのノードでセッションレプリケーションとキャッシングサービスに UDP マルチキャストを使用します。
JBoss サーバーは、FMPM(障害監視およびパフォーマンス監視)ノードおよびホストされた仮想マシンでは実行されません。
ノード上の JBoss サーバーがダウンすると、JBoss クラスター内の他のノードがこの変更を検出し、障害が発生したノードをクラスターから削除するように自動的に再構成します。障害が発生した JBoss サーバーを他のクラスター・メンバーが検出するのに必要な時間は、JBoss サーバー・プロセスが異常終了したか、応答していないかによって異なります。以前のケースでは、クラッシュした JBoss サーバーへの TCP 接続がオペレーティング システムによって閉じられているため、クラスタ メンバーは直ちに(約 2 秒)障害を検出します。後者の場合、クラスタメンバーは約52秒で障害を検出します。JBossサーバーがクラッシュした場合、ノードで実行されているウォッチドッグサービス(jmp-watchdog)によってJBossサーバーが自動的に再起動されます。JBoss サーバーがバックアップされると、JBoss サーバーは他のクラスタ メンバーによって自動的に検出され、クラスタに追加されます。その後、JBoss サーバーは、クラスター内の他のノードからキャッシュを同期します。JBoss サーバーの通常のリスタート時間は 2~5 分ですが、インストールされているアプリケーションの数、管理するデバイスの数、インストールされている DMI スキーマ バージョンの数などにより、より多くの時間がかかることがあります。
クラスター内の 1 つの JBoss サーバーは、常にクラスターの 1 次として機能します。プライマリ指定の主な目的は、クラスタ全体のシングルトン(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 アドレスは、プライマリ データベース ノードとして指定されたノードによって所有されます。1 次データベース・ノード上の MySQL サーバーはアクティブなデータベース・サーバーとして機能し、セカンダリ・データベース・ノード上のサーバーはスタンバイとして機能します。 図 2 は、Junos Space クラスタの一部として専用データベース ノードがある場合に Junos Space クラスタ内で形成される論理クラスタ(Apache Load Balancer クラスタ、JBoss クラスタ、MySQL クラスタ)を示しています。
各ノード上の MySQL サーバーは、固有のサーバー ID で構成されます。プライマリとバックアップの関係もノード上で対称的に設定されるため、最初のノード上のサーバーは2番目のノードがプライマリとして設定されます。2番目のノード上のサーバーは、最初のノードをプライマリとして設定します。したがって、どちらのノードも他方のノードのバックアップとして機能でき、VIP アドレスを所有するノード上で実行されているサーバーは、いつでもプライマリとして機能し、プライマリとバックアップの関係が、1 つのノードから他方のノードへの VIP 所有権スイッチとして動的に切り替わります。アクティブ(プライマリ)サーバー上でコミットされたすべてのトランザクションは、バイナリ ロギング メカニズムに基づく MySQL が提供する非同期レプリケーション ソリューション [2] によって、ほぼリアルタイムでスタンバイ(バックアップ)サーバーに複製されます。プライマリ(データベースのソースが変更される)として動作する MySQL サーバーは、更新と変更をバイナリ ログに「イベント」として書き込みます。バイナリ ログの情報は、記録されるデータベースの変更に応じて、異なるログ形式で保存されます。バックアップ サーバーは、プライマリからバイナリ ログを読み取り、バックアップのローカル データベースでバイナリ ログ内のすべてのイベントを実行するように構成されています。
ノード上の MySQL サーバーがダウンした場合、そのノードのウォッチドッグ・サービスによってサーバーが自動的に再始動されます。再起動すると、MySQL サーバーは 20~60 秒以内に起動する必要があります。このノードが VIP アドレスを所有している場合、JBoss はこの 20~60 秒間、短時間のデータベース障害が発生する可能性があります。この期間中に、データベースへのアクセスを必要とする要求はすべて失敗します。一方、MySQL サーバーが VIP アドレスを現在所有していないノード上でダウンした場合、JBoss が気付く副作用はありません。ウォッチドッグサービスはサーバーを再起動し、サーバーは1分未満でバックアップされます。サーバーをバックアップした後、バックグラウンドでプライマリと再同期し、再同期時間は障害発生時に発生した変更数に依存します。
カサンドラクラスター
リリース 15.2R2 以降、Cassandra クラスターは、Junos Space クラスター内に含めることができるオプションの論理クラスターです。Cassandra クラスタは、2 つ以上の専用 Cassandra ノード、または Cassandra サービスが実行されている 2 つ以上の JBoss ノード、またはこれらの組み合わせが Junos Space ファブリック内で存在する場合に形成されます。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 データベースに保存されているファイルは失われます。