Junos Space高可用性ソフトウェアアーキテクチャの概要
Junos Spaceプラットフォームは、次のような機能で構成されるクラスター化された多階層型の分散型アーキテクチャにより、99.999%の可用性を確保できるように設計されています。
-
標準的なブラウザベースのWeb 2.0 GUIクライアントとREST/HTTPSベースのNBIクライアント
-
最上位のロードバランサーとしての Apache Load Balancer
-
J2EE技術をベースにしたJBoss Application Serverがアプリケーションフレームワークを提供
-
永続データを管理するためのMySQLデータベース
-
デバイスイメージファイルとJunos Spaceアプリケーションからのファイルを保存するCassandra分散ファイルシステム
以下のセクションでは、Junos Spaceアーキテクチャについて説明し、Junos Spaceクラスタ内のノード間の通信に関する基本的な要件を特定します。
Junos Spaceソフトウェアアーキテクチャ
図1は、Junos Spaceのソフトウェアアーキテクチャの概要を示しています。Junos Spaceサービスには、クラスタの単一の仮想IPアドレスを使用して、GUIおよびNBIクライアントからアクセスできます。
クライアントからの要求は、クラスター内の 2 つのノードにアクティブ/ホット スタンバイ構成でデプロイされる Apache HTTP Load Balancer を介して、クラスター内の複数のノード間で負荷分散されます。仮想 IP (VIP) アドレスを所有するノード上のロード バランサーは、アクティブなインスタンスとして機能します。現在 VIP アドレスを所有しているノードがダウンした場合、Linux 仮想サーバー (LVS) クラスター内の他のノードがこの障害を検出し、自動的に VIP アドレスを引き継ぎます。HTTP リクエストは、ラウンドロビンアルゴリズムを使用して、クラスター内のすべてのアクティブな JBoss サーバー間で負荷分散されます。
クラスター内のアクティブな JBoss サーバーは、以下のサービスを含む Junos Space アプリケーションのアプリケーションフレームワークを提供します。
-
アプリケーションおよび関連するビジネス・ロジックのホスティング
-
クラスタ内のアプリケーションレベルのロードバランシング
-
アプリケーションの監視と自動リカバリ
-
クラスター ノードの監視と自動回復
-
JDBCを介してMySQL DBに直接アクセスできるデータベースサービス
-
ホスティング・デバイス・メディエーション・ロジック
ロードバランシングアーキテクチャ
Junos Spaceクラスターには、2種類の負荷がかかります。
-
GUIおよびNBIクライアントからの着信要求
-
管理対象デバイスとの通信
Junos Space は、クラスタ内のすべてのアクティブ ノード間で受信リクエストの負荷分散を行うように設計されています。GUI および NBI クライアントからの要求は、Apache HTTP ロードバランサーのアクティブインスタンスによって処理される HTTP 要求として届きます。ロードバランサーは、ラウンドロビンアルゴリズムを使用して、クラスター内のすべてのアクティブな JBoss サーバーにリクエストを分散します。スティッキー・セッションは、特定の GUI セッションに関連するすべての HTTP 要求が、そのセッションの存続期間中に同じ JBoss サーバーによって処理されるようにするために利用されます。アプリケーションレベルのロードバランシングを目的として、JBoss ビジネスロジックは複雑なリクエストを一連のサブジョブとして処理し、クラスター内の複数のノードに分散します。たとえば、100 台のデバイスを再同期するという 4 ノードのスペース クラスターに対する 1 つの要求は、4 つの異なるノードで実行される 4 つのサブジョブに分割され、各ノードは 25 台のデバイスを再同期します。ロードバランシングの詳細な概要については、トピック Junos Spaceクラスタ内の論理クラスタを理解するを参照してください。
デバイスレベルのロードバランシングを実行するために、Junos Spaceはデバイスメディエーションレイヤー(DML)のロジックを採用し、デバイス接続がクラスタ内のすべてのアクティブノードに均等に分散されるようにしています。デバイスレベルのロードバランシングは、デバイス検出時に、個々のノードが提供するデバイス接続数を比較し、最も負荷の少ないノードを選択することによって実行されます。いずれかのノードがダウンした場合、関連するすべてのデバイス接続がクラスタ内の残りのアクティブノードに分散されるため、ノードの停止がデバイスの接続に影響を与えるのを防ぎます。デバイス接続管理の詳細な概要については、 トピック「DMI接続の高可用性管理について」を参照してください。
データベースアーキテクチャ
MySQL Enterprise Edition は、プラットフォームとアプリケーションの両方の永続データを管理するためのデータベースサービスを提供するために使用されます。MySQL DBサーバーは、クラスタ内の2つのノードでアクティブ/スタンバイ構成で実行されています。データベーストランザクションは、2つのMySQLサーバー間でほぼリアルタイムで複製されます。各Junos Spaceクラスタ内で形成されるMySQLクラスタの詳細については、 Junos Spaceクラスタ内の論理クラスタを理解するを参照してください。
Junos Spaceプラットフォームには、障害およびパフォーマンス管理のためのネットワーク監視機能も組み込まれており、障害およびパフォーマンス関連データの保存にはPostgreSQL リレーショナル データベースサービスを使用します。PostgreSQLサーバは、Spaceクラスタ内の2つのノード上でアクティブ/アクティブ構成で稼働し、リアルタイムレプリケーションにより、これらのノードの1つに障害が発生した場合でも、障害とパフォーマンスのデータを引き続き利用できるようにします。詳細については、「 ネットワーク監視の高可用性」を参照してください。
Junos Spaceクラスタ内のノード間のノード間通信
Spaceクラスタ内のノード間のシームレスな通信を促進し、クラスタの最適なパフォーマンスを実現するには、次のことを確認する必要があります。
-
Junos Spaceクラスタ内のすべてのノードは、同じサブネット内のIPアドレスで設定されます。これは、VIPスイッチオーバーメカニズムが正しく機能するために重要です。
-
Spaceクラスタ内のすべてのノードは、1Gbpsまたは100Mbpsのローカルネットワークで接続されており、レイテンシーは無視できます。
-
Junos Spaceクラスタ内のJBossサーバは、UDPマルチキャストで通信し、論理クラスタを形成します。
手記:UDP マルチキャスト トラフィックは、クラスタ内のノード内で許可する必要があります。つまり、クラスタを相互接続するスイッチでは IGMP スヌーピングを無効にするか、ノード間で UDP マルチキャストを許可するように明示的に設定する必要があります。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。