WebLogic クラスタの管理



\| WebLogic Server ホーム \| WebLogic Server クラスタ \| 前へ \| 次へ \| 目次 \| 索引 \| PDF 版

WebLogic クラスタの管理

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

始める前に

この節では、WebLogic Server クラスタをセットアップするための情報および前提となる作業の概要を示します。

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

クラスタ構成で WebLogic Server インスタンスをインストールするには、正規のクラスタライセンスが必要です。クラスタライセンスをお持ちでない場合は、BEA の販売担当者にお問い合わせください。

コンフィグレーションプロセスを理解する

クラスタのコンフィグレーションプロセスと、コンフィグレーション作業の実施要領についての基本を理解していれば、この節で示す情報を最も有効に活用できます。

WebLogic Server 6.1 クラスタのすべてのコンフィグレーションは Administration Console を使用して行います。クラスタのコンフィグレーション情報は、クラスタを含むドメインの config.xml ファイルに格納されます。Administration Console では、クラスタを構成するインスタンスへのオブジェクトと Web アプリケーションのデプロイメントも管理します。

WebLogic Server 6.1 のコンフィグレーションに関する全般的な情報は、『WebLogic Server 管理者ガイド』を参照してください。

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

どのクラスタアーキテクチャが最もニーズに適しているかを決定します。アーキテクチャ上の重要な決定事項を以下に示します。

すべてのアプリケーション層を 1 つのクラスタにまとめるか、それともアプリケーション層を複数のクラスタに分割するか
クラスタ内のサーバインスタンス間でどのようにして負荷の分散を図るか。以下のような選択肢がある
- WebLogic Server の基本的なロードバランシング機能を使用する
- サードパーティ製のロードバランサを実装する
- アプリケーションの Web 層を 1 台以上のセカンダリ HTTP サーバにデプロイし、プロキシを使用してアプリケーションへのリクエストをそれらのサーバに転送する
1 台以上のファイアウォールを使用して、Web アプリケーションの非武装地帯（DMZ）を定義するか

これらの決定にあたっては、 WebLogic Server クラスタのプランニングを参考にしてください。

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

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

適切なセキュリティトポロジを設定するための基礎を形成するのはセキュリティ上の要件です。さまざまなレベルのアプリケーションセキュリティを実現する各種の代替アーキテクチャについては、クラスタアーキテクチャのセキュリティオプションを参照してください。

注意: 一部のネットワークトポロジはマルチキャスト通信に干渉する可能性があります。WAN 間でクラスタをデプロイしている場合の対処については、 WAN クラスタのマルチキャスト要件を参照してください。

クラスタ内の複数のサーバインスタンスを、ファイアウォールを間に挟んでデプロイすることは避けてください。ファイアウォールを越えてマルチキャストトラフィックをトンネリングすることの影響については、ファイアウォールがマルチキャスト通信を遮断することがあるで説明しています。

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

WebLogic Server をインストールする予定のマシン（この節全体を通じて「ホスト」と呼びます）を特定し、必要なリソースを各マシンが備えていることを確認します。システムおよびソフトウェアの事前要件の一覧については、『インストールガイド』の「WebLogic Server のインストール準備」を参照してください。

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

複数 CPU を備えるマシン上の WebLogic Server インスタンス

BEA WebLogic Server では、1 つのクラスタを構成するサーバインスタンスの数について仕様上の制限はありません。Sun Microsystems, Inc. の Sun Enterprise 10000 など、複数のプロセッサを備える大規模なサーバには、非常に大規模なクラスタや複数のクラスタを収容できます。

ほとんどの場合、WebLogic Server クラスタの規模は、2 基の CPU につき 1 つの WebLogic Server インスタンスの割合でデプロイされるときが最適です。ただし、サーバインスタンスの最適数および分散構成を決定するために、ターゲットの Web アプリケーションを使用して実際のデプロイメントをテストすることをお勧めします。詳細については、『BEA WebLogic Server パフォーマンスチューニングガイド』の「マルチ CPU マシンのパフォーマンスに関する考慮事項」を参照してください。

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

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

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

クラスタのコンフィグレーションプロセスの間、クラスタとそのメンバーのアドレス情報（IP アドレスまたは DNS 名）を指定します。

クラスタ内通信の詳細と、クラスタ内通信によってロードバランシングおよびフェイルオーバが実現されるしくみについては、クラスタ内のサーバの通信を参照してください。

クラスタをセットアップするときは、以下の位置情報を指定する必要があります。

管理サーバ
管理対象サーバ
マルチキャストロケーション

