ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 8.1 ドキュメント > WebLogic Server クラスタ ユーザーズ ガイド > WebLogic クラスタの設定

WebLogic Server クラスタ ユーザーズ ガイド

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

WebLogic クラスタの設定

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

 

始める前に

この節では、WebLogic Server クラスタを設定するための前提となる作業および情報についてまとめています。

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

WebLogic Server インスタンスをクラスタ構成でインストールするには、有効なクラスタ ライセンスが必要です。クラスタ ライセンスの入手方法については、BEA 販売代理店にお問い合わせください。

コンフィグレーション プロセスについて

クラスタのコンフィグレーション プロセスと、コンフィグレーション タスクの実施方法の基本を理解しておくと、この節で示す情報がより有益なものとなります。

WebLogic Server が備えるコンフィグレーション機能と、それらの機能を通じて実施できるタスクの詳細については、「クラスタのコンフィグレーションとアプリケーションのデプロイメント」を参照してください。

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

どのクラスタ アーキテクチャが、対象アプリケーションのニーズに最も適しているかを決定します。アーキテクチャ上の重要な決定には、以下のものがあります。

これらを決定するためには、「クラスタ アーキテクチャ」および「クラスタでのロード バランシング」の情報が参考になります。

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

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

アプリケーションのセキュリティ要件は、適切なセキュリティ トポロジを設計するための基礎となります。多様なレベルのアプリケーション セキュリティを提供する各種の代替アーキテクチャの詳細については、「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。

注意 : 一部のネットワーク トポロジは、マルチキャスト通信に干渉することがあります。WAN にクラスタをデプロイしている場合の注意事項については、「クラスタが WAN 内の複数のサブネットにまたがる場合」を参照してください。

ファイアウォールを越えてクラスタにサーバ インスタンスをデプロイしないでください。ファイアウォールを通じてマルチキャスト トラフィックをトンネリングすることの影響については、「ファイアウォールがマルチキャスト通信を遮断することがある」を参照してください。

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

WebLogic Server をインストールする予定の 1 台以上のマシン (この節では「ホスト」と呼ぶ) を確定し、各マシンが必要なリソースを備えていることを確認します。システムおよびソフトウェアの前提条件の一覧については、『WebLogic Platform のインストール』の「WebLogic Platform インストールの準備」を参照してください。

注意 : WebLogic Server では、クラスタを非マルチホーム環境の 1 台のマシン上に設定できます。この新しい機能は、デモンストレーションまたは開発用の環境で役立ちます。

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

マルチ CPU マシン上の WebLogic Server インスタンス

BEA WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems, Inc. の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバを、大規模なクラスタまたは複数のクラスタのホストとすることができます。

ほとんどの場合、WebLogic Server クラスタは、2 つの CPU につき 1 つの WebLogic Server インスタンスの割合でデプロイするのが最適です。ただし、どのようなキャパシティ プランニングにも共通することですが、サーバ インスタンスの最適数および分散方法を決定する場合は、対象となる Web アプリケーションで実際のデプロイメントを事前にテストする必要があります。詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「マルチ CPU マシンのパフォーマンスに関する考慮事項」を参照してください。

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

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

切断された Windows マシン上のクラスタの設定

WebLogic Server クラスタを単一の切断された Windows マシン上におく場合は、Windows に TCP/IP スタックをロードさせる必要があります。デフォルトでは、物理的なネットワーク接続が検出されない場合、Windows は TCP/IP スタックをロードしません。

