ナビゲーションをスキップ

WebLogic Server FAQ 集

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

FAQ : クラスタ化


Q. WebLogic Server クラスタでスタブはどのように機能するのですか。

A. WebLogic Server クラスタに接続して、クラスタ化されたオブジェクトをルック アップするクライアントは、そのオブジェクトのレプリカ対応スタブを取得します。このスタブには、そのオブジェクトの実装のホストとして使用可能なサーバ インスタンスのリストが入っています。スタブには、ホスト サーバ間で負荷を分散するためのロードバランシング ロジックも含まれています。


Q. 障害が発生し、スタブが WebLogic Server インスタンスに接続できない場合はどうなりますか。

A. 障害が発生すると、スタブでは機能しなくなったサーバ インスタンスがリストから削除されます。リストにサーバが残っていない場合には、スタブは再度 DNS を使用して動作中のサーバを検索し、動作中のインスタンスの最新リストを取得します。さらにスタブでは、クラスタ内の利用可能なサーバ インスタンスのリストが定期的に更新されます。この更新によって、スタブでは新しいサーバがクラスタに追加されるのに応じて、それらを利用できるようになります。


Q. サーバは、別のサーバが利用できなくなったときに、どのようにしてそれを知るのですか。

A. WebLogic Server では、2 つのメカニズムを使用して、特定のサーバ インスタンスが利用できるのかどうかを確認します。

クラスタ内の各 WebLogic Server インスタンスは、自身が使用可能であることを通知するためにマルチキャストを使用して定期的に「ハートビート」メッセージをブロードキャストします。ハートビート メッセージをモニタすることにより、クラスタ内のサーバ インスタンスは、どの時点でサーバ インスタンスに障害が発生したかを特定します。あるサーバ インスタンスから 3 回連続でハートビートを受け取らなかった場合、他のサーバ インスタンスはそのサーバ インスタンスを除外します。

また、WebLogic Server はソケット エラーをモニタして、サーバ インスタンスが利用できるかどうかを調べます。たとえば、サーバ インスタンス A にサーバ インスタンス B への利用可能なソケットがあり、そのソケットが不意に閉じた場合、サーバ A はサーバ B がオフライン状態にあるものと仮定します。


Q. クラスタにサーバが追加されたとき、その通知はどのように行われるのですか。

A. クラスタに新しいインスタンスが加わるたびに、WebLogic Server クラスタは新しいサーバ インスタンスが利用可能であることをブロードキャストします。また、クラスタ対応スタブでも、利用可能なサーバ インスタンスのリストが定期的に更新されます。


Q. クライアントは、新しい WebLogic Server インスタンスのことをどのようにして知るのですか。

A. クライアントは、いったん JNDI ルックアップを済ませてオブジェクト参照を使い始めると、クラスタ対応スタブが利用可能なサーバのリストを更新した後でしか、新しいサーバ インスタンスの存在に気付きません。


Q. 機能の停止したサーバへの DNS リクエストを、クライアントはどのように処理するのですか。

A. サーバが機能しなくなった後、利用できないマシンに DNS がリクエストを送り続けると、帯域幅の浪費につながります。Java クライアント アプリケーションの場合、この問題は起動時にしか発生しません。WebLogic Server は DNS エントリをキャッシュし、利用できないエントリを削除して、機能しなくなったサーバにクライアントが再びアクセスしないようにします。

サーバの障害は、ブラウザ ベースのクライアントにとってはもっと大きい問題となる可能性があります。ブラウザ ベースのクライアントは常に DNS を利用するからです。ブラウザ ベースのクライアントで不必要な DNS リクエストを発行しないようにするには、Resonate、BigIP、Alteon、LocalDirector といったサードパーティのロード バランサを使用します。これらの製品は、複数の DNS アドレスを単一のアドレスに見せかけます。さらにこれらの製品は、ラウンドロビンよりも高度なロードバランシング オプションを提供するほか、機能しなくなったサーバを追跡して不必要なリクエストをルーティングしないようにします。


Q. 複数の CPU を搭載するマシン上で実行できる WebLogic Server の数はいくつですか。

A. 考え得るコンフィグレーションは多数あり、それぞれに利点と欠点があります。BEA WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems, Inc. の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、大規模なクラスタまたは複数のクラスタのホストとなることができます。

ほとんどの場合、WebLogic Server クラスタは、2 つの CPU につき 1 つの WebLogic Server インスタンスの割合でデプロイするのが最適です。ただし、すべてのキャパシティ プランニングと同じように、サーバ インスタンスの最適数および分散方法を決定する場合は、対象となる Web アプリケーションで実際のデプロイメントを事前にテストする必要があります。詳細については、「マルチ CPU マシンのパフォーマンスに関する考慮事項」を参照してください。


Q. クラスタでのマルチキャスト用に別のネットワークを使用する必要がありますか。

A. いいえ。マルチキャスト トラフィックは、別のネットワークを必要とするほど重くはありません。


Q. クラスタが「ハング」または「フリーズ」してしまった場合は、どうすればよいでしょうか。

A. WebLogic Server クラスタが「フリーズ」した場合は、BEA テクニカル サポートに連絡する前に、スレッド ダンプや Java ガベージ コレクション メトリックなどの診断情報を収集する必要があります。詳細については、「ログ ファイルの生成」を参照してください。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次