以降の節では、指定が必要な情報と、リソースの識別に用いる手法に影響する各種の要因について説明します。

リスンアドレスの問題の回避

クラスタをコンフィグレーションするとき、クラスタおよびクラスタを構成するサーバインスタンスのアドレス情報は、IP アドレス/DNS 名のどちらで指定してもかまいません。

DNS 名と IP アドレス

DNS 名と IP アドレスのどちらを使うかを決定するときは、クラスタの目的を考慮します。プロダクション環境では、一般に DNS 名の使用が推奨されます。IP アドレスを使用すると、以下の場合に変換エラーが発生する可能性があります。

クライアントがファイアウォールを経由してクラスタに接続する場合
プレゼンテーション層とオブジェクト層の間にファイアウォールがある場合。推奨多層アーキテクチャについての説明にあるように、サーブレットクラスタと EJB クラスタの間にファイアウォールを配置する場合などが相当する。

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

IP アドレスの代わりに DNS 名を使用する方法の詳細については、ファイアウォールに関する制限を参照してください。

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

WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同じでない場合、サーバインスタンスの ExternalDNSName 属性を使用して、サーバインスタンスの外部 DNS 名を定義します。ファイアウォールの外側では、ExternalDNSName はサーバの外部 IP アドレスに変換されます。Administration Console の [サーバ｜コンフィグレーション｜一般] タブを使用してこの属性を設定します。『Administration Console オンラインヘルプ』の「[サーバ] --> [コンフィグレーション] --> [一般]」を参照してください。

ローカルホストの検討事項

サーバインスタンスのリスンアドレスがローカルホストのアドレスとして識別されると、非ローカルプロセスからそのサーバインスタンスに接続することはできません。そのサーバインスタンスをホスティングしているマシンのプロセスのみが、サーバインスタンスに接続できます。サーバインスタンスにローカルホストとしてアクセスしなければならない場合 (ローカルホストに接続する管理スクリプトがある場合など)で、リモートプロセスからもアクセスできるようにしなければならないときは、リスンアドレスを空白にしておきます。空白にしておくと、サーバインスタンスはマシンのアドレスを判断し、そのアドレス上でリスンします。

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

WebLogic Server 環境内にあるコンフィグレーション可能な各リソースに、固有の名前が付いていることを確認します。個々のドメイン、サーバ、マシン、クラスタ、JDBC 接続プール、仮想ホストなどのリソースは、固有の名前を持っていなければなりません。

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

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

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

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

クラスタに参加させる予定の各管理対象サーバの DNS 名または IP アドレスを識別します。

クラスタ内の各管理対象サーバには一意な IP アドレスが必要であり、またリスンポート番号は同じでなければなりません。1 台のマシンが、クラスタ化される複数のサーバインスタンスのホストとなる場合、マルチホーム環境を設定して各サーバインスタンスに別々の IP アドレスを供給する必要があります。

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

クラスタでのマルチキャスト通信専用に使用するアドレスおよびポートを識別します。

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

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

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

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

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

WebLogic Server クラスタのプランニングで説明している推奨多層アーキテクチャを、クラスタ間にファイアウォールを挟む構成でセットアップしている場合、専用のマルチキャストアドレスが 2 つ必要になります。1 つはプレゼンテーション（サーブレット）クラスタ用であり、もう 1 つはオブジェクトクラスタ用です。2 つのマルチキャストアドレスを使用することにより、ファイアウォールがクラスタの通信に干渉しないことが保証されます。

クラスタアドレス

Administration Console を使ってクラスタを構成する際に、そのクラスタ内の管理対象サーバを識別するクラスタアドレスを付けます。

エンティティ Bean およびステートレス Bean 内では、クラスタアドレスを使って、URL のホスト名部分を構成します。クラスタアドレスが設定されていないと、EJB ハンドルが正しく機能しません。

クラスタアドレスは、以下のものとして指定できます。

クラスタ内の管理対象サーバの DNS 名または IP アドレスにマップされるDNS 名。
以下の例に示すような、クラスタ内の管理対象サーバの DNS名または IP アドレスを含むリスト。

DNSName1,DNSName2,DNSName3

IPaddress1,IPaddress2;IPaddress3

プロダクション環境の場合、クラスタアドレスには、クラスタ内の管理対象サーバのホスト名またはアドレスを含む DNS 名を設定することをお勧めします。クラスタ内の管理対象サーバにマップされる DNS 名としてクラスタアドレスを定義しない場合、エンティティ Bean とEJB ハンドルに対してフェイルオーバが機能しません。エンティティ Bean と EJB ハンドルに対するフェイルオーバを参照してください。

