> WebLogic Server クラスタ ユーザーズ ガイド > WebLogic クラスタの設定

WebLogic Server クラスタ ユーザーズ ガイド

     前  次    新しいウィンドウで目次を開く     
ここから内容の開始

WebLogic クラスタの設定

以下の節では、WebLogic Server クラスタをコンフィグレーションするためのガイドラインと手順を示します。

 

始める前に

この節では、WebLogic Server クラスタを設定するための前提となる作業および情報についてまとめています。

クラスタ ライセンスを取得する

WebLogic Server インスタンスをクラスタ構成でインストールするには、有効なクラスタ ライセンスが必要です。クラスタ ライセンスの入手方法については、BEA 販売代理店にお問い合わせください。

コンフィグレーション プロセスについて

クラスタのコンフィグレーション プロセスと、コンフィグレーション タスクの実施方法の基本を理解しておくと、この節で示す情報がより有益なものとなります。

WebLogic Server が備えるコンフィグレーション機能と、それらの機能を通じて実施できるタスクの詳細については、「クラスタのコンフィグレーションについて」を参照してください。

クラスタ アーキテクチャを決定する

どのクラスタ アーキテクチャが、対象アプリケーションのニーズに最も適しているかを決定します。アーキテクチャ上の重要な決定には、以下のものがあります。

これらを決定するためには、「クラスタ アーキテクチャ」および「クラスタでのロード バランシング」の情報が参考になります。

選択するアーキテクチャによって、クラスタの設定方法も変わります。クラスタ アーキテクチャによっては、ロード バランサ、HTTP サーバ、プロキシ プラグインなどの、他のリソースのインストールまたはコンフィグレーションが必要になる場合もあります。

ネットワーク トポロジとセキュリティ トポロジを考慮する

アプリケーションのセキュリティ要件は、適切なセキュリティ トポロジを設計するための基礎となります。多様なレベルのアプリケーション セキュリティを提供する各種の代替アーキテクチャの詳細については、「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。

注意 : 一部のネットワーク トポロジは、マルチキャスト通信に干渉することがあります。WAN にクラスタをデプロイしている場合の注意事項については、「クラスタが WAN 内の複数のサブネットにまたがる場合」を参照してください。
注意 : ファイアウォールを越えてクラスタにサーバ インスタンスをデプロイしないでください。ファイアウォールを通じてマルチキャスト トラフィックをトンネリングすることの影響については、「ファイアウォールがマルチキャスト通信を遮断することがある」を参照してください。

クラスタをインストールするマシンを選択する

WebLogic Server をインストールする予定の 1 台以上のマシン (この節では「ホスト」と呼ぶ) を確定し、各マシンが必要なリソースを備えていることを確認します。WebLogic Server では、クラスタを非マルチホーム環境の 1 台のマシン上に設定できます。この新しい機能は、デモンストレーションまたは開発用の環境で役立ちます。

注意 : IP アドレスが動的に割り当てられるマシンに WebLogic Server をインストールしないでください。

マルチ CPU マシン上の WebLogic Server インスタンス

BEA WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems, Inc. の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバを、大規模なクラスタまたは複数のクラスタのホストとすることができます。

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

ホスト マシンのソケット リーダー実装をチェックする

ソケットの最適なパフォーマンスを実現するには、pure-Java 実装ではなく、オペレーティング システムに対応したネイティブ ソケット リーダー実装を使用するよう WebLogic Server ホスト マシンをコンフィグレーションします。ネイティブ ソケットをコンフィグレーションする、または pure-Java ソケット通信を最適化する理由とその手順については、「IP ソケットを使用したピア ツー ピア通信」を参照してください。

切断された Windows マシン上のクラスタの設定

WebLogic Server クラスタを単一の切断された Windows マシン上に置く場合は、Windows に TCP/IP スタックをロードさせる必要があります。デフォルトでは、物理的なネットワーク接続が検出されない場合、Windows は TCP/IP スタックをロードしません。