Windows に TCP/IP スタックをロードさせるには、「Windows で TCP/IP のメディア検出機能を無効にする方法」(http://support.microsoft.com/default.aspx?scid=kb;jp-jp;239924) の指示に従って Windows のメディア センス機能を無効にします。

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

クラスタのコンフィグレーション プロセスの間、クラスタとそのメンバーについてアドレス情報 (IP アドレスまたは DNS 名、およびポート番号) を指定します。

クラスタ内通信の概要と、クラスタ内通信を利用したロード バランシングとフェイルオーバの仕組みについては、「クラスタでの WebLogic Server の通信」を参照してください。

クラスタを設定するときは、以下の要素の位置情報を指定する必要があります。

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

リスン アドレスの問題を回避する

クラスタをコンフィグレーションするときには、クラスタおよびそのクラスタを構成するサーバ インスタンスのアドレス情報を IP アドレスまたは DNS 名を使用して指定できます。

DNS 名と IP アドレス

DNS 名と IP アドレスのどちらを使用するかを決定するときは、クラスタの目的を考慮してください。プロダクション環境では一般に、DNS 名を使用することをお勧めします。IP アドレスを使用すると、以下の状況で変換エラーが発生するおそれがあります。

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

IP アドレスの代わりに DNS 名を使用する場合の注意事項については、「ファイアウォールについての考慮事項」を参照してください。

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

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

注意 : クライアントがデフォルト チャネルと T3 を介して WebLogic Server にアクセスしている場合は、WebLogic Server インスタンスの内部 DNS 名と外部 DNS 名が異なる場合でも、ExternalDNSName 属性を設定しないでください。

ExternalDNSName の使い方

ExternalDNSName に対して IP アドレスを指定しないでください。ExternalDNSName は実際のドメイン名でなければなりません。

localhost の考慮事項

サーバ インスタンスのリスン アドレスを localhost として識別すると、非ローカルのプロセスがそのサーバ インスタンスに接続できなくなります。サーバ インスタンスのホスト マシン上のプロセスのみ、そのサーバ インスタンスに接続できます。(たとえば localhost に接続する管理スクリプトがある場合などに) サーバ インスタンスが localhost としてアクセス可能でなければならない場合で、かつリモート プロセスからもアクセス可能でなければならない場合は、リスン アドレスを空白にします。リスン アドレスを空白にすると、サーバ インスタンスはマシンのアドレスを判別してそのアドレスでリスンします。

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

WebLogic Server 環境のコンフィグレーション可能な各リソースには、ユニークな名前を割り当てる必要があります。ドメイン、サーバ、マシン、クラスタ、JDBC 接続プール、仮想ホストなどのリソースにはユニークな名前が必要です。

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

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

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

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

クラスタ用の各管理対象サーバの DNS 名と IP アドレスを識別します。

クラスタ内の各管理対象サーバについて、アドレスとリスン ポート番号の組み合わせはユニークでなければなりません。非マルチホーム環境の 1 台のマシン上でクラスタ化されるサーバ インスタンスについては、インスタンス間でアドレスが重複してもかまいませんが、使用するリスン ポートはインスタンスごとに異なっている必要があります。

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

クラスタのマルチキャスト通信専用のアドレスとポートを識別します。マルチキャスト アドレスは、224.0.0.0 ～ 239.255.255.255 の範囲の IP アドレスです。

注意 : WebLogic Server で使用されるデフォルトのマルチキャスト アドレスは、239.192.0.0 です。x.0.0.1 の値のマルチキャスト アドレスを使用することはできません。

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

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

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

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

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

「クラスタ アーキテクチャ」で説明しているような、クラスタ間にファイアウォールを設ける推奨多層アーキテクチャを設定している場合、専用のマルチキャスト アドレスが 2 つ必要になります。1 つはプレゼンテーション (サーブレット) クラスタ用であり、もう 1 つはオブジェクト クラスタ用です。2 つのマルチキャスト アドレスを使用することにより、ファイアウォールはクラスタの通信に干渉しなくなります。

クラスタ アドレス

クラスタをコンフィグレーションする際に、クラスタ内の管理対象サーバを識別するクラスタ アドレスを定義します。クラスタ アドレスは、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 のインストールからアプリケーション コンポーネントの初期デプロイメントまで順を追って説明します。

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

この節では、典型的なクラスタ実装のタスクをリストし、コンフィグレーションに関する重要な考慮事項を説明します。実際のプロセスは、環境ごとにユニークな特性およびアプリケーションの性質によって決まります。以下のタスクを説明します。

  1. WebLogic Server をインストールする
  2. クラスタ化されたドメインを作成する
  3. ノード マネージャをコンフィグレーションする
  4. EJB と RMI のロード バランシング方式をコンフィグレーションする
  5. 分散 JMS 送り先のサーバ アフィニティをコンフィグレーションする
  6. パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする
  7. プロキシ プラグインをコンフィグレーションする
  8. レプリケーション グループをコンフィグレーションする
  9. 固定サービスの移行可能対象をコンフィグレーションする
  10. クラスタ化された JDBC をコンフィグレーションする
  11. デプロイメント用にアプリケーションをパッケージ化する
  12. アプリケーションをデプロイする
  13. 移行可能サービスをデプロイ、アクティブ化、および移行する
  14. インメモリ HTTP レプリケーションをコンフィグレーションする
  15. コンフィグレーションに関するその他のトピック

クラスタの実装によっては、一部の手順が不要である場合があります。また、ここで示す以外の手順が必要になる場合もあります。

WebLogic Server をインストールする

まだインストールしていない場合、WebLogic Server をインストールします。手順については、『WebLogic Platform のインストール』を参照してください。

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

クラスタ化されたドメインを作成する

クラスタ化されたドメインの作成方法は複数あります。リストについては、「クラスタをコンフィグレーションする方法」を参照してください。

クラスタの作成手順については、以下を参照してください。

WebLogic Server クラスタを起動する

クラスタを起動するには複数の方法があります。コマンドライン インタフェース、必要なコマンドを含むスクリプト、ノード マネージャなどを使用できます。

注意 : ノード マネージャを使用すると、ローカルとリモートの管理対象サーバを起動したり、障害発生後に再起動したりするプロセスが簡単になります (ノード マネージャを使用して管理サーバを起動することはできません)。ノード マネージャを使用するには、最初に、クラスタ内の管理対象サーバをホストする各マシンでノード マネージャ プロセスをコンフィグレーションする必要があります。「ノード マネージャをコンフィグレーションする」を参照してください。

サーバ インスタンスの起動と停止については、Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。

どの方法を使用してクラスタを起動する場合でも、最初にクラスタ内の管理サーバを起動し、次に管理対象サーバを起動します。

以下の手順に従って、コマンド シェルからクラスタを起動します。各サーバ インスタンスを別々のコマンド シェルで起動することに注意してください。

  1. コマンド シェルを開きます。
  2. コンフィグレーション ウィザードで作成したドメイン ディレクトリに移動します。
  3. 次のコマンドを入力して管理サーバを起動します。

    4. StartWebLogic

  4. 「Enter username to boot WebLogic Server」というプロンプトが表示されたら、ドメインのユーザ名を入力します。
  5. 「Enter password to boot WebLogic Server」というプロンプトが表示されたら、ドメインのパスワードを入力します。

    6. 起動プロセスの状態を知らせるメッセージがコマンド シェルに表示されます。

  6. 管理対象サーバを起動するために、別のコマンド シェルを開きます。
  7. コンフィグレーション ウィザードで作成したドメイン ディレクトリに移動します。
  8. 次のコマンドを入力します。

    9. StartManagedWebLogic server_name address:port

    各要素の説明は次のとおりです。

    server_name : 起動する管理対象サーバの名前

    address : ドメインの管理サーバの IP アドレスまたは DNS 名

    port : ドメインの管理サーバのリスン ポート

  9. 「Enter username to boot WebLogic Server」というプロンプトが表示されたら、ドメインのユーザ名を入力します。
  10. 「Enter password to boot WebLogic Server」というプロンプトが表示されたら、ドメインのパスワードを入力します。

    11. 起動プロセスの状態を知らせるメッセージがコマンド シェルに表示されます。

    注意 : 管理対象サーバを起動すると、クラスタ内の他の実行中サーバ インスタンスからハートビートがリスンされます。管理対象サーバは、「WebLogic Server による JNDI ツリー更新の仕組み」で説明しているように、クラスタワイドの JNDI ツリーのローカル コピーを構築し、クラスタ内の実行中の管理対象サーバとの同期が取れたら、ステータス メッセージを表示します。同期化プロセスには、1 分ほどかかります。

  11. クラスタ内の別のサーバ インスタンスを起動するには、手順 6 から手順 10 までを繰り返します。
  12. クラスタ内のすべての管理対象サーバを起動したら、クラスタの起動プロセスは完了です。

ノード マネージャをコンフィグレーションする

ノード マネージャは、WebLogic Server 付属のスタンドアロンの Java プログラムであり、管理サーバとは異なるマシン上にある管理対象サーバの起動に便利です。またノード マネージャには、クラスタ内にある管理対象サーバの可用性の向上に役立つ機能もあります。ノード マネージャの詳細と、コンフィグレーション方法および使用方法については、『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャの概要」および「ノード マネージャのコンフィグレーション、起動、および停止」を参照してください。

EJB と RMI のロード バランシング方式をコンフィグレーションする

この節の手順に従うと、EJB および RMI オブジェクトのロード バランシング アルゴリズムを選択できます。

その他の方式を明示的に指定しない場合、WebLogic Server はクラスタ化されるオブジェクトのスタブに対して、デフォルトのロード バランシング方式であるラウンドロビン アルゴリズムを使用します。それ以外のロード バランシング方式については、「EJB と RMI オブジェクトのロード バランシング」を参照してください。デフォルトのロード バランシング アルゴリズムを変更するには、次の手順に従います。

  1. WebLogic Server Console を起動します。
  2. [クラスタ] ノードを選択します。
  3. クラスタを選択します。
  4. [デフォルトのロード バランス アルゴリズム] の横のドロップダウン矢印をクリックして、ロード バランシング アルゴリズムの選択肢を表示します。
  5. 選択肢のリストから、使用するロード バランシング アルゴリズムを選択します。
  6. [サービス期間しきい値] フィールドに設定値を入力します。この属性の定義については、Administration Console オンライン ヘルプを参照してください。
  7. [適用] をクリックして変更を保存します。

分散 JMS 送り先のサーバ アフィニティをコンフィグレーションする

WebLogic Server が提供する JMS のサーバ アフィニティのサポートについては、「JMS のロード バランシング」を参照してください。

分散 JMS 送り先のサーバ アフィニティをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「分散送り先のチューニング」を参照してください。

パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする

パッシブなクッキーの永続性をサポートするロード バランサは、セッションをホストする WebLogic Server インスタンスをクライアントと関連付けるために WebLogic Server セッション クッキーの情報を使用できます。セッション クッキーには、ロード バランサがセッションのプライマリ サーバ インスタンスを識別する文字列が含まれています。

外部ロード バランサ、セッション クッキーの永続性、および WebLogic Server セッション クッキーの詳細については、「外部ロード バランサによる HTTP セッションのロード バランシング」を参照してください。

クラスタで動作するようにロード バランサをコンフィグレーションするには、ロード バランサの機能を使用して、文字列定数のオフセットと長さを定義します。

セッション クッキーのセッション ID 部分がデフォルト長の 52 バイトであると想定して、ロード バランサで次のように設定します。

アプリケーションまたは環境によって、ランダム セッション ID の長さをデフォルト値の 52 バイト以外に変更しなければならない場合は、それに応じて文字列のオフセットをロード バランサで設定してください。文字列のオフセットは、セッション ID の長さに、区切り文字用の 1 バイトを加えたものと同じ値にする必要があります。

注意 : BIG-IP ロード バランサのベンダ固有のコンフィグレーション手順については、「クラスタに関する BIG-IPTM ハードウェアのコンフィグレーション」を参照してください。

プロキシ プラグインをコンフィグレーションする

プロキシ プラグインを使用してサーブレットおよび JSP のロード バランシングを行う場合は、この節で示す手順を参考にしてください。プロキシ プラグインは、リクエストを Web サーバからクラスタ内の WebLogic Server インスタンスに中継し、プロキシを経由する HTTP リクエストのロード バランシングとフェイルオーバを可能にします。

プロキシ プラグインによるロード バランシングの詳細については、「プロキシ プラグインによるロード バランシング」を参照してください。プロキシ プラグインによる接続とフェイルオーバの詳細については、「サーブレットと JSP のレプリケーションとフェイルオーバ」および「クラスタ化されたサーブレットと JSP へのプロキシ経由のアクセス」を参照してください。

注意 : リクエストをクラスタにプロキシ経由で中継する各 Web サーバでは、プラグインが同じようにコンフィグレーションされている必要があります。

HttpClusterServlet を設定する

HTTP クラスタ サーブレットを使用するには、以下の手順で説明するように、プロキシ サーバ マシン上でサーブレットをデフォルト Web アプリケーションとしてコンフィグレーションします。Web アプリケーションの概要については、『WebLogic Server Web アプリケーションの開発』の「Web アプリケーションの概要」を参照してください。

  1. まだコンフィグレーションしていない場合は、独立したクラスタ化されていない管理対象サーバをコンフィグレーションして、HTTP クラスタ サーブレットをホストするようにします。
  2. サーブレットの web.xml デプロイメント記述子を作成します。このファイルは、Web アプリケーション ディレクトリの \WEB-INF サブディレクトリに配置する必要があります。プロキシ サーブレットのサンプルのデプロイメント記述子は「サンプルの web.xml」にあります。web.xml の詳細については、『WebLogic Server Web アプリケーションの開発』の「デプロイメント記述子の要素」を参照してください。
    1. web.xml の <servlet> 要素で、サーブレットの名前とクラスを定義します。サーブレット名は HttpClusterServlet です。サーブレット クラスは weblogic.servlet.proxy.HttpClusterServlet です。
    2. web.xml の <servlet> 要素で、WebLogicCluster パラメータを定義して、プロキシ サーブレットのリクエストの転送先となる、クラスタ化されたサーバ インスタンスを指定します。
    3. <servlet-mapping> スタンザを作成して、サーブレットがクラスタにプロキシするリクエストを指定します。<url-pattern> 要素を使用して特定のファイル拡張子 (*.jsp または *.html など) を指定します。パターンごとに別々の <servlet-mapping> スタンザに定義します。

      4. <url-pattern> を「/」に設定すると、WebLogic Server によって解決できないリクエストをリモート サーバ インスタンスにプロキシできます。その場合、拡張子が *.jsp、*.htm、および *.html のファイルをプロキシするために、これらの拡張子もマップしなければなりません。例については、「サンプルの web.xml」を参照してください。

    4. 必要に応じて、追加のパラメータを定義します。主なパラメータのリストについては表 7-1 を参照してください。詳細なリストについては、『WebLogic Server における Web サーバ プラグインの使い方』の「Web サーバ プラグインのパラメータ」を参照してください。「クラスタのコンフィグレーションとプロキシ プラグイン」も参照してください。「プロキシ サーブレットのデプロイメント パラメータ」の構文の指示に従ってください。
  3. サーブレットの weblogic.xml デプロイメント記述子を作成します。このファイルは、Web アプリケーション ディレクトリの \WEB-INF サブディレクトリに配置する必要があります。

    4. <weblogic-web-app> スタンザの <context-root> 要素をフォワード スラッシュ文字 (/) に設定して、プロキシ サーブレットをプロキシ マシンにある管理対象サーバのデフォルト Web アプリケーションとして割り当てます。例については、「サンプルの weblogic.xml」を参照してください。

  4. Administration Console で、プロキシ サーバ マシン上の管理対象サーバにサーブレットをデプロイします。手順については、Administration Console オンライン ヘルプの「新しい Web アプリケーションのデプロイメント」を参照してください。

サンプルの web.xml

この節では HttpClusterServlet のサンプルのデプロイメント記述子ファイル (web.xml) を示します。

web.xml では、HTTP クラスタ サーブレットの位置と動作を指定するさまざまなパラメータを定義します。

パラメータの定義については、「プロキシ サーブレットのデプロイメント パラメータ」を参照してください。

<!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>

</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

この節ではサンプルの weblogic.xml ファイルを示します。<context-root> デプロイメント パラメータは「/」に設定されています。この設定により、プロキシ サーブレットがプロキシ サーバのデフォルト Web アプリケーションになります。

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.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でプロキシ サーブレットの動作をコンフィグレーションするための主なパラメータを表 7-1に示します。

プロキシ サーブレットのパラメータは、Apache、Microsoft、および Netscape Web サーバ用の WebLogic Server プラグインのコンフィグレーションに使用するパラメータと同じです。プロキシ サーブレットおよびサード パーティ製 Web サーバのプラグインをコンフィグレーションするパラメータの詳細なリストについては、『WebLogic Server における Web サーバ プラグインの使い方』の「Web サーバ プラグインのパラメータ」を参照してください。

パラメータを指定する際の構文と指定先のファイルは、プロキシ サーブレットと各プラグインごとに異なります。

プロキシ サーブレットの場合、web.xml でパラメータを指定します。パラメータごとに、web.xml の <servlet> スタンザ内の <init-param> スタンザで指定します。次に例を示します。

<init-param>
<param-name>ParameterName</param-name>
<param-value>ParameterValue</param-value>
</init-param>

表 7-1 プロキシ サーブレットのデプロイメント パラメータ

パラメータ

適用

WebLogicCluster

<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>WLS1.com:port|WLS2.com:port
</param-value>

WLS1.com と WLS2.com は、クラスタ内のサーバのホスト名。port は、ホストが HTTP リクエストをリスンするポート。

プラグインと WebLogic Server の間で SSL を使用する場合は、ポート番号を SSL リスン ポートに設定して (「リスンポートのコンフィグレーション」を参照)、SecureProxy パラメータを ON に設定する。

SecureProxy

<init-param>
<param-name>SecureProxy</param-name>
<param-value>ParameterValue</param-value>
</init-param>

有効な値は ON および OFF。

プラグインと WebLogic Server の間で SSL を使用する場合は、ポート番号を SSL リスン ポートに設定して (「リスンポートのコンフィグレーション」を参照)、SecureProxy パラメータを ON に設定する。

DebugConfigInfo

<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ParameterValue</param-value>
</init-param>

有効な値は ON および OFF。

ON に設定する場合、リクエストに ?__WebLogicBridgeConfig というリクエスト パラメータを追加して、HttpClusterServlet にデバッグ情報を問い合わせることができる (注意 : ? の後は 2 つのアンダースコア ( _ ) 文字)。セキュリティ上の理由により、プロダクション環境では DebugConfigInfo パラメータを OFF に設定することを推奨。

ConnectRetry
Secs

サーバ インスタンスへの接続試行の間に、サーブレットがスリープする間隔 (秒単位)。ConnectTimeoutSecs より小さい値を割り当てる。

HTTP 503/Service Unavailable 応答がクライアントに返されるまでにサーブレットが接続を試行する回数は、ConnectTimeoutSecs を ConnectRetrySecs で除算した数。

構文 :

<init-param>
<param-name>ConnectRetrySecs</param-name>
<param-value>ParameterValue</param-value>
</init-param>

ConnectTimeout
Secs

サーブレットがサーバ インスタンスへの接続を試行する最大時間 (秒単位)。ConnectRetrySecs より大きい値を割り当てる。

接続が成功する前に ConnectTimeoutSecs が経過した場合は、HTTP 503/Service Unavailable 応答がクライアントに送信される。

構文 :

<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

が解析用にプラグインに渡され、PathTrim が次のように設定される場合、

/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

クライアント証明書を信頼するために、WL-Proxy-Client-Cert ヘッダで指定する。

有効な値は true および false。デフォルト値は false。

この設定は、ユーザ認証がプロキシ サーバで実行される場合に役立つ。clientCertProxy を true に設定すると、プロキシ サーバは WL-Proxy-Client-Cert という特別なヘッダでクラスタに証明書を渡す。

WL-Proxy-Client-Cert ヘッダは、WebLogic Server に直接アクセス可能なクライアントで使用できる。WebLogic Server は、安全なソース (プラグイン) からのものであることを信用してヘッダの証明書情報を受け取り、その情報を使用してユーザを認証する。

そのため、clientCertProxy を true に設定する場合は、接続フィルタを使用して、WebLogic Server がプラグインの実行されているマシンからのみ接続を受信するようにすること。『WebLogic Security プログラマーズ ガイド』の「ネットワーク接続フィルタの使い方」を参照。

PathPrepend

PathTrim が取り除かれた後、URL がクラスタに転送される前に、元の URL の先頭にサーブレットが付加する文字列。

<init-param>
<param-name>PathPrepend</param-name>
<param-value>ParameterValue</param-value>
</init-param>

クラスタのコンフィグレーションとプロキシ プラグイン

2 つの WebLogic Server コンフィグレーション属性をクラスタ レベルで設定することで、HttpClusterServlet の動作を制御できます。

プロキシ サーバ経由のアプリケーションへのアクセス

クライアントがプロキシ サーバ経由でアクセスするアプリケーションを、クラスタにデプロイします。クライアント リクエストの送信先として、プロキシ サーバのリスン アドレスおよびリスン ポートを指定します。

問題がある場合は、以下の点を確認してください。

レプリケーション グループをコンフィグレーションする

WebLogic Server では、HTTP セッション ステートをメモリ内にレプリケートすることによって、サーブレットおよび JSP の自動フェイルオーバを行います。それ以外にも、レプリケーション グループを使用することにより、セカンダリ ステートが置かれる場所を独自に制御することができます。レプリケーション グループは、セッション ステートのレプリカの格納先として使用する、クラスタ内のサーバ インスタンスの優先順を定義するリストです。

クラスタがサーブレットまたはステートフル セッション EJB のホストになる場合は、WebLogic Server インスタンスのレプリケーション グループを作成して、セッション ステートのレプリカのホストにすることができます。

各レプリケーション グループに参加させるサーバ インスタンスと、各サーバ インスタンスの優先レプリケーション グループを決定する手順については、「レプリケーション グループの使用」を参照してください。

次に、個々の WebLogic Server インスタンスについて、次の手順に従ってレプリケーション グループをコンフィグレーションします。

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

  1. WebLogic Server Console を起動します。
  2. [サーバ] ノードを選択します。
  3. コンフィグレーションするサーバを選択します。
  4. [クラスタ] タブを選択します。
  5. 以下の属性フィールドに値を入力します。
    • [レプリケーション グループ] : このサーバ インスタンスが属するレプリケーション グループ名を入力します。
    • [セカンダリ プリファレンス グループ] : このサーバ インスタンスをレプリケートされた HTTP セッション ステートのホストにする場合に使用するレプリケーション グループ名を入力します。
  6. 変更を適用します。

固定サービスの移行可能対象をコンフィグレーションする

WebLogic Server では、オプションの移行可能対象をコンフィグレーションできます。移行可能対象には、JMS サーバや Java Transaction API (JTA) トランザクション回復サービスなどの移行可能サービスのホストとなることのできる、クラスタ内のサーバ インスタンスのリストを定義します。移行可能対象を使用する場合、クラスタ内でサービスをデプロイまたはアクティブ化する前に、対象サーバ リストをコンフィグレーションします。

クラスタ内の移行可能対象をコンフィグレーションしない場合、移行可能サービスは、クラスタ内のどの WebLogic Server インスタンスにも移行できます。詳細については、「固定サービスの移行」を参照してください。

JMS の移行可能な対象のコンフィグレーション手順については、『WebLogic JMS プログラマーズ ガイド』の「JMS サーバの移行可能対象のコンフィグレーション」を参照してください。

JTA の移行可能な対象のコンフィグレーション手順については、Administration Console オンライン ヘルプの「トランザクション回復サービスの移行先になるサーバの制限」を参照してください。

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

この節では、Administration Console による JDBC コンポーネントのコンフィグレーション手順を示します。JDBC コンポーネントのコンフィグレーション時に選択した内容は、クラスタを含む WebLogic Server ドメインの config.xml ファイルに反映されます。

接続プール、および必要に応じてマルチプールを作成してから、データ ソースを作成します。データ ソース オブジェクトを作成しているときに、データ ソース属性の 1 つとして接続プールまたはマルチプールを指定します。これによって、そのデータ ソースを特定の接続プールまたはマルチプールに関連付けます。

接続プールをクラスタ化する

次の手順を実行し、クラスタ内の基本接続プールを設定します。

  1. 接続プールを作成します。

    2. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  2. 接続プールをクラスタに割り当てます。

    3. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  3. データ ソースを作成します。[プール名] 属性に、前の手順で作成した接続プールを指定します。

    4. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  4. データ ソースをクラスタに割り当てます。

    5. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

マルチプールをクラスタ化する

可用性を向上させ、必要に応じてロード バランシングを提供するために、次の手順を実行してクラスタ化されたマルチプールを作成します。

注意 : 通常、マルチプールは、レプリケートされて同期を取られているデータベース インスタンスに対する接続の可用性を向上させ、ロード バランシングを提供するために使用します。詳細については、「JDBC 接続」を参照してください。

  1. 複数の接続プールを作成します。

    2. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  2. 各接続プールをクラスタに割り当てます。

    3. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  3. マルチプールを作成します。前の手順で作成した接続プールをマルチプールに割り当てます。

    4. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  4. マルチプールをクラスタに割り当てます。

    5. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  5. データ ソースを作成します。[プール名] 属性に、前の手順で作成したマルチプールを指定します。

    6. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

  6. データ ソースをクラスタに割り当てます。

    7. 手順については、Administration Console オンライン ヘルプの「JDBC」を参照してください。

デプロイメント用にアプリケーションをパッケージ化する

アプリケーションは、WebLogic Server にデプロイする前にパッケージ化する必要があります。詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server アプリケーションの作成」でパッケージ化のトピックを参照してください。

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

WebLogic Server でクラスタ化するオブジェクトは、均一にデプロイすることをお勧めします。均一なデプロイメントが確実に行われるようにするには、対象を選択するときに、クラスタ内の個別の WebLogic Server インスタンスではなくクラスタ名を使用します。

Administration Console では、クラスタへのレプリカ対応オブジェクトのデプロイメントが自動化されます。アプリケーションまたはオブジェクトをクラスタにデプロイする場合、Administration Console では、アプリケーションまたはオブジェクトがクラスタの全メンバーに自動的にデプロイされます。メンバーは、管理サーバ マシンのローカルにあっても、リモート マシン上にあってもかまいません。クラスタ環境でのアプリケーションのデプロイメントについては、「アプリケーションのデプロイメントについて」を参照してください。デプロイメントに関する一般的なトピックについては、『WebLogic Server アプリケーションのデプロイメント』を参照してください。

WebLogic Server Administration Console を使用してアプリケーションをコンフィグレーションおよびデプロイする手順については、Administration Console オンライン ヘルプの「アプリケーションおよびモジュールのデプロイメント」を参照してください。

注意 : Administration Console を使用してアプリケーションをクラスタにデプロイするときは、クラスタ内のすべてのサーバ インスタンスを動作させておくことをお勧めします。

1 つのサーバ インスタンスにデプロイする (固定デプロイメント)

クラスタのすべてのメンバーでなく、1 つのサーバ インスタンスにアプリケーションをデプロイする形態を固定デプロイメントと呼びます。固定デプロイメントでは特定のサーバ インスタンスが対象となりますが、デプロイメント プロセスの間は、クラスタ内のすべてのサーバ インスタンスが動作していなければなりません。

固定デプロイメントは、Administration Console から実行することも、weblogic.Deployer を使用してコマンドラインから実行することもできます。

コマンドラインからの固定デプロイメント

コマンド シェルから、次の構文を使用して対象のサーバ インスタンスを指定します。

java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1

クラスタのデプロイメントをキャンセルする

Administration Console を使用するか、または weblogic.Deployer を使用してコマンドラインからデプロイメントをキャンセルすることができます。

コマンドラインからデプロイメントをキャンセルする

コマンド シェルから、次の構文を使用してデプロイメント タスク ID をキャンセルします。

java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag

Administration Console を使用してデプロイメントをキャンセルする

Administration Console で [タスク] ノードを開き、現在のデプロイメント タスクを表示してキャンセルします。

デプロイ済みアプリケーションを表示する

デプロイ済みのアプリケーションを Administration Console で表示するには、次の操作を行います。

  1. Administration Console で、[デプロイメント] をクリックします。
  2. [アプリケーション] オプションをクリックします。
  3. Administration Console 内のテーブルに、デプロイ済みアプリケーションの一覧が表示されます。

デプロイ済みアプリケーションをアンデプロイする

デプロイ済みのアプリケーションを WebLogic Server Administration Console からアンデプロイするには、次の操作を行います。

  1. Administration Console で、[デプロイメント] をクリックします。
  2. [アプリケーション] オプションをクリックします。
  3. 表示されたテーブルで、アンデプロイするアプリケーションの名前をクリックします。
  4. [コンフィグレーション] タブをクリックし、[デプロイ] チェック ボックスをオフにします。
  5. [適用] をクリックします。

移行可能サービスをデプロイ、アクティブ化、および移行する

以降の節では、移行可能サービスをデプロイ、アクティブ化、および移行するためのガイドラインと手順を示します。移行可能サービスについては、「固定サービスの移行」を参照してください。

移行可能対象のサーバ インスタンスに JMS をデプロイする

ここで作成する移行可能対象は、移行可能サービスのホストとなることができるクラスタ内のサーバ インスタンスのスコープを定義します。後から対象サーバ リストの内部でサービスを移行するためには、移行可能対象として登録されているいずれかのサーバ インスタンス上で固定サービスをデプロイまたはアクティブ化する必要があります。次の手順に従って移行可能対象上に JMS サーバをデプロイするか、後から移行できるように JTA トランザクション回復システムをアクティブ化します。

注意 : 移行可能対象をコンフィグレーションしていない場合は、単純に JMS サーバをクラスタ内の任意の WebLogic Server インスタンスにデプロイします。その後、クラスタ内の任意の別サーバ インスタンスに JMS サーバを移行できます (移行可能対象は使用しません)。

Administration Console を使用して JMS サーバを移行可能対象にデプロイするには、次の手順に従います。

  1. まだ作成していない場合、「固定サービスの移行可能対象をコンフィグレーションする」の指示に従って、クラスタに対して移行可能対象を作成します。
  2. 対象のクラスタの管理サーバを起動し、Administration Console にログインします。
  3. 左ペインで [サービス｜JMS] ノードを選択し、このノードの下にある [サーバ] ノードを選択します。
  4. クラスタにデプロイする、コンフィグレーション済み JMS サーバの名前を選択します。JMS サーバのコンフィグレーションが右ペインに表示されます。
  5. 右ペインで [対象｜移行可能な対象] タブを選択します。
  6. ドロップダウン リストから、サーバ インスタンスの名前を選択します。このドロップダウン リストには、移行可能対象の一部として定義されているサーバの名前が表示されます。
  7. [適用] をクリックして、選択した WebLogic Server インスタンスに JMS サーバを適用します。

移行可能サービスとして JTA をアクティブ化する

JTA 回復サービスは、クラスタの移行可能対象として登録されているいずれかのサーバ インスタンス上で自動的に起動されます。選択したサーバ インスタンスにサービスをデプロイする必要はありません。

JTA 移行可能対象をコンフィグレーションしない場合、WebLogic Server はクラスタ内で使用可能な任意の WebLogic Server インスタンス上でサービスをアクティブ化します。JTA サービスのホストである現在のサーバ インスタンスを変更するには、「対象サーバ インスタンスに固定サービスを移行する」で示されている手順に従います。

対象サーバ インスタンスに固定サービスを移行する

移行可能サービスをデプロイした後で、Administration Console を使用して、サービスをクラスタ内の別のサーバ インスタンスに移行できます。サービスに対して移行可能対象がコンフィグレーションされている場合、移行可能対象として登録されているサーバ インスタンスであれば、動作していない場合でもそのサーバ インスタンスにサービスを移行することができます。移行可能対象をコンフィグレーションしない場合、クラスタ内のその他の任意のサーバ インスタンスにサービスを移行できます。

停止しているサーバ インスタンスにサービスを移行する場合、そのサーバ インスタンスは次回の起動時に直ちにサービスをアクティブ化します。動作中の WebLogic Server インスタンスにサービスを移行する場合、移行は直ちに有効になります。

Administration Console を使用して固定サービスを移行するには、次の操作を行います。

  1. まだデプロイしていない場合、「移行可能対象のサーバ インスタンスに JMS をデプロイする」の指示に従って、固定サービスをクラスタにデプロイします。
  2. 対象のクラスタの管理サーバを起動し、Administration Console にログインします。
  3. 左ペインで [サーバ] ノードを選択し、コンフィグレーションするクラスタのメンバーであるサーバ インスタンスを選択します。
  4. JMS サービスを移行する場合は [制御｜移行] を、JTA トランザクション回復サービスを移行する場合は [制御｜JTA 移行] をそれぞれ選択します。

    5. [現在のサーバ] フィールドには、その時点で固定サービスのホストとなっている WebLogic Server インスタンスが表示されています。[送り先サーバ] ドロップダウン リストには、サービスを移行できるサーバ インスタンスが表示されます。

警告 : グローバル トランザクションに単独で参加している JMS サービスを、保留中のトランザクションが残らないように移行するには、JMS サービスと JTA サービスの両方を移行する必要があります。その場合、JMS サービスを移行してから JTA サービスを移行しなければなりません。

  1. [送り先サーバ] ドロップダウン リストを使用して、新しく固定サービスのホストとなるサーバ インスタンスを選択します。
  2. [移行] をクリックして、固定サービスを現在のサーバから移行先サーバへ移行します。
  3. 現在のサーバに管理サーバからアクセスできない場合は、Administration Console に次のメッセージが表示されます。

    4. 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.

    Before bringing up MyServer-1 again after this migration, use the java weblogic.PurgeConfigCache utility to prevent redundant activation of the migrated service.See Help for more information

    このメッセージが表示される場合は、「現在アクティブなホストがない場合の移行」の手順を行ってください。

  4. 送り先サーバが停止している場合は、Administration Console がその停止しているサーバ インスタンスを通知し、移行を続行するかどうか尋ねます。停止しているサーバ インスタンスへの移行を続けるには [続行] を、移行を中止して別のサーバ インスタンスを選択するには [取り消し] をそれぞれクリックします。
  5. サーバ インスタンスのコンフィグレーションによっては、移行プロセスを完了するまでに数分以上かかる場合があります。ただし、移行タスクを処理しながら、Administration Console で他の作業を続けることができます。後から移行の状況を確認するには、左ペインで [タスク] ノードをクリックし、対象のドメインに対して実行中であるタスクを表示します。次に、移行タスクの説明を選択して、現在の状況を表示します。

現在アクティブなホストがない場合の移行

移行可能サービスのアクティブ サーバだったクラスタ化されている管理対象サーバがクラッシュしたか、アクセス不能になった場合は、この移行手順を使用します。

この手順では、障害の発生した管理対象サーバのコンフィグレーション キャッシュをパージします。キャッシュをパージする目的は、障害の発生したサーバ インスタンスが再び利用可能になったときに、別の管理対象サーバに移行したサービスが再デプロイされないようにすることです。キャッシュをパージすると、サービスのアクティブなホストだった管理対象サーバが再び起動したときに、そのサーバによってローカルの古いコンフィグレーション データが使用されるリスクがなくなります。

  1. マシンのネットワークとの接続を完全に切断します。管理サーバやクライアント トラフィックからアクセスできないようにする必要があります。マシンにデュアル ポート ディスクがある場合は、それを切断します。
  2. 移行可能なサービスを別のマシン上の管理対象サーバ インスタンスに移行します。管理サーバは動作している必要があります。動作していれば、移行を調整し、アクティブ化テーブルを更新できます。
    • 移行にコマンドラインを使用する場合は、-sourcedown フラグを使用する
    • コンソールを使用する場合は、ソース サーバが再起動しないよう確認する必要がある

    この時点で、移行可能サービスは別のマシンの別の管理対象サーバで利用可能になっています。次の手順は、時間があるときに行ってください。

  3. 障害の発生したマシンで必要な修理または保守を行います。
  4. マシンを再起動します。ただし、ネットワークへの接続は行いません。

    5. ノード マネージャがサービスまたはデーモンとして起動し、マシン上の管理対象サーバを起動しようとします。

    • 管理対象サーバの独立が有効な場合、管理対象サーバは管理サーバに接続できなくても起動する
    • 管理対象サーバの独立が無効な場合、管理対象サーバは管理サーバに接続できないので起動しない
  5. java weblogic.PurgeConfigCache ユーティリティを使用して、マシン上の移行可能サービスをホストするすべての管理対象サーバを無効にします。このユーティリティは、マシン上の WebLogic Server のホーム ディレクトリから実行します。マシンに WebLogic Server が複数インストールされており、それぞれが異なるルート ディレクトリを持ってクラスタに参加している場合は、各 WebLogic Server ホーム ディレクトリからユーティリティを実行します。

    6. このユーティリティは次のように機能します。

    • モニタ プロセス リスト (障害の後に再起動されるサーバ インスタンスのリスト) から管理対象サーバの PID を削除する
    • マシンが再起動されたときに起動した管理対象サーバをすべて停止し、再び再起動するのを防止する
    • レプリケートされた config.xml を管理対象サーバのルート ディレクトリから削除する
  6. マシンをネットワークおよび共有ストレージ (デュアル ポート ディスクなど) に再接続します。
  7. ノード マネージャ デーモン/サービスを再起動するか、マシンを再起動して、残りのすべての管理対象サーバを起動します。
  8. 手順 5 で無効にした管理対象サーバを起動します。これは、ノード マネージャによって実行される再起動ではなく通常の起動です。管理サーバは動作していて、アクセス可能である必要があります。管理サーバがその状態であれば、管理対象サーバは管理サーバ上にある移行可能サービスのアクティブ化テーブルと同期をとって、それが現在は移行可能サービスのアクティブなホストでないことを認識できます。

インメモリ 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>

</session-descriptor>

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

以降の節では、クラスタの特殊なコンフィグレーションを行うときに役に立つヒントを示します。

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

最適なパフォーマンスを得るために、WebLogic Server インスタンスのホストであるマシン上では、pure-Java 実装ではなくネイティブのソケット リーダー実装を使用することをお勧めします。

ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。

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

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

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

  1. WebLogic Server Console を起動します。
  2. [サーバ] ノードを選択します。
  3. コンフィグレーション対象のサーバ インスタンスを選択します。
  4. [チューニング] タブを選択します。
  5. [ネイティブ IO を有効化] ボックスをチェックします。
  6. 変更を適用します。

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

デフォルトでは、WebLogic Server インスタンスは起動時に 3 つのソケット リーダー スレッドを作成します。クラスタ システムがピーク時に 4 つ以上のソケットを使用する可能性がある場合は、ソケット リーダー スレッド数を増やします。

  1. WebLogic Server Console を起動します。
  2. [サーバ] ノードを選択します。
  3. コンフィグレーション対象のサーバ インスタンスを選択します。
  4. [チューニング] タブを選択します。
  5. [ソケット リーダー] 属性フィールドで Java リーダー スレッドの割合を編集します。Java ソケット リーダーの数が、合計実行スレッド数 ([実行スレッド] 属性フィールドに表示されます) の割合として計算されます。
  6. 変更を適用します。

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

クライアント マシン上では、クライアントを実行する 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」に記載されている警告を読んでください。

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

以下のいずれかの場合にマシン名をコンフィグレーションします。

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

手順については、Administration Console オンライン ヘルプの「マシンのコンフィグレーション」を参照してください。

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

多層アーキテクチャのクラスタのコンフィグレーションについては、「多層アーキテクチャのコンフィグレーションに関する考慮事項」のガイドラインを参照してください。

URL 書き換えを有効にする

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

 

フッタのナビゲーションのスキップ  ページの先頭 前 次