プロダクション環境では、アドレスのカンマ区切りリストとしてクラスタアドレスを定義することは推奨されません。

注意: 管理サーバをクラスタに参加させないでください。管理サーバの IP アドレスが、クラスタ全体の DNS 名に含まれないようにしてください。詳細については、管理サーバに関する考慮事項を参照してください。

クラスタの実装手順

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

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

以下、クラスタを実装する作業の一般的な流れを示し、コンフィグレーション時の選択に影響する重要な考慮事項について説明します。実際の作業でのプロセスは、環境ごとに異なる特性やアプリケーションの性質によって異なる場合があります。この節では以下の作業について説明します。

すべてのクラスタ実装ですべての手順を経る必要があるとは限りません。また場合によっては、追加の手順が必要になることがあります。

WebLogic Server をインストールする

まだ、インストールしていない場合は、WebLogic Server をインストールします。マルチホームのクラスタにインストールする場合は、\bea ディレクトリにある WebLogic Server 配布キットを 1 つインストールして、すべてのクラスタ化されたインスタンスで使用します。リモートのネットワーク接続されたマシンにインストールする場合は、各 WebLogic Server ホストにインストールします。

クラスタ化された WebLogic Server インスタンスに対してインストールを行う場合にも、有効なクラスタライセンスが必要になります。詳細については、クラスタライセンスを取得するを参照してください。

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

マシン名を定義する（省略可能）

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

新しい WebLogic Server インスタンスを作成する前に、以下の手順を実行して、サーバインスタンスのホストになる個々のマシンの名前を定義します。

システムの管理サーバを起動します。手順については、『WebLogic Server 管理者ガイド』の「WebLogic 管理サーバの起動」を参照してください。
『WebLogic Server 管理者ガイド』の「Administration Console の起動」にある手順に従って、Administration Console を起動します。
[マシン] ノードを選択します。
[新しい Machine のコンフィグレーション] を選択して Windows NT マシンを定義するか、または [新しい Unix Machine のコンフィグレーション] を選択します。
[名前] 属性フィールドに新しいマシンのユニークな名前を入力します。
[作成] をクリックして、新しいマシンの定義を作成します。
新しい UNIX サーバのその他の属性をコンフィグレーションする場合は、Administration Console オンラインヘルプを参照してください。
クラスタ内の 1 つまたは複数の WebLogic Server インスタンスのホストになるマシンごとに、上記の手順を繰り返します。

WebLogic Server インスタンスを作成する

サーバでクラスタを構成する前に、WebLogic Server Administration Console を使用して各サーバインスタンスの新しい定義を作成する必要があります。以下の手順を実行します。

システムの管理サーバを起動します。詳細については、『WebLogic Server 管理者ガイド』の「WebLogic 管理サーバの起動」を参照してください。
『WebLogic Server 管理者ガイド』の「Administration Console の起動」にある手順に従って、Administration Console を起動します。
[サーバ] ノードを選択します。
[新しい Server のコンフィグレーション] を選択します。
以下の属性フィールドに値を入力します。
- [名前] : Administration Console で使用する、このサーバインスタンスの名前を入力します。startup コマンドでこの名前を使用して、起動するサーバを指定します。
  WebLogic Server リソースへの名前の割り当てを参照してください。
- [リスンポート] : このサーバに接続する場合に使用するポート番号を入力します。指定したクラスタ内のすべてのサーバは、同じポート番号を使用する必要があります。
- [リスンアドレス] : このサーバにバインドする DNS 名または IP アドレスを入力します。
  リスンアドレスの問題の回避を参照してください。
[マシン] 属性については、新しいサーバが存在するマシンを選択します。[マシン] 属性には、マシン名を定義する（省略可能）で作成したすべてのマシンの名前が表示されます。
[作成] をクリックして、新しいサーバのコンフィグレーションを作成します。
新しいサーバのその他の属性をコンフィグレーションする場合は、『WebLogic Server 管理者ガイド』の「サーバコンフィグレーションの作業」を参照してください。
クラスタを構成する WebLogic Server ごとに、上記の手順を繰り返します。

新しいクラスタを作成する

個々の WebLogic Server インスタンスを作成したら、以下の手順を実行して、新しいクラスタをコンフィグレーションします。

