| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server クラスタ ユーザーズ ガイド > WebLogic クラスタの設定 |
|
WebLogic Server クラスタ ユーザーズ ガイド
|
以降の節では、WebLogic Server クラスタをコンフィグレーションするためのガイドラインと手順を示します。
この節では、WebLogic Server クラスタを設定するための前提となる作業および情報についてまとめています。
WebLogic Server インスタンスをクラスタ構成でインストールするには、有効なクラスタ ライセンスが必要です。クラスタ ライセンスの入手方法については、BEA 販売代理店にお問い合わせください。
クラスタのコンフィグレーション プロセスと、コンフィグレーション タスクの実施方法の基本を理解しておくと、この節で示す情報がより有益なものとなります。
WebLogic Server が備えるコンフィグレーション機能と、それらの機能を通じて実施できるタスクの詳細については、クラスタのコンフィグレーションとアプリケーションのデプロイメントを参照してください。
どのクラスタ アーキテクチャが、対象アプリケーションのニーズに最も適しているかを決定します。アーキテクチャ上の重要な決定には、以下のものがあります。
これらを決定するためには、クラスタ アーキテクチャおよびクラスタでのロード バランシングの情報が参考になります。
選択するアーキテクチャによって、クラスタの設定方法も変わります。クラスタ アーキテクチャによっては、ロード バランサ、HTTP サーバ、プロキシ プラグインなどの、他のリソースのインストールまたはコンフィグレーションが必要になる場合もあります。
アプリケーションのセキュリティ要件は、適切なセキュリティ トポロジを設計するための基礎となります。多様なレベルのアプリケーション セキュリティを提供する各種の代替アーキテクチャの詳細については、クラスタ アーキテクチャのセキュリティ オプションを参照してください。
注意: 一部のネットワーク トポロジは、マルチキャスト通信に干渉することがあります。WAN にクラスタをデプロイしている場合の注意事項については、クラスタが WAN 内の複数のサブネットにまたがる場合を参照してください。
ファイアウォールを越えてクラスタにサーバ インスタンスをデプロイしないでください。ファイアウォールを通じてマルチキャスト トラフィックをトンネリングすることの影響については、ファイアウォールがマルチキャスト通信を遮断することがあるを参照してください。
WebLogic Server をインストールする予定の 1 台以上のマシン (この節では「ホスト」と呼ぶ) を確定し、各マシンが必要なリソースを備えていることを確認します。システムおよびソフトウェアの前提条件の一覧については、『インストール ガイド』の「WebLogic Server のインストール準備」を参照してください。
注意: WebLogic Server バージョン 7.0 では、クラスタを非マルチホーム環境の 1 台のマシン上に設定できます。この新しい機能は、デモンストレーションまたは開発用の環境で役立ちます。
IP アドレスが動的に割り当てられるマシンに WebLogic Server をインストールしないでください。
マルチ CPU マシン上の WebLogic Server インスタンス
BEA WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、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 ソケットを使用したピア ツー ピア通信を参照してください。
切断された単一の Windows マシン上で 1 つの WebLogic Server クラスタを示す場合は、TCP/IP スタックをロードするよう Windows に強制する必要があります。 デフォルトでは、Windows は物理的なネットワーク接続を検出しないと TCP/IP スタックをロードしません。
TCP/IP スタックをロードするよう Windows に強制するには、http://support.microsoft.com/default.aspx?scid=kb;ja;239924 の「Windows で TCP/IP のメディア検出機能を無効にする方法」にある手順に従って、Windows のメディア検出機能を無効にします。
クラスタのコンフィグレーション プロセスの間、クラスタとそのメンバーについてアドレス情報 (IP アドレスまたは DNS 名、およびポート番号) を指定します。
クラスタ内通信の概要と、クラスタ内通信を利用したロード バランシングとフェイルオーバの仕組みについては、クラスタでの WebLogic Server の通信を参照してください。
クラスタを設定するときは、以下の要素の位置情報を指定する必要があります。
以降の節では、指定しなければならない情報と、リソースの識別に用いる手法に影響する要因について説明しています。
クラスタをコンフィグレーションするときには、クラスタおよびそのクラスタを構成するサーバ インスタンスのアドレス情報を IP アドレスまたは DNS 名を使用して指定できます。
DNS 名と IP アドレスのどちらを使用するかを決定するときは、クラスタの目的を考慮してください。プロダクション環境では一般に、DNS 名を使用することをお勧めします。IP アドレスを使用すると、以下の状況で変換エラーが発生するおそれがあります。
変換エラーは、個別のサーバ インスタンスのアドレスを DNS 名にバインドすることによって回避できます。サーバ インスタンスの DNS 名が、ファイアウォールの両側で必ず一致するようにしてください。また、ネットワーク上の NT システムの名前でもある DNS 名は使用しないでください。
IP アドレスの代わりに DNS 名を使用する場合の注意事項については、ファイアウォールについての考慮事項を参照してください。
WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が同じでない場合、サーバ インスタンスの ExternalDNSName 属性を使用して、サーバの外部 DNS 名を定義します。ファイアウォールの外で、externalDNSName はサーバの外部 IP アドレスに変換されます。Administration Console の [サーバ｜コンフィグレーション｜一般] タブで、この属性を設定します。Administration Console オンライン ヘルプの「[サーバ] --> [コンフィグレーション] --> [一般]」を参照してください。
注意: クライアントがデフォルト チャネルと T3 を使用して WebLogic Server にアクセスする場合、WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が異なっていても、ExternalDNSName 属性を設定しないでください。
ExternalDNSName には IP アドレスを使用しないでください。ExternalDNSName は実際のドメイン名でなければなりません。
サーバ インスタンスのリスン アドレスを localhost として識別すると、非ローカルのプロセスがそのサーバ インスタンスに接続できなくなります。サーバ インスタンスのホスト マシン上のプロセスのみ、そのサーバ インスタンスに接続できます。(たとえば localhost に接続する管理スクリプトがある場合などに) サーバ インスタンスが localhost としてアクセス可能でなければならない場合で、かつリモート プロセスからもアクセス可能でなければならない場合は、リスン アドレスを空白にします。リスン アドレスを空白にすると、サーバ インスタンスはマシンのアドレスを判別してそのアドレスでリスンします。
名前を WebLogic Server リソースに割り当てる
WebLogic Server 環境でコンフィグレーション可能な各リソースの名前がユニークであることを確認します。 ドメイン、サーバ、マシン、クラスタ、JDBC 接続プール、仮想ホスト、またはその他のリソースのそれぞれの名前は、ユニークでなければなりません。
クラスタに対して使用する管理サーバの DNS 名または IP アドレスおよびリスン ポートを識別します。
管理サーバは、そのドメイン内のすべての管理対象サーバをコンフィグレーションおよび管理するために使われる WebLogic Server インスタンスです。管理対象サーバを起動するときには、その管理サーバのホストとポートを識別します。
クラスタ用の各管理対象サーバの DNS 名と IP アドレスを識別します。
クラスタ内の各管理対象サーバについて、アドレスとリスン ポート番号の組み合わせはユニークでなければなりません。非マルチホーム環境の 1 台のマシン上でクラスタ化されるサーバ インスタンスについては、インスタンス間でアドレスが重複してもかまいませんが、使用するリスン ポートはインスタンスごとに異なっている必要があります。
クラスタのマルチキャスト通信専用のアドレスとポートを識別します。
クラスタ内のサーバ インスタンスは、マルチキャストを使用して互いに通信します。具体的には、マルチキャストを使用して各自のサービスを全体に通知し、インスタンスが継続的に使用可能であることを知らせるハートビートを一定間隔で出します。
クラスタのマルチキャスト アドレスは、クラスタ通信以外の目的には使用しないことをお勧めします。クラスタのマルチキャスト アドレスが存在するマシンが、マルチキャスト通信を使用するクラスタ外部のプログラムのホストであるか、またはそのようなプログラムによってアクセスされる場合、そのマルチキャスト通信では必ず、クラスタのマルチキャスト ポートとは異なるポートを使用してください。
ネットワーク上の複数のクラスタは、必要に応じてマルチキャスト アドレスとマルチキャスト ポートの組み合わせを共有できます。
クラスタ アーキテクチャ,で説明しているような、クラスタ間にファイアウォールを設ける推奨多層アーキテクチャを設定している場合、専用のマルチキャスト アドレスが 2 つ必要になります。1 つはプレゼンテーション (サーブレット) クラスタ用であり、もう 1 つはオブジェクト クラスタ用です。2 つのマルチキャスト アドレスを使用することにより、ファイアウォールはクラスタの通信に干渉しなくなります。
クラスタをコンフィグレーションする際に、クラスタ内の管理対象サーバを識別するクラスタ アドレスを定義します。クラスタ アドレスは、URL のホスト名部分を構築するためにエンティティ Bean およびステートレス Bean で使用されます。クラスタ アドレスが設定されていない場合、EJB ハンドルは正しく動作しません。
プロダクション環境では、クライアント アプリケーションは、クラスタ内の各 WebLogic Server インスタンスの IP アドレスまたは DNS 名にマップされる DNS 名としてクラスタ アドレスを指定する必要があります。 クラスタ内の管理対象サーバにマップされる DNS 名としてクラスタ アドレスを定義しなかった場合、エンティティ Bean および EJB ハンドルのフェイルオーバで説明したように、フェイルオーバはエンティティ Bean および EJB ハンドルに関して機能しません。
クラスタ アドレスを DNS 名として定義した場合、クラスタ メンバーのリスン ポートは、クラスタ アドレスで指定されません。クラスタ内の各管理対象サーバが同じリスン ポート番号を持っていると見なされます。クラスタ内の各サーバ インスタンスは、ユニークなアドレスとリスン ポートの組み合わせを持つ必要があるので、クラスタ アドレスが DNS 名の場合、クラスタ内の各サーバ インスタンスには以下が必要です。
クライアントがクラスタ DNS 名を提供して初期 JNDI コンテキストを取得すると、weblogic.jndi.WLInitialContextFactory はその DNS 名にマップされているすべてのアドレスのリストを取得します。このリストは WebLogic Server インスタンスによってキャッシュされ、新しい初期コンテキスト リクエストは、キャッシュされているリスト内のアドレスをラウンドロビン アルゴリズムで使うことによって実行されます。キャッシュされているリスト内のサーバ インスタンスが使用できない場合、そのサーバはリストから削除されます。アドレス リストは、サーバ インスタンスがキャッシュ内のどのアドレスにもアクセスできない場合にのみ、DNS サービスによって更新されます。
キャッシュされているアドレス リストを使用すると、DNS ラウンドロビンだけを利用する場合の問題を避けることができます。たとえば、DNS ラウンドロビンでは、アドレスがアクセス可能かどうかに関わりなく、ドメイン名にマップされているすべてのアドレスが使用され続けます。アドレス リストをキャッシュすると、WebLogic Server はアクセス不能なアドレスを削除できるので、初期コンテキスト リクエストで接続の失敗が繰り返されることはありません。
注意: 管理サーバをクラスタに参加させないでください。管理サーバの IP アドレスがクラスタワイドの DNS 名に含まれていないことを確認してください。詳細については、管理サーバについての考慮事項を参照してください。
クラスタ アドレスに対してクラスタ DNS 名を使用することは、前節で推奨したプロダクション環境だけではなく、開発環境とテスト環境でも役立ちます。
代わりに、次の例で示すように、DNS 名 (または IP アドレス)、およびクラスタ内の各管理対象サーバのリスン ポートを格納するリストとしてクラスタ アドレスを定義することもできます。
DNSName1:port1,DNSName1:port2,DNSName1:port3
IPaddress1:port1,IPaddress2:port2;IPaddress3:port3
各クラスタ メンバーは、ユニークなアドレスとポートの組み合わせを持っています。
マルチホーム環境の 1 台のマシン上でクラスタが動作しており、クラスタ内の各サーバ インスタンスで異なった IP アドレスを使用する場合、クラスタ内のサーバ インスタンスの IP アドレスにマップする DNS 名を使用してクラスタ アドレスを定義します。クラスタ アドレスを DNS 名として定義する場合、クラスタ内の各管理対象サーバで共通のリスン ポート番号を指定します。
この節では、アプリケーションをクラスタ構成にして実行する手順を、WebLogic Server のインストールからアプリケーション コンポーネントの初期デプロイメントまで順を追って説明します。
ここでは、クラスタ実装における典型的な作業の流れと、コンフィグレーションの選択に影響する重要な考慮事項を示します。実際のプロセスは、環境ごとにユニークな特性およびアプリケーションの性質によって決まります。この節では、以下の作業について説明します。
クラスタの実装によっては、一部の手順が不要である場合があります。また、ここで示す以外の手順が必要になる場合もあります。
まだインストールしていない場合、WebLogic Server をインストールします。手順については、『インストール ガイド』を参照してください。
注意: 共有ファイルシステムと 1 つのインストールを使用して、異なるマシン上で複数の WebLogic Server インスタンスを実行しないでください。共有ファイルシステムを使用すると、クラスタにシングル ポイントの競合が発生します。すべてのサーバ インスタンスが、ファイルシステムにアクセスする (また場合によっては、個別のログ ファイルへの書き込みを行う) ために競合しなければならなくなります。さらに、共有ファイルシステムに障害が発生した場合には、クラスタ化されたサーバ インスタンスを起動できなくなることもあります。
ここでは、BEA ドメイン コンフィグレーション ウィザードを使用してクラスタを作成する手順を示します。
注意: クラスタのコンフィグレーションを作成および管理する方法は他にもあります。クラスタをコンフィグレーションする方法を参照してください。
クラスタでカスタムのネットワーク チャネルを使用する場合の手順については、『WebLogic Server ドメイン管理』の「クラスタにおけるネットワーク チャネルのコンフィグレーション」を参照してください。その節で示されている手順に従って管理対象サーバを作成し、クラスタを作成し、チャネルを作成して割り当て、マルチキャスト アドレスを設定します。
作成した各サーバ インスタンスにユニークな名前を割り当てます。WebLogic Server 環境の他の管理対象サーバまたは管理サーバと同じ名前は割り当てないでください。
リスン アドレスを指定する方法については、リスン アドレスの問題を回避するを参照してください。
クラスタ アドレスを変更する場合は、適切なアドレス形式を使用します。 この形式は、クラスタをプロダクション環境で使用するかそうでないかによって異なります。プロダクション環境とそれ以外の環境でのクラスタ アドレスの形式についての詳細は、クラスタ アドレスを参照してください。
作成した各サーバ インスタンスにユニークな名前を割り当てます。WebLogic Server 環境の他の管理対象サーバまたは管理サーバと同じ名前は割り当てないでください。
リスン アドレスを指定する方法については、リスン アドレスの問題を回避するを参照してください。
ユーザ名とパスワードは、クラスタ内のサーバ インスタンスを起動するために必要です。ユーザ名は、サーバ インスタンスを起動する権限のあるロールに属していなければなりません。ロールの詳細については、『管理者ガイド』の「システム管理操作の保護」を参照してください。
コンフィグレーションの以前のステップでの設定を変更し、コンフィグレーション プロセスを完了するには、Administration Console を使用します。Administration Console の使用方法については、Administration Console オンライン ヘルプを参照してください。
注意: クラスタ コンフィグレーションに変更を加える場合は、クラスタを含むドメインの管理サーバを実行する必要があります。管理サーバを起動するには、次の節の手順 1 〜 6 に従います。
この節では、クラスタを起動するための手順を示します。まずクラスタの管理サーバを起動し、次に、クラスタ内の個々の管理対象サーバを起動します。個々のサーバ インスタンスは、個別のコマンド シェルで実行するコマンドによって起動されます。
サーバ インスタンスの起動と停止については、『管理者ガイド』の「WebLogic Server の起動と停止」を参照してください。
StartManagedWebLogic server_name address:port
起動プロセスの状態を知らせるメッセージがコマンド シェルに表示されます。
注意 : 管理対象サーバを起動すると、クラスタ内の他の実行中サーバ インスタンスからハートビートがリスンされます。管理対象サーバは、WebLogic Server による JNDI ツリー更新のしくみで説明しているように、クラスタワイドの JNDI ツリーのローカル コピーを構築し、クラスタ内の実行中の管理対象サーバとの同期が取れたら、ステータス メッセージを表示します。同期化プロセスには、1 分ほどかかります。
ノード マネージャは、WebLogic Server 付属のスタンドアロンの Java プログラムであり、管理サーバとは異なるマシン上にある管理対象サーバの起動に便利です。またノード マネージャには、クラスタ内にある管理対象サーバの可用性の向上に役立つ機能もあります。ノード マネージャの詳細と、コンフィグレーション方法および使用方法については、『WebLogic Server ドメイン管理』の「ノード マネージャによるサーバの可用性の管理」を参照してください。
EJB と RMI のロード バランシング方式をコンフィグレーションする
EJB と RMI オブジェクトに対して、重みベースまたはランダム方式のロード バランシングを使用する場合は、この節の手順に従います。
その他の方式を明示的に指定しない場合、WebLogic Server はクラスタ化されるオブジェクトのスタブに対して、デフォルトのロード バランシング方式であるラウンドロビン アルゴリズムを使用します。それ以外のロード バランシング方式については、EJB と RMI オブジェクトのロード バランシングを参照してください。デフォルトのロード バランシング アルゴリズムを変更するには、次の手順に従います。
パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする
パッシブなクッキーの永続性をサポートするロード バランサは、セッションをホストする WebLogic Server インスタンスをクライアントと関連付けるために WebLogic Server セッション クッキーの情報を使用できます。 セッション クッキーには、ロード バランサがセッションのプライマリ サーバ インスタンスを識別する文字列が含まれています。
外部ロード バランサ、セッション クッキーの永続性、および WebLogic Server のセッション クッキーの詳細については、外部ロード バランサによる HTTP セッションのロード バランシングを参照してください。
クラスタで動作するようにロード バランサをコンフィグレーションするには、ロード バランサの機能を使用して、文字列定数のオフセットと長さを定義します。
セッション クッキーのセッション ID 部分が、デフォルト長の 52 バイトに設定されている場合、次のように設定します。
アプリケーションまたは環境によって、ランダム セッション ID の長さをデフォルト値の 52 バイト以外に変更しなければならない場合は、それに応じて文字列のオフセットもロード バランサで設定します。 文字列のオフセットは、セッション ID の長さに、区切り文字用の 1 バイトを加えたものと同じ値にする必要があります。
注意: WebLogic Server で Big-IP ロード バランサをコンフィグレーションする際のベンダ固有の手順については、クラスタに関する BIG-IPｪ ハードウェアのコンフィグレーションを参照してください。
プロキシ プラグインを使用してサーブレットおよび JSP のロード バランシングを行う場合は、この節で示す手順を参考にしてください。 プロキシ プラグインは、リクエストを Web サーバからクラスタ内の WebLogic サーバ インスタンスに中継し、プロキシを経由する HTTP リクエストのロード バランシングとフェイルオーバを可能にします。
プロキシ プラグインによるロード バランシングの詳細については、プロキシ プラグインによるロード バランシングを参照してください。プロキシ プラグインによる接続とフェイルオーバの詳細については、サーブレットと JSP のレプリケーションとフェイルオーバおよびクラスタ化されたサーブレットと JSP へのプロキシ経由のアクセスを参照してください。
サード パーティ製の Web サーバ用のプラグインを設定するには、『WebLogic Server における Web サーバ プラグインの使い方』の手順に従ってください。
注意: リクエストをクラスタにプロキシ経由で中継する各 Web サーバでは、プラグインが同じようにコンフィグレーションされている必要があります。
この節では、HttpClusterServlet のデプロイ手順を示します。
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>
weblogic.servlet.proxy.HttpClusterServlet
</servlet-class>
<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>
注意: weblogic.Deployer ツールを使用して Web アプリケーションをデプロイすることもできます。 詳細については、『管理者ガイド』の「Deployer」を参照してください。
HttpClusterServlet の動作を制御するために、WebLogic Server の 2 つのコンフィグレーション属性をクラスタ レベルで設定できます。
HttpClusterServlet 用デプロイメント記述子のサンプル
次に示すのは、HttpClusterServlet を使用するための、Web アプリケーション デプロイメント記述子 web.xml の設定例です。
コード リスト 7-1 HttpClusterServlet を使用するときの web.xml の設定例
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.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>
myserver1:7736:7737|myserver2:7736:7737|myserver:7736:7737
</param-value>
</init-param>
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ON</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 Server では、HTTP セッション ステートをメモリ内にレプリケートすることによって、サーブレットおよび JSP の自動フェイルオーバを行います。それ以外にも、レプリケーション グループを使用することにより、セカンダリ ステートが置かれる場所を独自に制御することができます。レプリケーション グループは、セッション ステートのレプリカの格納先として使用する、クラスタ内のサーバ インスタンスの優先順を定義するリストです。
クラスタがサーブレットまたはステートフル セッション EJB のホストになる場合は、WebLogic Server インスタンスのレプリケーション グループを作成して、セッション ステートのレプリカのホストにすることができます。
各レプリケーション グループに参加させるサーバ インスタンスと、各サーバ インスタンスの優先レプリケーション グループを決定する手順については、レプリケーション グループを使用するを参照してください。
次に、個々の WebLogic Server インスタンスについて、次の手順に従ってレプリケーション グループをコンフィグレーションします。
WebLogic Server インスタンスのレプリケーション グループをコンフィグレーションするには、次の手順を実行します。
WebLogic Server では、オプションの移行可能対象をコンフィグレーションできます。 移行可能対象には、JMS サーバや Java Transaction API (JTA) トランザクション回復サービスなどの移行可能サービスのホストとなることのできる、クラスタ内のサーバ インスタンスのリストを定義します。移行可能対象を使用する場合、クラスタ内でサービスをデプロイまたは活性化する前に、対象サーバ リストをコンフィグレーションします。
クラスタ内の移行可能対象をコンフィグレーションしない場合、移行可能サービスは、クラスタ内のどの WebLogic Server インスタンスにも移行できます。詳細については、固定サービスの移行を参照してください。
JTA または JMS に対して移行可能対象をコンフィグレーションするには、次の手順に従います。
この節では、Administration Console による JDBC コンポーネントのコンフィグレーション手順を示します。JDBC コンポーネントのコンフィグレーション時に選択した内容は、クラスタを含む WebLogic Server ドメインの config.xml ファイルに反映されます。
接続プール、および必要に応じてマルチプールを作成してから、データ ソースを作成します。データ ソース オブジェクトを作成しているときに、データ ソース属性の 1 つとして接続プールまたはマルチプールを指定します。これによって、そのデータ ソースを特定の接続プールまたはマルチプールに関連付けます。
手順については、Administration Console オンライン ヘルプの「1 つまたは複数のサーバまたはクラスタへの JDBC 接続プールの割り当て」を参照してください。
手順については、「1 つまたは複数のサーバまたはクラスタへの JDBC 接続プールの割り当て」を参照してください。
手順については、Administration Console オンライン ヘルプの「JDBC データ ソースの作成とコンフィグレーション」を参照してください。
手順については、「サーバまたはクラスタへの JDBC データ ソースの割り当て」を参照してください。
可用性を向上させ、必要に応じてロード バランシングを提供するために、次の手順を実行してクラスタ化されたマルチプールを作成します。
注意: 通常、マルチプールは、レプリケートされて同期を取られているデータベース インスタンスに対する接続の可用性を向上させ、ロード バランシングを提供するために使用します。詳細については、JDBC 接続を参照してください。
手順については、Administration Console オンライン ヘルプの「JDBC 接続プールの作成とコンフィグレーション」を参照してください。
手順については、「1 つまたは複数のサーバまたはクラスタへの JDBC 接続プールの割り当て」を参照してください。
手順については、「JDBC マルチプールの作成とコンフィグレーション」を参照してください。
手順については、「1 つまたは複数のサーバへの JDBC マルチプールの割り当て」を参照してください。
手順については、「JDBC データ ソースの作成とコンフィグレーション」を参照してください。
『WebLogic Server アプリケーションの開発』の「WebLogic Server アプリケーションのパッケージ化」の指示に従って、デプロイメント用にアプリケーションを準備します。アプリケーションのパッケージ化は、デプロイメントのための前提条件です。
この節では、一般的なデプロイメント作業の手順を示します。クラスタ環境でのアプリケーションのデプロイメントについては、アプリケーションのデプロイメントについてを参照してください。デプロイメントに関する全般的なトピックについては、『WebLogic Server アプリケーションの開発』の「WebLogic Server デプロイメント」を参照してください。
WebLogic Server Administration Console を使用してアプリケーションをコンフィグレーションおよびデプロイするには、この節の手順に従います。
注意: Administration Console を使用してアプリケーションをクラスタにデプロイするときは、クラスタ内のすべてのサーバ インスタンスを動作させておくことをお勧めします。
注意: WebLogic Server でクラスタ化するオブジェクトは、均一にデプロイすることをお勧めします。オブジェクトにレプリカ対応スタブが含まれる場合は、Administration Console でクラスタ名を使用してオブジェクトをデプロイします。
均一なデプロイメントが確実に行われるようにするには、対象を選択するときに、クラスタ内の個別の WebLogic Server インスタンスではなくクラスタ名を使用します。
Administration Console では、クラスタへのレプリカ対応オブジェクトのデプロイメントが自動化されます。アプリケーションまたはオブジェクトをクラスタにデプロイする場合、Administration Console では、アプリケーションまたはオブジェクトがクラスタの全メンバーに自動的にデプロイされます。メンバーは、管理サーバ マシンのローカルにあっても、リモート マシン上にあってもかまいません。
クラスタのすべてのメンバーでなく、1 つのサーバ インスタンスにアプリケーションをデプロイする形態を固定デプロイメントと呼びます。固定デプロイメントでは特定のサーバ インスタンスが対象となりますが、デプロイメント プロセスの間は、クラスタ内のすべてのサーバ インスタンスが動作していなければなりません。
固定デプロイメントは、Administration Console から実行することも、weblogic.Deployer を使用してコマンドラインから実行することもできます。
コマンド シェルから、次の構文を使用して対象のサーバ インスタンスを指定します。
java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1
Administration Console を使用しての固定デプロイメント
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 からアンデプロイするには、次の操作を行います。
以降の節では、移行可能サービスをデプロイ、活性化、および移行するためのガイドラインと手順を示します。移行可能サービスについては、固定サービスの移行を参照してください。
移行可能対象のサーバ インスタンスに JMS をデプロイする
ここで作成する移行可能対象は、移行可能サービスのホストとなることができるクラスタ内のサーバ インスタンスのスコープを定義します。後から対象サーバ リストの内部でサービスを移行するためには、移行可能対象として登録されているいずれかのサーバ インスタンス上で固定サービスをデプロイまたは活性化する必要があります。次の手順に従って移行可能対象上に JMS サーバをデプロイするか、後から移行できるように JTA トランザクション回復システムを活性化します。
注意: 移行可能対象をコンフィグレーションしていない場合は、単純に JMS サーバをクラスタ内の任意の WebLogic Server インスタンスにデプロイします。 その後、クラスタ内の任意の別サーバ インスタンスに JMS サーバを移行できます (移行可能対象は使用しません)。
Administration Console を使用して JMS サーバを移行可能対象にデプロイするには、次の手順に従います。
JTA 回復サービスは、クラスタの移行可能対象として登録されているいずれかのサーバ インスタンス上で自動的に起動されます。
選択したサーバ インスタンスにサービスをデプロイする必要はありません。 JTA 移行可能対象をコンフィグレーションしない場合、WebLogic Server はクラスタ内で使用可能な任意の WebLogic Server インスタンス上でサービスを活性化します。JTA サービスのホストである現在のサーバ インスタンスを変更するには、対象サーバ インスタンスに固定サービスを移行するで示されている手順に従います。
移行可能サービスをデプロイした後で、Administration Console を使用して、サービスをクラスタ内の別のサーバ インスタンスに移行できます。サービスに対して移行可能対象がコンフィグレーションされている場合、移行可能対象として登録されているサーバ インスタンスであれば、動作していない場合でもそのサーバ インスタンスにサービスを移行することができます。移行可能対象をコンフィグレーションしない場合、クラスタ内のその他の任意のサーバ インスタンスにサービスを移行できます。
停止しているサーバ インスタンスにサービスを移行する場合、そのサーバ インスタンスは次回の起動時に直ちにサービスを活性化します。動作中の WebLogic Server インスタンスにサービスを移行する場合、移行は直ちに有効になります。
Administration Console を使用して固定サービスを移行するには、次の操作を行います。
[現在のサーバ] フィールドには、その時点で固定サービスのホストとなっている WebLogic Server インスタンスが表示されています。[送り先サーバ] ドロップダウン リストには、サービスを移行できるサーバ インスタンスが表示されます。
インメモリ HTTP レプリケーションをコンフィグレーションする
WebLogic Server では、HTTP セッション ステートをメモリ内にレプリケートすることによって、サーブレットおよび JSP の自動フェイルオーバを行います。
注意: WebLogic Server では、ファイルベースまたは JDBC ベースの永続性メカニズムを利用して、サーブレットまたは JSP の HTTP セッション ステートを維持することもできます。 それぞれの永続性メカニズムの詳細については、『WebLogic HTTP サーブレット プログラマーズ ガイド』の「セッションの永続化」を参照してください。
インメモリでの 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>
以降の節では、クラスタの特殊なコンフィグレーションを行うときに役に立つヒントを示します。
最適なパフォーマンスを得るために、WebLogic Server インスタンスのホストであるマシン上では、pure-Java 実装ではなくネイティブのソケット リーダー実装を使用することをお勧めします。
ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
以降の節では、ホスト マシンに対してネイティブ ソケット リーダー スレッドをコンフィグレーションする方法と、ホストおよびクライアント マシンに対してリーダー スレッドの数を設定する方法について説明します。
サーバ インスタンスのホスト マシン上でネイティブの IP ソケット リーダーをコンフィグレーションする
ネイティブのソケット リーダー スレッド実装を使用するように WebLogic Server インスタンスをコンフィグレーションするには、次の手順に従います。
サーバ インスタンスのホスト マシン上のリーダー スレッドの数を設定する
デフォルトでは、WebLogic Server インスタンスは起動時に 3 つのソケット リーダー スレッドを作成します。クラスタ システムがピーク時に 4 つ以上のソケットを使用する可能性がある場合は、ソケット リーダー スレッド数を増やします。
クライアント マシン上では、クライアントを実行する Java 仮想マシン (JVM) 内でソケット リーダーの数をコンフィグレーションできます。クライアントの Java コマンドラインで -Dweblogic.ThreadPoolSize=value オプションおよび -Dweblogic.ThreadPoolPercentSocketReaders=value オプションを定義してソケット リーダーを指定します。
マルチキャスト存続時間 (TTL) をコンフィグレーションする
クラスタが WAN 内の複数のサブネットにまたがっている場合、マルチキャスト パケットが最終の送り先に到達する前にルータがパケットを破棄しないように、クラスタのマルチキャスト存続時間 (Time-To-Live: TTL) パラメータの値を十分に大きく設定する必要があります。マルチキャスト存続時間パラメータには、パケットが破棄されるまでにマルチキャスト メッセージが経由できるネットワーク ホップ数を設定します。マルチキャスト存続時間パラメータを適切に設定することにより、クラスタ内のサーバ インスタンス間で送受信されるマルチキャスト メッセージが消失するリスクが少なくなります。
マルチキャスト メッセージが確実に転送されるようにネットワーク トポロジを設計する方法については、クラスタが WAN 内の複数のサブネットにまたがる場合を参照してください。
クラスタのマルチキャスト存続時間をコンフィグレーションするには、Administration Console で、対象となるクラスタの [マルチキャスト] タブにある [マルチキャスト TTL] の値を変更します。config.xml の以下の抜粋部分は、マルチキャスト存続時間値に 3 を指定したクラスタを示しています。この値によって、破棄される前にクラスタのマルチキャスト メッセージを 3 つのルータに渡すことができます。
<Cluster
Name="testcluster"
ClusterAddress="wanclust"
MulticastAddress="wanclust-multi"
MulticastTTL="3"
/>
クラスタ内のサーバ インスタンスが受信メッセージを適時に処理しないことが原因でマルチキャスト ストームが発生する場合は、マルチキャスト バッファのサイズを増やすことができます。マルチキャスト ストームの詳細については、マルチキャスト ストームが起こったらを参照してください。
TCP/IP カーネル パラメータは、UNIX の ndd ユーティリティを使用してコンフィグレーションできます。udp_max_buf パラメータでは、UDP ソケットの送信および受信バッファのサイズをバイト単位で管理します。udp_max_buf の適切な値は、デプロイメントによって異なります。マルチキャスト ストームが発生する場合は、udp_max_buf の値を 32KB 単位で増やして、その変更の効果を評価します。
必要な場合以外は、udp_max_buf の値を変更しないでください。udp_max_buf を変更する前に、『Solaris Tunable Parameters Reference Manual』 (http://docs.sun.com/?p=/doc/806-6779/6jfmsfr7o&) の「TCP/IP Tunable Parameters」という章の「UDP Parameters with Additional Cautions」に記載されいてる警告を読んでください。
クラスタ内の各サーバ インスタンスにマシン名を定義することができます。マシン名は必須ではありませんが、複数のマシンでクラスタを構成する場合と、複数のサーバ インスタンスがクラスタ内の 1 台のマシン上で実行される場合には設定することをお勧めします。
WebLogic Server では、コンフィグレーションされたマシン名を使用して、2 つのサーバ インスタンスが物理的に同じハードウェアに存在しているかどうかを調べることができます。マシン名は一般に、マルチホーム WebLogic Server インスタンスのホストとなるマシンで使用されます。そのようなインストール用のマシン名を定義していない場合、各インスタンスは物理的に異なるハードウェア上に存在するものとして扱われます。このことは、レプリケーション グループを使用するで説明するように、セカンダリ HTTP セッション ステートのレプリカのホストになるサーバ インスタンスの選択に悪影響を与えることがあります。
1 台のマシン上で複数のサーバ インスタンスを実行する予定の場合、それらのサーバ インスタンスを作成する前に、サーバ インスタンスのホストとなるマシンの名前を次のようにして定義します。
多層アーキテクチャのクラスタのコンフィグレーションについては、多層アーキテクチャのコンフィグレーションに関する注意のガイドラインを参照してください。
これらのコンフィグレーション属性の詳細については、『管理者ガイド』の「JMS サーバのコンフィグレーション」または「接続ファクトリのコンフィグレーション」を参照してください。
注意: 同じ送り先を複数の JMS サーバにデプロイすることはできません。また、1 つの JMS サーバを複数の WebLogic Server にデプロイすることもできません。
必要に応じて、クラスタの内部で単独の分散送り先セットの一部として物理送り先をコンフィグレーションすることができます。詳細については、『管理者ガイド』の「分散送り先のコンフィグレーション」を参照してください。
デフォルト コンフィグレーションの WebLogic Server では、クライアント側のクッキーを使用して、クライアントのサーブレット セッション ステートのホストであるプライマリ サーバ インスタンスとセカンダリ サーバ インスタンスが追跡されます。クライアントのブラウザでクッキーが無効になっている場合、WebLogic Server では URL 書き換えによってもプライマリ サーバ インスタンスとセカンダリ サーバ インスタンスを追跡できます。URL 書き換えを利用する場合は、クライアント セッション ステートの両方の位置が、クライアントとプロキシ サーバの間で渡される URL に挿入されます。この機能をサポートするには、WebLogic Server クラスタで URL 書き換えを有効にする必要があります。URL 書き換えを有効にする方法については、『Web アプリケーションのアセンブルとコンフィグレーション』の「URL 書き換えの使い方」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
