![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
バックアップ・クラスター
バックアップ・クラスターは、プライマリー・サーバー・クラスターをミラーリングします。 ミラーリングされたクラスターのサポートは、Enterprise JavaBeans (EJB) 要求のみを対象としています。

あるクラスターのすべてのメンバーが Enterprise JavaBeans (EJB) 要求の処理に使用できなくなった場合は、そのクラスター内のいずれかの Enterprise JavaBeans (EJB) アプリケーション・サーバーと対話する必要のあるすべてのクライアントが機能しません。 1 次クラスター内のどの Enterprise JavaBeans (EJB) アプリケーション・サーバーも要求を処理できない場合、ミラーリングされたクラスターは、EJB クラスター (1 次クラスター) を別の Enterprise JavaBeans (EJB) クラスター (バックアップ・クラスター) にフェイルオーバーできるようにします。 バックアップ・クラスターにより、1 次クラスター内のすべてのクラスター・メンバーが使用不可になった場合でも、クライアントは機能を継続できます。
フェイルバックは自動です。 1 次クラスター内のサーバーの再始動後に、1 次クラスターへのフェイルバックを開始する必要はありません。 バックアップ・クラスターは、1 次クラスターが使用可能になるとすぐ、要求の処理を停止します。 しかし、バックアップ・クラスター・サポートに対して、すべてのデプロイメント・マネージャーが機能している必要があります。 また、1 次クラスターがバックアップ・クラスターのバックアップとして定義されている必要があります。
- 1 次クラスターで使用可能であったオブジェクトやリソースがバックアップ・クラスターでも使用できる必要があります。
- バックアップ・クラスターでも、1 次クラスターの場合と同じクラスター名を使用し、同じアプリケーションをインストールし、同じアプリケーション名を使用し、同じリソースを定義する必要があります。
- クラスターはセル内で固有の名前を持つ必要があるため、1 次クラスターとバックアップ・クラスターは別々のセルに存在する必要があります。
- 1 次クラスターとバックアップ・クラスターの両方にバックアップ・クラスターが構成され、それぞれのクラスターが、対向するクラスターをバックアップ・クラスターとして指定する必要があります。
1 次クラスターとバックアップ・クラスターが別々のセルに存在するため、現行バージョンの製品では、クラスターも別々のコア・グループに存在します。 コア・グループ・ブリッジ・サービスを構成し、コア・グループ間の通信を可能にする必要があります。 コア・グループ・ブリッジ・サービスにより、バックアップ・クラスターのサポートのために、デプロイメント・マネージャーおよびノード・エージェントを実行する必要性がなくなります。 以前のリリースでは、デプロイメント・マネージャーが停止した場合、1 次クラスターに障害が発生した後、新規の要求をバックアップ・クラスターに転送できませんでした。 1 次クラスターを含むセルに構成されたコア・グループ・ブリッジ・サーバーは、 バックアップ・クラスターについての情報を提供できます。 バックアップ・クラスターは、セル内のすべてのコア・グループ・ブリッジ・サーバーが稼働中でない場合にのみ、サポートに失敗します。
クラスターのフェイルオーバーとフェイルバックが期待どおりに機能するためには、デプロイメント・マネージャー、ノード・エージェント、およびアプリケーション・サーバーなどの、1 次クラスターとバックアップ・クラスター両方のすべてのサーバーが、ミラーリングされたクラスターのサポートを提供しているリリースおよびレベルでなければなりません。
ミラーリングされたクラスターのサポートは、デフォルトでは構成されません。 ミラーリングされたクラスターのサポートを使用するには、ご使用の構成にバックアップ・クラスターを指定する必要があります。 各クラスターは、バックアップ・クラスターを 1 つだけ持つことができ、それらを バックアップ・クラスターとして指定する前に構成しておく必要があります。
クラスターにバックアップ・クラスターを構成するには、名前およびドメイン・ブートストラップ・アドレスを指定します。 ブートストラップ・ホストとは、 バックアップ・クラスターが構成されているデプロイメント・マネージャーを含んでいるホストです。 ブートストラップ・ポートは、そのデプロイメント・マネージャーに対するブートストラップ・ポートです。
1 次クラスターとバックアップ・クラスターは、 別々のセルに配置する必要があります。 ミラーリングされたクラスターを別々のセルに配置するには、適切なバックアップ・クラスターのドメイン・ブートストラップ・アドレスを構成します。 バックアップ・クラスターのブートストラップ・ホストとブートストラップ・ポートは、 バックアップ・クラスターが含まれたセルを判別します。
- 「ドメイン・ブートストラップ・アドレス」ページの 「構成」タブを使用して、 バックアップ・クラスターを静的に定義します。 デプロイメント・マネージャーが始動するたびに、 静的な値が使用されます。
- 「ドメイン・ブートストラップ・アドレス」ページの 「ランタイム」タブを使用して、 クラスターが稼働しているときの バックアップ・クラスターを定義します。 デプロイメント・マネージャーが停止すると、 ランタイム・バックアップ・クラスターを定義する情報は廃棄されます。
1 次クラスターとバックアップ・クラスターが別々のセルに存在するため、現行バージョンの製品では、クラスターも別々のコア・グループに存在します。 コア・グループ・ブリッジ・サービスを構成し、コア・グループ間の通信を可能にする必要があります。 アクセス・ポイント・グループを使用して、2 つのコア・グループを結合します。 1 次セルのデプロイメント・マネージャーにおいて、バックアップ・セル用のコア・グループ・アクセス・ポイントをピア・アクセス・ポイントとして持つアクセス・ポイント・グループを構成します。 バックアップ・セルのデプロイメント・マネージャーにおいて、1 次セルに作成したアクセス・ポイント・グループと同じ名前を持つ、アクセス・ポイント・グループを作成します。 1 次セルに、コア・グループ・アクセス・ポイントを参照するピア・アクセス・ポイントを追加します。
ExtendedCluster MBean を使用してバックアップ・クラスターを構成する場合は、ランタイム構成のみを変更できます。 MBean の変更は、静的構成には影響を与えません。 ランタイム構成を変更するには、ExtendedCluster MBean について setBackup 操作を使用することができます。例えば、1 次クラスターのバックアップ・クラスターを設定するには、以下の Java コードを使用できます。
ac.invoke(extendedCluster, "setBackup", new Object[] {
backupClusterName, backupBootstrapHost, backupBootstrapPort},
new String[] {
"java.lang.String", "java.lang.String", "java.lang.Integer"});
この例では、ac は AdminClient であり、extendedCluster は 1 次クラスターの ExtendedClusterObjectName です。
- 最初のシナリオでは、クライアントにより 1 次クラスターに対する要求が なされ、1 次クラスターは結局要求の受け入れを停止します。 すると、要求はバックアップ・クラスター へと発送されます。 クライアントは、最初に要求を 1 次クラスターに送信したので、 1 次クラスターの情報を持っています。 結果として、1 次クラスターが再度使用可能になると、要求は 1 次クラスター にフェイルバックされます。
- 2 番目のシナリオでは、クライアントは、1 次クラスターが停止するま で要求の送信を開始せず、要求はバックアップ・クラスターに直接送られます。 このケースでは、クライアントはバックアップ・クラスターについての情報のみを持っています。 クライアントはバックアップ・クラスターについての情報しか得ていないため、1 次クラスターが使用可能になっても、このクライアントからの要求はバックアップ・クラスターに発送され続け、1 次クラスターが使用可能になってもフェイルバックされません。 このシナリオは、オブジェクトがバックア ップ・クラスター上で作成された場合に起こります。 このケースでは、このオブジェクトに対してはバックアッ プ・クラスターが 1 次クラスターになります。