Administration Console を起動します。
[クラスタ] ノードを選択します。
[新しい Cluster のコンフィグレーション] を選択します。
以下の属性フィールドに値を入力します。
- [名前] : Administration Console で使用する、このクラスタの名前を入力します。この名前を使用して、クラスタにメンバシップを割り当てたり、別のクラスタ属性をコンフィグレーションしたりします。
- [クラスタアドレス] : クラスタで使用する DNS 名（クラスタ内の個々の WebLogic Server インスタンスすべての IP アドレスまたは DNS 名を含む）を入力します。詳細については、クラスタアドレスを参照してください。
- [デフォルトのロードバランスアルゴリズム] : このクラスタで使用するデフォルトのロードアルゴリズムを入力するか、またはデフォルト値をそのまま使用します。
[作成] をクリックして、新しいクラスタのコンフィグレーションを作成します。
[マルチキャスト] タブを選択します。
[マルチキャストアドレス] 属性フィールドにクラスタのマルチキャストアドレスを入力します。
変更を適用します。

WebLogic Serverクラスタの起動

クラスタに参加する WebLogic Server インスタンスを起動するには、管理対象サーバの起動と同じ手順に従います。サーバインスタンスが使用する管理サーバを特定します。サーバインスタンスのコンフィグレーション情報は、管理サーバと関連付けられた config.xml ファイルから取得されます。

クラスタを起動するための基本的なプロセスは以下のとおりです。

クラスタが位置しているドメインの Administration Console を起動します。手順については、『WebLogic Server 管理者ガイド』の「Administration Console の起動」を参照してください。
.クラスタを構成する個別のサーバインスタンスを管理対象サーバとして起動します。次に例を示します。
```
% java -ms64m -mx64m -classpath $CLASSPATH
-Dweblogic.Domain=mydomain -Dweblogic.Name=clusterServer1
-Djava.security.policy==$WL_HOME/lib/weblogic.policy
-Dweblogic.management.server=192.168.0.101:7001 -Dweblogic.management.username=system
-Dweblogic.management.password=systemPassword weblogic.Server
```
サーバインスタンスのクラスタコンフィグレーションは管理サーバによって格納されるため、アドレスのバインドまたはマルチキャストの情報をコマンドラインで明示的に指定する必要はありません。ただし、以下の要素は指定が必要です。
- weblogic.Name : 起動するクラスタ内のインスタンスを識別する
- weblogic.management.server : クラスタ化されるインスタンスのコンフィグレーションを格納する管理サーバのホストとポート番号を識別する
- weblogic.management.username : 管理サーバに接続するためのユーザ名を指定する
- weblogic.management.password : ユーザのパスワードを指定する
  詳細については、『WebLogic Server 管理者ガイド』の「WebLogic 管理対象サーバの起動」を参照してください。

クラスタ化されたインスタンスの起動中、インスタンスがクラスタに参加していることをログメッセージで確認します。インスタンスはクラスタのマルチキャストアドレスと共通ポート番号をバインドすることによって開始します。

Starting Cluster Service ....

<Jul 25, 2001 6:35:17 PM PDT> <Notice> <WebLogicServer> <ListenThread listening on port 7001, ip address 172.17.13.25>

<Jul 25, 2001 6:35:18 PM PDT> <Notice> <Cluster> <Listening for multicast messages (cluster MyCluster) on port 7001 at address 239.0.0.84>

<Jul 25, 2001 6:35:18 PM PDT> <Notice> <WebLogicServer> <Started WebLogic Managed Server "MyServer-1" for domain "mydomain" running in Production Mode>

クラスタ化されたすべてのインスタンスがクラスタに参加していることを確認するために、Administration Console を開きます。クラスタを選択して [モニタ] タブを選択し、[このクラスタを構成するサーバをモニタ] を選択します。起動したサーバインスタンスのうち表示されていないものがある場合、サーバインスタンスのコンフィグレーションでマルチキャストアドレスとポート番号が正しいかどうか確認します。

ロードバランシングハードウェアをコンフィグレーションする（省略可能）

この節では、外部ロードバランサのセットアップに関する一般的なガイドラインを示します。Alteon ロードバランサのセットアップ手順については、クラスタに関する Alteon ハードウェアのコンフィグレーションを参照してください。BIG-IP ロードバランサのセットアップ手順については、クラスタに関する BIG-IP ハードウェアのコンフィグレーションを参照してください。

ロードバランシングハードウェアを含むコンフィグレーションで WebLogic Server がクラスタ化されたサーブレットおよび JSP にアクセスするしくみについては、クラスタ化されたサーブレットと JSP へのロードバランシングハードウェアを利用したアクセスを参照してください。

