以下の節では、WebLogic Server クラスタをコンフィグレーションするためのガイドラインと手順を示します。
この節では、WebLogic Server クラスタを設定するための前提となる作業および情報についてまとめています。
クラスタのコンフィグレーション プロセスと、コンフィグレーション タスクの実施方法の基本を理解しておくと、この節で示す情報がより有益なものとなります。
WebLogic Server が備えるコンフィグレーション機能と、それらの機能を通じて実施できるタスクの詳細については、「クラスタのコンフィグレーションについて」を参照してください。
どのクラスタ アーキテクチャが、対象アプリケーションのニーズに最も適しているかを決定します。アーキテクチャ上の重要な決定には、以下のものがあります。
すべてのアプリケーション層を 1 つのクラスタにまとめるか、それともアプリケーションの各層を複数のクラスタ間に分離するか
クラスタ内のサーバ インスタンス間での負荷調整の方法。次のうちどの方法を使用するか
WebLogic Server の基本ロード バランシング機能を使用する
サード パーティ製のロード バランサを実装する
アプリケーションの Web 層を 1 つ以上のセカンダリ HTTP サーバにデプロイし、Web 層へのリクエストをプロキシで中継する
Web アプリケーションに対して、1 つ以上のファイアウォールを備えた非武装地帯 (DMZ) を定義するか
これらを決定するためには、「クラスタ アーキテクチャ」および「クラスタでのロード バランシング」の情報が参考になります。
選択するアーキテクチャによって、クラスタの設定方法も変わります。クラスタ アーキテクチャによっては、ロード バランサ、HTTP サーバ、プロキシ プラグインなどの、他のリソースのインストールまたはコンフィグレーションが必要になる場合もあります。
アプリケーションのセキュリティ要件は、適切なセキュリティ トポロジを設計するための基礎となります。多様なレベルのアプリケーション セキュリティを提供する各種の代替アーキテクチャの詳細については、「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。
注意 : 一部のネットワーク トポロジは、マルチキャスト通信に干渉することがあります。WAN にクラスタをデプロイしている場合の注意事項については、「クラスタが WAN 内の複数のサブネットにまたがる場合」を参照してください。ファイアウォールを越えてクラスタにサーバ インスタンスをデプロイしないでください。ファイアウォールを通じてマルチキャスト トラフィックをトンネリングすることの影響については、「ファイアウォールがマルチキャスト通信を遮断することがある」を参照してください。 |
WebLogic Server をインストールする予定の 1 台以上のマシン (この節では「ホスト」と呼ぶ) を確定し、各マシンが必要なリソースを備えていることを確認します。WebLogic Server では、クラスタを非マルチホーム環境の 1 台のマシン上に設定できます。この新しい機能は、デモンストレーションまたは開発用の環境で役立ちます。
注意 : IP アドレスが動的に割り当てられるマシンに WebLogic Server をインストールしないでください。 |
WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems, Inc. の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバを、大規模なクラスタまたは複数のクラスタのホストとすることができます。
ほとんどの場合、WebLogic Server クラスタは、2 つの CPU につき 1 つの WebLogic Server インスタンスの割合でデプロイするのが最適です。ただし、どのようなキャパシティ プランニングにも共通することですが、サーバ インスタンスの最適数および分散方法を決定する場合は、対象となる Web アプリケーションで実際のデプロイメントを事前にテストする必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド』の「マルチ CPU マシンのパフォーマンスに関する考慮事項」を参照してください。
ソケットの最適なパフォーマンスを実現するには、pure-Java 実装ではなく、オペレーティング システムに対応したネイティブ ソケット リーダー実装を使用するよう WebLogic Server ホスト マシンをコンフィグレーションします。ネイティブ ソケットをコンフィグレーションする、または pure-Java ソケット通信を最適化する理由とその手順については、「IP ソケットを使用したピア ツー ピア通信」を参照してください。
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 アドレスを使用すると、以下の状況で変換エラーが発生するおそれがあります。
クライアントがファイアウォールを経由してクラスタに接続する場合
プレゼンテーション層とオブジェクト層の間にファイアウォールを設ける場合。たとえば、推奨多層クラスタの説明箇所で示しているように、サーブレット クラスタと EJB クラスタの間にファイアウォールを置く場合など
変換エラーは、個別のサーバ インスタンスのアドレスを DNS 名にバインドすることによって回避できます。サーバ インスタンスの DNS 名が、ファイアウォールの両側で必ず一致するようにしてください。また、ネットワーク上の NT システムの名前でもある DNS 名は使用しないでください。
IP アドレスの代わりに DNS 名を使用する場合の注意事項については、「ファイアウォールについての考慮事項」を参照してください。
WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同じでない場合、サーバ インスタンスの ExternalDNSName
属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外で、ExternalDNSName
はサーバの外部 IP アドレスに変換されます。クライアントがデフォルト チャネルと T3 を介して WebLogic Server にアクセスしている場合は、WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が異なる場合でも、ExternalDNSName
属性を設定しないでください。
サーバ インスタンスのリスン アドレスを localhost として識別すると、非ローカルのプロセスがそのサーバ インスタンスに接続できなくなります。サーバ インスタンスのホスト マシン上のプロセスのみ、そのサーバ インスタンスに接続できます。(たとえば localhost に接続する管理スクリプトがある場合などに) サーバ インスタンスが localhost としてアクセス可能でなければならない場合で、かつリモート プロセスからもアクセス可能でなければならない場合は、リスン アドレスを空白にします。リスン アドレスを空白にすると、サーバ インスタンスはマシンのアドレスを判別してそのアドレスでリスンします。
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
の組み合わせは、リクエストを受信した管理対象サーバとネットワーク チャネルに対応します。
リクエストが管理対象サーバのデフォルト チャネルで受信された場合、クラスタ アドレス内の listen address:listen port
の組み合わせには、関連付けられた ServerMBean
インスタンスおよび SSLMBean
インスタンスの ListenAddress
値および ListenPort
値が反映される。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「デフォルト ネットワーク チャネル」を参照してください。
リクエストがカスタム ネットワーク チャネルで受信された場合、クラスタ アドレス内の listen address:listen port
の組み合わせには、そのチャネルを定義する NetworkAccessPointMBean
の ListenAddress
値および ListenPort
値が反映される。クラスタのネットワーク チャネルの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「クラスタにおけるネットワーク チャネルのコンフィグレーション」を参照してください。
クラスタ アドレスに含まれる ListenAddress:ListenPort
の組み合わせの数には、ClusterMBean
の NumberOfServersInClusterAddress
属性の値 (デフォルトは 3) が適用されます。
NumberOfServersInClusterAddress
の値は、Administration Console の [環境|クラスタ|(クラスタ名)|コンフィグレーション|全般] ページで変更できます。
クラスタ内で使用可能な管理対象サーバの数が NumberOfServersInClusterAddress
の値より少ない場合、動的に生成されるクラスタ アドレスには実行中の各管理対象サーバの ListenAddress:ListenPort
の組み合わせが含まれる。
クラスタ内で使用可能な管理対象サーバの数が NumberOfServersInClusterAddress
の値より多い場合、WebLogic Server は使用可能なインスタンスから NumberOfServersInClusterAddress
の値と同数のインスタンスのサブセットを選択し、それらのインスタンスの ListenAddress:ListenPort
の組み合わせを使用してクラスタ アドレスを生成する。
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
各クラスタ メンバーは、ユニークなアドレスとポートの組み合わせを持っています。
この節では、アプリケーションをクラスタ構成にして実行する手順を、WebLogic Server のインストールからアプリケーション コンポーネントの初期デプロイメントまで順を追って説明します。
この節では、典型的なクラスタ実装のタスクをリストし、コンフィグレーションに関する重要な考慮事項を説明します。実際のプロセスは、環境ごとにユニークな特性およびアプリケーションの性質によって決まります。以下のタスクを説明します。
クラスタの実装によっては、一部の手順が不要である場合があります。また、ここで示す以外の手順が必要になる場合もあります。
まだインストールしていない場合、WebLogic Server をインストールします。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server インストール ガイド』を参照してください。
クラスタを 1 台のマシン上で実行する場合、/bea
ディレクトリの下に、クラスタ内のすべてのインスタンスに対して使用する単体の WebLogic Server をインストールします。
ネットワーク上のリモート マシンについては、各マシンに同じバージョンの WebLogic Server をインストールします。各マシンは次の要件を満たしている必要があります。
永続的に割り当てられる静的な IP アドレスを持つこと。クラスタ化環境では、動的に割り当てられる IP アドレスは使用できません。
クライアントからアクセス可能であること。サーバ インスタンスとクライアントの間にファイアウォールがある場合、各サーバ インスタンスには、クライアントから到達できるパブリックな静的 IP アドレスを割り当てる必要があります。
すべてのマシンが同じローカル エリア ネットワーク (LAN) 上にあり、IP マルチキャストによって通信できること。
注意 : 共有ファイルシステムと 1 つのインストールを使用して、異なるマシン上で複数の WebLogic Server インスタンスを実行しないでください。共有ファイルシステムを使用すると、クラスタにシングル ポイントの競合が発生します。すべてのサーバ インスタンスが、ファイルシステムにアクセスする (また場合によっては、個別のログ ファイルへの書き込みを行う) ために競合しなければならなくなります。さらに、共有ファイルシステムに障害が発生した場合には、クラスタ化されたサーバ インスタンスを起動できなくなることもあります。 |
クラスタ化されたドメインの作成方法は複数あります。リストについては、「クラスタをコンフィグレーションする方法」を参照してください。
クラスタの作成手順については、以下を参照してください。
コンフィグレーション ウィザード。まず、ドメインの作成手順については『Oracle Fusion Middleware コンフィグレーション ウィザードを使用したドメインの作成』の「WebLogic ドメインの作成」を参照し、次に、クラスタのコンフィグレーション手順については「環境のカスタマイズ」を参照してください。
Administration Console。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「クラスタの作成とコンフィグレーション」を参照してください。
クラスタを起動するには複数の方法があります。コマンドライン インタフェース、必要なコマンドを含むスクリプト、ノード マネージャなどを使用できます。
注意 : ノード マネージャを使用すると、サーバを起動したり、障害発生後にサーバを再起動したりするプロセスが簡単になります。ノード マネージャを使用するには、最初に、クラスタ内の管理対象サーバをホストする各マシンでノード マネージャ プロセスをコンフィグレーションする必要があります。「ノード マネージャをコンフィグレーションする」を参照してください。 |
どの方法を使用してクラスタを起動する場合でも、最初にクラスタ内の管理サーバを起動し、次に管理対象サーバを起動します。
以下の手順に従って、コマンド シェルからクラスタを起動します。各サーバ インスタンスを別々のコマンド シェルで起動することに注意してください。
コマンド シェルを開きます。
コンフィグレーション ウィザードで作成したドメイン ディレクトリに移動します。
次のコマンドを入力して管理サーバを起動します。
StartWebLogic
「Enter username to boot WebLogic Server」というプロンプトが表示されたら、ドメインのユーザ名を入力します。
「Enter password to boot WebLogic Server」というプロンプトが表示されたら、ドメインのパスワードを入力します。
起動プロセスの状態を知らせるメッセージがコマンド シェルに表示されます。
管理対象サーバを起動するために、別のコマンド シェルを開きます。
コンフィグレーション ウィザードで作成したドメイン ディレクトリに移動します。
次のコマンドを入力します。
StartManagedWebLogic server_name address:port
各要素の説明は次のとおりです。
server_name : 起動する管理対象サーバの名前
address : ドメインの管理サーバの IP アドレスまたは DNS 名
port : ドメインの管理サーバのリスン ポート
「Enter username to boot WebLogic Server」というプロンプトが表示されたら、ドメインのユーザ名を入力します。
「Enter password to boot WebLogic Server」というプロンプトが表示されたら、ドメインのパスワードを入力します。
起動プロセスの状態を知らせるメッセージがコマンド シェルに表示されます。
注意 : 管理対象サーバを起動すると、クラスタ内の他の実行中サーバ インスタンスからハートビートがリスンされます。管理対象サーバは、「WebLogic Server による JNDI ツリー更新の仕組み」で説明しているように、クラスタワイドの JNDI ツリーのローカル コピーを構築し、クラスタ内の実行中の管理対象サーバとの同期が取れたら、ステータス メッセージを表示します。同期化プロセスには、1 分ほどかかります。 |
クラスタ内の別のサーバ インスタンスを起動するには、手順 6 から手順 10 までを繰り返します。
クラスタ内のすべての管理対象サーバを起動したら、クラスタの起動プロセスは完了です。
ノード マネージャは、WebLogic Server 付属のスタンドアロンの Java プログラムであり、管理サーバとは異なるマシン上にある管理対象サーバの起動に便利です。またノード マネージャには、クラスタ内にある管理対象サーバの可用性の向上に役立つ機能もあります。ノード マネージャの詳細と、コンフィグレーション方法および使用方法については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』を参照してください。
この節の手順に従うと、EJB および RMI オブジェクトのロード バランシング アルゴリズムを選択できます。
その他の方式を明示的に指定しない場合、WebLogic Server はクラスタ化されるオブジェクトのスタブに対して、デフォルトのロード バランシング方式であるラウンドロビン アルゴリズムを使用します。それ以外のロード バランシング方式については、「EJB と RMI オブジェクトのロード バランシング」を参照してください。デフォルトのロード バランシング アルゴリズムを変更するには、次の手順に従います。
WebLogic Server Console を起動します。
[環境|クラスタ] ノードを選択します。
テーブルでクラスタの名前をクリックします。
まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
[デフォルトのロード バランス アルゴリズム] フィールドに、使用するロード バランシング アルゴリズムを入力します。
[詳細] リンクをクリックします。
[サービス期間しきい値] フィールドに設定値を入力します。
[保存] をクリックして変更を保存します。
左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。
ClusterMBean の ReplicationTimeoutEnabled を true に設定することで、ReplicationManager の呼び出し時にタイムアウト オプションを有効にできます。
タイムアウト値はマルチキャスト ハートビートのタイムアウト値と同じです。マルチキャストのタイムアウト値はカスタマイズできますが、ReplicationManager のタイムアウト値は変更できません。この制限があるのは、ReplicationManager のタイムアウトはクラスタのメンバシップに影響しないからです。マルチキャスト ハートビートがなくなるとそのメンバーはクラスタから削除され、ReplicationManager の呼び出しがタイムアウトすると接続先の新しいセカンダリ サーバが選択されます。
注意 : クラスタ メンバーはマルチキャスト ハートビートを送信し続けることができますが、レプリケーション リクエストは処理できません。そのため、セカンダリ サーバの分散が不均一になるおそれがあります。このような状態になると、警告メッセージがサーバ ログに記録されます。 |
WebLogic Server が提供する JMS のサーバ アフィニティのサポートについては、「JMS のロード バランシング」を参照してください。
パッシブなクッキーの永続性をサポートするロード バランサは、セッションをホストする WebLogic Server インスタンスをクライアントと関連付けるために WebLogic Server セッション クッキーの情報を使用できます。セッション クッキーには、ロード バランサがセッションのプライマリ サーバ インスタンスを識別する文字列が含まれています。
外部ロード バランサ、セッション クッキーの永続性、および WebLogic Server セッション クッキーの詳細については、「外部ロード バランサによる HTTP セッションのロード バランシング」を参照してください。
クラスタで動作するようにロード バランサをコンフィグレーションするには、ロード バランサの機能を使用して、文字列定数のオフセットと長さを定義します。
セッション クッキーのセッション ID 部分がデフォルト長の 52 バイトであると想定して、ロード バランサで次のように設定します。
文字列のオフセットは、ランダム セッション ID 長に区切り文字用の 1 バイトを加えた 53 バイト
文字列の長さは 10 バイト
アプリケーションまたは環境によって、ランダム セッション ID の長さをデフォルト値の 52 バイト以外に変更しなければならない場合は、それに応じて文字列のオフセットをロード バランサで設定してください。文字列のオフセットは、セッション ID の長さに、区切り文字用の 1 バイトを加えたものと同じ値にする必要があります。
プロキシ プラグインを使用してサーブレットおよび JSP のロード バランシングを行う場合は、この節で示す手順を参考にしてください。プロキシ プラグインは、リクエストを Web サーバからクラスタ内の WebLogic Server インスタンスに中継し、プロキシを経由する HTTP リクエストのロード バランシングとフェイルオーバを可能にします。
プロキシ プラグインによるロード バランシングの詳細については、「プロキシ プラグインによるロード バランシング」を参照してください。プロキシ プラグインによる接続とフェイルオーバの詳細については、「サーブレットと JSP のレプリケーションとフェイルオーバ」および「クラスタ化されたサーブレットと JSP へのプロキシ経由のアクセス」を参照してください。
Web サーバとして WebLogic Server を使用する場合、「HttpClusterServlet を設定する」の指示に従って、HttpClusterServlet
を設定する。
サポートされているサード パーティ製 Web サーバを使用する場合、その製品に固有のプラグインを設定する (サポートされている Web サーバの一覧については、「プロキシ プラグインによるロード バランシング」を参照)。『Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server』の手順に従ってください。
注意 : リクエストをクラスタにプロキシ経由で中継する各 Web サーバでは、プラグインが同じようにコンフィグレーションされている必要があります。 |
HTTP クラスタ サーブレットを使用するには、以下の手順で説明するように、プロキシ サーバ マシン上でサーブレットをデフォルト Web アプリケーションとしてコンフィグレーションします。Web アプリケーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「Web アプリケーション、サーブレット、および JSP について」を参照してください。
まだコンフィグレーションしていない場合は、独立したクラスタ化されていない管理対象サーバをコンフィグレーションして、HTTP クラスタ サーブレットをホストするようにします。
サーブレットの web.xml
デプロイメント記述子を作成します。このファイルは、Web アプリケーション ディレクトリの \WEB-INF
サブディレクトリに配置する必要があります。プロキシ サーブレットのサンプルのデプロイメント記述子は「サンプルの web.xml」にあります。web.xml
の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「Web アプリケーション、サーブレット、および JSP について」を参照してください。
web.xml
の <servlet>
要素で、サーブレットの名前とクラスを定義します。サーブレット名は HttpClusterServlet
です。サーブレット クラスは weblogic.servlet.proxy.HttpClusterServlet
です。
web.xml
の <servlet>
要素で、WebLogicCluster
パラメータを定義して、プロキシ サーブレットのリクエストの転送先となる、クラスタ化されたサーバ インスタンスを指定します。
独自の ID 証明書とキーで双方向 SSL を使用する場合は、必要に応じて以下の <KeyStore>
初期化パラメータを定義します。デプロイメント記述子に <KeyStore>
が指定されていない場合、プロキシでは一方向 SSL と見なされます。
<KeyStore>
- Web アプリケーションのキーストアの場所。
<KeyStoreType>
- キーストアのタイプ。定義されていない場合、デフォルトのタイプが使用されます。
<PrivateKeyAlias>
- プライベート キーのエリアス。
<KeyStorePasswordProperties>
- Web アプリケーション内のプロパティ ファイル。キーストアおよびプライベート キーのエリアスにアクセスするための暗号化されたパスワードを定義します。このファイルの内容は次のとおりです。
KeyStorePassword={3DES}i4+50LCKenQO8BBvlsXTrg\=\= PrivateKeyPassword={3DES}a4TcG4mtVVBRKtZwH3p7yA\=\=
パスワードを暗号化するには、weblogic.security.Encrypt コマンドライン ユーティリティを使用する必要があります。Encrypt
ユーティリティや、CertGen および der2pem ユーティリティの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「Oracle WebLogic Server Java ユーティリティの使い方」を参照してください。
<servlet-mapping>
スタンザを作成して、サーブレットがクラスタにプロキシするリクエストを指定します。<url-pattern>
要素を使用して特定のファイル拡張子 (*.jsp
または *.html
など) を指定します。パターンごとに別々の <servlet-mapping>
スタンザに定義します。
<url-pattern>
を「/
」に設定すると、WebLogic Server によって解決できないリクエストをリモート サーバ インスタンスにプロキシできます。その場合、拡張子が *.jsp
、*.htm
、および *.html
のファイルをプロキシするために、これらの拡張子もマップしなければなりません。例については、「サンプルの web.xml」を参照してください。
必要に応じて、追加のパラメータを定義します。主なパラメータのリストについては、表 10-1 を参照してください。詳細なリストについては、『Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server』の「Web サーバ プラグインのパラメータ」を参照してください。「プロキシ サーブレットのデプロイメント パラメータ」の構文の指示に従ってください。
サーブレットの weblogic.xml
デプロイメント記述子ファイルを作成します。このファイルは、Web アプリケーション ディレクトリの \WEB-INF
サブディレクトリに配置する必要があります。
<weblogic-web-app>
スタンザの <context-root>
要素をフォワード スラッシュ文字 (/) に設定して、プロキシ サーブレットをプロキシ マシンにある管理対象サーバのデフォルト Web アプリケーションとして割り当てます。例については、「サンプルの weblogic.xml」を参照してください。
Administration Console で、プロキシ サーバ マシン上の管理対象サーバにサーブレットをデプロイします。手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「アプリケーションおよびモジュールのデプロイ」を参照してください。
この節では HttpClusterServlet
のサンプルのデプロイメント記述子ファイル (web.xml
) を示します。
web.xml
では、プロキシ サーブレットの位置と動作を指定するさまざまなパラメータを定義します。
DOCTYPE
スタンザは、web.xml
の有効性を検証するために WebLogic Server で使用される DTD を指定する。
servlet
スタンザは次のように機能する。
プロキシ プラグイン サーブレット クラスの場所を指定する。ファイルは、WL_HOME/server/lib
ディレクトリの weblogic.jar
にある。WebLogic Server の起動時に weblogic.jar
が CLASSPATH に配置されるため、web.xml
ではサーブレットの絶対ディレクトリ パスを指定する必要はありません。
WebLogicCluster
パラメータを使用して、クラスタ内の各管理対象サーバのホスト名 (DNS 名または IP アドレス) とリスン ポートを識別する。
独自の ID 証明書とキーで双方向 SSL を使用するためのキー ストア初期化パラメータを識別する。
4 つの servlet-mapping
スタンザは、サーブレットが「/」、「htm」、「html」、または「jsp」で終わる URL をクラスタにプロキシすることを指定する。
パラメータの定義については、「プロキシ サーブレットのデプロイメント パラメータ」を参照してください。
<!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
ファイルを示します。<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
でプロキシ サーブレットの動作をコンフィグレーションするための主なパラメータを表 10-1 に示します。
プロキシ サーブレットのパラメータは、Apache、Microsoft、および Netscape Web サーバ用の WebLogic Server プラグインのコンフィグレーションに使用するパラメータと同じです。プロキシ サーブレットおよびサード パーティ製 Web サーバのプラグインをコンフィグレーションするパラメータの詳細なリストについては、『Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server』の「Web サーバ プラグインのパラメータ」を参照してください。
パラメータを指定する際の構文と指定先のファイルは、プロキシ サーブレットとプラグインごとに異なります。
プロキシ サーブレットの場合、web.xml
でパラメータを指定します。パラメータごとに、web.xml
の <servlet>
スタンザ内の <init-param>
スタンザで指定します。次に例を示します。
<init-param> <param-name>ParameterName</param-name> <param-value>ParameterValue</param-value> </init-param>
表 10-1 プロキシ サーブレットのデプロイメント パラメータ
パラメータ | 適用 |
---|---|
WebLogicCluster |
<init-param> <param-name>WebLogicCluster</param-name> <param-value>WLS1.com:port|WLS2.com:port </param-value>
プラグインと WebLogic Server の間で SSL を使用する場合は、ポート番号を SSL リスン ポートに設定して (「リスンポートのコンフィグレーション」を参照)、 |
SecureProxy |
<init-param>
<param-name>SecureProxy</param-name>
<param-value>ParameterValue</param-value>
</init-param>
有効な値は ON および OFF。 プラグインと WebLogic Server の間で SSL を使用する場合は、ポート番号を SSL リスン ポートに設定して (「リスンポートのコンフィグレーション」を参照)、 |
DebugConfigInfo |
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ParameterValue</param-value>
</init-param>
有効な値は ON および OFF。 ON に設定する場合、リクエストに |
ConnectRetrySecs |
サーバ インスタンスへの接続試行の間に、サーブレットがスリープする間隔 (秒単位)。
構文 :
<init-param>
<param-name>ConnectRetrySecs</param-name>
<param-value>ParameterValue</param-value>
</init-param>
|
ConnectTimeoutSecs |
サーブレットがサーバ インスタンスへの接続を試行する最大時間 (秒単位)。 接続が成功する前に 構文 :
<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 が解析用にプラグインに渡され、 /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 |
クライアント証明書を信頼するために、 有効な値は true および false。デフォルト値は false。 この設定は、ユーザ認証がプロキシ サーバで実行される場合に役立つ。
そのため、 |
PathPrepend |
<init-param>
<param-name>PathPrepend</param-name>
<param-value>ParameterValue</param-value>
</init-param>
|
クライアントがプロキシ サーバ経由でアクセスするアプリケーションを、クラスタにデプロイします。クライアント リクエストの送信先として、プロキシ サーバのリスン アドレスおよびリスン ポートを指定します。
問題がある場合は、以下の点を確認してください。
すべてのサーバ インスタンスがユニークなアドレスとポートの組み合わせになっている
コンフィグレーション内の各サーバ インスタンスは、リスン アドレスとリスン ポートの組み合わせがユニークである必要があります。
プロキシ サーブレットがプロキシ サーバのデフォルト アプリケーションになっている
アプリケーションにアクセスしようとして「ページが見つからない」エラーが発生した場合は、weblogic.xml
がアプリケーションの \WEB-INF
にあり、context-root
デプロイメント パラメータが「/」に設定されていることを確認してください。
上記 2 項目を確認して問題が解決されない場合は再起動する
問題がある場合は、すべてのサーバを再起動してみてください。コンフィグレーション時に行った変更の一部がコンフィグレーション ファイルに保持されていないおそれがあります。
コンフィグレーションを確認する
HttpClusterServlet
のコンフィグレーションを確認するには、次の手順に従います。
web.xml
で DebugConfigInfo
パラメータを ON に設定します。
Web ブラウザを使用して、次の URL にアクセスします。
http://myServer:port/placeholder.jsp?__WebLogicBridgeConfig
各値の説明は次のとおりです。
myServer は HttpClusterServlet
が動作するプロキシ マシン上の管理対象サーバです。port
は、HTTP リクエストをリスンしているサーバ上のポート番号です。placeholder.jsp
は、サーバ上に存在しないファイルです。
プラグインはコンフィグレーション情報と実行時統計を収集して、その情報をブラウザに返します。詳細については、『Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server』の「Web サーバ プラグインのパラメータ」を参照してください。
WebLogic Server では、HTTP セッション ステートをメモリ内にレプリケートすることによって、サーブレットおよび JSP の自動フェイルオーバを行います。それ以外にも、レプリケーション グループを使用することにより、セカンダリ ステートが置かれる場所を独自に制御することができます。レプリケーション グループは、セッション ステートのレプリカの格納先として使用する、クラスタ内のサーバ インスタンスの優先順を定義するリストです。
クラスタがサーブレットまたはステートフル セッション EJB のホストになる場合は、WebLogic Server インスタンスのレプリケーション グループを作成して、セッション ステートのレプリカのホストにすることができます。
各レプリケーション グループに参加させるサーバ インスタンスと、各サーバ インスタンスの優先レプリケーション グループを決定する手順については、「レプリケーション グループの使用」を参照してください。
次に、個々の WebLogic Server インスタンスについて、次の手順に従ってレプリケーション グループをコンフィグレーションします。
WebLogic Server インスタンスのレプリケーション グループをコンフィグレーションするには、次の手順を実行します。
WebLogic Server Console を起動します。
[環境|サーバ] ノードを選択します。
テーブルで、コンフィグレーションするサーバの名前をクリックします。
[クラスタ] タブを選択します。
まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
以下の属性フィールドに値を入力します。
[レプリケーション グループ] : このサーバ インスタンスが属するレプリケーション グループ名を入力します。
[セカンダリ プリファレンス グループ] : このサーバ インスタンスをレプリケートされた HTTP セッション ステートのホストにする場合に使用するレプリケーション グループ名を入力します。
[保存] をクリックして変更を保存します。
左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。
WebLogic Server では、必要に応じて移行可能対象をコンフィグレーションできます。移行可能対象とは、クラスタ内のサーバから別のサーバに移行できる特別な対象です。つまり、移行可能対象を使用することで、一緒に移行する必要のある固定サービスをグループ化できます。移行可能対象を移行すると、その対象によってホストされているすべてのサービスが移行されます。固定サービスには、JMS 関連サービス (JMS サーバ、SAF エージェント、パス サービス、永続ストアなど) や JTA トランザクション回復サービスなどがあります。
移行可能対象を使用する場合、クラスタ内でサービスをデプロイまたはアクティブ化する前に、対象サーバ リストをコンフィグレーションします。クラスタ内に移行可能対象をコンフィグレーションしない場合、移行可能サービスは、クラスタ内で使用可能などの WebLogic Server インスタンスにでも移行できます。移行可能対象の詳細については、「クラスタ内の移行可能対象について」を参照してください。
この節では、Administration Console による JDBC コンポーネントのコンフィグレーション手順を示します。JDBC コンポーネントのコンフィグレーション時に選択した内容は、クラスタを含む WebLogic Server ドメインのコンフィグレーション ファイルに反映されます。
まずデータ ソースを作成し、必要に応じてマルチ データ ソースを作成します。
WebLogic Server クラスタ内での JDBC オブジェクトの動作については、「JDBC 接続」を参照してください。
クラスタ化された JDBC がアプリケーションの可用性をどのように向上させるかについては、「フェイルオーバと JDBC 接続」を参照してください。
クラスタ化された JDBC がロード バランシングをどのようにサポートするかについては、「JDBC 接続のロード バランシング」を参照してください。
次の手順を実行し、クラスタ内の基本データ ソースを設定します。
データ ソースを作成します。
手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの作成」を参照してください。
データ ソースをクラスタに割り当てます。
可用性を向上させ、必要に応じてロード バランシングを提供するために、次の手順を実行してクラスタ化されたマルチ データ ソースを作成します。
注意 : 通常、マルチ データ ソースは、レプリケートされて同期を取られているデータベース インスタンスに対する接続の可用性を向上させ、ロード バランシングを提供するために使用します。詳細については、「JDBC 接続」を参照してください。 |
複数のデータ ソースを作成します。
手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの作成」を参照してください。
各データ ソースをクラスタに割り当てます。
マルチ データ ソースを作成します。前の手順で作成したデータ ソースをマルチ データ ソースに割り当てます。
手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC マルチ データ ソースのコンフィグレーション」を参照してください。
マルチ データ ソースをクラスタに割り当てます。
アプリケーションは、WebLogic Server にデプロイする前にパッケージ化する必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
WebLogic Server でクラスタ化するオブジェクトは、均一にデプロイすることをお勧めします。均一なデプロイメントが確実に行われるようにするには、対象を選択するときに、クラスタ内の個別の WebLogic Server インスタンスではなくクラスタ名を使用します。
Administration Console では、クラスタへのレプリカ対応オブジェクトのデプロイメントが自動化されます。アプリケーションまたはオブジェクトをクラスタにデプロイする場合、Administration Console では、アプリケーションまたはオブジェクトがクラスタの全メンバーに自動的にデプロイされます。メンバーは、管理サーバ マシンのローカルにあっても、リモート マシン上にあってもかまいません。クラスタ環境でのアプリケーションのデプロイメントについては、「クラスタをコンフィグレーションする方法」を参照してください。デプロイメントに関する全般的なトピックについては、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』を参照してください。
注意 : Administration Console を使用してアプリケーションをクラスタにデプロイするときは、クラスタ内のすべてのサーバ インスタンスを動作させておくことをお勧めします。 |
クラスタのすべてのメンバーでなく、1 つのサーバ インスタンスにアプリケーションをデプロイする形態を固定デプロイメントと呼びます。固定デプロイメントでは特定のサーバ インスタンスが対象となりますが、デプロイメント プロセスの間は、クラスタ内のすべてのサーバ インスタンスが動作していなければなりません。
固定デプロイメントは、Administration Console から実行することも、weblogic.Deployer
を使用してコマンドラインから実行することもできます。
Administration Console を使用するか、または weblogic.Deployer
を使用してコマンドラインからデプロイメントをキャンセルすることができます。
コマンド シェルから、次の構文を使用してデプロイメント タスク ID をキャンセルします。
java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag
デプロイ済みのアプリケーションを Administration Console で表示するには、次の操作を行います。
Administration Console で、[デプロイメント] ノードをクリックします。
Administration Console 内のテーブルに、デプロイ済みアプリケーションの一覧が表示されます。
デプロイ済みのアプリケーションを WebLogic Server Administration Console からアンデプロイするには、次の操作を行います。
Administration Console で、[デプロイメント] をクリックします。
表示されたテーブルで、アンデプロイするアプリケーションの左側にあるチェック ボックスをチェックします。
まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
[停止] をクリックします。
アプリケーションを停止 (アンデプロイ) する時期を選択します。
[はい] をクリックします。
Administration Console の左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。
以下の節では、移行可能サービスをデプロイ、アクティブ化、および移行するためのガイドラインと手順を示します。
ここで作成する移行可能対象は、移行可能サービスのホストとなることができるクラスタ内のサーバ インスタンスのスコープを定義します。後から対象サーバ リストの内部でサービスを移行するためには、移行可能対象として登録されているいずれかのサーバ インスタンス上で固定サービスをデプロイまたはアクティブ化する必要があります。次の手順に従って移行可能対象上に JMS サービスをデプロイするか、後から移行できるように JTA トランザクション回復システムをアクティブ化します。
注意 : 移行可能対象をコンフィグレーションしていない場合は、単純に JMS サーバをクラスタ内の任意の WebLogic Server インスタンスにデプロイします。その後、クラスタ内の任意の別サーバ インスタンスに JMS サーバを移行できます (移行可能対象は使用しません)。 |
まず最初に、「固定サービスの移行可能対象をコンフィグレーションする」の指示に従って、クラスタの移行可能対象を作成します。次に、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプにある以下のトピックの指示に従って、JMS 関連サービスを移行可能対象にデプロイします。
「ファイル ストアの作成」および「JDBC ストアの作成」
JTA 回復サービスは、クラスタの移行可能対象として登録されているいずれかのサーバ インスタンス上で自動的に起動されます。選択したサーバ インスタンスにサービスをデプロイする必要はありません。
JTA 移行可能対象をコンフィグレーションしない場合、WebLogic Server はクラスタ内で使用可能な任意の WebLogic Server インスタンス上でサービスをアクティブ化します。JTA サービスのホストである現在のサーバ インスタンスを変更するには、「対象サーバ インスタンスに固定サービスを移行する」で示されている手順に従います。
移行可能サービスをデプロイした後で、Administration Console を使用して、サービスを手動でクラスタ内の別のサーバ インスタンスに移行できます。サービスに対して移行可能対象がコンフィグレーションされている場合、移行可能対象として登録されているサーバ インスタンスであれば、動作していない場合でもそのサーバ インスタンスにサービスを移行することができます。移行可能対象をコンフィグレーションしない場合、クラスタ内のその他の任意のサーバ インスタンスにサービスを移行できます。
停止しているサーバ インスタンスにサービスを移行する場合、そのサーバ インスタンスは次回の起動時に直ちにサービスをアクティブ化します。動作中の WebLogic Server インスタンスにサービスを移行する場合、移行は直ちに有効になります。
まず最初に、「移行可能対象のサーバ インスタンスに JMS をデプロイする」の指示に従って、固定サービスをクラスタにデプロイします。次に、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックの指示に従い、Administration Console を使用して固定サービスを移行します。
以下に、Administration Console オンライン ヘルプでは説明されていない追加手順を示します。
現在のサーバに管理サーバからアクセスできない場合は、Administration Console に次のメッセージが表示されます。
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.
このメッセージが表示される場合は、「現在アクティブなホストがない場合の移行」の手順を行ってください。
送り先サーバが停止している場合は、Administration Console がその停止しているサーバ インスタンスを通知し、移行を続行するかどうか尋ねます。停止しているサーバ インスタンスへの移行を続けるには [続行] を、移行を中止して別のサーバ インスタンスを選択するには [取り消し] をそれぞれクリックします。
サーバ インスタンスのコンフィグレーションによっては、移行プロセスを完了するまでに数分以上かかる場合があります。ただし、移行タスクを処理しながら、Administration Console で他の作業を続けることができます。後から移行の状況を確認するには、左ペインで [タスク] ノードをクリックし、対象のドメインに対して実行中であるタスクを表示します。次に、移行タスクの説明を選択して、現在の状況を表示します。
移行可能サービスのアクティブ サーバだったクラスタ化されている管理対象サーバがクラッシュしたか、アクセス不能になった場合は、この移行手順を使用します。
この手順では、障害の発生した管理対象サーバのコンフィグレーション キャッシュをパージします。キャッシュをパージする目的は、障害の発生したサーバ インスタンスが再び利用可能になったときに、別の管理対象サーバに移行したサービスが再デプロイされないようにすることです。キャッシュをパージすると、サービスのアクティブなホストだった管理対象サーバが再び起動したときに、そのサーバによってローカルの古いコンフィグレーション データが使用されるリスクがなくなります。
マシンのネットワークとの接続を完全に切断します。管理サーバやクライアント トラフィックからアクセスできないようにする必要があります。マシンにデュアル ポート ディスクがある場合は、それを切断します。
移行可能なサービスを別のマシン上の管理対象サーバ インスタンスに移行します。管理サーバは動作している必要があります。動作していれば、移行を調整し、アクティブ化テーブルを更新できます。
移行にコマンドラインを使用する場合は、-sourcedown
フラグを使用する
コンソールを使用する場合は、ソース サーバが再起動しないよう確認する必要がある
この時点で、移行可能サービスは別のマシンの別の管理対象サーバで利用可能になっています。次の手順は、時間があるときに行ってください。
障害の発生したマシンで必要な修理または保守を行います。
マシンを再起動します。ただし、ネットワークへの接続は行いません。
ノード マネージャがサービスまたはデーモンとして起動し、マシン上の管理対象サーバを起動しようとします。
管理対象サーバの独立が有効な場合、管理対象サーバは管理サーバに接続できなくても起動する
管理対象サーバの独立が無効な場合、管理対象サーバは管理サーバに接続できないので起動しない
マシンをネットワークおよび共有ストレージ (デュアル ポート ディスクなど) に再接続します。
ノード マネージャ デーモン/サービスを再起動するか、マシンを再起動して、残りのすべての管理対象サーバを起動します。
無効にした管理対象サーバを起動します。これは、ノード マネージャによって実行される再起動ではなく通常の起動です。管理サーバは動作していて、アクセス可能である必要があります。管理サーバがその状態であれば、管理対象サーバは管理サーバ上にある移行可能サービスのアクティブ化テーブルと同期をとって、それが現在は移行可能サービスのアクティブなホストでないことを認識できます。
WebLogic Server では、HTTP セッション ステートをメモリ内にレプリケートすることによって、サーブレットおよび JSP の自動フェイルオーバを行います。
注意 : WebLogic Server では、ファイルベースまたは JDBC ベースの永続性メカニズムを利用して、サーブレットまたは JSP の HTTP セッション ステートを保持することもできます。それぞれの永続性メカニズムの詳細については、『Oracle Fusion Middleware Oracle 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>
以下の節では、クラスタの特殊なコンフィグレーションを行うときに役に立つヒントを示します。
最適なパフォーマンスを得るために、WebLogic Server インスタンスのホストであるマシン上では、pure-Java 実装ではなくネイティブのソケット リーダー実装を使用することをお勧めします。
ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
クラスタ内での IP ソケットの使用方法と、ネイティブ ソケット リーダー スレッドが最適なパフォーマンスをもたらす理由については、「IP ソケットを使用したピア ツー ピア通信」および「ソケット経由のクライアント通信」を参照してください。
クラスタで必要なソケット リーダー スレッドの数を決定する方法については、「ソケットの使用数を確定する」を参照してください。多層クラスタ アーキテクチャにサーブレット クラスタをデプロイしている場合、「多層アーキテクチャのコンフィグレーションに関する考慮事項」で説明しているように、これは必要なソケットの数に影響します。
以下の節では、ホスト マシンに対してネイティブ ソケット リーダー スレッドをコンフィグレーションする方法と、ホストおよびクライアント マシンに対してリーダー スレッドの数を設定する方法について説明します。
ネイティブのソケット リーダー スレッド実装を使用するように WebLogic Server インスタンスをコンフィグレーションするには、次の手順に従います。
WebLogic Server Administration Console を起動します。
[環境|サーバ] ノードを選択します。
コンフィグレーションするサーバ インスタンスの名前をクリックします。
まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
[コンフィグレーション|チューニング] タブを選択します。
[ネイティブ IO を有効化] ボックスをチェックします。
[保存] をクリックします。
Administration Console の左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。
デフォルトでは、WebLogic Server インスタンスは起動時に 3 つのソケット リーダー スレッドを作成します。クラスタ システムがピーク時に 4 つ以上のソケットを使用する可能性がある場合は、ソケット リーダー スレッド数を増やします。
WebLogic Server Administration Console を起動します。
[環境|サーバ] ノードを選択します。
コンフィグレーションするサーバ インスタンスの名前をクリックします。
まだクリックしていない場合は、Administration Console の左上隅にある [ロックして編集] ボタンをクリックします。
[コンフィグレーション|チューニング] タブを選択します。
[ソケット リーダー] フィールドで Java リーダー スレッドの割合を編集します。Java ソケット リーダーの数が、合計実行スレッド数 ([実行スレッド] フィールドに表示されます) の割合として計算されます。
[保存] をクリックして変更を保存します。
Administration Console の左上隅にある [変更のアクティブ化] ボタンをクリックして、変更内容をアクティブ化します。
クライアント マシン上では、クライアントを実行する Java 仮想マシン (JVM) 内でソケット リーダーの数をコンフィグレーションできます。クライアントの Java コマンドラインで -Dweblogic.ThreadPoolSize
=value オプションおよび -Dweblogic.ThreadPoolPercentSocketReaders
=value オプションを定義してソケット リーダーを指定します。
クラスタが 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://dlc.sun.com/pdf/819-2724/819-2724.pdf
) の「TCP/IP Tunable Parameters」という章の「UDP Parameters with Additional Cautions」に記載されている Sun の警告を読んでください。
WebLogic Server では、クラスタ間で送信されるマルチキャスト メッセージを暗号化できます。Administration Console で [環境|クラスタ|(クラスタ名)|マルチキャスト] ノードに移動し、[詳細] を選択して [マルチキャスト データの暗号化を有効にする] をチェックすることで、このオプションを有効にできます。
マルチキャスト メッセージのデータ部分のみが暗号化されます。マルチキャスト ヘッダの情報は暗号化されません。
以下のいずれかの場合にマシン名をコンフィグレーションします。
クラスタが複数のマシンにまたがっており、複数のサーバ インスタンスがクラスタ内の各マシンで動作する場合
管理サーバをホストしないマシンでノード マネージャを実行する場合
WebLogic Server では、コンフィグレーションされたマシン名を使用して、2 つのサーバ インスタンスが物理的に同じハードウェアに存在しているかどうかを調べることができます。マシン名は一般に、複数のサーバ インスタンスのホストとなるマシンで使用されます。そのようなインストール用のマシン名を定義していない場合、各インスタンスは物理的に異なるハードウェア上に存在するものとして扱われます。このことは、「レプリケーション グループの使用」で説明しているように、セカンダリ HTTP セッション ステートのレプリカのホストになるサーバ インスタンスの選択に悪影響を与えることがあります。
多層アーキテクチャのクラスタのコンフィグレーションについては、「多層アーキテクチャのコンフィグレーションに関する考慮事項」のガイドラインを参照してください。
デフォルト コンフィグレーションの WebLogic Server では、クライアントサイドのクッキーを使用して、クライアントのサーブレット セッション ステートのホストであるプライマリ サーバ インスタンスとセカンダリ サーバ インスタンスが追跡されます。クライアントのブラウザでクッキーが無効になっている場合、WebLogic Server では URL 書き換えによってもプライマリ サーバ インスタンスとセカンダリ サーバ インスタンスを追跡できます。URL 書き換えを利用する場合は、クライアント セッション ステートの両方の場所が、クライアントとプロキシ サーバの間で渡される URL に挿入されます。この機能をサポートするには、WebLogic Server クラスタで URL 書き換えを有効にする必要があります。URL 書き換えを有効にする方法については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「クッキーに代わる URL 書き換えの使用」を参照してください。