この章では、WebLogic Serverクラスタを構成するためのガイドラインと手順を示します。
この章の内容は次のとおりです。
この項では、WebLogic Serverクラスタを設定するための前提条件となる作業および情報についてまとめています。
クラスタの構成プロセスと、構成タスクの実施方法の基本を理解しておくと、この項で示す情報がより有益なものとなります。
WebLogic Serverが備える構成機能と、それらの機能を通じて実施できるタスクの詳細は、「クラスタの構成の理解」を参照してください。
どのクラスタ・アーキテクチャが、ターゲット・アプリケーションのニーズに最も適しているかを決定します。アーキテクチャ上の重要な決定には、次のものがあります。
すべてのアプリケーション層を1つのクラスタにまとめるか、それともアプリケーションの各層を複数のクラスタ間に分離するか
クラスタ内のサーバー・インスタンス間での負荷調整の方法。次のうちどの方法を使用するか
WebLogic Serverの基本ロード・バランシング機能を使用する
サード・パーティ製のロード・バランサを実装する、または
アプリケーションのWeb層を1つ以上のセカンダリHTTPサーバーにデプロイし、Web層へのリクエストをプロキシで中継する
Webアプリケーションに対して、1つ以上のファイアウォールを備えた非武装地帯(DMZ)を定義するか
これらを決定するためには、「クラスタ・アーキテクチャ」および「クラスタでのロード・バランシング」の情報が参考になります。
選択するアーキテクチャによって、クラスタの設定方法も変わります。クラスタ・アーキテクチャによっては、ロード・バランサ、HTTPサーバー、プロキシ・プラグインなどの、他のリソースのインストールまたは構成が必要になる場合もあります。
アプリケーションのセキュリティ要件は、適切なセキュリティ・トポロジを設計するための基礎となります。多様なレベルのアプリケーション・セキュリティを提供する各種の代替アーキテクチャの詳細は、「クラスタ・アーキテクチャのセキュリティ・オプション」を参照してください。
注意: 一部のネットワーク・トポロジは、マルチキャスト通信に干渉することがあります。WANにクラスタをデプロイしている場合の注意事項については、「クラスタがWAN内の複数のサブネットにまたがる場合」を参照してください。 1つのクラスタ内のサーバー・インスタンス群を、ファイアウォールをまたいでデプロイしないでください。ファイアウォールを通過するマルチキャスト・トラフィックのトンネリングの影響については、「ファイアウォールがマルチキャスト通信を遮断することがある」を参照してください。 |
WebLogic Serverをインストールする予定の1台以上のマシン(この項では「ホスト」と呼ぶ)を確定し、各マシンが必要なリソースを備えていることを確認します。WebLogic Serverでは、クラスタを非マルチホーム環境の1台のマシン上に設定できます。この新しい機能は、デモンストレーションまたは開発用の環境で役立ちます。
注意: IPアドレスが動的に割り当てられるマシンにWebLogic Serverをインストールしないでください。 |
WebLogic Serverには、クラスタ内のサーバー・インスタンス数に関する制限はありません。したがって、Sun MicrosystemsのSun Enterprise 10000などの大規模マルチプロセッサ・サーバーを、大規模なクラスタまたは複数のクラスタのホストとすることができます。
CPUごとに1つのサーバーを起動し、予期される動作に基づいてスケール・アップすることをお薦めします。ただし、あらゆるキャパシティ・プランニングと同様、サーバー・インスタンスの最適数および分散方法を決定する場合は、ターゲットWebアプリケーションで実際のデプロイメントをテストする必要があります。追加情報は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のマルチ・コア・マシン上で複数のサーバー・インスタンスの実行に関する項を参照してください。
ソケットの最適なパフォーマンスを実現するには、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環境の構成可能な各リソースには、一意の名前を割り当てる必要があります。ドメイン、サーバー、マシン、クラスタ、データ・ソース、仮想ホストなどのリソースには一意の名前が必要です。
クラスタに対して使用する管理サーバーの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の値のマルチキャスト・アドレスを使用することはできません。 |
クラスタ内のサーバー・インスタンスは、マルチキャストを使用して互いに通信します。具体的には、マルチキャストを使用して各自のサービスを全体に通知し、インスタンスが継続的に使用可能であることを知らせるハートビートを一定間隔で発行します。
クラスタのマルチキャスト・アドレスは、クラスタ通信以外の目的には使用しないことをお薦めします。クラスタのマルチキャスト・アドレスが存在するマシンが、マルチキャスト通信を使用するクラスタ外部のプログラムのホストであるか、またはそのようなプログラムによってアクセスされる場合、そのマルチキャスト通信では必ず、クラスタのマルチキャスト・ポートとは異なるポートを使用してください。
第9章「クラスタ・アーキテクチャ」で説明しているような、クラスタ間にファイアウォールを設ける推奨多層アーキテクチャを設定している場合、専用のマルチキャスト・アドレスが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 WebLogic Serverサーバー環境の管理』のデフォルト・ネットワーク・チャネルに関する項を参照してください。
リクエストがカスタム・ネットワーク・チャネルで受信された場合、クラスタ・アドレス内のlisten address:listen port
には、そのチャネルを定義するNetworkAccessPointMBean
のListenAddress
値とListenPort
値が反映されます。クラスタ内のネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のクラスタにおけるネットワーク・チャネルの構成に関する項を参照してください。
クラスタ・アドレスに含まれるListenAddress:ListenPort
の組合せの数には、ClusterMBean
のNumberOfServersInClusterAddress
属性の値(デフォルトは3)が適用されます。
NumberOfServersInClusterAddress
の値は、管理コンソールの「環境」>「クラスタ」>ClusterName>「構成」>「全般」ページで変更できます。
クラスタ内で使用可能な管理対象サーバーの数が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 WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。
クラスタを1台のマシン上で実行する場合、/Oracle
ディレクトリの下に、クラスタ化されたすべてのインスタンスに使用される単一のWebLogic Serverをインストールします。
ネットワーク上のリモート・マシンについては、各マシンに同じバージョンのWebLogic Serverをインストールします。各マシンは:
永続的に割り当てられる静的なIPアドレスを持つ必要があります。クラスタリング環境では、動的に割り当てられるIPアドレスは使用できません。
クライアントからアクセス可能であることが必要です。サーバー・インスタンスとクライアントの間にファイアウォールがある場合、各サーバー・インスタンスには、クライアントから到達できるパブリックな静的IPアドレスを割り当てる必要があります。
すべてのマシンが同じローカル・エリア・ネットワーク(LAN)上にあり、IPマルチキャストによって通信できることが必要です。
クラスタ化ドメインの作成方法は複数あります。リストについては、「クラスタを構成する方法」を参照してください。
クラスタの作成手順については、次を使用してください。
構成ウィザード。ドメインの作成手順は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成に関する項を参照してください。クラスタの構成方法は、オプションの構成の選択に関する項を参照してください。
管理コンソールの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの作成と構成に関する項を参照してください。
クラスタを起動するには複数の方法があります。コマンドライン・インタフェース、必要なコマンドを含むスクリプト、およびノード・マネージャなどを使用できます。
注意: ノード・マネージャを使用すると、サーバーを起動したり、障害発生後にサーバーを再起動したりするプロセスが簡単になります。 ノード・マネージャを使用するには、最初に、クラスタ内の管理対象サーバーをホストする各マシンでノード・マネージャ・プロセスを構成する必要があります。「ノード・マネージャを構成する」を参照してください。 |
どの方法を使用してクラスタを起動する場合でも、最初にクラスタ内の管理サーバーを起動し、次に管理対象サーバーを起動します。
次の手順に従って、コマンド・シェルからクラスタを起動します。各サーバー・インスタンスを別々のコマンド・シェルで起動することに注意してください。
コマンド・シェルを開きます。
構成ウィザードで作成したドメイン・ディレクトリに移動します。
次のコマンドを入力して管理サーバーを起動します。
StartWebLogic
「WebLogic Serverを起動するためのユーザー名を入力してください」というプロンプトが表示されたら、ドメインのユーザー名を入力します。
「WebLogic Serverを起動するためのパスワードを入力してください」というプロンプトが表示されたら、ドメインのパスワードを入力します。
起動プロセスのステータスを知らせるメッセージがコマンド・シェルに表示されます。
管理対象サーバーを起動するために、別のコマンド・シェルを開きます。
構成ウィザードで作成したドメイン・ディレクトリに移動します。
このコマンドを入力します
StartManagedWebLogic server_name address:port
説明:
server_nameは、起動する管理対象サーバーの名前です
addressは、ドメインの管理サーバーのIPアドレスまたはDNS名です
portは、ドメインの管理サーバーのリスニング・ポートです
「WebLogic Serverを起動するためのユーザー名を入力してください」というプロンプトが表示されたら、ドメインのユーザー名を入力します。
「WebLogic Serverを起動するためのパスワードを入力してください」というプロンプトが表示されたら、ドメインのパスワードを入力します。
起動プロセスのステータスを知らせるメッセージがコマンド・シェルに表示されます。
注意: 管理対象サーバーを起動すると、クラスタ内の他の実行中のサーバーからのハートビートがリスニングされます。管理対象サーバーは、クラスタ全体のJNDIツリーのローカル・コピーをビルドし(「WebLogic ServerによるJNDIツリーの更新方法」を参照)、クラスタ内の実行中の各管理対象サーバーと同期したら、ステータス・メッセージを表示します。同期化プロセスには1分ほどかかります。 |
クラスタ内の別のサーバー・インスタンスを起動するには、ステップ6に戻ります。ステップ10を続けてください。
クラスタ内のすべての管理対象サーバーを起動したら、クラスタの起動プロセスは完了です。
ノード・マネージャは、WebLogic Serverで提供されるスタンドアロンプログラムであり、管理サーバーとは別のマシンにある管理対象サーバーの起動に利用できます。また、ノード・マネージャには、クラスタ内の管理対象サーバーの可用性の向上に役立つ機能もあります。ノード・マネージャの詳細および構成方法と使用方法は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
この項の手順に従うと、EJBおよびRMIオブジェクトのロード・バランシング・アルゴリズムを選択できます。
他のものを明示的に指定しない場合、WebLogic Serverはクラスタ化されるオブジェクトのスタブに対して、デフォルトのロード・バランシング戦略であるラウンドロビン・アルゴリズムを使用します。それ以外のロード・バランシング方式については、「EJBとRMIオブジェクトのロード・バランシング」を参照してください。デフォルトのロード・バランシング・アルゴリズムを変更するには:
WebLogic Server管理コンソールを起動します。
「環境」>「クラスタ」の順に選択します。
表でクラスタの名前を選択します。
クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。
「デフォルトのロード・バランス・アルゴリズム」
フィールドに、使用するロード・バランシング・アルゴリズムを入力します。
「詳細」を選択します。
「サービス期間しきい値」
フィールドに任意の値を入力します。
「保存」をクリックして変更を保存します。
変更をアクティブ化するには、左上隅にある「変更のアクティブ化」をクリックします。
ClusterMBeanのReplicationTimeoutEnabledをtrueに設定することで、ReplicationManagerの呼出し時にタイムアウト・オプションを有効にできます。
タイムアウト値はマルチキャスト・ハートビートのタイムアウト値と同じです。マルチキャストのタイムアウト値はカスタマイズできますが、ReplicationManagerのタイムアウト値は変更できません。この制限があるのは、ReplicationManagerのタイムアウトはクラスタのメンバーシップに影響しないからです。マルチキャスト・ハートビートがなくなるとそのメンバーはクラスタから削除され、ReplicationManagerの呼出しがタイムアウトすると接続先の新しいセカンダリ・サーバーが選択されます。
注意: クラスタ・メンバーはマルチキャスト・ハートビートを送信し続けることができますが、レプリケーション・リクエストは処理できません。そのため、セカンダリ・サーバーの分散が不均一になるおそれがあります。このような状態になると、警告メッセージがサーバー・ログに記録されます。 |
WebLogic Serverが提供するJMSのサーバー・アフィニティのサポートについては、「JMSのロード・バランシング」を参照してください。
パッシブなCookieの永続性をサポートするロード・バランサは、セッションをホストするWebLogic Serverインスタンスをクライアントと関連付けるためにWebLogic ServerセッションCookieの情報を使用できます。セッションCookieには、ロード・バランサがセッションのプライマリ・サーバー・インスタンスを識別する文字列が含まれています。
外部ロード・バランサ、セッションCookieの永続性、およびWebLogic ServerセッションCookieの詳細は、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください。
クラスタで動作するようにロード・バランサを構成するには、ロード・バランサの機能を使用して、文字列定数のオフセットと長さを定義します。
セッションCookieのセッションID部分がデフォルト長の52バイトであると想定して、ロード・バランサで次を設定します。
文字列のオフセットは、ランダム・セッションID長に区切り文字用の1バイトを加えた53バイト
文字列の長さは10バイト
アプリケーションまたは環境によって、ランダム・セッションIDの長さをデフォルト値の52バイト以外に変更しなければならない場合は、それに応じて文字列のオフセットをロード・バランサで設定してください。文字列のオフセットは、セッションIDの長さに、区切り文字用の1バイトを加えたものと同じ値にする必要があります。
プロキシ・プラグインを使用してサーブレットおよびJSPのロード・バランシングを行う場合は、この項で示す手順を参考にしてください。プロキシ・プラグインは、リクエストをWebサーバーからクラスタ内のWebLogic Serverインスタンスに中継し、プロキシを経由するHTTPリクエストのロード・バランシングとフェイルオーバーを可能にします。
プロキシ・プラグインによるロード・バランシングの詳細は、「プロキシ・プラグインによるロード・バランシング」を参照してください。プロキシ・プラグインによる接続とフェイルオーバーの詳細は、「サーブレットとJSPのレプリケーションとフェイルオーバー」および「クラスタ化されたサーブレットとJSPへのプロキシ経由のアクセス」を参照してください。
WebサーバーとしてWebLogic Serverを使用する場合、「HttpClusterServletを設定する」の指示に従って、HttpClusterServlet
を設定します。
サポートされているサード・パーティ製Webサーバーを使用する場合、『Oracle WebLogic Serverプロキシ・プラグイン12.1.2の使用』の手順に従って、その製品に固有のプラグインを設定します(サポートされているWebサーバーの一覧については、「プロキシ・プラグインによるロード・バランシング」を参照)。
注意: リクエストをクラスタにプロキシ経由で中継する各Webサーバーでは、プラグインが同じように構成されている必要があります。 |
HTTPクラスタ・サーブレットを使用するには、次の手順で説明するように、プロキシ・サーバー・マシン上でサーブレットをデフォルトWebアプリケーションとして構成します。Webアプリケーションの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のWebアプリケーション、サーブレット、およびJSPの理解に関する項を参照してください。
まだ構成していない場合は、独立したクラスタ化されていない管理対象サーバーを構成して、HTTPクラスタ・サーブレットをホストするようにします。
サーブレットのweb.xml
デプロイメント記述子ファイルを作成します。このファイルは、Webアプリケーション・ディレクトリの\WEB-INF
サブディレクトリに配置する必要があります。プロキシ・サーブレットのサンプルのデプロイメント記述子は、「サンプルのweb.xml」に示します。web.xml
の詳細は、『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={AES}yWv/i0qhfM4/IvzoghzjHj/xpJUkQPF8OWuSfh0f0Ss= PrivateKeyPassword={AES}wr86u9Z5DHr+5p7WIbzTDSy4M/sl7EYnX/K5xzcarDQ=
パスワードを暗号化するためにweblogic.security.Encryptコマンドライン・ユーティリティを使用する必要があります。Encrypt
ユーティリティおよびCertGenとder2pemユーティリティの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のWebLogic Server Javaユーティリティの使用に関する項を参照してください。
<servlet-mapping>
スタンザを作成して、サーブレットがクラスタにプロキシするリクエストを指定します。<url-pattern>
要素を使用して特定のファイル拡張子(*.jsp
または*.html
など)を指定します。パターンごとに別々の<servlet-mapping>
スタンザに定義します。
<url-pattern>
を「/」
に設定すると、WebLogic Serverによって解決できないリクエストをリモート・サーバー・インスタンスにプロキシできます。その場合、拡張子が*.jsp
、*.htm
、および*.html
のファイルをプロキシするために、これらの拡張子もマップしなければなりません。例については、「サンプルのweb.xml」を参照してください。
必要に応じて、追加のパラメータを定義します。主なパラメータのリストについては、表10-1を参照してください。完全なリストについては、『Oracle WebLogic Serverプロキシ・プラグイン12.1.2の使用』のWebサーバー・プラグインのパラメータに関する項を参照してください。「プロキシ・サーブレットのデプロイメント・パラメータ」の構文の指示に従ってください。
サーブレットのweblogic.xml
デプロイメント記述子ファイルを作成します。このファイルは、Webアプリケーション・ディレクトリの\WEB-INF
サブディレクトリに配置する必要があります。
<weblogic-web-app>
スタンザの<context-root>
要素をフォワード・スラッシュ文字(/)に設定して、プロキシ・サーブレットをプロキシ・マシンにある管理対象サーバーのデフォルトWebアプリケーションとして割り当てます。例については、「サンプルのweblogic.xml」を参照してください。
管理コンソールで、プロキシ・マシン上の管理対象サーバーにサーブレットをデプロイします。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーションおよびモジュールのデプロイに関する項を参照してください。
この項では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 WebLogic Serverプロキシ・プラグイン12.1.2の使用』の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>
|
|
Webサービスのクラスタ・ルーティングをサポートするようプロキシ・サーブレットを拡張します。詳細は、『Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング』のクラスタのWebサービスの管理に関する項を参照してください。 <init-param> <param-name>RoutingHandlerClassName</param-name> <param-value> weblogic.wsee.jaxws.cluster.proxy.SOAPRoutingHandler </param-value> </init-param> |
クライアントがプロキシ・サーバー経由でアクセスするアプリケーションを、クラスタにデプロイします。クライアント・リクエストの送信先として、プロキシ・サーバーのリスニング・アドレスおよびリスニング・ポートを指定します。
問題がある場合は:
すべてのサーバー・インスタンスが一意のアドレスとポートの組み合わせになっているかどうかを確認します
構成内の各サーバー・インスタンスは、リスニング・アドレスとリスニング・ポートの組合せが固有である必要があります。
プロキシ・サーブレットがプロキシ・サーバーのデフォルト・アプリケーションになっていることを確認します
アプリケーションにアクセスしようとして「ページが見つからない」エラーが発生した場合は、weblogic.xml
がアプリケーションの\WEB-INF
にあり、context-root
デプロイメント・パラメータが「/」に設定されていることを確認してください。
解決しない場合は再起動します
問題がある場合は、すべてのサーバーを再起動してみてください。構成時に行った変更の一部が構成ファイルに保持されていない可能性があります。
構成を確認します
HttpClusterServlet
の構成を確認するには:
web.xml
でDebugConfigInfo
パラメータをONに設定します。
Webブラウザを使用して、次のURLにアクセスします。
http://myServer:port/placeholder.jsp?__WebLogicBridgeConfig
説明:
myServerはHttpClusterServlet
が動作するプロキシ・マシン上の管理対象サーバーです。port
は、HTTPリクエストをリスニングしているサーバー上のポート番号です。placeholder.jsp
は、サーバー上に存在しないファイルです。
プラグインは構成情報と実行時統計を収集して、その情報をブラウザに返します。詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.1.2の使用』のWebサーバー・プラグインのパラメータに関する項を参照してください。
WebLogic Serverでは、HTTPセッション状態をメモリー内にレプリケートすることによって、サーブレットおよびJSPの自動フェイルオーバーを行います。それ以外にも、レプリケーション・グループを使用することにより、セカンダリ状態が置かれる場所を独自に制御することができます。レプリケーション・グループは、セッション状態のレプリカの格納先として使用する、クラスタ内のサーバー・インスタンスの優先順を定義するリストです。
クラスタがサーブレットまたはステートフル・セッションEJBのホストになる場合は、WebLogic Serverインスタンスのレプリケーション・グループを作成して、セッション状態のレプリカのホストにすることができます。
各レプリケーション・グループに参加させるサーバー・インスタンスと、各サーバー・インスタンスの優先レプリケーション・グループを決定する手順については、「レプリケーション・グループの使用」を参照してください。
次に、個々のWebLogic Serverインスタンスについて、次の手順に従ってレプリケーション・グループを構成します。
WebLogic Serverインスタンスのレプリケーション・グループを構成するには:
WebLogic Server管理コンソールを起動します。
「環境」>「サーバー」の順に選択します。
表で、構成するサーバーの名前を選択します。
「クラスタ」ページを選択します。
クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。
次の属性フィールドに値を入力します。
レプリケーション・グループ
: このサーバー・インスタンスが属するレプリケーション・グループ名を入力します。
セカンダリ・プリファレンス・グループ
: このサーバー・インスタンスを、レプリケートされたHTTPセッション状態のホストにする場合に使用するレプリケーション・グループ名を入力します。
「保存」をクリックして変更を保存します。
左上隅にある「変更のアクティブ化」をクリックして、変更をアクティブ化します。
WebLogic Serverでは、必要に応じて移行可能ターゲットを構成できます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。つまり、移行可能ターゲットを使用することで、一緒に移行する必要のある固定サービスをグループ化できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべてのサービスが移行されます。固定サービスには、JMS関連サービス(JMSサーバー、SAFエージェント、パス・サービス、永続ストアなど)、とJTAトランザクション・リカバリ・サービスが含まれます。
移行可能ターゲットを使用する場合、クラスタ内でサービスをデプロイまたはアクティブ化する前に、ターゲット・サーバー・リストを構成します。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内で使用可能などのWebLogic Serverインスタンスにでも移行できます。移行可能ターゲットの詳細は、「クラスタ内の移行可能ターゲットの理解」を参照してください。
WebLogic Serverにデプロイする前にアプリケーションをパッケージ化する必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項にあるパッケージ化に関するトピックを参照してください。
WebLogic Serverでクラスタリングするオブジェクトは、均一にデプロイすることをお薦めします。均一なデプロイメントが確実に行われるようにするには、ターゲットを選択するときに、クラスタ内の個別のWebLogic Serverインスタンスではなくクラスタ名を使用します。
コンソールでは、レプリカ対応オブジェクトのクラスタへのデプロイが自動化されます。クラスタにアプリケーションまたはオブジェクトをデプロイすると、コンソールでは、それらがクラスタのすべてのメンバー(管理サーバーのローカル・メンバーとリモート・マシンにあるメンバーの両方)に自動的にデプロイされます。クラスタリング環境でのアプリケーションのデプロイメントの詳細は、「クラスタの構成方法」を参照してください。デプロイメントに関する全般的なトピックは、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
注意: 管理コンソールを使用してアプリケーションをクラスタにデプロイするときは、クラスタ内のすべてのサーバー・インスタンスを動作させておくことをお薦めします。 |
クラスタのすべてのメンバーでなく、1つのサーバー・インスタンスにアプリケーションをデプロイする形態を固定デプロイメントと呼びます。固定デプロイメントでは特定のサーバー・インスタンスがターゲットとなりますが、デプロイメント・プロセスの間は、クラスタ内のすべてのサーバー・インスタンスが動作していなければなりません。
固定デプロイメントは、管理コンソールから実行することも、weblogic.Deployer
を使用してコマンド・ラインから実行することもできます。
管理コンソールを使用するか、またはweblogic.Deployer
を使用してコマンド・ラインからデプロイメントを取り消すことができます。
コマンド・シェルから、次の構文を使用してデプロイメント・タスクIDを取り消します。
java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag
デプロイ済のアプリケーションを管理コンソールで表示するには:
管理コンソールで「デプロイメント」を選択します。
表にデプロイ済アプリケーションのリストを表示します。
次の項では、移行可能サービスをデプロイ、アクティブ化、および移行するためのガイドラインと手順を示します。
ここで作成する移行可能ターゲットは、移行可能サービスのホストとなることができるクラスタ内のサーバー・インスタンスのスコープを定義します。後からターゲット・サーバー・リストの内部でサービスを移行するためには、移行可能ターゲットとして登録されているいずれかのサーバー・インスタンス上で固定サービスをデプロイまたはアクティブ化する必要があります。次の手順に従って移行可能ターゲット上にJMSサービスをデプロイするか、後から移行できるようにJTAトランザクション・リカバリ・システムをアクティブ化します。
注意: 移行可能ターゲットを構成していない場合は、単純にJMSサーバーをクラスタ内の任意のWebLogic Serverインスタンスにデプロイします。その後、クラスタ内の任意の別サーバー・インスタンスにJMSサーバーを移行できます(移行可能ターゲットは使用しません)。 |
はじめに、「固定サービス用の移行可能ターゲットを構成する」の指示に従って、クラスタの移行可能ターゲットを作成します。次に、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックの説明に従って、JMS関連サービスを移行可能ターゲットにデプロイします。
JTAリカバリ・サービスは、クラスタの移行可能ターゲットとして登録されているいずれかのサーバー・インスタンス上で自動的に起動されます。選択したサーバー・インスタンスにサービスをデプロイする必要はありません。
JTA移行可能ターゲットを構成しない場合、WebLogic Serverはクラスタ内で使用可能な任意のWebLogic Serverインスタンス上でサービスをアクティブ化します。JTAサービスのホストである現在のサーバー・インスタンスを変更するには、「ターゲット・サーバー・インスタンスに固定サービスを移行する」で示されている手順に従います。
移行可能サービスをデプロイした後で、管理コンソールを使用して、サービスを手動でクラスタ内の別のサーバー・インスタンスに移行できます。サービスに対して移行可能ターゲットが構成されている場合、移行可能ターゲットとして登録されているサーバー・インスタンスであれば、動作していない場合でもそのサーバー・インスタンスにサービスを移行することができます。移行可能ターゲットを構成しない場合、クラスタ内のその他の任意のサーバー・インスタンスにサービスを移行できます。
停止しているサーバー・インスタンスにサービスを移行する場合、そのサーバー・インスタンスは次回の起動時に直ちにサービスをアクティブ化します。動作中のWebLogic Serverインスタンスにサービスを移行する場合、移行は直ちに有効になります。
はじめに、「移行可能ターゲット・サーバー・インスタンスにJMSをデプロイする」の指示に従って、固定サービスをクラスタにデプロイします。次に、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの該当する指示に従って、管理コンソールを使用して固定サービスを移行します。
コンソール・ヘルプでは説明されていない追加手順を次に示します。
現在のサーバーに管理サーバーからアクセスできない場合は、管理コンソールに次のメッセージが表示されます。
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.
このメッセージが表示される場合は、「現在アクティブなホストがない場合の移行」の手順を行ってください。
宛先サーバーが停止している場合は、管理コンソールがその停止しているサーバー・インスタンスを通知し、移行を続行するかどうか尋ねます。停止しているサーバー・インスタンスへの移行を続けるには「続行」を、移行を中止して別のサーバー・インスタンスを選択するには「取消し」をそれぞれクリックします。
サーバー・インスタンスの構成によっては、移行プロセスを完了するまでに数分以上かかる場合があります。ただし、移行タスクを処理しながら、管理コンソールで他の作業を続けることができます。後から移行のステータスを確認するには、左ペインで「タスク」ノードをクリックし、ターゲット・ドメインに対して実行中であるタスクを表示します。次に、移行タスクの説明を選択して、現在の状況を表示します。
移行可能サービスのアクティブ・サーバーだったクラスタ化されている管理対象サーバーがクラッシュしたか、アクセス不能になった場合は、この移行手順を使用します。
この手順では、障害の発生した管理対象サーバーの構成キャッシュをパージします。キャッシュをパージする目的は、障害の発生したサーバー・インスタンスが再び利用可能になったときに、別の管理対象サーバーに移行したサービスが再デプロイされないようにすることです。キャッシュをパージすると、サービスのアクティブなホストだった管理対象サーバーが再び起動したときに、そのサーバーによってローカルの古い構成データが使用されるリスクがなくなります。
マシンのネットワークとの接続を完全に切断します。管理サーバーやクライアント・トラフィックからアクセスできないようにする必要があります。マシンにデュアル・ポート・ディスクがある場合は、それを切断します。
移行可能なサービスを別のマシン上の管理対象サーバー・インスタンスに移行します。管理サーバーは動作している必要があります。動作していれば、移行を調整し、アクティブ化表を更新できます。
移行にコマンド・ラインを使用する場合は、-sourcedown
フラグを使用します。
コンソールを使用する場合は、ソース・サーバーが再起動しないよう確認する必要があります。
この時点で、移行可能サービスは別のマシンの別の管理対象サーバーで利用可能になっています。次の手順は、時間があるときに行ってください。
障害の発生したマシンで必要な修理または保守を行います。
マシンを再起動します。ただし、ネットワークへの接続は行いません。
ノード・マネージャがサービスまたはデーモンとして起動し、マシン上の管理対象サーバーを起動しようとします。
管理対象サーバーの独立が有効な場合、管理対象サーバーは管理サーバーに接続できなくても起動します。
管理対象サーバーの独立が無効な場合、管理対象サーバーは管理サーバーに接続できないため起動しません。
マシンをネットワークおよび共有ストレージ(デュアル・ポート・ディスクなど)に再接続します。
ノード・マネージャ・デーモン/サービスを再起動するか、マシンを再起動して、残りのすべての管理対象サーバーを起動します。
無効にした管理対象サーバーを起動します。これは、ノード・マネージャによって実行される再起動ではなく通常の起動です。管理サーバーは動作していて、アクセス可能である必要があります。管理サーバーがその状態であれば、管理対象サーバーは管理サーバー上にある移行可能サービスのアクティブ化表と同期をとって、それが現在は移行可能サービスのアクティブなホストでないことを認識できます。
WebLogic Serverでは、HTTPセッション状態をメモリー内にレプリケートすることによって、サーブレットおよびJSPの自動フェイルオーバーを行います。
注意: WebLogic Serverでは、ファイル・ベースまたはJDBCベースの永続性メカニズムを利用して、サーブレットまたはJSPのHTTPセッション状態を保持することもできます。それぞれの永続性メカニズムの詳細は、『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> <persistent-store-type>replicated</persistent-store-type> </session-descriptor>
次の項では、クラスタの特殊な構成を行うときに役に立つヒントを示します。
最適なパフォーマンスを得るために、WebLogic Serverインスタンスのホストであるマシン上では、pure-Java実装ではなくネイティブのソケット・リーダー実装を使用することをお薦めします。
ホスト・マシンでpure-Javaソケット・リーダー実装を使用しなければならない場合でも、サーバー・インスタンスおよびクライアント・マシンごとにソケット・リーダー・スレッドの数を適切に構成することによって、ソケット通信のパフォーマンスを向上させることができます。
クラスタ内でのIPソケットの使用方法と、ネイティブ・ソケット・リーダー・スレッドが最適なパフォーマンスをもたらす理由については、「IPソケットを使用したピア・ツー・ピア通信」および「ソケット経由のクライアント通信」を参照してください。
クラスタで必要なソケット・リーダー・スレッドの数を決定する方法については、「ソケットの使用数を確定する」を参照してください。複数層クラスタ・アーキテクチャにサーブレット・クラスタをデプロイしている場合、「複数層アーキテクチャの構成に関する考慮事項」で説明しているように、これは必要なソケットの数に影響します。
次の項では、ホスト・マシンに対してネイティブ・ソケット・リーダー・スレッドを構成する方法と、ホストおよびクライアント・マシンに対してリーダー・スレッドの数を設定する方法について説明します。
ネイティブのソケット・リーダー・スレッド実装を使用するようにWebLogic Serverインスタンスを構成するには:
WebLogic Server管理コンソールを起動します。
「環境」>「サーバー」の順に選択します。
構成するサーバー・インスタンスの名前を選択します。
クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。
「構成」>「チューニング」の順に選択します。
「ネイティブIOの有効化」
チェック・ボックスを選択します。
「保存」をクリックします。
コンソールの左上隅にある「変更のアクティブ化」をクリックして、変更をアクティブ化します。
デフォルトでは、WebLogic Serverインスタンスは起動時に3つのソケット・リーダー・スレッドを作成します。クラスタ・システムがピーク時に4つ以上のソケットを使用する可能性がある場合は、ソケット・リーダー・スレッド数を増やします。
WebLogic Server管理コンソールを起動します。
「環境」>「サーバー」の順に選択します。
構成するサーバー・インスタンスの名前を選択します。
クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。
「構成」>「チューニング」の順に選択します。
「ソケット・リーダー」
フィールドでJavaリーダー・スレッドの割合を編集します。Javaソケット・リーダーの数が、合計実行スレッド数(「実行スレッド」
フィールドに表示)の割合として計算されます。
「保存」をクリックして変更を保存します。
コンソールの左上隅にある「変更のアクティブ化」をクリックして、変更をアクティブ化します。
クライアント・マシン上では、クライアントを実行するJava仮想マシン(JVM)内でソケット・リーダーの数を構成できます。クライアントのJavaコマンド・ラインで-Dweblogic.ThreadPoolSize
=valueオプションおよび-Dweblogic.ThreadPoolPercentSocketReaders
=valueオプションを定義してソケット・リーダーを指定します。
クラスタがWAN内の複数のサブネットにまたがっている場合、マルチキャスト・パケットが最終の宛先に到達する前にルーターがパケットを破棄しないように、クラスタのマルチキャスト存続時間(TTL)パラメータの値を十分に大きく設定する必要があります。マルチキャスト存続時間パラメータには、パケットが破棄されるまでにマルチキャスト・メッセージが経由できるネットワーク・ホップ数を設定します。マルチキャスト存続時間パラメータを適切に設定することにより、クラスタ内のサーバー・インスタンス間で送受信されるマルチキャスト・メッセージが消失するリスクが少なくなります。
マルチキャスト・メッセージが確実に転送されるようにネットワーク・トポロジを設計する方法については、「クラスタがWAN内の複数のサブネットにまたがる場合」を参照してください。
クラスタのマルチキャスト存続時間(TTL)を構成するには、管理コンソールで、ターゲットとなるクラスタのマルチキャスト・ページにある「マルチキャストTTL」
の値を変更します。次のconfig.xml
の抜粋部分は、マルチキャスト存続時間(TTL)値に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
の値を32K単位で増やして、その変更の効果を評価します。
必要な場合以外は、udp_max_buf
の値を変更しないでください。udp_max_buf
を変更する前に、『Solaris Tunable Parameters Reference Manual』(http://docs.oracle.com/docs/cd/E19253-01/817-0404/chapter4-70/index.html
)の「Internet Protocol Suite Tunable Parameters」章のUDP Parameters with Additional Cautionsに記載されているSunの警告をご確認ください。
WebLogic Serverでは、クラスタ間で送信されるマルチキャスト・メッセージを暗号化できます。管理コンソールで「環境」>「クラスタ」>クラスタ名>「マルチキャスト」ノードに移動し、「詳細」
を選択して「マルチキャスト・データの暗号化を有効にする」を選択することで、このオプションを有効にできます。
マルチキャスト・メッセージのデータ部分のみが暗号化されます。マルチキャスト・ヘッダーの情報は暗号化されません。
次の場合にマシン名を構成します。
クラスタが複数のマシンにまたがっており、複数のサーバー・インスタンスがクラスタ内の各マシンで動作する、あるいは
管理サーバーをホストしないマシンでノード・マネージャを実行する
WebLogic Serverでは、構成されたマシン名を使用して、2つのサーバー・インスタンスが物理的に同じハードウェアに存在しているかどうかを調べることができます。マシン名は一般に、複数のサーバー・インスタンスのホストとなるマシンで使用されます。そのようなインストール用のマシン名を定義していない場合、各インスタンスは物理的に異なるハードウェア上に存在するものとして扱われます。このことは、「レプリケーション・グループの使用」で説明しているように、セカンダリHTTPセッション状態のレプリカのホストになるサーバー・インスタンスの選択に悪影響を与えることがあります。
複数層アーキテクチャのクラスタの構成については、「複数層アーキテクチャの構成に関する考慮事項」のガイドラインを参照してください。
デフォルト構成のWebLogic Serverでは、クライアント側のCookieを使用して、クライアントのサーブレット・セッション状態のホストであるプライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスが追跡されます。クライアントのブラウザでCookieが無効になっている場合、WebLogic ServerではURL書換えによってもプライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスを追跡できます。URL書換えを利用する場合は、クライアント・セッション状態の両方の場所が、クライアントとプロキシ・サーバーの間で渡されるURLに挿入されます。この機能をサポートするには、WebLogic ServerクラスタでURL書換えを有効にする必要があります。URL書換えを有効にする方法は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のCookieにかわるURL書換えの使用に関する項を参照してください。