HTTP セッションステートのレプリケーションでハードウェアによるロードバランシングソリューションを使用している場合は、WebLogic Server セッションクッキーをサポートするよう、ロードバランサをコンフィグレーションする必要があります。コンフィグレーションの手順は、ロードバランシングハードウェアで使用される、クッキーの永続性メカニズムのタイプによって異なります。次の表に、使用できるコンフィグレーションを示します。

永続性タイプ
アクティブなクッキーの永続性		パッシブなクッキーの永続性
ロードバランサによってクッキーが上書きされる	ロードバランサによって追加のクッキーが挿入される
サポートされていない	コンフィグレーションは不要	オフセットと文字列定数を指定する

アクティブなクッキーの永続性の使用

WebLogic Server クラスタでは、WebLogic HTTP セッションクッキーを上書きまたは変更するアクティブなクッキーの永続性メカニズムはサポートされていません。

ロードバランサのアクティブなクッキーの永続性メカニズムが、クライアントセッションに独自のクッキーを追加するものである場合は、WebLogic Server クラスタでロードバランサを使用するにあたって、新たなコンフィグレーションは不要です。

パッシブなクッキーの永続性の使用

パッシブなクッキーの永続性を使用するロードバランサは、WebLogic セッションクッキーに文字列定数を使用することで、クライアントをそのプライマリ HTTP セッションステートのホストになるサーバインスタンスに関連付けることができます。文字列定数は、クラスタ内のサーバインスタンスをユニークに識別します。ロードバランサのコンフィグレーションには、オフセットと文字列定数の長さも必要です。セッションクッキーの形式に従ったオフセットと長さの有効な値は、次のようになります。

セッションクッキーについて

セッションクッキーの基本形式は以下のとおりです。

各値は次のとおりです。

ランダムセッション ID は、ランダムに生成された HTTP セッションID 。値の長さは、そのアプリケーション用の weblogic.xml ファイルのなかの <session-descriptor> 要素の IDLength パラメータを設定することにより、コンフィグレーションが可能です。デフォルトでは、ランダムセッション ID の長さは 52 バイトです。
文字列定数 は、セッションをホストするWebLogic Server インスタンスを、そのホストマシンとポートも含めて識別します。
クラスタ化されていない環境では、文字列定数は、以下の形式で最大 60 バイトです。

Primary_JVMID_Differentiator!HOST!PORT!SSLPORT

クラスタ環境では、文字列定数はそのセッションに対してプライマリとセカンダリ両方の WebLogic Server インスタンスを指定し、つまり、以下の形式で最大 120 バイトです。

Primary_JVMID_Differentiator!Host!Port!SSLPort!Secondary_JVMID_Differentiator!Host!Port!SSLPort

WebLogic Server バージョン 6.1 の初期リリースでは、文字列定数の最初の 19 バイトがプライマリ WebLogic Server インスタンスを一意に識別します。WebLogic Server バージョン 6.1 サービスパック 1 およびそれ以降では、最初の 10 バイトだけでサーバインスタンスが識別されます。

WAP-対応アプリケーションのためのセッションクッキー

無線デバイスがクッキーをサポートしないため、それに代わるセッション追跡方法として、WAP アプリケーションに対して、URL 書き換えを使用できます。無線デバイスでは、限られた長さの URL だけをサポートすることが多いので、WAP 対応アプリケーションに対する URL 書き換えの使用には、セッションパラメータの長さを短くすることが必要です。無線アプリケーション用の URL 書き換えに関する詳細は、『WebLogic Server Wireless Application 開発プログラマーズガイド』の「セッショントラッキングの代替手法－ URL 書き換え」を参照してください。

2 通りの方法で、ロードバランサをどうコンフィグレーションするかに影響するセッションパラメータの長さを制限します。

アプリケーション用の weblogic.xml ファイル内にある <session-descriptor> 要素の IDLength パラメータの値を編集して、ランダムセッション ID の長さを制限できます。ランダムセッション ID は、最短 8 バイトです。
そのドメイン用の config.xml ファイル内にある WAPEnabled パラメータを「true」に設定することにより、プライマリサーバインスタンスとセカンダリサーバインスタンスを指定するセッションパラメータの長さを制限できます。WAPEnabled が「true」になっていると、プライマリサーバインスタンスとセカンダリサーバインスタンスは、短いハッシュコードによってクッキー内で識別されます。

サーバインスタンスを指定するランダムセッション IDとセッションパラメータを短くすることにより、文字列定数は以下の形式になります。

Rand_Sess_ID!Primary_JVMID_HASH!Secondary_JVMID_HASH