Windows に TCP/IP スタックをロードさせるには、「How to disable Media Sensing for TCP/IP in Windows」(http://support.microsoft.com/default.aspx?scid=kb;en-us;239924) の指示に従って Windows のメディア センス機能を無効にします。

名前とアドレスを識別する

クラスタのコンフィグレーション プロセスの間、クラスタ内のサーバ インスタンスについてアドレス情報 (IP アドレスまたは DNS 名、およびポート番号) を指定します。

クラスタ内通信の概要と、クラスタ内通信を利用したロード バランシングとフェイルオーバの仕組みについては、「クラスタでの WebLogic Server の通信」を参照してください。

クラスタを設定するときは、以下の要素の場所の情報を指定する必要があります。

以下の節では、指定しなければならない情報と、リソースの識別に用いる手法に影響する要因について説明しています。

リスン アドレスの問題を回避する

クラスタをコンフィグレーションするときには、アドレス情報を IP アドレスまたは DNS 名を使用して指定できます。

DNS 名と IP アドレス

DNS 名と IP アドレスのどちらを使用するかを決定するときは、クラスタの目的を考慮してください。プロダクション環境では一般に、DNS 名を使用することをお勧めします。IP アドレスを使用すると、以下の状況で変換エラーが発生するおそれがあります。

変換エラーは、個別のサーバ インスタンスのアドレスを DNS 名にバインドすることによって回避できます。サーバ インスタンスの DNS 名が、ファイアウォールの両側で必ず一致するようにしてください。また、ネットワーク上の NT システムの名前でもある DNS 名は使用しないでください。

IP アドレスの代わりに DNS 名を使用する場合の注意事項については、「ファイアウォールについての考慮事項」を参照してください。

内部 DNS 名と外部 DNS 名が異なる場合

WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同じでない場合、サーバ インスタンスの ExternalDNSName 属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外で、ExternalDNSName はサーバの外部 IP アドレスに変換されます。クライアントがデフォルト チャネルと T3 を介して WebLogic Server にアクセスしている場合は、WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が異なる場合でも、ExternalDNSName 属性を設定しないでください。

localhost の考慮事項

サーバ インスタンスのリスン アドレスを localhost として識別すると、非ローカルのプロセスがそのサーバ インスタンスに接続できなくなります。サーバ インスタンスのホスト マシン上のプロセスのみ、そのサーバ インスタンスに接続できます。 (たとえば localhost に接続する管理スクリプトがある場合などに) サーバ インスタンスが localhost としてアクセス可能でなければならない場合で、かつリモート プロセスからもアクセス可能でなければならない場合は、リスン アドレスを空白にします。リスン アドレスを空白にすると、サーバ インスタンスはマシンのアドレスを判別してそのアドレスでリスンします。

WebLogic Server リソースへの名前割り当て

WebLogic Server 環境のコンフィグレーション可能な各リソースには、ユニークな名前を割り当てる必要があります。ドメイン、サーバ、マシン、クラスタ、JDBC データ ソース、仮想ホストなどのリソースにはユニークな名前が必要です。

管理サーバのアドレスとポート

クラスタに対して使用する管理サーバの DNS 名または IP アドレスおよびリスン ポートを識別します。

管理サーバは、そのドメイン内のすべての管理対象サーバをコンフィグレーションおよび管理するために使われる WebLogic Server インスタンスです。管理対象サーバを起動するときには、対応する管理サーバのホストとポートを識別します。

管理対象サーバのアドレスとリスン ポート

クラスタ用の各管理対象サーバの DNS 名と IP アドレスを識別します。

クラスタ内の各管理対象サーバについて、アドレスとリスン ポート番号の組み合わせはユニークでなければなりません。非マルチホーム環境の 1 台のマシン上でクラスタ化されるサーバ インスタンスについては、インスタンス間でアドレスが重複してもかまいませんが、使用するリスン ポートはインスタンスごとに異なっている必要があります。

クラスタのマルチキャスト アドレスとマルチキャスト ポート

クラスタのマルチキャスト通信専用のアドレスとポートを識別します。マルチキャスト アドレスは、224.0.0.0 ～ 239.255.255.255 の範囲の IP アドレスです。

注意 : WebLogic Server で使用されるデフォルトのマルチキャスト アドレスは、239.192.0.0 です。x.0.0.1 の値のマルチキャスト アドレスを使用することはできません。

クラスタ内のサーバ インスタンスは、マルチキャストを使用して互いに通信します。具体的には、マルチキャストを使用して各自のサービスを全体に通知し、インスタンスが継続的に使用可能であることを知らせるハートビートを一定間隔で出します。

クラスタのマルチキャスト アドレスは、クラスタ通信以外の目的には使用しないことをお勧めします。クラスタのマルチキャスト アドレスが存在するマシンが、マルチキャスト通信を使用するクラスタ外部のプログラムのホストであるか、またはそのようなプログラムによってアクセスされる場合、そのマルチキャスト通信では必ず、クラスタのマルチキャスト ポートとは異なるポートを使用してください。

マルチキャストと複数のクラスタ

ネットワーク上の複数のクラスタは、必要に応じてマルチキャスト アドレスとマルチキャスト ポートの組み合わせを共有できます。

マルチキャストと多層クラスタ

「クラスタ アーキテクチャ」で説明しているような、クラスタ間にファイアウォールを設ける推奨多層アーキテクチャを設定している場合、専用のマルチキャスト アドレスが 2 つ必要になります。1 つはプレゼンテーション (サーブレット) クラスタ用であり、もう 1 つはオブジェクト クラスタ用です。2 つのマルチキャスト アドレスを使用することにより、ファイアウォールはクラスタの通信に干渉しなくなります。

クラスタ アドレス

WebLogic Server クラスタでは、クラスタ アドレスは、リクエスト URL のホスト名部分を構築するためにエンティティ Bean およびステートレス Bean で使用されます。

クラスタをコンフィグレーションするときに、クラスタ アドレスを明示的に定義できます。定義しない場合、WebLogic Server は新しいリクエストごとにクラスタ アドレスを動的に生成します。WebLogic Server によるクラスタ アドレスの動的生成を有効にするほうが、システム管理上簡単であり、開発環境およびプロダクション環境の両方に適しています。

動的なクラスタ アドレス

クラスタをコンフィグレーションするときにクラスタ アドレスを明示的に定義しない場合は、クラスタ化されたサーバ インスタンスがリモート リクエストを受信するときに、WebLogic Server によって次の形式でクラスタ アドレスが生成されます。 

listenaddress1:listenport1,listenaddress2:listenport2;listenaddress3:
listenport3

クラスタ アドレス内の各 listen address:listen port の組み合わせは、リクエストを受信した管理対象サーバとネットワーク チャネルに対応します。

クラスタ アドレスに含まれる ListenAddress:ListenPort の組み合わせの数には、ClusterMBean の NumberOfServersInClusterAddress 属性の値 (デフォルトは 3) が適用されます。

NumberOfServersInClusterAddress の値は、Administration Console の [環境｜クラスタ｜(クラスタ名)｜コンフィグレーション｜全般] ページで変更できます。

ListenAddress:ListenPort の組み合わせはランダムな順序でクラスタ アドレスに表示され、リクエストごとにその順序は変わります。

プロダクション環境でクラスタ アドレスを明示的に定義する

プロダクション環境でクラスタのクラスタ アドレスを明示的に定義する場合は、クラスタ内の各 WebLogic Server インスタンスの IP アドレスまたは DNS 名にマップする DNS 名としてクラスタ アドレスを指定します。

クラスタ アドレスを DNS 名として定義した場合、クラスタ メンバーのリスン ポートは、クラスタ アドレスで指定されません。クラスタ内の各管理対象サーバが同じリスン ポート番号を持っていると見なされます。クラスタ内の各サーバ インスタンスはユニークなアドレスとリスン ポートの組み合わせを持つ必要があるので、クラスタ アドレスが DNS 名の場合、クラスタ内の各サーバ インスタンスには以下が必要です。

クライアントがクラスタ DNS 名を提供して初期 JNDI コンテキストを取得すると、weblogic.jndi.WLInitialContextFactory はその DNS 名にマップされているすべてのアドレスのリストを取得します。このリストは WebLogic Server インスタンスによってキャッシュされ、新しい初期コンテキスト リクエストは、キャッシュされているリスト内のアドレスをラウンドロビン アルゴリズムで使うことによって実行されます。キャッシュされているリスト内のサーバ インスタンスが使用できない場合、そのサーバはリストから削除されます。アドレス リストは、サーバ インスタンスがキャッシュ内のどのアドレスにもアクセスできない場合にのみ、DNS サービスによって更新されます。

キャッシュされているアドレス リストを使用すると、DNS ラウンドロビンだけを利用する場合の問題を避けることができます。たとえば、DNS ラウンドロビンでは、アドレスがアクセス可能かどうかに関わりなく、ドメイン名にマップされているすべてのアドレスが使用され続けます。アドレス リストをキャッシュすると、WebLogic Server はアクセス不能なアドレスを削除できるので、初期コンテキスト リクエストで接続の失敗が繰り返されることはありません。

注意 : 管理サーバをクラスタに参加させないでください。必ず、管理サーバの IP アドレスがクラスタワイドの DNS 名に含まれないようにしてください。詳細については、「管理サーバについての考慮事項」を参照してください。
開発およびテスト環境でクラスタ アドレスを明示的に定義する

開発環境で使用するクラスタ アドレスを明示的に定義する場合は、前の節で説明したようにクラスタ アドレスにクラスタ DNS 名を使用できます。

代わりに、次の例で示すように、DNS 名 (または IP アドレス)、およびクラスタ内の各管理対象サーバのリスン ポートを格納するリストとしてクラスタ アドレスを定義することもできます。 

DNSName1:port1,DNSName1:port2,DNSName1:port3
IPaddress1:port1,IPaddress2:port2;IPaddress3:port3

各クラスタ メンバーは、ユニークなアドレスとポートの組み合わせを持っています。

単一のマルチホーム マシンでクラスタ アドレスを明示的に定義する

マルチホーム環境の 1 台のマシン上でクラスタが動作しており、クラスタ内の各サーバ インスタンスで異なった IP アドレスを使用する場合、クラスタ内のサーバ インスタンスの IP アドレスにマップする DNS 名を使用してクラスタ アドレスを定義します。クラスタ アドレスを DNS 名として定義する場合、クラスタ内の各管理対象サーバで共通のリスン ポート番号を指定します。

 

クラスタ実装の手順

この節では、アプリケーションをクラスタ構成にして実行する手順を、WebLogic Server のインストールからアプリケーション コンポーネントの初期デプロイメントまで順を追って説明します。

コンフィグレーションのロードマップ

この節では、典型的なクラスタ実装のタスクをリストし、コンフィグレーションに関する重要な考慮事項を説明します。実際のプロセスは、環境ごとにユニークな特性およびアプリケーションの性質によって決まります。以下のタスクを説明します。

  1. WebLogic Server をインストールする
  2. クラスタ化されたドメインを作成する
  3. ノード マネージャをコンフィグレーションする
  4. EJB と RMI のロード バランシング方式をコンフィグレーションする
  5. 分散 JMS 送り先のサーバ アフィニティをコンフィグレーションする
  6. パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする
  7. プロキシ プラグインをコンフィグレーションする
  8. レプリケーション グループをコンフィグレーションする
  9. 固定サービスの移行可能対象をコンフィグレーションする
  10. クラスタ化された JDBC をコンフィグレーションする
  11. デプロイメント用にアプリケーションをパッケージ化する
  12. アプリケーションをデプロイする
  13. 移行可能サービスをデプロイ、アクティブ化、および移行する
  14. インメモリ HTTP レプリケーションをコンフィグレーションする
  15. コンフィグレーションに関するその他のトピック

クラスタの実装によっては、一部の手順が不要である場合があります。また、ここで示す以外の手順が必要になる場合もあります。

WebLogic Server をインストールする

まだインストールしていない場合、WebLogic Server をインストールします。手順については、『インストール ガイド』を参照してください。

注意 : 共有ファイルシステムと 1 つのインストールを使用して、異なるマシン上で複数の WebLogic Server インスタンスを実行しないでください。共有ファイルシステムを使用すると、クラスタにシングル ポイントの競合が発生します。すべてのサーバ インスタンスが、ファイルシステムにアクセスする (また場合によっては、個別のログ ファイルへの書き込みを行う) ために競合しなければならなくなります。さらに、共有ファイルシステムに障害が発生した場合には、クラスタ化されたサーバ インスタンスを起動できなくなることもあります。

クラスタ化されたドメインを作成する

クラスタ化されたドメインの作成方法は複数あります。リストについては、「クラスタをコンフィグレーションする方法」を参照してください。

クラスタの作成手順については、以下を参照してください。

WebLogic Server クラスタを起動する

クラスタを起動するには複数の方法があります。コマンドライン インタフェース、必要なコマンドを含むスクリプト、ノード マネージャなどを使用できます。

注意 : ノード マネージャを使用すると、サーバを起動したり、障害発生後にサーバを再起動したりするプロセスが簡単になります。
注意 : ノード マネージャを使用するには、最初に、クラスタ内の管理対象サーバをホストする各マシンでノード マネージャ プロセスをコンフィグレーションする必要があります。「ノード マネージャをコンフィグレーションする」を参照してください。

どの方法を使用してクラスタを起動する場合でも、最初にクラスタ内の管理サーバを起動し、次に管理対象サーバを起動します。

以下の手順に従って、コマンド シェルからクラスタを起動します。各サーバ インスタンスを別々のコマンド シェルで起動することに注意してください。

  1. コマンド シェルを開きます。
  2. コンフィグレーション ウィザードで作成したドメイン ディレクトリに移動します。
  3. 次のコマンドを入力して管理サーバを起動します。
    4. StartWebLogic
  4. 「Enter username to boot WebLogic Server」というプロンプトが表示されたら、ドメインのユーザ名を入力します。
  5. 「Enter password to boot WebLogic Server」というプロンプトが表示されたら、ドメインのパスワードを入力します。

    6. 起動プロセスの状態を知らせるメッセージがコマンド シェルに表示されます。

  6. 管理対象サーバを起動するために、別のコマンド シェルを開きます。
  7. コンフィグレーション ウィザードで作成したドメイン ディレクトリに移動します。
  8. 次のコマンドを入力します。

    9. StartManagedWebLogic server_name address:port

    各要素の説明は次のとおりです。

    server_name : 起動する管理対象サーバの名前

    address : ドメインの管理サーバの IP アドレスまたは DNS 名

    port : ドメインの管理サーバのリスン ポート

  9. 「Enter username to boot WebLogic Server」というプロンプトが表示されたら、ドメインのユーザ名を入力します。
  10. 「Enter password to boot WebLogic Server」というプロンプトが表示されたら、ドメインのパスワードを入力します。

    11. 起動プロセスの状態を知らせるメッセージがコマンド シェルに表示されます。

    注意 : 管理対象サーバを起動すると、クラスタ内の他の実行中サーバ インスタンスからハートビートがリスンされます。管理対象サーバは、「WebLogic Server による JNDI ツリー更新の仕組み」で説明しているように、クラスタワイドの JNDI ツリーのローカル コピーを構築し、クラスタ内の実行中の管理対象サーバとの同期が取れたら、ステータス メッセージを表示します。同期化プロセスには、1 分ほどかかります。
  11. クラスタ内の別のサーバ インスタンスを起動するには、手順 6 から手順 10 までを繰り返します。
  12. クラスタ内のすべての管理対象サーバを起動したら、クラスタの起動プロセスは完了です。

ノード マネージャをコンフィグレーションする

ノード マネージャは、WebLogic Server 付属のスタンドアロンの Java プログラムであり、管理サーバとは異なるマシン上にある管理対象サーバの起動に便利です。またノード マネージャには、クラスタ内にある管理対象サーバの可用性の向上に役立つ機能もあります。ノード マネージャの詳細と、コンフィグレーション方法および使用方法については、『サーバの起動と停止の管理』の「ノード マネージャを使用したサーバの制御」を参照してください。

EJB と RMI のロード バランシング方式をコンフィグレーションする

この節の手順に従うと、EJB および RMI オブジェクトのロード バランシング アルゴリズムを選択できます。

その他の方式を明示的に指定しない場合、WebLogic Server はクラスタ化されるオブジェクトのスタブに対して、デフォルトのロード バランシング方式であるラウンドロビン アルゴリズムを使用します。それ以外のロード バランシング方式については、「EJB と RMI オブジェクトのロード バランシング」を参照してください。デフォルトのロード バランシング アルゴリズムを変更するには、次の手順に従います。

  1. WebLogic Server Console を起動します。
  2. [環境｜クラスタ] ノードを選択します。
  3. テーブルでクラスタの名前をクリックします。
  4. まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
  5. [デフォルトのロード バランス アルゴリズム] フィールドに、使用するロード バランシング アルゴリズムを入力します。
  6. [詳細] リンクをクリックします。
  7. [サービス期間しきい値] フィールドに設定値を入力します。
  8. [保存] をクリックして変更を保存します。
  9. 左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。

RMI のタイムアウト値を指定する

ClusterMBean の ReplicationTimeoutEnabled を true に設定することで、ReplicationManager の呼び出し時にタイムアウト オプションを有効にできます。

タイムアウト値はマルチキャスト ハートビートのタイムアウト値と同じです。マルチキャストのタイムアウト値はカスタマイズできますが、ReplicationManager のタイムアウト値は変更できません。この制限があるのは、ReplicationManager のタイムアウトはクラスタのメンバシップに影響しないからです。マルチキャスト ハートビートがなくなるとそのメンバーはクラスタから削除され、ReplicationManager の呼び出しがタイムアウトすると接続先の新しいセカンダリ サーバが選択されます。

注意 : クラスタ メンバーはマルチキャスト ハートビートを送信し続けることができますが、レプリケーション リクエストは処理できません。そのため、セカンダリ サーバの分散が不均一になるおそれがあります。このような状態になると、警告メッセージがサーバ ログに記録されます。

分散 JMS 送り先のサーバ アフィニティをコンフィグレーションする

WebLogic Server が提供する JMS のサーバ アフィニティのサポートについては、「JMS のロード バランシング」を参照してください。

パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする

パッシブなクッキーの永続性をサポートするロード バランサは、セッションをホストする WebLogic Server インスタンスをクライアントと関連付けるために WebLogic Server セッション クッキーの情報を使用できます。セッション クッキーには、ロード バランサがセッションのプライマリ サーバ インスタンスを識別する文字列が含まれています。

外部ロード バランサ、セッション クッキーの永続性、および WebLogic Server セッション クッキーの詳細については、「外部ロード バランサによる HTTP セッションのロード バランシング」を参照してください。

クラスタで動作するようにロード バランサをコンフィグレーションするには、ロード バランサの機能を使用して、文字列定数のオフセットと長さを定義します。

セッション クッキーのセッション ID 部分がデフォルト長の 52 バイトであると想定して、ロード バランサで次のように設定します。

アプリケーションまたは環境によって、ランダム セッション ID の長さをデフォルト値の 52 バイト以外に変更しなければならない場合は、それに応じて文字列のオフセットをロード バランサで設定してください。文字列のオフセットは、セッション ID の長さに、区切り文字用の 1 バイトを加えたものと同じ値にする必要があります。

注意 : BIG-IP ロード バランサのベンダ固有のコンフィグレーション手順については、「クラスタに関する BIG-IP™ ハードウェアのコンフィグレーション」を参照してください。

プロキシ プラグインをコンフィグレーションする

プロキシ プラグインを使用してサーブレットおよび JSP のロード バランシングを行う場合は、この節で示す手順を参考にしてください。プロキシ プラグインは、リクエストを Web サーバからクラスタ内の WebLogic Server インスタンスに中継し、プロキシを経由する HTTP リクエストのロード バランシングとフェイルオーバを可能にします。

プロキシ プラグインによるロード バランシングの詳細については、「プロキシ プラグインによるロード バランシング」を参照してください。プロキシ プラグインによる接続とフェイルオーバの詳細については、「サーブレットと JSP のレプリケーションとフェイルオーバ」および「クラスタ化されたサーブレットと JSP へのプロキシ経由のアクセス」を参照してください。

注意 : リクエストをクラスタにプロキシ経由で中継する各 Web サーバでは、プラグインが同じようにコンフィグレーションされている必要があります。

HttpClusterServlet を設定する

HTTP クラスタ サーブレットを使用するには、以下の手順で説明するように、プロキシ サーバ マシン上でサーブレットをデフォルト Web アプリケーションとしてコンフィグレーションします。Web アプリケーションの概要については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「Web アプリケーション、サーブレット、および JSP について」を参照してください。

  1. まだコンフィグレーションしていない場合は、独立したクラスタ化されていない管理対象サーバをコンフィグレーションして、HTTP クラスタ サーブレットをホストするようにします。
  2. サーブレットの web.xml デプロイメント記述子を作成します。このファイルは、Web アプリケーション ディレクトリの \WEB-INF サブディレクトリに配置する必要があります。プロキシ サーブレットのサンプルのデプロイメント記述子は「サンプルの web.xml」にあります。web.xml の詳細については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「Web アプリケーション、サーブレット、および JSP について」を参照してください。
    1. web.xml の <servlet> 要素で、サーブレットの名前とクラスを定義します。サーブレット名は HttpClusterServlet です。サーブレット クラスは weblogic.servlet.proxy.HttpClusterServlet です。
    2. web.xml の <servlet> 要素で、WebLogicCluster パラメータを定義して、プロキシ サーブレットのリクエストの転送先となる、クラスタ化されたサーバ インスタンスを指定します。
    3. 独自の ID 証明書とキーで双方向 SSL を使用する場合は、必要に応じて以下の <KeyStore> 初期化パラメータを定義します。デプロイメント記述子に <KeyStore> が指定されていない場合、プロキシでは一方向 SSL と見なされます。
      • <KeyStore> - Web アプリケーションのキーストアの場所。
      • <KeyStoreType> - キーストアのタイプ。定義されていない場合、デフォルトのタイプが使用されます。
      • <PrivateKeyAlias> - プライベート キーのエリアス。
      • <KeyStorePasswordProperties> - Web アプリケーション内のプロパティ ファイル。キーストアおよびプライベート キーのエリアスにアクセスするための暗号化されたパスワードを定義します。このファイルの内容は次のようになっています。
        KeyStorePassword={3DES}i4+50LCKenQO8BBvlsXTrg\=\=
        PrivateKeyPassword={3DES}a4TcG4mtVVBRKtZwH3p7yA\=\=

        パスワードを暗号化するには、weblogic.security.Encrypt コマンドライン ユーティリティを使用する必要があります。Encrypt ユーティリティや、CertGen および der2pem ユーティリティの詳細については、『WebLogic Server コマンド リファレンス』の「WebLogic Server Java ユーティリティの使い方」を参照してください。
    4. <servlet-mapping> スタンザを作成して、サーブレットがクラスタにプロキシするリクエストを指定します。<url-pattern> 要素を使用して特定のファイル拡張子 (*.jsp または *.html など) を指定します。パターンごとに別々の <servlet-mapping> スタンザに定義します。

      5. <url-pattern> を「/」に設定すると、WebLogic Server によって解決できないリクエストをリモート サーバ インスタンスにプロキシできます。その場合、拡張子が *.jsp、*.htm、および *.html のファイルをプロキシするために、これらの拡張子もマップしなければなりません。例については、「サンプルの web.xml」を参照してください。

    5. 必要に応じて、追加のパラメータを定義します。主なパラメータのリストについては、表 9-1 を参照してください。詳細なリストについては、『Web サーバ プラグインの使用』の「Web サーバ プラグインのパラメータ」を参照してください。「プロキシ サーブレットのデプロイメント パラメータ」の構文の指示に従ってください。
  3. サーブレットの weblogic.xml デプロイメント記述子ファイルを作成します。このファイルは、Web アプリケーション ディレクトリの \WEB-INF サブディレクトリに配置する必要があります。

    4. <weblogic-web-app> スタンザの <context-root> 要素をフォワード スラッシュ文字 (/) に設定して、プロキシ サーブレットをプロキシ マシンにある管理対象サーバのデフォルト Web アプリケーションとして割り当てます。例については、「サンプルの weblogic.xml」を参照してください。

  4. Administration Console で、プロキシ サーバ マシン上の管理対象サーバにサーブレットをデプロイします。手順については、Administration Console オンライン ヘルプの「アプリケーションおよびモジュールのデプロイ」を参照してください。
サンプルの web.xml

この節では HttpClusterServlet のサンプルのデプロイメント記述子ファイル (web.xml) を示します。

web.xml では、プロキシ サーブレットの位置と動作を指定するさまざまなパラメータを定義します。

パラメータの定義については、「プロキシ サーブレットのデプロイメント パラメータ」を参照してください。

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";>

<web-app>

<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>
weblogic.servlet.proxy.HttpClusterServlet
</servlet-class>

  <init-param>
    <param-name>WebLogicCluster</param-name>
    <param-value>hostname1:7736|hostname2:7736|hostname:7736</param-value>
  </init-param> 

  <init-param>
    <param-name>KeyStore</param-name>
    <param-value>/mykeystore</param-value>
  </init-param>
  <init-param>
    <param-name>KeyStoreType</param-name>
    <param-value>jks</param-value>
  </init-param>
  <init-param>
    <param-name>PrivateKeyAlias</param-name>
    <param-value>passalias</param-value>
  </init-param>
  <init-param>
    <param-name>KeyStorePasswordProperties</param-name>
    <param-value>mykeystore.properties</param-value>
  </init-param>

</servlet>

<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>

</web-app>

サンプルの weblogic.xml

この節ではサンプルの weblogic.xml ファイルを示します。<context-root> デプロイメント パラメータは「/」に設定されています。この設定により、プロキシ サーブレットがプロキシ サーバのデフォルト Web アプリケーションになります。

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 9.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic
810-web-jar.dtd">
<weblogic-web-app>
<context-root>/</context-root>
</weblogic-web-app>

プロキシ サーブレットのデプロイメント パラメータ

web.xml でプロキシ サーブレットの動作をコンフィグレーションするための主なパラメータを表 9-1 に示します。

プロキシ サーブレットのパラメータは、Apache、Microsoft、および Netscape Web サーバ用の WebLogic Server プラグインのコンフィグレーションに使用するパラメータと同じです。プロキシ サーブレットおよびサード パーティ製 Web サーバのプラグインをコンフィグレーションするパラメータの詳細なリストについては、『Web サーバ プラグインの使用』の「Web サーバ プラグインのパラメータ」を参照してください。

パラメータを指定する際の構文と指定先のファイルは、プロキシ サーブレットとプラグインごとに異なります。

プロキシ サーブレットの場合、web.xml でパラメータを指定します。パラメータごとに、web.xml の <servlet> スタンザ内の <init-param> スタンザで指定します。次に例を示します。

<init-param>
<param-name>ParameterName</param-name>
<param-value>ParameterValue</param-value>
</init-param>

表 9-1 プロキシ サーブレットのデプロイメント パラメータ
パラメータ
適用
WebLogicCluster
<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>WLS1.com:port|WLS2.com:port
</param-value>
WLS1.com と WLS2.com は、クラスタ内のサーバのホスト名。port は、ホストが HTTP リクエストをリスンするポート。
プラグインと WebLogic Server の間で SSL を使用する場合は、ポート番号を SSL リスン ポートに設定して (「リスンポートのコンフィグレーション」を参照)、SecureProxy パラメータを ON に設定する。
SecureProxy
<init-param>
<param-name>SecureProxy</param-name>
<param-value>ParameterValue</param-value>
</init-param>
有効な値は ON および OFF。
プラグインと WebLogic Server の間で SSL を使用する場合は、ポート番号を SSL リスン ポートに設定して (「リスンポートのコンフィグレーション」を参照)、SecureProxy パラメータを ON に設定する。
DebugConfigInfo
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ParameterValue</param-value>
</init-param>
有効な値は ON および OFF。
ON に設定する場合、リクエストに ?__WebLogicBridgeConfig というリクエスト パラメータを追加して、HttpClusterServlet にデバッグ情報を問い合わせることができる (注意 : ? の後は 2 つのアンダースコア ( _ ) 文字)。セキュリティ上の理由により、プロダクション環境では DebugConfigInfo パラメータを OFF に設定することを推奨。
ConnectRetry
Secs
サーバ インスタンスへの接続試行の間に、サーブレットがスリープする間隔 (秒単位)。ConnectTimeoutSecs より小さい値を割り当てる。
HTTP 503/Service Unavailable 応答がクライアントに返されるまでにサーブレットが接続を試行する回数は、ConnectTimeoutSecs を ConnectRetrySecs で除算した数。
構文 :
<init-param>
<param-name>ConnectRetrySecs</param-name>
<param-value>ParameterValue</param-value>
</init-param>
ConnectTimeout
Secs
サーブレットがサーバ インスタンスへの接続を試行する最大時間 (秒単位)。ConnectRetrySecs より大きい値を割り当てる。
接続が成功する前に ConnectTimeoutSecs が経過した場合は、HTTP 503/Service Unavailable 応答がクライアントに送信される。
構文 :
<init-param>
<param-name>ConnectTimeoutSecs</param-name>
<param-value>ParameterValue</param-value>
</init-param>
PathTrim
リクエストがクラスタに転送される前に、元の URL の先頭からプラグインによって取り除かれる文字列。
構文 :
<init-param>
<param-name>PathTrim</param-name>
<param-value>ParameterValue</param-value>
</init-param>
例:
URL
http://myWeb.server.com/weblogic/foo
が解析用にプラグインに渡され、PathTrim が次のように設定される場合、
/weblogic
WebLogic Server に転送される URL は次のようになる。
http://myWeb.server.com:7001/foo
TrimExt
URL の末尾から取り除かれるファイル拡張子。
構文 :
<init-param>
<param-name>TrimExt</param-name>
<param-value>ParameterValue</param-value>
</init-param>
clientCertProxy
クライアント証明書を信頼するために、WL-Proxy-Client-Cert ヘッダで指定する。
有効な値は true および false。デフォルト値は false。
この設定は、ユーザ認証がプロキシ サーバで実行される場合に役立つ。clientCertProxy を true に設定すると、プロキシ サーバは WL-Proxy-Client-Cert という特別なヘッダでクラスタに証明書を渡す。
WL-Proxy-Client-Cert ヘッダは、WebLogic Server に直接アクセス可能なクライアントで使用できる。WebLogic Server は、安全なソース (プラグイン) からのものであることを信用してヘッダの証明書情報を受け取り、その情報を使用してユーザを認証する。
そのため、clientCertProxy を true に設定する場合は、接続フィルタを使用して、WebLogic Server がプラグインの実行されているマシンからのみ接続を受信するようにすること。『WebLogic Security プログラマーズ ガイド』の「ネットワーク接続フィルタの使い方」を参照。
PathPrepend
PathTrim が取り除かれた後、URL がクラスタに転送される前に、元の URL の先頭にサーブレットが付加する文字列。
<init-param>
<param-name>PathPrepend</param-name>
<param-value>ParameterValue</param-value>
</init-param>

プロキシ サーバ経由のアプリケーションへのアクセス

クライアントがプロキシ サーバ経由でアクセスするアプリケーションを、クラスタにデプロイします。クライアント リクエストの送信先として、プロキシ サーバのリスン アドレスおよびリスン ポートを指定します。

問題がある場合は、以下の点を確認してください。

レプリケーション グループをコンフィグレーションする

WebLogic Server では、HTTP セッション ステートをメモリ内にレプリケートすることによって、サーブレットおよび JSP の自動フェイルオーバを行います。それ以外にも、レプリケーション グループを使用することにより、セカンダリ ステートが置かれる場所を独自に制御することができます。レプリケーション グループは、セッション ステートのレプリカの格納先として使用する、クラスタ内のサーバ インスタンスの優先順を定義するリストです。

クラスタがサーブレットまたはステートフル セッション EJB のホストになる場合は、WebLogic Server インスタンスのレプリケーション グループを作成して、セッション ステートのレプリカのホストにすることができます。

各レプリケーション グループに参加させるサーバ インスタンスと、各サーバ インスタンスの優先レプリケーション グループを決定する手順については、「レプリケーション グループの使用」を参照してください。

次に、個々の WebLogic Server インスタンスについて、次の手順に従ってレプリケーション グループをコンフィグレーションします。

WebLogic Server インスタンスのレプリケーション グループをコンフィグレーションするには、次の手順を実行します。

  1. WebLogic Server Console を起動します。
  2. [環境｜サーバ] ノードを選択します。
  3. テーブルで、コンフィグレーションするサーバの名前をクリックします。
  4. [クラスタ] タブを選択します。
  5. まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
  6. 以下の属性フィールドに値を入力します。
    • [レプリケーション グループ] : このサーバ インスタンスが属するレプリケーション グループ名を入力します。
    • [セカンダリ プリファレンス グループ] : このサーバ インスタンスをレプリケートされた HTTP セッション ステートのホストにする場合に使用するレプリケーション グループ名を入力します。
  7. [保存] をクリックして変更を保存します。
  8. 左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。

固定サービスの移行可能対象をコンフィグレーションする

WebLogic Server では、オプションの移行可能対象をコンフィグレーションできます。移行可能対象には、JMS サーバや Java Transaction API (JTA) トランザクション回復サービスなどの移行可能サービスのホストとなることのできる、クラスタ内のサーバ インスタンスのリストを定義します。移行可能対象を使用する場合、クラスタ内でサービスをデプロイまたはアクティブ化する前に、対象サーバ リストをコンフィグレーションします。

クラスタ内の移行可能対象をコンフィグレーションしない場合、移行可能サービスは、クラスタ内のどの WebLogic Server インスタンスにも移行できます。

JMS の移行可能な対象のコンフィグレーション手順については、『WebLogic JMS のコンフィグレーションと管理』の「クラスタ化 WebLogic JMS リソースのコンフィグレーション」を参照してください。

クラスタ化された JDBC をコンフィグレーションする

この節では、Administration Console による JDBC コンポーネントのコンフィグレーション手順を示します。JDBC コンポーネントのコンフィグレーション時に選択した内容は、クラスタを含む WebLogic Server ドメインのコンフィグレーション ファイルに反映されます。

まずデータ ソースを作成し、必要に応じてマルチ データ ソースを作成します。

データ ソースをクラスタ化する

次の手順を実行し、クラスタ内の基本データ ソースを設定します。

  1. データ ソースを作成します。

    2. 手順については、Administration Console オンライン ヘルプの「JDBC データ ソースの作成」を参照してください。

  2. データ ソースをクラスタに割り当てます。

マルチ データ ソースをクラスタ化する

可用性を向上させ、必要に応じてロード バランシングを提供するために、次の手順を実行してクラスタ化されたマルチ データ ソースを作成します。

注意 : 通常、マルチ データ ソースは、レプリケートされて同期を取られているデータベース インスタンスに対する接続の可用性を向上させ、ロード バランシングを提供するために使用します。詳細については、「JDBC 接続」を参照してください。
  1. 複数のデータ ソースを作成します。

    2. 手順については、Administration Console オンライン ヘルプの「JDBC データ ソースの作成」を参照してください。

  2. 各データ ソースをクラスタに割り当てます。
  3. マルチ データ ソースを作成します。前の手順で作成したデータ ソースをマルチ データ ソースに割り当てます。

    4. 手順については、Administration Console オンライン ヘルプの「JDBC マルチ データ ソースのコンフィグレーション」を参照してください。

  4. マルチ データ ソースをクラスタに割り当てます。

デプロイメント用にアプリケーションをパッケージ化する

アプリケーションは、WebLogic Server にデプロイする前にパッケージ化する必要があります。詳細については、『WebLogic Server アプリケーションの開発』の「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。

アプリケーションをデプロイする

WebLogic Server でクラスタ化するオブジェクトは、均一にデプロイすることをお勧めします。均一なデプロイメントが確実に行われるようにするには、対象を選択するときに、クラスタ内の個別の WebLogic Server インスタンスではなくクラスタ名を使用します。

Administration Console では、クラスタへのレプリカ対応オブジェクトのデプロイメントが自動化されます。アプリケーションまたはオブジェクトをクラスタにデプロイする場合、Administration Console では、アプリケーションまたはオブジェクトがクラスタの全メンバーに自動的にデプロイされます。メンバーは、管理サーバ マシンのローカルにあっても、リモート マシン上にあってもかまいません。クラスタ環境でのアプリケーションのデプロイメントについては、「クラスタをコンフィグレーションする方法」を参照してください。デプロイメントに関する全般的なトピックについては、『WebLogic Server アプリケーションのデプロイメント』を参照してください。

注意 : Administration Console を使用してアプリケーションをクラスタにデプロイするときは、クラスタ内のすべてのサーバ インスタンスを動作させておくことをお勧めします。

1 つのサーバ インスタンスにデプロイする (固定デプロイメント)

クラスタのすべてのメンバーでなく、1 つのサーバ インスタンスにアプリケーションをデプロイする形態を固定デプロイメントと呼びます。固定デプロイメントでは特定のサーバ インスタンスが対象となりますが、デプロイメント プロセスの間は、クラスタ内のすべてのサーバ インスタンスが動作していなければなりません。

固定デプロイメントは、Administration Console から実行することも、weblogic.Deployer を使用してコマンドラインから実行することもできます。

コマンドラインからの固定デプロイメント

コマンド シェルから、次の構文を使用して対象のサーバ インスタンスを指定します。 

java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1

クラスタのデプロイメントをキャンセルする

Administration Console を使用するか、または weblogic.Deployer を使用してコマンドラインからデプロイメントをキャンセルすることができます。

コマンドラインからデプロイメントをキャンセルする

コマンド シェルから、次の構文を使用してデプロイメント タスク ID をキャンセルします。 

java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag
Administration Console を使用してデプロイメントをキャンセルする

Administration Console で [タスク] ノードを開き、現在のデプロイメント タスクを表示してキャンセルします。

デプロイ済みアプリケーションを表示する

デプロイ済みのアプリケーションを Administration Console で表示するには、次の操作を行います。

  1. Administration Console で、[デプロイメント] ノードをクリックします。
  2. Administration Console 内のテーブルに、デプロイ済みアプリケーションの一覧が表示されます。

デプロイ済みアプリケーションをアンデプロイする

デプロイ済みのアプリケーションを WebLogic Server Administration Console からアンデプロイするには、次の操作を行います。

  1. Administration Console で、[デプロイメント] をクリックします。
  2. 表示されたテーブルで、アンデプロイするアプリケーションの左側にあるチェック ボックスをチェックします。
  3. まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
  4. [停止] をクリックします。
  5. アプリケーションを停止 (アンデプロイ) する時期を選択します。
  6. [はい] をクリックします。
  7. Administration Console の左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。

移行可能サービスをデプロイ、アクティブ化、および移行する

以下の節では、移行可能サービスをデプロイ、アクティブ化、および移行するためのガイドラインと手順を示します。

移行可能対象のサーバ インスタンスに JMS をデプロイする

ここで作成する移行可能対象は、移行可能サービスのホストとなることができるクラスタ内のサーバ インスタンスのスコープを定義します。後から対象サーバ リストの内部でサービスを移行するためには、移行可能対象として登録されているいずれかのサーバ インスタンス上で固定サービスをデプロイまたはアクティブ化する必要があります。次の手順に従って移行可能対象上に JMS サーバをデプロイするか、後から移行できるように JTA トランザクション回復システムをアクティブ化します。

注意 : 移行可能対象をコンフィグレーションしていない場合は、単純に JMS サーバをクラスタ内の任意の WebLogic Server インスタンスにデプロイします。その後、クラスタ内の任意の別サーバ インスタンスに JMS サーバを移行できます (移行可能対象は使用しません)。

Administration Console を使用して JMS サーバを移行可能対象にデプロイするには、次の手順に従います。

  1. まだ作成していない場合、「固定サービスの移行可能対象をコンフィグレーションする」の指示に従って、クラスタに対して移行可能対象を作成します。
  2. 対象のクラスタの管理サーバを起動し、Administration Console にログインします。
  3. まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
  4. 左ペインの [サービス｜JMS｜サーバ] ノードをクリックします。
  5. 表示されたテーブルで、クラスタにデプロイする、コンフィグレーション済み JMS サーバの名前をクリックします。JMS サーバのコンフィグレーションが右ペインに表示されます。
  6. 右ペインの [対象とデプロイ] タブを選択します。
  7. ドロップダウン リストから、サーバ インスタンスの名前を選択します。このドロップダウン リストには、移行可能対象の一部として定義されているサーバの名前が表示されます。
  8. [保存] をクリックして変更を保存します。
  9. Administration Console の左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。

移行可能サービスとして JTA をアクティブ化する

JTA 回復サービスは、クラスタの移行可能対象として登録されているいずれかのサーバ インスタンス上で自動的に起動されます。選択したサーバ インスタンスにサービスをデプロイする必要はありません。

JTA 移行可能対象をコンフィグレーションしない場合、WebLogic Server はクラスタ内で使用可能な任意の WebLogic Server インスタンス上でサービスをアクティブ化します。JTA サービスのホストである現在のサーバ インスタンスを変更するには、「対象サーバ インスタンスに固定サービスを移行する」で示されている手順に従います。

対象サーバ インスタンスに固定サービスを移行する

移行可能サービスをデプロイした後で、Administration Console を使用して、サービスをクラスタ内の別のサーバ インスタンスに移行できます。サービスに対して移行可能対象がコンフィグレーションされている場合、移行可能対象として登録されているサーバ インスタンスであれば、動作していない場合でもそのサーバ インスタンスにサービスを移行することができます。移行可能対象をコンフィグレーションしない場合、クラスタ内のその他の任意のサーバ インスタンスにサービスを移行できます。

停止しているサーバ インスタンスにサービスを移行する場合、そのサーバ インスタンスは次回の起動時に直ちにサービスをアクティブ化します。動作中の WebLogic Server インスタンスにサービスを移行する場合、移行は直ちに有効になります。

Administration Console を使用して固定サービスを移行するには、次の操作を行います。

  1. まだデプロイしていない場合、「移行可能対象のサーバ インスタンスに JMS をデプロイする」の指示に従って、固定サービスをクラスタにデプロイします。
  2. 対象のクラスタの管理サーバを起動し、Administration Console にログインします。
  3. まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
  4. 左ペインの [環境｜サーバ] ノードをクリックします。
  5. コンフィグレーションする、クラスタのメンバーであるサーバ インスタンスの名前をクリックします。
  6. JMS サービスを移行する場合は [制御｜移行] を、JTA トランザクション回復サービスを移行する場合は [制御｜JTA 移行] をそれぞれ選択します。

    7. [ホスト サーバ] フィールドには、その時点で固定サービスのホストとなっている WebLogic Server インスタンスが表示されています。[移行先のサーバ] ドロップダウン リストには、サービスを移行できるサーバ インスタンスが表示されます。

  7. [移行先のサーバ] ドロップダウン リストを使用して、新しく固定サービスのホストとなるサーバ インスタンスを選択します。
  8. [Migrate] をクリックして、固定サービスを現在のサーバから移行先サーバへ移行します。
  9. 現在のサーバに管理サーバからアクセスできない場合は、Administration Console に次のメッセージが表示されます。

    10. Unable to contact server MyServer-1, the source server from which services are being migrated.

    Please ensure that server MyServer-1 is NOT running! If the administration server cannot reach server MyServer-1 due to a network partition, inspect the server directly to verify that it is not running. Continue the migration only if MyServer-1 is not running. Cancel the migration if MyServer-1 is running, or if you do not know whether it is running.

    このメッセージが表示される場合は、「現在アクティブなホストがない場合の移行」の手順を行ってください。

  10. 送り先サーバが停止している場合は、Administration Console がその停止しているサーバ インスタンスを通知し、移行を続行するかどうか尋ねます。停止しているサーバ インスタンスへの移行を続けるには [続行] を、移行を中止して別のサーバ インスタンスを選択するには [取り消し] をそれぞれクリックします。
  11. サーバ インスタンスのコンフィグレーションによっては、移行プロセスを完了するまでに数分以上かかる場合があります。ただし、移行タスクを処理しながら、Administration Console で他の作業を続けることができます。後から移行の状況を確認するには、左ペインで [タスク] ノードをクリックし、対象のドメインに対して実行中であるタスクを表示します。次に、移行タスクの説明を選択して、現在の状況を表示します。
現在アクティブなホストがない場合のサービスの移行

移行可能サービスのアクティブ サーバだったクラスタ化されている管理対象サーバがクラッシュしたか、アクセス不能になった場合は、この移行手順を使用します。

この手順では、障害の発生した管理対象サーバのコンフィグレーション キャッシュをパージします。キャッシュをパージする目的は、障害の発生したサーバ インスタンスが再び利用可能になったときに、別の管理対象サーバに移行したサービスが再デプロイされないようにすることです。キャッシュをパージすると、サービスのアクティブなホストだった管理対象サーバが再び起動したときに、そのサーバによってローカルの古いコンフィグレーション データが使用されるリスクがなくなります。

  1. マシンのネットワークとの接続を完全に切断します。管理サーバやクライアント トラフィックからアクセスできないようにする必要があります。マシンにデュアル ポート ディスクがある場合は、それを切断します。
  2. 移行可能なサービスを別のマシン上の管理対象サーバ インスタンスに移行します。管理サーバは動作している必要があります。動作していれば、移行を調整し、アクティブ化テーブルを更新できます。
    • 移行にコマンドラインを使用する場合は、-sourcedown フラグを使用する
    • コンソールを使用する場合は、ソース サーバが再起動しないよう確認する必要がある

      • この時点で、移行可能サービスは別のマシンの別の管理対象サーバで利用可能になっています。次の手順は、時間があるときに行ってください。

  3. 障害の発生したマシンで必要な修理または保守を行います。
  4. マシンを再起動します。ただし、ネットワークへの接続は行いません。

    5. ノード マネージャがサービスまたはデーモンとして起動し、マシン上の管理対象サーバを起動しようとします。

    • 管理対象サーバの独立が有効な場合、管理対象サーバは管理サーバに接続できなくても起動する
    • 管理対象サーバの独立が無効な場合、管理対象サーバは管理サーバに接続できないので起動しない
  5. マシンをネットワークおよび共有ストレージ (デュアル ポート ディスクなど) に再接続します。
  6. ノード マネージャ デーモン/サービスを再起動するか、マシンを再起動して、残りのすべての管理対象サーバを起動します。
  7. 手順 5 で無効にした管理対象サーバを起動します。これは、ノード マネージャによって実行される再起動ではなく通常の起動です。管理サーバは動作していて、アクセス可能である必要があります。管理サーバがその状態であれば、管理対象サーバは管理サーバ上にある移行可能サービスのアクティブ化テーブルと同期をとって、それが現在は移行可能サービスのアクティブなホストでないことを認識できます。

インメモリ HTTP レプリケーションをコンフィグレーションする

WebLogic Server では、HTTP セッション ステートをメモリ内にレプリケートすることによって、サーブレットおよび JSP の自動フェイルオーバを行います。

注意 : WebLogic Server では、ファイルベースまたは JDBC ベースの永続性メカニズムを利用して、サーブレットまたは JSP の HTTP セッション ステートを保持することもできます。それぞれの永続性メカニズムの詳細については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「セッションとセッション永続性の使用」を参照してください。

インメモリでの HTTP セッション ステート レプリケーションは、デプロイするアプリケーションごとに個別に制御されます。レプリケーションを制御するパラメータ (PersistentStoreType) は、対象アプリケーションの WebLogic デプロイメント記述子ファイルである weblogic.xml の session-descriptor 要素の内部にあります。

domain_directory/applications/application_directory/Web-Inf/weblogic.xml

クラスタ内のサーバ インスタンス間でインメモリでの HTTP セッション ステート レプリケーションを使用するには、PersistentStoreType を replicated に設定します。次に示すのは、weblogic.xml での適切な設定例です。 

<session-descriptor> 
	<session-param> 
		<param-name> PersistentStoreType </param-name> 
		<param-value> replicated </param-value> 
	</session-param>

</session-descriptor>

コンフィグレーションに関するその他のトピック

以下の節では、クラスタの特殊なコンフィグレーションを行うときに役に立つヒントを示します。

IP ソケットをコンフィグレーションする

最適なパフォーマンスを得るために、WebLogic Server インスタンスのホストであるマシン上では、pure-Java 実装ではなくネイティブのソケット リーダー実装を使用することをお勧めします。

ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。

以下の節では、ホスト マシンに対してネイティブ ソケット リーダー スレッドをコンフィグレーションする方法と、ホストおよびクライアント マシンに対してリーダー スレッドの数を設定する方法について説明します。

サーバ インスタンスのホスト マシン上でネイティブの IP ソケット リーダーをコンフィグレーションする

ネイティブのソケット リーダー スレッド実装を使用するように WebLogic Server インスタンスをコンフィグレーションするには、次の手順に従います。

  1. WebLogic Server Administration Console を起動します。
  2. [環境｜サーバ] ノードを選択します。
  3. コンフィグレーションするサーバ インスタンスの名前をクリックします。
  4. まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
  5. [コンフィグレーション｜チューニング] タブを選択します。
  6. [ネイティブ IO を有効化] ボックスをチェックします。
  7. [保存] をクリックします。
  8. Administration Console の左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。
サーバ インスタンスのホスト マシン上のリーダー スレッドの数を設定する

デフォルトでは、WebLogic Server インスタンスは起動時に 3 つのソケット リーダー スレッドを作成します。クラスタ システムがピーク時に 4 つ以上のソケットを使用する可能性がある場合は、ソケット リーダー スレッド数を増やします。

  1. WebLogic Server Administration Console を起動します。
  2. [環境｜サーバ] ノードを選択します。
  3. コンフィグレーションするサーバ インスタンスの名前をクリックします。
  4. まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
  5. [コンフィグレーション｜チューニング] タブを選択します。
  6. [ソケット リーダー] フィールドで Java リーダー スレッドの割合を編集します。Java ソケット リーダーの数が、合計実行スレッド数 ([実行スレッド] フィールドに表示されます) の割合として計算されます。
  7. [保存] をクリックして変更を保存します。
  8. Administration Console の左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。
クライアント マシン上のリーダー スレッド数を設定する

クライアント マシン上では、クライアントを実行する Java 仮想マシン (JVM) 内でソケット リーダーの数をコンフィグレーションできます。クライアントの Java コマンドラインで -Dweblogic.ThreadPoolSize=value オプションおよび -Dweblogic.ThreadPoolPercentSocketReaders=value オプションを定義してソケット リーダーを指定します。

マルチキャスト存続時間 (TTL) をコンフィグレーションする

クラスタが WAN 内の複数のサブネットにまたがっている場合、マルチキャスト パケットが最終の送り先に到達する前にルータがパケットを破棄しないように、クラスタのマルチキャスト存続時間 (Time-To-Live : TTL) パラメータの値を十分に大きく設定する必要があります。マルチキャスト存続時間パラメータには、パケットが破棄されるまでにマルチキャスト メッセージが経由できるネットワーク ホップ数を設定します。マルチキャスト存続時間パラメータを適切に設定することにより、クラスタ内のサーバ インスタンス間で送受信されるマルチキャスト メッセージが消失するリスクが少なくなります。

マルチキャスト メッセージが確実に転送されるようにネットワーク トポロジを設計する方法については、「クラスタが WAN 内の複数のサブネットにまたがる場合」を参照してください。

クラスタのマルチキャスト存続時間をコンフィグレーションするには、Administration Console で、対象となるクラスタの [マルチキャスト] タブにある [マルチキャスト TTL] の値を変更します。config.xml の以下の抜粋部分は、マルチキャスト存続時間値に 3 を指定したクラスタを示しています。この値によって、破棄される前にクラスタのマルチキャスト メッセージを 3 つのルータに渡すことができます。 

<Cluster
	Name="testcluster"
	ClusterAddress="wanclust"
	MulticastAddress="wanclust-multi"
	MulticastTTL="3"
/>
注意 : マルチキャスト TTL 値に依存する場合は、クラスタ化された環境において、サーバ間のタイムスタンプが同期しない場合がある点に注意してください。この現象は、たとえばレプリケートされた HTTP セッションや EJB で発生します。
注意 : ClusterDebug フラグが有効になっていると、クラスタ メンバーのクロックが同期していない場合に、サーバ ログにエラーが記録されます。

マルチキャスト バッファのサイズをコンフィグレーションする

クラスタ内のサーバ インスタンスが受信メッセージを適時に処理しないことが原因でマルチキャスト ストームが発生する場合は、マルチキャスト バッファのサイズを増やすことができます。マルチキャスト ストームの詳細については、「マルチキャスト ストームが起こったら」を参照してください。

TCP/IP カーネル パラメータは、UNIX の ndd ユーティリティを使用してコンフィグレーションできます。udp_max_buf パラメータでは、UDP ソケットの送信および受信バッファのサイズをバイト単位で管理します。udp_max_buf の適切な値は、デプロイメントによって異なります。マルチキャスト ストームが発生する場合は、udp_max_buf の値を 32KB 単位で増やして、その変更の効果を評価します。

必要な場合以外は、udp_max_buf の値を変更しないでください。udp_max_buf を変更する前に、『Solaris Tunable Parameters Reference Manual』(http://docs.sun.com/?p=/doc/806-6779/6jfmsfr7o&) の「TCP/IP Tunable Parameters」という章の「UDP Parameters with Additional Cautions」に記載されている警告を読んでください。

マルチキャスト データの暗号化をコンフィグレーションする

WebLogic Server では、クラスタ間で送信されるマルチキャスト メッセージを暗号化できます。Administration Console で [環境｜クラスタ｜(クラスタ名)｜マルチキャスト] ノードに移動し、[詳細] を選択して [マルチキャスト データの暗号化を有効にする] をチェックすることで、このオプションを有効にできます。

マルチキャスト メッセージのデータ部分のみが暗号化されます。マルチキャスト ヘッダの情報は暗号化されません。

マシン名をコンフィグレーションする

以下のいずれかの場合にマシン名をコンフィグレーションします。

WebLogic Server では、コンフィグレーションされたマシン名を使用して、2 つのサーバ インスタンスが物理的に同じハードウェアに存在しているかどうかを調べることができます。マシン名は一般に、複数のサーバ インスタンスのホストとなるマシンで使用されます。そのようなインストール用のマシン名を定義していない場合、各インスタンスは物理的に異なるハードウェア上に存在するものとして扱われます。このことは、「レプリケーション グループの使用」で説明しているように、セカンダリ HTTP セッション ステートのレプリカのホストになるサーバ インスタンスの選択に悪影響を与えることがあります。

多層アーキテクチャのコンフィグレーションに関する注意

多層アーキテクチャのクラスタのコンフィグレーションについては、「多層アーキテクチャのコンフィグレーションに関する考慮事項」のガイドラインを参照してください。

URL 書き換えを有効にする

デフォルト コンフィグレーションの WebLogic Server では、クライアント側のクッキーを使用して、クライアントのサーブレット セッション ステートのホストであるプライマリ サーバ インスタンスとセカンダリ サーバ インスタンスが追跡されます。クライアントのブラウザでクッキーが無効になっている場合、WebLogic Server では URL 書き換えによってもプライマリ サーバ インスタンスとセカンダリ サーバ インスタンスを追跡できます。URL 書き換えを利用する場合は、クライアント セッション ステートの両方の場所が、クライアントとプロキシ サーバの間で渡される URL に挿入されます。この機能をサポートするには、WebLogic Server クラスタで URL 書き換えを有効にする必要があります。URL 書き換えを有効にする方法については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「クッキーに代わる URL 書き換えの使用」を参照してください。


  ページの先頭       前  次