|
|
|
|
|
|
| | | |
FAQ: クラスタ化
WebLogic Server クラスタでスタブはどのように機能するのですか。
WebLogic Server クラスタに接続して、クラスタ化されたオブジェクトをルック アップするクライアントは、そのオブジェクトのレプリカ対応スタブを取得します。このスタブには、そのオブジェクトの実装のホストとして使用可能なサーバ インスタンスのリストが入っています。スタブには、ホスト サーバ間で負荷を分散するためのロードバランシング ロジックも含まれています。
障害が発生し、スタブが WebLogic Server インスタンスに接続できない場合はどうなりますか。
障害が発生すると、スタブでは機能しなくなったサーバ インスタンスがリストから削除されます。リストにサーバが残っていない場合には、スタブは再度 DNS を使用して動作中のサーバを検索し、動作中のインスタンスの最新リストを取得します。さらにスタブでは、クラスタ内の利用可能なサーバ インスタンスのリストが定期的に更新されます。この更新によって、スタブでは新しいサーバがクラスタに追加されるのに応じて、それらを利用できるようになります。
サーバは、別のサーバが利用できなくなったときに、どのようにしてそれを知るのですか。
WebLogic Server では、2 つのメカニズムを使用して、特定のサーバ インスタンスが利用できるのかどうかを確認します。
クラスタ内の各 WebLogic Server インスタンスは、マルチキャストを使って定期的に「ハートビート」メッセージをブロードキャストし、自分が利用可能であることを通知します。クラスタ内のサーバ インスタンスは、ハートビート メッセージをモニタすることで、他のサーバ インスタンスでの障害発生を検出します。あるサーバ インスタンスからのハートビートを 3 回連続して受信しないと、他のサーバ インスタンスはそのサーバ インスタンスをクラスタから削除します。
WebLogic Server は、サーバ インスタンスが利用できるかどうかの判断に、ソケット エラーも利用します。たとえば、サーバ インスタンス A がサーバ インスタンス B に対するソケットを開いていて、そのソケットが不意に閉じた場合、サーバ A はサーバ B がオフライン状態になったものと見なします。
クラスタにサーバが追加されたとき、その通知はどのように行われるのですか。
クラスタに新しいインスタンスが加わるたびに、WebLogic Server クラスタは新しいサーバ インスタンスが利用可能であることをブロードキャストします。また、クラスタ対応スタブでも、利用可能なサーバ インスタンスのリストが定期的に更新されます。
クライアントは、新しい WebLogic Server インスタンスのことをどのようにして知るのですか。
クライアントは、いったん JNDI ルックアップを済ませてオブジェクト参照を使い始めると、クラスタ対応スタブが利用可能なサーバのリストを更新した後でしか、新しいサーバ インスタンスの存在に気付きません。
機能の停止したサーバへの DNS リクエストを、クライアントはどのように処理するのですか。
サーバが機能しなくなった後、利用できないマシンに DNS がリクエストを送り続けると、帯域幅の浪費につながります。Java クライアント アプリケーションの場合、この問題は起動時にしか発生しません。WebLogic Server は DNS エントリをキャッシュし、利用できないエントリを削除して、機能しなくなったサーバにクライアントが再びアクセスしないようにします。
サーバの障害は、ブラウザ ベースのクライアントにとってはもっと大きい問題となる可能性があります。ブラウザ ベースのクライアントは常に DNS を利用するからです。ブラウザ ベースのクライアントで不必要な DNS リクエストを発行しないようにするには、Resonate、BigIP、Alteon、LocalDirector といったサードパーティのロード バランサを使用します。これらの製品は、複数の DNS アドレスを単一のアドレスに見せかけます。さらにこれらの製品は、ラウンドロビンよりも高度なロードバランシング オプションを提供するほか、機能しなくなったサーバを追跡して不必要なリクエストをルーティングしないようにします。
複数の CPU を搭載するマシン上で実行できる WebLogic Server の数はいくつですか。
考え得るコンフィグレーションは多数あり、それぞれに利点と欠点があります。BEA WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems, Inc. の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、大規模なクラスタまたは複数のクラスタのホストとなることができます。
ほとんどの場合、WebLogic Server クラスタは、2 つの CPU につき 1 つの WebLogic Server インスタンスの割合でデプロイするのが最適です。ただし、すべてのキャパシティ プランニングと同じように、サーバ インスタンスの最適数および分散方法を決定する場合は、対象となる Web アプリケーションで実際のデプロイメントを事前にテストする必要があります。詳細については、「複数の CPU を搭載するマシンでのパフォーマンスについての考慮事項」を参照してください。
クラスタでのマルチキャスト用に別のネットワークを使用する必要がありますか。
いいえ。マルチキャスト トラフィックは、別のネットワークを必要とするほど重くはありません。
クラスタが「ハング」または「フリーズ」してしまった場合は、どうすればよいでしょうか。
WebLogic Server クラスタが「フリーズ」した場合は、BEA テクニカル サポートに連絡する前に、スレッド ダンプや Java ガベージ コレクション メトリックなどの診断情報を収集する必要があります。詳細については、「診断情報の収集」を参照してください。
|
|
|