ここで、それぞれの長さは以下のとおりです。

Rand_Sess_ID は 8 バイト。

Primary_JVMID_HASH iは 8 ～ 10 バイト。

SECONDARY_JVMID_HASH は 8 ～ 10 バイト。

ロードバランサのコンフィグレーション

ランダムセッション ID の長さを、デフォルト長である 52 バイトから変更していない場合、以下のようにロードバランサの機能を使って,文字列定数のオフセットと長さを設定します。

文字列定数オフセット-53 バイトに設定。デフォルトのランダムセッション ID長＋区切り文字用の1 バイト。
文字列定数の長さ-BEA は、文字列定数長は、少なくとも 19 バイトに設定することをお勧めします。19 バイトあれば、プライマリサーバインスタンスをユニークに識別するのに十分な長さです。

使用するアプリケーションまたは環境による要件によって、ランダムセッション ID の長さをデフォルト値の 52 バイトから変更する必要がある場合、それに伴ってロードバランサ上で文字列定数オフセットを設定します。文字列定数オフセットは、「ランダムセッション ID長＋区切り文字用の1 バイト」に等しくします。

使用するクラスタが、WAP 対応アプリケーションをホストする場合、ロードバランサのコンフィグレーションに影響すると思われるセッションパラメータを考慮します。詳細については、セッションパラメータ長短縮のためのロードバランサのコンフィグレーション（WAP 対応）を参照してください。

セッションパラメータ長短縮のためのロードバランサのコンフィグレーション（WAP 対応）

使用するドメインについて、WAPEnabled が「true」、IDLength が 8 バイトに設定されている場合、文字列定数のオフセットと長さを以下のように設定します。

文字列定数オフセット- 9 バイトに設定。ランダムセッション ID長＋区切り文字用の1 バイト。
文字列定数の長さ-文字列定数の長さを 8 に設定。プライマリサーバインスタンスを識別するハッシュコードの最短の長さ。

プロキシプラグインをコンフィグレーションする（省略可能）

WebLogic プロキシプラグイン（または HttpClusterServlet）を使用する Web サーバからクラスタにアクセスする場合は、『WebLogic Server 管理者ガイド』にある手順に従って、プロキシソフトウェアをコンフィグレーションします。リクエストをクラスタにプロキシするすべての Web サーバを同じようにコンフィグレーションする必要があります。プロキシプラグインを使用した接続とフェイルオーバの詳細については、クラスタ化されたサーブレットと JSP へのプロキシ経由のアクセスを参照してください。

レプリケーショングループをコンフィグレーションする（省略可能）

クラスタがサーブレットまたはステートフルセッション EJB のホストとなる場合、セッションステートのレプリカを保持するために、WebLogic Server インスタンスのレプリケーショングループを作成できます。そのためには、レプリケーショングループの使用の指示に従って、各レプリケーショングループに参加するサーバインスタンスを決定し、各サーバインスタンスの優先レプリケーショングループを決定します。

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

Administration Console を開きます。
[サーバ] ノードを選択します。
コンフィグレーション対象のサーバインスタンスを選択します。
[クラスタ] タブを選択します。
以下の属性フィールドの値を入力します。
- [レプリケーショングループ] : このサーバインスタンスが属するレプリケーショングループの名前を入力します。
- [セカンダリプリファレンスグループ] : このサーバインスタンスで、レプリケートされた HTTP セッションステートのホストとして使用するレプリケーショングループの名前を入力します。
変更内容を適用します。

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

この節では、Administration Console を使用して JDBC コンポーネントをコンフィグレーションする手順を示します。JDBC コンポーネントをコンフィグレーションする過程で行う選択は、クラスタが位置している WebLogic Server ドメインの config.xml ファイルに反映されます。

まず接続プールと、必要であればマルチプールを作成します。次にデータソースを作成します。データソースオブジェクトを作成するときは、データソース属性の 1 つとして接続プールまたはマルチプールを指定します。これにより、データソースが 1 つの特定の接続プールまたはマルチプールと関連付けられます。

JDBC 接続では、JDBC オブジェクトが WebLogic Server クラスタ内で機能するしくみの概要を示しています。
フェイルオーバと JDBC 接続では、JDBC のクラスタ化によってアプリケーションの可用性を改善できるしくみについて説明しています。
ロードバランシングと JDBC 接続では、JDBC のクラスタ化におけるロードバランシングのサポートについて説明しています。

接続プールのクラスタ化

クラスタ内で基本接続プールをセットアップするには、次の手順に従います。

