バックアップ・クラスターは、プライマリー・サーバー・クラスターをミラーリングします。 ミラーリングされたクラスターは、Enterprise JavaBeans (EJB) 要求のみをサポートします。
概要と前提条件
クラスターのすべてのメンバーが EJB 要求の処理に使用できなくなった場合、 そのクラスター内のいずれかの EJB アプリケーション・サーバーと対話する必要のあるすべてのクライアントは機能しません。 1 次クラスター内のどの EJB アプリケーション・サーバー も要求を処理できない場合、ミラーリングされたクラスターは、他の EJB クラスター (バッ クアップ・クラスター) へのフェイルオーバーのために、EJB クラスター (1 次クラスター) を使用可能にします。 バックアップ・クラスターにより、1 次クラスター内のすべてのクラスター・メンバーが使用不可になった場合でも、クライアントは機能を継続できます。
フェイルバックは自動です。 1 次クラスター内のサーバーの再始動後に、1 次クラスターへのフェイルバックを開始する必要はありません。 バックアップ・クラスターは、1 次クラスターが使用可能になるとすぐ、要求の処理を停止します。 しかし、バックアップ・クラスター・サポートに対して、すべてのデプロイメント・マネージャーが機能している必要があります。 また、1 次クラスターがバックアップ・クラスターのバックアップとして定義されている必要があります。
1 次およびバックアップの各クラスターが別々のセルに存在するため、現行バージョンの WebSphere Application Server では、各クラスターは別々のコア・グループにも存在します。 コア・グループ・ブリッジ・サービスを構成し、コア・グループ間の通信を可能にする必要があります。 コア・グループ・ブリッジ・サービスにより、バックアップ・クラスターのサポートのために、デプロイメント・マネージャーおよびノード・エージェントを実行する必要性がなくなります。 以前のリリースでは、デプロイメント・マネージャーが停止した場合、1 次クラスターに障害が発生した後、新規の要求をバックアップ・クラスターに転送できませんでした。 1 次クラスターを含むセルに構成されたコア・グループ・ブリッジ・サーバーは、 バックアップ・クラスターについての情報を提供できます。 バックアップ・クラスターは、セル内のすべてのコア・グループ・ブリッジ・サーバーが稼働中でない場合にのみ、サポートに失敗します。
クラスターのフェイルオーバーとフェイルバックが期待どおりに機能するためには、 1 次クラスターおよびバックアップ・クラスターの両方のサーバーすべて (デプロイメント・マネージャー、ノード・エージェント、 およびアプリケーション・サーバー) が、 ミラーリングされたクラスターのサポートを提供しているリリースおよびレベルでなければなりません。 ただし、V5.x クラスターを使用して現行リリースのクラスターをバックアップしている場合、 V5.x クラスターでコア・グループ・ブリッジ・サービスの機能を使用することができません。
構成
ミラーリングされたクラスターのサポートは、デフォルトでは構成されません。 ミラーリングされたクラスターのサポートを使用するには、ご使用の構成にバックアップ・クラスターを指定する必要があります。 各クラスターは、バックアップ・クラスターを 1 つだけ持つことができ、それらを バックアップ・クラスターとして指定する前に構成しておく必要があります。
クラスターにバックアップ・クラスターを構成するには、名前およびドメイン・ブートストラップ・アドレスを指定します。 ブートストラップ・ホストとは、 バックアップ・クラスターが構成されているデプロイメント・マネージャーを含んでいるホストです。 ブートストラップ・ポートは、そのデプロイメント・マネージャーに対するブートストラップ・ポートです。
1 次クラスターとバックアップ・クラスターは、 別々のセルに配置する必要があります。 ミラーリングされたクラスターを別々のセルに配置するには、適切なバックアップ・クラスターのドメイン・ブートストラップ・アドレスを構成します。 バックアップ・クラスターのブートストラップ・ホストとブートストラップ・ポートは、 バックアップ・クラスターが含まれたセルを判別します。
1 次およびバックアップの各クラスターが別々のセルに存在するため、現行バージョンの WebSphere Application Server では、各クラスターは別々のコア・グループにも存在します。 コア・グループ・ブリッジ・サービスを構成し、コア・グループ間の通信を可能にする必要があります。 アクセス・ポイント・グループを使用して、2 つのコア・グループを結合します。 1 次セルのデプロイメント・マネージャーにおいて、バックアップ・セル用のコア・グループ・アクセス・ポイントをピア・アクセス・ポイントとして持つアクセス・ポイント・グループを構成します。 バックアップ・セルのデプロイメント・マネージャーにおいて、1 次セルに作成したアクセス・ポイント・グループと同じ名前を持つ、アクセス・ポイント・グループを作成します。 1 次セル内のコア・グループ・アクセス・ポイントを参照する、ピア・アクセス・ポイントを追加します。 現行リリース上のクラスターをバックアップするように V5.x クラスターを構成する場合、V5.x クラスターはコア・グループに属さないため、コア・グループ・ブリッジ・サービスを構成する必要はありません。その場合、バックアップ・クラスターはドメイン・ブートストラップ・アドレスのみを使用して機能します。
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 です。
フェイルバック・サポートのシナリオ
クラスターのフェイルバック・サポートに影響を与えるシナリオは 2 つあります。
最初のシナリオでは、クライアントにより 1 次クラスターに対する要求が なされ、1 次クラスターは結局要求の受け入れを停止します。 すると、要求はバックアップ・クラスター へと発送されます。 クライアントは、最初に要求を 1 次クラスターに送信したので、 1 次クラスターの情報を持っています。 結果として、1 次クラスターが再度使用可能になると、要求は 1 次クラスター にフェイルバックされます。
2 番目のシナリオでは、クライアントは、1 次クラスターが停止するま で要求の送信を開始せず、要求はバックアップ・クラスターに直接送られます。 このケースでは、クライアントはバックアップ・クラスターについての情報のみを持っています。 クライアントはバックアップ・クラスターについての情報しか得ていないため、1 次クラスターが使用可能になっても、このクライアントからの要求はバックアップ・クラスターに発送され続け、1 次クラスターが使用可能になってもフェイルバックされません。 このシナリオは、オブジェクトがバックア ップ・クラスター上で作成された場合に起こります。 このケースでは、このオブジェクトに対してはバックアッ プ・クラスターが 1 次クラスターになります。
クライアントが要求を既存のオブジェクトに送信し、1 次クラスターが 処理を停止した後に新規オブジェクトを作成した場合には、両方のシナリオが同一クラ イアント上で同時に起こる可能性があります。