クラスタ内の高可用性ノードについて

デフォルトでは、クラスタに追加された最初の 2 つのノードは HA ノードとして機能します。トピック「 Junos Space クラスタ内の論理クラスタについて」の例では、最初の 2 つのノード(ノード 1 とノード 2)が HA ノードであることを示しています。 [ネットワーク管理プラットフォーム] > [管理] > [ファブリック ] ワークスペースからノード 1 またはノード 2 を削除する場合、システムは、削除された HA ノードを置き換えるためにクラスタ内の他のノードを使用できるかどうかを確認します。次に、選択可能なノード (この例ではノード 3 のみ) の一覧が表示されます。選択したノードを確認すると、分散リソースマネージャー (DRM) サービスは、新しく選択したノードで実行されているノード管理エージェント (NMA) に要求を送信して、ノードを HA クラスターに追加します。HA クラスターに追加されたノードで、以下のアクションが開始されます:

• mod_proxyロードバランサーを持つ Apache HTTP サーバーがノードで起動され、ノードはすべての JBoss ノードをメンバーとして設定されます。

• クラスタ内に専用のデータベースノードがない場合は、クラスタ内の他の HA ノード上の MySQL サーバーのデータベースがコピーされ、MySQL サーバーがノード上で起動されます。このサーバーは、クラスタ内の他の MySQL サーバーのバックアップとして構成され、バックグラウンドでプライマリと再同期します。既存の MySQL サーバーも、この新しいサーバーのバックアップとして機能するように再構成され、両方の対称プライマリ/バックアップ構成が保証されます。

Junos Space クラスタに専用データベースノードを追加する場合、2 つのノードをプライマリおよびセカンダリデータベースノードとして追加して、MySQL クラスタを形成します。データベースは、アクティブな HA ノードから 2 つのデータベースノードにコピーされ、HA ノードでは無効になります。クラスタからデータベース ノードの 1 つを削除すると、もう一方のデータベース ノードがプライマリ データベース ノードに指定されます。システムは、クラスタ内の非 HA ノードが削除されたデータベースノードを置き換えることができるかどうかを確認し、削除されたノードを置き換えるために選択できるノードのリストを表示します。

ノードを選択すると、分散リソースマネージャー (DRM) サービスは、新しく選択されたノードで実行されているノード管理エージェント (NMA) にリクエストを送信して、ノードを MySQL クラスタに追加します。

MySQL クラスタに追加されたノードで次のアクションが開始されます:

• クラスタ内のプライマリデータベースノード上の MySQL サーバーからデータベースがコピーされ、新しく追加されたセカンダリデータベースノードで MySQL サーバーが起動されます。このサーバーは、プライマリデータベースノード上の MySQL サーバーのバックアップとして構成され、バックグラウンドでプライマリサーバーと再同期します。プライマリデータベースノード上の既存の MySQL サーバーも、セカンダリデータベースノード上のこの新しいサーバーのバックアップとして機能するように再構成され、両方で対称プライマリ/バックアップ構成が保証されます。

• JBoss サーバーは、新しく追加されたデータベースノードで停止します。

3 つのデフォルトの論理クラスターに加えて、Junos Space ファブリックの一部として Cassandra クラスターがある場合、Cassandra にアップロードされたファイルは、Cassandra クラスターの一部であるすべての Cassandra ノードにコピーされます。したがって、1 つの Cassandra ノードに障害が発生しても、障害が発生したノードのファイルは失われません。しかし、Junos Space プラットフォームは、障害が発生したノードが削除されるまで、Cassandra データベースへのファイルのアップロードや削除ができません。

Cassandra サービスが HA ノードで有効になっていて、そのノードがダウンし、新しく追加された HA ノードで Cassandra サービスを実行する場合は、ノードで Cassandra サービスを手動で有効にして開始する必要があります。Cassandra サービスが実行されている最後のノードが削除されると、Cassandra データベースに格納されているファイルは失われます。