接続プールを作成します。
手順については、『Administration Console オンラインヘルプ」の「JDBC 接続プールのコンフィグレーション」を参照してください。
接続プールをクラスタに割り当てます。
手順については、「サーバ、クラスタへの JDBC 接続プールの割り当て」を参照してください。
データソースを作成します。Pool Name 属性に、前の手順で作成した接続プールを指定します。
手順については、『Administration Console オンラインヘルプ」の「JDBC データソースのコンフィグレーション」を参照してください。
データソースをクラスタに割り当てます。
手順については、「JDBC データソースの割り当て」を参照してください。

マルチプールのクラスタ化

可用性を高めるためにマルチプールのクラスタを作成し、必要に応じてロードバランシングを行うには、次の手順に従います。

注意: マルチプールは一般に、可用性の向上と、レプリケートおよび同期の対象となるデータベースインスタンスへの接続のロードバランシングを目的として使用されます。詳細については、 JDBC 接続を参照してください。

2 つ以上の接続プールを作成します。
手順については、『Administration Console オンラインヘルプ』の「JDBC 接続プールのコンフィグレーション」を参照してください。
各接続プールをクラスタに割り当てます。
手順については、「サーバ、クラスタへの JDBC 接続プールの割り当て」を参照してください。
マルチプールを作成します。前の手順で作成した接続プールをマルチプールに割り当てます。
手順については、「JDBC マルチプールのコンフィグレーション」を参照してください。
マルチプールをクラスタに割り当てます。
手順については、「サーバ、クラスタへの JDBC マルチプールの割り当て」を参照してください。
データソースを作成します。Pool Name 属性に、前の手順で作成したマルチプールを指定します。
手順については、「JDBC データソースのコンフィグレーション」を参照してください。
データソースをクラスタに割り当てます。
手順については、「JDBC データソースの割り当て」を参照してください。

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

クラスタに対して JMS をコンフィグレーションするには、『管理者ガイド』の「JMS の管理」の指示に従います。以下のガイドラインを守るようにしてください。

JMS サーバ-1 つの JMS サーバを複数の管理対象サーバにデプロイすることはできません。
送り先- 複数の JMS サーバに同じ送り先をデプロイすることはできません。
接続ファクトリ-個々の接続ファクトリを複数の WebLogic Server にデプロイすることができます。
管理対象サーバ-サーバが複数の異なったドメインに分散している場合でも、クラスタ化された WebLogic Server に JMS クライアントがアクセスするためには、一意な WebLogic Server 名が必要です。必ず、JMS クライアントがアクセスするすべての管理対象サーバに一意なサーバ名を付けるようにしてください。

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

サーブレットと JSP の自動フェイルオーバに対応するために、WebLogic Server は HTTP セッションステートをメモリ内でレプリケートします。

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

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

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

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

<session-descriptor>

	<session-param>

		<param-name> PersistentStoreType </param-name>

		<param-value> replicated </param-value>

	</session-param>

</session-descriptor>

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

「Web アプリケーションのパッケージ化とデプロイ」にある手順に従って、Web アプリケーションおよび EJB をクラスタにデプロイします。アプリケーションまたは EJB をデプロイする対象を選択するときには、クラスタ内の個々の WebLogic Server インスタンスではなく、新しいクラスタを作成するで指定したクラスタ名を選択します。クラスタ名を使用することで、アプリケーションまたは EJB がクラスタ全体に均一にデプロイされます。

WebLogic Server では、クラスタ化されたオブジェクトは均一にデプロイされなければなりません。オブジェクトにレプリカ対応スタブが含まれる場合は、Administration Console でクラスタ名を使用してオブジェクトをデプロイします。それ以外の場合は、レプリカ非対応の（「ピン固定された」）オブジェクトを個々のサーバインスタンスに対してのみデプロイします。

Administration Console では、レプリカ対応オブジェクトのクラスタへのデプロイが自動化されています。アプリケーションまたはオブジェクトをクラスタにデプロイする場合、Administration Console では、アプリケーションまたはオブジェクトがクラスタの全メンバーに自動的にデプロイされます（メンバーは、管理サーバマシンのローカルにあっても、リモートマシン上にあってもかまいません）。

Administration Console を使用してアプリケーションをデプロイするとき、管理サーバはターゲットサーバインスタンスにアプリケーションファイルのコピーを送り、その後、ターゲットサーバインスタンスがアプリケーションをロードします。

注意: あるサーバインスタンスへのデプロイメントが失敗すると、ターゲットサーバインスタンス間でデプロイメント状態の整合性が失われる場合があります。

