| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0) E90317-02 |
|
 前 |
 次 |
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の値のマルチキャスト・アドレスを使用することはできません。
クラスタ内のサーバー・インスタンスは、マルチキャストを使用して互いに通信します。具体的には、マルチキャストを使用して各自のサービスを全体に通知し、インスタンスが継続的に使用可能であることを知らせるハートビートを一定間隔で発行します。
クラスタのマルチキャスト・アドレスは、クラスタ通信以外の目的には使用しないことをお薦めします。クラスタのマルチキャスト・アドレスが存在するマシンが、マルチキャスト通信を使用するクラスタ外部のプログラムのホストであるか、またはそのようなプログラムによってアクセスされる場合、そのマルチキャスト通信では必ず、クラスタのマルチキャスト・ポートとは異なるポートを使用してください。
「クラスタ・アーキテクチャ」で説明しているような、クラスタ間にファイアウォールを配置する推奨複数層アーキテクチャを設定している場合、専用のマルチキャスト・アドレスが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属性は最小値の1に設定できます。この属性は、WebLogic ServerがEJBでの使用のためにクラスタ・アドレスを動的に構築する場合に使用されます。WebLogic Serverクラスタでは、クラスタ・アドレスは、リクエストされたURLのホスト名部分を構築するためにエンティティBeanおよびステートレスBeanで使用されます。クラスタを構成するときに、クラスタ・アドレスを明示的に定義できます。そうしなかった場合、WebLogic Serverでは新しい要求ごとにクラスタ・アドレスを動的に生成します。WebLogic Serverによるクラスタ・アドレスの動的生成を有効にする方法が、システム管理上最も簡単かつ便利であり、開発環境および本番環境の両方に適しています。
NumberOfServersInClusterAddressの値は、WebLogic Server管理コンソールの「環境」→「クラスタ」→「Cluster@Name」→「構成」→「全般」ページで変更できます。
クラスタ内で使用可能な管理対象サーバーの数が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のインストールと構成』の「Oracle WebLogic Serverインストールの計画」を参照してください。
クラスタを1台のマシン上で実行する場合、/Oracleディレクトリの下に、クラスタ化されたすべてのインスタンスに使用される単一のWebLogic Serverをインストールします。
ネットワーク上のリモート・マシンについては、各マシンに同じバージョンのWebLogic Serverをインストールします。各マシンは:
永続的に割り当てられる静的なIPアドレスを持つ必要があります。クラスタリング環境では、動的に割り当てられるIPアドレスは使用できません。
クライアントからアクセス可能であることが必要です。サーバー・インスタンスとクライアントの間にファイアウォールがある場合、各サーバー・インスタンスには、クライアントから到達できるパブリックな静的IPアドレスを割り当てる必要があります。
すべてのマシンが同じローカル・エリア・ネットワーク(LAN)上にあり、IPマルチキャストによって通信できることが必要です。
クラスタ化ドメインの作成方法は複数あります。「クラスタを構成する方法」を参照してください。
クラスタの作成手順については、次を使用してください。
構成ウィザード。ドメインの作成手順は、構成ウィザードによるWebLogicドメインの作成のWebLogicドメインの作成を参照してください。クラスタの構成方法は、クラスタを参照してください。
WebLogic Server管理コンソールの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの作成と構成を参照してください。
クラスタを起動するには複数の方法があります。コマンド行インタフェース、必要なコマンドを含むスクリプト、およびノード・マネージャなどを使用できます。
注意:
ノード・マネージャを使用すると、サーバーを起動したり、障害発生後にサーバーを再起動したりするプロセスが簡単になります。
ノード・マネージャを使用するには、最初に、クラスタ内の管理対象サーバーをホストする各マシンでノード・マネージャ・プロセスを構成する必要があります。「ノード・マネージャを構成する」を参照してください
どの方法を使用してクラスタを起動する場合でも、最初にクラスタ内の管理サーバーを起動し、次に管理対象サーバーを起動します。
次の手順に従って、コマンド・シェルからクラスタを起動します。各サーバー・インスタンスを別々のコマンド・シェルで起動することに注意してください。
ノード・マネージャは、WebLogic Serverで提供されるスタンドアロンプログラムであり、管理サーバーとは別のマシンにある管理対象サーバーの起動に利用できます。また、ノード・マネージャには、クラスタ内の管理対象サーバーの可用性の向上に役立つ機能もあります。ノード・マネージャの構成および使用の手順は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
この項の手順に従うと、EJBおよびRMIオブジェクトのロード・バランシング・アルゴリズムを選択できます。
他のものを明示的に指定しない場合、WebLogic Serverはクラスタ化されるオブジェクトのスタブに対して、デフォルトのロード・バランシング戦略であるラウンドロビン・アルゴリズムを使用します。それ以外のロード・バランシング方式については、「EJBとRMIオブジェクトのロード・バランシング」を参照してくださいデフォルトのロード・バランシング・アルゴリズムを変更するには:
「デフォルトのロード・バランス・アルゴリズム」フィールドに、使用するロード・バランシング・アルゴリズムを入力します。「サービス期間しきい値」フィールドに任意の値を入力します。ClusterMBeanのReplicationTimeoutEnabledをtrueに設定することで、ReplicationManagerの呼出し時にタイムアウト・オプションを有効にできます。
タイムアウト値はマルチキャスト・ハートビートのタイムアウト値と同じです。マルチキャストのタイムアウト値はカスタマイズできますが、ReplicationManagerのタイムアウト値は変更できません。この制限があるのは、ReplicationManagerのタイムアウトはクラスタのメンバーシップに影響しないからです。マルチキャスト・ハートビートがなくなるとそのメンバーはクラスタから削除され、ReplicationManagerの呼出しがタイムアウトすると接続先の新しいセカンダリ・サーバーが選択されます。
注意:
クラスタ・メンバーはマルチキャスト・ハートビートを送信し続けることができますが、レプリケーション・リクエストは処理できません。そのため、セカンダリ・サーバーの分散が不均一になるおそれがあります。このような状態になると、警告メッセージがサーバー・ログに記録されます。
パッシブなCookieの永続性をサポートするロード・バランサは、セッションをホストするWebLogic Serverインスタンスをクライアントと関連付けるためにWebLogic ServerセッションCookieの情報を使用できます。セッションCookieには、ロード・バランサがセッションのプライマリ・サーバー・インスタンスを識別する文字列が含まれています。
外部ロード・バランサ、セッションCookieの永続性、およびWebLogic ServerセッションCookieの詳細は、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください
クラスタで動作するようにロード・バランサを構成するには、ロード・バランサの機能を使用して、文字列定数のオフセットと長さを定義します。
セッションCookieのセッションID部分がデフォルト長の52バイトであると想定して、ロード・バランサで次を設定します。
文字列のオフセットは、ランダム・セッションID長に区切り文字用の1バイトを加えた53バイト
文字列の長さは10バイト
アプリケーションまたは環境によって、ランダム・セッションIDの長さをデフォルト値の52バイト以外に変更しなければならない場合は、それに応じて文字列のオフセットをロード・バランサで設定してください。文字列のオフセットは、セッションIDの長さに、区切り文字用の1バイトを加えたものと同じ値にする必要があります。
注意:
BIG-IPロード・バランサのベンダー固有の構成手順については、「クラスタに関するBIG-IPハードウェアの構成」を参照してください。
プロキシ・プラグインを使用してサーブレットおよびJSPのロード・バランシングを行う場合は、この項で示す手順を参考にしてください。プロキシ・プラグインは、リクエストをWebサーバーからクラスタ内のWebLogic Serverインスタンスに中継し、プロキシを経由するHTTPリクエストのロード・バランシングとフェイルオーバーを可能にします。
プロキシ・プラグインによるロード・バランシングの詳細は、「プロキシ・プラグインによるロード・バランシング」を参照してくださいプロキシ・プラグインによる接続とフェイルオーバーの詳細は、サーブレットとJSPのレプリケーションとフェイルオーバーおよびクラスタ化されたサーブレットとJSPへのプロキシ経由のアクセスを参照してください
WebサーバーとしてWebLogic Serverを使用する場合、「HttpClusterServletを設定する」の指示に従って、HttpClusterServletを設定します
サポートされているサード・パーティ製Webサーバーを使用する場合、『Oracle WebLogic Serverプロキシ・プラグインの使用』の手順に従って、その製品に固有のプラグインを設定します(サポートされている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」を参照してください
WLProxyPassThrough属性を有効化すると、一連のプロキシおよびWLProxySSLPassThrough属性を介してヘッダーを渡すことが可能になるため、SSLの使用がWebLogic Serverに渡されます。これらの属性の詳細は、Oracle WebLogic Serverプロキシ・プラグインの使用のWeb Serverプラグインのための汎用パラメータを参照してください。
必要に応じて、追加のパラメータを定義します。主なパラメータのリストについては、表10-1を参照してください。完全なリストについては、Oracle WebLogic Serverプロキシ・プラグインの使用のWebサーバー・プラグインのパラメータを参照してください。「プロキシ・サーブレットのデプロイメント・パラメータ」の構文の指示に従ってください
サーブレットのweblogic.xmlデプロイメント記述子ファイルを作成します。このファイルは、Webアプリケーション・ディレクトリの\WEB-INFサブディレクトリに配置する必要があります。
<weblogic-web-app>スタンザの<context-root>要素をフォワード・スラッシュ文字(/)に設定して、プロキシ・サーブレットをプロキシ・マシンにある管理対象サーバーのデフォルトWebアプリケーションとして割り当てます。例については、「サンプルのweblogic.xml」を参照してください
WebLogic Server管理コンソールで、プロキシ・サーバー・マシン上の管理対象サーバーにサーブレットをデプロイします。詳細は、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でプロキシ・サーブレットの動作を構成するための主なパラメータを開始する前にに示します。
プロキシ・サーブレットのパラメータは、Apache、MicrosoftおよびNetscape Webサーバー用のWebLogic Serverプラグインの構成に使用するパラメータと同じです。プロキシ・サーブレットおよびサード・パーティ製Webサーバー用のプラグインを構成するパラメータの完全なリストは、『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>
|
|
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プロキシ・プラグインの使用』の「Webサーバー・プラグインのパラメータ」を参照してください。
WebLogic Serverでは、HTTPセッション状態をメモリー内にレプリケートすることによって、サーブレットおよびJSPの自動フェイルオーバーを行います。それ以外にも、レプリケーション・グループを使用することにより、セカンダリ状態が置かれる場所を独自に制御することができます。レプリケーション・グループは、セッション状態のレプリカの格納先として使用する、クラスタ内のサーバー・インスタンスの優先順を定義するリストです。
クラスタがサーブレットまたはステートフル・セッションEJBのホストになる場合は、WebLogic Serverインスタンスのレプリケーション・グループを作成して、セッション状態のレプリカのホストにすることができます。
各レプリケーション・グループに参加させるサーバー・インスタンスと、各サーバー・インスタンスの優先レプリケーション・グループを決定する手順については、「レプリケーション・グループの使用」を参照してください
次に、個々のWebLogic Serverインスタンスについて、次の手順に従ってレプリケーション・グループを構成します。
WebLogic Serverインスタンスのレプリケーション・グループを構成するには:
WebLogic Serverでは、必要に応じて移行可能ターゲットを構成できます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。つまり、移行可能ターゲットを使用することで、一緒に移行する必要のある固定サービスをグループ化できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべてのサービスが移行されます。固定サービスには、JMS関連サービス(JMSサーバー、SAFエージェント、パス・サービス、永続ストアなど)、とJTAトランザクション・リカバリ・サービスが含まれます。
移行可能ターゲットを使用する場合、クラスタ内でサービスをデプロイまたはアクティブ化する前に、ターゲット・サーバー・リストを構成します。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内で使用可能などのWebLogic Serverインスタンスにでも移行できます。「クラスタ内の移行可能ターゲットの理解」を参照してください
WebLogic Serverにデプロイする前にアプリケーションをパッケージ化する必要があります。『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項にあるパッケージ化に関するトピックを参照してください。
WebLogic Serverでクラスタリングするオブジェクトは、均一にデプロイすることをお薦めします。均一なデプロイメントが確実に行われるようにするには、ターゲットを選択するときに、クラスタ内の個別のWebLogic Serverインスタンスではなくクラスタ名を使用します。クラスタが動的または混在クラスタ・タイプの場合、クラスタ全体で1つのインスタンスが必要か、クラスタ・メンバーごとに1つのインスタンスが必要かに基づき、シングルトン・デプロイメントまたは分散デプロイメントを選択できます。
コンソールでは、レプリカ対応オブジェクトのクラスタへのデプロイが自動化されます。クラスタにアプリケーションまたはオブジェクトをデプロイすると、コンソールでは、それらがクラスタのすべてのメンバー(管理サーバーのローカル・メンバーとリモート・マシンにあるメンバーの両方)に自動的にデプロイされます。クラスタリング環境でのアプリケーションのデプロイメントの詳細は、「クラスタの構成方法」を参照してくださいデプロイメントに関する全般的なトピックは、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
注意:
WebLogic Server管理コンソールを使用してアプリケーションをクラスタにデプロイするときは、クラスタ内のすべてのサーバー・インスタンスを動作させておく必要があります。
クラスタのすべてのメンバーでなく、1つのサーバー・インスタンスにアプリケーションをデプロイする形態を固定デプロイメントと呼びます。固定デプロイメントでは特定のサーバー・インスタンスがターゲットとなりますが、デプロイメント・プロセスの間は、クラスタ内のすべてのサーバー・インスタンスが動作していなければなりません。
固定デプロイメントは、管理コンソールから実行することも、weblogic.Deployerを使用してコマンド行から実行することもできます。
デプロイメントは、WebLogic Server管理コンソールを使用して取り消すか、weblogic.Deployerを使用してコマンド行から取り消すことができます。
コマンド・シェルから、次の構文を使用してデプロイメント・タスクIDを取り消します。
java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag
デプロイ済のアプリケーションをWebLogic Server管理コンソールで表示するには:
デプロイ済のアプリケーションをWebLogic Server管理コンソールからアンデプロイするには:
次の項では、移行可能サービスをデプロイ、アクティブ化、および移行するためのガイドラインと手順を示します。
ここで作成する移行可能ターゲットは、移行可能サービスのホストとなることができるクラスタ内のサーバー・インスタンスのスコープを定義します。後からターゲット・サーバー・リストの内部でサービスを移行するためには、移行可能ターゲットとして登録されているいずれかのサーバー・インスタンス上で固定サービスをデプロイまたはアクティブ化する必要があります。次の手順に従って移行可能ターゲット上にJMSサービスをデプロイするか、後から移行できるようにJTAトランザクション・リカバリ・システムをアクティブ化します。
注意:
移行可能ターゲットを構成していない場合は、単純にJMSサーバーをクラスタ内の任意のWebLogic Serverインスタンスにデプロイします。その後、クラスタ内の任意の別サーバー・インスタンスにJMSサーバーを移行できます(移行可能ターゲットは使用しません)。
はじめに、「固定サービス用の移行可能ターゲットを構成する」の指示に従って、クラスタの移行可能ターゲットを作成します。次に、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックの説明に従って、JMS関連サービスを移行可能ターゲットにデプロイします。
JTAリカバリ・サービスは、クラスタの移行可能ターゲットとして登録されているいずれかのサーバー・インスタンス上で自動的に起動されます。選択したサーバー・インスタンスにサービスをデプロイする必要はありません。
JTA移行可能ターゲットを構成しない場合、WebLogic Serverはクラスタ内で使用可能な任意のWebLogic Serverインスタンス上でサービスをアクティブ化します。JTAサービスのホストである現在のサーバー・インスタンスを変更するには、「ターゲット・サーバー・インスタンスに固定サービスを移行する」で示されている手順に従います
移行可能サービスをデプロイした後で、WebLogic Server管理コンソールを使用して、サービスを手動でクラスタ内の別のサーバー・インスタンスに移行できます。サービスに対して移行可能ターゲットが構成されている場合、移行可能ターゲットとして登録されているサーバー・インスタンスであれば、動作していない場合でもそのサーバー・インスタンスにサービスを移行することができます。移行可能ターゲットを構成しない場合、クラスタ内のその他の任意のサーバー・インスタンスにサービスを移行できます。
停止しているサーバー・インスタンスにサービスを移行する場合、そのサーバー・インスタンスは次回の起動時に直ちにサービスをアクティブ化します。動作中のWebLogic Serverインスタンスにサービスを移行する場合、移行は直ちに有効になります。
はじめに、「移行可能ターゲット・サーバー・インスタンスにJMSをデプロイする」の指示に従って、固定サービスをクラスタにデプロイします。次に、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの該当する指示に従って、WebLogic Server管理コンソールを使用して固定サービスを移行します。
コンソール・ヘルプでは説明されていない追加手順を次に示します。
移行可能サービスのアクティブ・サーバーだったクラスタ化されている管理対象サーバーがクラッシュしたか、アクセス不能になった場合は、この移行手順を使用します。
この手順では、障害の発生した管理対象サーバーの構成キャッシュをパージします。キャッシュをパージする目的は、障害の発生したサーバー・インスタンスが再び利用可能になったときに、別の管理対象サーバーに移行したサービスが再デプロイされないようにすることです。キャッシュをパージすると、サービスのアクティブなホストだった管理対象サーバーが再び起動したときに、そのサーバーによってローカルの古い構成データが使用されるリスクがなくなります。
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インスタンスを構成するには:
「ネイティブIOの有効化」チェック・ボックスを選択します。デフォルトでは、WebLogic Serverインスタンスは起動時に3つのソケット・リーダー・スレッドを作成します。クラスタ・システムがピーク時に4つ以上のソケットを使用する可能性がある場合は、ソケット・リーダー・スレッド数を増やします。
「ソケット・リーダー」フィールドでJavaリーダー・スレッドの割合を編集します。Javaソケット・リーダーの数が、合計実行スレッド数(「実行スレッド」フィールドに表示)の割合として計算されます。クラスタがWAN内の複数のサブネットにまたがっている場合、マルチキャスト・パケットが最終の宛先に到達する前にルーターがパケットを破棄しないように、クラスタのマルチキャスト存続時間(TTL)パラメータの値を十分に大きく設定する必要があります。マルチキャスト存続時間パラメータには、パケットが破棄されるまでにマルチキャスト・メッセージが経由できるネットワーク・ホップ数を設定します。マルチキャスト存続時間パラメータを適切に設定することにより、クラスタ内のサーバー・インスタンス間で送受信されるマルチキャスト・メッセージが消失するリスクが少なくなります。
マルチキャスト・メッセージが確実に転送されるようにネットワーク・トポロジを設計する方法については、「クラスタがWAN内の複数のサブネットにまたがる場合」を参照してください。
クラスタのマルチキャスト存続時間(TTL)を構成するには、WebLogic Server管理コンソールで、ターゲットとなるクラスタの「マルチキャスト」ページにある「マルチキャスト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管理コンソールで「環境」→「クラスタ」→「cluster_name」→「マルチキャスト」ノードに移動し、「詳細」オプションを選択して、「マルチキャスト・データの暗号化を有効にする」を選択することで、このオプションを有効にできます。
マルチキャスト・メッセージのデータ部分のみが暗号化されます。マルチキャスト・ヘッダーの情報は暗号化されません。
次の場合にマシン名を構成します。
クラスタが複数のマシンにまたがっており、複数のサーバー・インスタンスがクラスタ内の各マシンで動作する、あるいは
管理サーバーをホストしないマシンでノード・マネージャを実行する
WebLogic Serverでは、構成されたマシン名を使用して、2つのサーバー・インスタンスが物理的に同じハードウェアに存在しているかどうかを調べることができます。マシン名は一般に、複数のサーバー・インスタンスのホストとなるマシンで使用されます。そのようなインストール用のマシン名を定義していない場合、各インスタンスは物理的に異なるハードウェア上に存在するものとして扱われます。このことは、「レプリケーション・グループの使用」で説明しているように、セカンダリHTTPセッション状態のレプリカのホストになるサーバー・インスタンスの選択に悪影響を与えることがあります
デフォルト構成のWebLogic Serverでは、クライアント側のCookieを使用して、クライアントのサーブレット・セッション状態のホストであるプライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスが追跡されます。クライアントのブラウザでCookieが無効になっている場合、WebLogic ServerではURL書換えによってもプライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスを追跡できます。URL書換えを利用する場合は、クライアント・セッション状態の両方の場所が、クライアントとプロキシ・サーバーの間で渡されるURLに挿入されます。この機能をサポートするには、WebLogic ServerクラスタでURL書換えを有効にする必要があります。URL書換えを有効にする方法は、Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発のCookieにかわるURL書換えの使用を参照してください。