クラスタ化されるオブジェクトがクラスタワイドの JNDI ツリーにバインドされるしくみについては、クラスタワイドの JNDI ツリーの作成および JNDI ツリーの更新を参照してください。

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

この節では、特定のクラスタコンフィグレーションで役に立つヒントを示します。

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

BEA では、最適なパフォーマンスが得られるように、WebLogic Server インスタンスのホストとなるマシン上で、pure-Java 実装ではなくネイティブソケットリーダー実装を使用することを推奨しています。

ホストマシンで pure-Java ソケットリーダー実装を使用しなければならない場合でも、個々のサーバインスタンスとクライアントマシンについてソケットリーダースレッド数を適切に調整することによって、ソケット通信のパフォーマンスを改善することができます。

クラスタで IP ソケットが使用されるしくみの詳細と、ネイティブソケットリーダースレッドによって最適なパフォーマンスが得られる理由については、 IP ソケットを使用したピアツーピア通信およびクライアントとクラスタワイドの JNDI ツリーとの対話を参照してください。
クラスタでのソケットリーダースレッドの必要数を決定する方法については、ソケットの使用数の確定を参照してください。多層クラスタアーキテクチャでサーブレットクラスタをデプロイしている場合、多層アーキテクチャのコンフィグレーションに関する注意で説明しているように、このことは必要なソケットの数に影響します。

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

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

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

WebLogic Server Administration Console を開きます。
[サーバ] ノードを選択します。
コンフィグレーション対象のサーバインスタンスを選択します。
[チューニング] タブを選択します。
[ネイティブ IO を有効化] チェックボックスをオンにします。
変更内容を適用します。

サーバインスタンスのホストであるマシン上のリーダースレッド数を設定する

デフォルトでは、WebLogic Server インスタンスは起動時に 3 個のソケットリーダースレッドを作成します。負荷のピーク時にクラスタシステムで 3 個以上のソケットを利用できると判断した場合、次の手順でソケットリーダースレッドの数を増やすことができます。

WebLogic Server Administration Console を開きます。
[サーバ] ノードを選択します。
コンフィグレーション対象のサーバインスタンスを選択します。
[チューニング] タブを選択します。
[ソケットリーダー] 属性フィールドで、Java リーダースレッドの比率を変更します。Java ソケットリーダーの数は、総実行スレッド数（[実行スレッド数] 属性フィールドの値）にこの比率を乗じて算出されます。
変更内容を適用します。

クライアントマシン上のリーダースレッド数を設定する

クライアントマシン上で、クライアントを実行する Java 仮想マシン（JVM）内のソケットリーダースレッドの数を設定できます。クライアントの Java コマンドラインで、-Dweblogic.ThreadPoolSize=value および -Dweblogic.ThreadPoolPercentSocketReaders=value オプションを定義することによってソケットリーダーを指定します。

マルチキャスト生存時間（TTL）をコンフィグレーションする

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

マルチキャストメッセージが確実に転送されるようにネットワークトポロジを設定する方法については、 WAN クラスタのマルチキャスト要件を参照してください。

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

<Cluster

	Name="testcluster"

	ClusterAddress="wanclust"

	MulticastAddress="wanclust-multi"

	MulticastTTL="3"

/>

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

クラスタ内のサーバインスタンスが受信メッセージを適切なタイミングで処理していないことが理由でマルチキャストストームが発生する場合、マルチキャストバッファのサイズを大きくすることで対処できます。マルチキャストストームの詳細については、マルチキャストストームが発生する場合を参照してください。

UNIX の ndd ユーティリティを使用して、TCP/IP カーネルパラメータを調整することができます。udp_max_buf パラメータは、UDP ソケットの送信バッファおよび受信バッファのサイズをバイト単位で設定します。udp_max_buf の適切な値はデプロイメント環境によって異なります。マルチキャストストームが発生している場合、udp_max_buf の値を 32K ずつ大きくして調整の効果を確認してください。

udp_max_buf パラメータは必要な場合以外は変更しないでください。udp_max_buf パラメータを変更する場合は、事前に『Solaris Tunable Parameters Reference Manual』（http://docs.sun.com/?p=/doc/806-6779/6jfmsfr7o&）の「TCP/IP Tunable Parameters」の章の「UDP Parameters with Additional Cautions」に記されている Sun からの警告を確認してください。

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

クラスタで多層アーキテクチャを採用している場合、多層アーキテクチャのコンフィグレーションに関する注意に示されているコンフィグレーション上のガイドラインを参照してください。

URL 書き換えを有効にする

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