ロード・バランシングとフェイルオーバーを目的としたWebSphere Application Server V5の使用

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 初級

Laurent Felici (laurentfelici@fr.ibm.com), Solution Architect, IBM　

2003年 7月 01日

この記事では、IBM WebSphere Application Server Version 5(アプリケーション・サーバー)で、ロード・バランシングやフェイルオーバーをサポートするクラスターの設定方法について説明いたします。まず、クラスターについて簡単な紹介をしてから、ロード・バランシングを目的としたクラスターを設定する方法について詳細に説明します。その後フェイルオーバーについても解説し、フェイルオーバーのメカニズムをテストする方法を提供いたします。

はじめに

アプリケーション・サーバー・クラスターとは、同じアプリケーションを実行しているアプリケーション・サーバー群です。アプリケーション・サーバー・プロセスは、同じマシンでも異なるマシンにおいても実行することができます。クライアントからは、クラスターは１つのサーバー・インスタンスであるように見えます。クラスター化されたアプリケーション・サーバーは、ロード・バランシングとフェイルオーバーの機能を提供する以外は１つのサーバーであるかのように動作しています。クラスター内のすべてのサーバー・インスタンスは、WebSphereドメインの同一のセル（後述されている）に存在していなければなりません。

• Scalability - アプリケーション能力を高める
• High availability - クラスター内でアプリケーション・サーバーのインスタンスが失敗しても、クラスター内の他のアプリケーション・サーバーのインスタンスでアプリケーション・プロセスが継続できる

アプリケーション・サーバー構造のトポロジーを理解するためには、いくつかの一般的な用語を定義しておきます。

管理対象サーバー

自身のJava Virtual Machine(JVM)で起動しているアプリケーション・サーバー・プロセス

ノード

物理的に同一のコンピュータに位置するサーバーの論理グループ。複数のノードが同一のコンピュータ上に存在することもできますが、この記事では、物理的なコンピュータにつき1つのノードだけが存在すると仮定します。

ノード・エージェント

ノード上で起動しているサーバーを管理する管理プロセス。１つのノードに１つのノード・エージェントが存在します。

セル

同一の管理ドメインに属するノードの論理グループ。

セルマネージャー

分散トポロジーで複数のノードを管理するネットワーク・デプロイメント・マネージャーとも呼ばれます。厳密に言えば、同一のセルに設定されているすべてのアプリケーション・サーバーを管理することができる管理コンソールのインスタンスを実行するアプリケーション・サーバーです。セル内のそれぞれの物理的なコンピュータ上で起動しているノード・エージェントと相互に作用しています。

基本的なアプリケーション・サーバーのインストールに、1台のアプリケーション・サーバー・プロセスに必要なもの、およびノード・エージェントを起動するために必要なコードが含まれています。ノードがセルに追加されると、ノード・エージエントが使用可能になります。アプリケーション・サーバーのネットワーク・デプロイメントのインストールによって、１台のサーバー・インストールにより連携するインスタンスを実行するように構成されたコンピュータ・システムのネットワーク・サポートが可能になります。図1は、製品をインストールするために必要となるCDを示しています。

上に戻る

ロード・バランシングを目的としたクラスターのセットアップ

ロード・バランシングはクラスター内のアプリケーション・サーバー間でのタスクの割り当てです。このセクションでは、作業負荷の管理をサポートするアプリケーション・サーバー・クラスターの設定に必要な手順について説明します。

インストール

図2は、この例で使用する装置の概要です。

この例をみなさんが再現するためには、まず製品をインストールする必要があります。オペレーティング・システムが適切にインストールされ設定されている2台のネットワークに接続されたコンピュータが必要です。この記事での例では、Windows2000を使用していますが、他のオペレーティング・システムでも簡単に適用することができます。

2台のコンピュータ(TP1とTP2)は固定IPアドレスを持つ必要があり、DNSサーバーを備えたネットワークに属していなければなりません。DNSサーバーにアクセスできない場合は、ネットワークの設定をするetc/hostsファイルを使用すると良いでしょう。

図3に、etc/hostsファイルでのTP1とTP2の設定について示しておきます。IPアドレスはネットワーク構成によって異なることに注意してください。

各コンピュータにアプリケーション・サーバーをインストールしなければなりません。製品のインストールに精通していない場合は、以下の手順に従ってください。

1. 1. アプリケーション・サーバーCDからインストーラー(install.batまたはinstall.sh)を起動します。
2. インストール言語(この例では英語)を選択してください。Windows2000の地域の設定がEnglish-USである場合、英語がデフォルト選択されています。
3. 設定タイプは、Fullを選択してください。
4. インストール・ディレクトリーについては、図4のようにデフォルトを変更してください。
   図4. インストール・ウィザード
   
   
5. インストール時、ノード名、ホスト名を入力する場合、
   - 最初のコンピュータのホスト名、ノード名にはTP1を登録してください。
   - 次のコンピュータのホスト名、ノード名にはTP2を登録してください。
   (TP1とTP2がDNSサーバーにとって有効なエントリーであるか、もしくはetc/hostsファイルに存在するかを確認してください)
6. Windowsに関しては、WebSphereをサービスとして実行する必要はありませんが、IBM HTTP ServerはTP1のサービスとして実行しておくべきです。システム管理者の適切なユーザーID、パスワードを入力してください。
7. インストールが完了するようデフォルトの手順に従ってください。

これで、2台のコンピュータへのアプリケーション・サーバーのインストールは完了です。次は、以下の手順でTP1にWebSphere Application Server Network Deploymentをインストールします。

1. WebSphere Application Server Network Deployment CDからインストーラー(install.batまたはinstall.sh)を起動してください。
2. Englishを選んでください。
3. インストーラーの手順に従ってください。機能選択では、デプロイメント・マネージャーだけが必要です。
4. デフォルトのインストール・ディレクトリーをC:￥WebSphere￥DeploymentManagerに変更してください。
5. ノード名をTP1Manager、ホスト名をTP1、セル名をTP1Networkにしてください。
6. Windowsでは、デプロイメント・マネージャーをサービスとして実行させておくことができます。
7. 手順に従ってインストールを完了してください。

インストールを完了すると、構成は次のとおりになっているはずです。

コンピュータ1

基本アプリケーション・サーバーをインストール済み。アプリケーション・サーバーのデプロイメント・マネージャーをインストール済み。IBM HTTP Serverがインストールされ、Windowsサービスとして実行中。

コンピュータ2

基本アプリケーション・サーバーをインストール済み。

構成

図5は、クラスター構成を示しています。

デプロイメント・マネージャー・セルの作成
TP1でデプロイメント・マネージャー・プロセスを開始してください。2つのWebSphereノードはデプロイメント・マネージャーのセルへ追加する必要があります。このためには、図6のように、WebSphere Application Serverインストール用の/binディレクトリーでaddNodeコマンドを使用してください。このコマンドは、2つのノードで同時に発行しないでください。最初にコンピュータTP1でaddNodeを実行して、コマンドが終了するのを待ち、その後コンピュータTP2でaddNodeを実行してください。コマンドには、デプロイメント・マネージャー・プロセスを実行するコンピュータホスト名のパラメーターが必要です。この場合、ホスト名はTP1です。

コマンドが終了したら、図7で示されるようなノードの連結が成功したというメッセージを受け取ります。

TP2(TP1がデプロイメント・マネージャーを実行するコンピュータのホスト名である場合はaddNode.bat TP1)で同じコマンドを発行することを忘れないでください。

• (TP1とTP2双方の) C:\WebSphere\AppServer\logs\nodeagent\SystemOut.log
• (TP1の) C:\WebSphere\DeploymentManager\logs\dmgr\SystemOut.log

メッセージ「Serverxxx open for e-business」は、xxxがdmgrかnodeagent.のいずれかである場合、プロセスが開始されていることを表しています。

クラスターの作成
これまでに説明してきたように、クラスターは同一のアプリケーションを実行するアプリケーション・サーバー群です。クラスター内では、それぞれのアプリケーション・サーバーはしばしばクローンと呼ばれます。図3には、TP2に2つのクローンとTP1に1つのクローンの合計3つのクローンがあります。アプリケーション・サーバーのVersion5では、クローンは、ロード・バランシングで使用されるウェイトを割り当てられます。ウェイトはクラスター内のすべてのクローンにおける相対的な値です。

このシナリオでは、すべてのコンピュータで、リクエストを平等に共有していくことにします。そのためには、クローン3のウェイトは、クローン2のウェイトとクローン1のウェイトの合計と同じにしてください。例えば、クローン1の値を2に、クローン2の値も2に、そしてクローン3の値に4を設定することができます。クローン1の値を3に、クローン2の値を3に、クローン3の値に6といったように、他の値を使用しても同じ結果にしてください。クローンの相対的なウェイトに大きな値を使用するべきではありません。

アプリケーション・サーバーのクラスターを作成するためには、WebSphereのAdministrative Consoleを使用してください。Servers > Clustersで、新しいクラスターを作成するために、図8に示されるようにNewを選択してください。

以下のステップ１では、クラスターの名前にcluster1を選んでください。レプリケーション・ドメインの意味については、この後の章の『クラスター内でのフェイルオーバーとレプリケーション』で理解することができます。ひとまず、create Republication Domain for this clusterにチェックを入れて、prefer local enabledのチェックをはずしてください。

Nextをクリックして、ステップ2に進んでください。

ステップ2では、上の図9bで示されるように、ノードTP2にclone1というクローンを作成します。weightには2をセットし、Unique Http PortsとCreate Replication Entry in this Serverにチェックを入れてください。Default application server templateを選択し、Applyをクリックしてください。

ノードTP2にclone2というクローンを作成するために、ステップ2を繰り返します。weightには2をセットし、Unique Http PortsとCreate Replication Entry in this Serverにチェックを入れてください。Default application server templateを選択し、Applyをクリックしてください。ノードTP1にclone3というクローンを作成するために再びステップ2を繰り返します。weightには4をセットし、Unique Http PortsとCreate Replication Entry in this Serverにチェックを入れてください。Default application server templateを選択し、Nextをクリックしてください。

クラスターが正しい属性を備えた3つのクローンを含むことを確認して、Finishをクリックして、変更を保存してください。

これで、クラスターの定義は終了です。次はエンタープライズ・アプリケーションをインストールします。この練習については、WebSphere Application Serverインストール時の/installableAppsディレクトリーにあるDefaultApplication.earを使用してください。クラスター上にエンタープライズ・アプリケーションをインストールするための手順は、1つの例外を除いては、スタンド・アロンのアプリケーション・サーバーにインストールする手順と同じです:「Map modules to applications servers,」のステップでは、すべてのモジュールでcluster1を選ばなければなりません。下の図10の例を参照してください。(エンタープライズ・アプリケーションの詳細なインストール手順の説明は、この記事の範囲外です。)

クラスターのセットアップ中に、一意なHTTPポートをもつ3つのクローンが作成されました。これは、それぞれのアプリケーションサーバ上で動作しているインターナル・サーバであるhttpリスナーが特定の値を持っていることを意味しています。新しいポートを作るためにadminプロセスで使用されるアルゴリズムは、既定値(HTTPトランスポートでは9080)を使用して、それぞれの新しいサーバーで規定されている次にあいている値になるまで増加させていきます。

今回は、アプリケーション・サーバーをインストールした時、server1というスタンド・アロンのサーバーが作成されました。ノードがデプロイメント・マネージャーに追加された時、server1はマネージャー・サーバーになるために移行されました。Server1はHTTPトランスポートにポート9080を使用していますが、TP2においては、clone1がポート9081を使用して、clone2がポート9082を使用するように作成しました。また、DefaultApplication.earをインストールする際、default_host仮想ホストをWebモジュールで使用しました。デフォルトでは、default_hostはポート9080のHTTPリクエストのみ受け入れます。したがって、ポート9081および9082のリクエストを受け入れるためには、この仮想ホストの設定が必要です。

デフォルト・ホストにポートを追加するためには、WebSphere Administrative Consoleで、Environment > Virtual Hosts > default_host > Host Aliasesを使用してください。新しいエイリアスを追加するために Newをクリックしてください。ホスト名には*を(*は全てのホスト名を表わします)、ポートには9081を指定してください。図11のように、ポート9082でもこのタスクを繰り返してください。

Synchronize changes with Nodesがチェックされていることを確認して、設定を保存してください。

これで、クラスターにアプリケーションがインストールされたので、次はテストをしましょう。ランタイムには、セル・マネージャー、ノード・エージェント、アプリケーション・サーバーの3つのプロセスがあります。それぞれはシステムレベルの個別のJavaプロセスです。

クラスターの開始および終了には、セル・マネージャーのAdministrative Consoleを使用します。その前に、ノード・エージェントが各ノードで実行されていなければなりません。このインストールでセル・マネージャーとノード・エージェントをコントロールするためには、表1のコマンドを使用することができます。

ノード・エージェントは、上記でaddNodeコマンドを実行後、今も実行中のはずです。TP1とTP2のノード・エージェントが実行中であることを確認するために、WebSphereのAdministrative ConsoleでSystem Administration > Node Agentを開き、ノードTP1とTP2のステータスを確認してください。どちらかのノード・エージェントが無効となっていれば、そのコンピュータのコマンドラインからノード・エージェントを開始してください。すべてのノード・エージェントが開始したら、図12のように、WebSphereのAdministrative Consoleからクラスターを開始することができます。起動プロセスはハードウェア構成に依存するので、数分かかることもあるかもしれません。

• http://TP2:9081/hello - クローン1が動作していることを確認
• http://TP2:9082/hello - クローン2が動作していることを確認
• http://TP1:9081/hello - クローン3が動作していることを確認

ワークロード管理のテスト
HTTPサーバーのプラグインはWebアプリケーションにワークロード管理を提供しています。IBM HTTP Serverは、TP1にWebSphere Application Serverと同時にインストールされています。デフォルトでは、プラグインはC:\WebSphere\AppServer\config\cellsディレクトリーにある設定ファイルplugin-cfg.xmlを使用します。プラグイン構成を生成するためには、Administrative ConsoleでEnvironment >Update Web Server Pluginを参照してください。

デプロイメント・マネージャーのAdministrative Consoleは、C:\WebSphere\DeploymentManager\config\cellsにファイルを生成します。したがって、C:\WebSphere\AppServer\config\cellsのような、HTTPサーバーのプラグインがファイルの存在を予期しているところに、生成されたファイルを手動でコピーする必要があります。

DefaultApplication.earのsnoop servletはワークロードのテストに役立ちます。snoop servletは、リクエストを実行するために使用されるプロセスの名前を表示します。ブラウザーを立ち上げて、URL http://TP1/snoopを入力してください。(IBM HTTP ServerはTP1にインストールされています。)

数回Reloadをクリックし、どのクローンがリクエストを実行しているか確認してください。クローンが設定された時、相対的な重みづけを反映する1233、1233のようなシーケンスを得るはずです。注:常に同じクローンIDが表示される場合は、ブラウザーを閉じて、再度ブラウザーを開いてください。これにより、WebSphereがセションに使用しているクッキーを削除することができます。

上に戻る

クラスター内でのフェイルオーバーとレプリケーション

フェイルオーバーとは、アプリケーションによって実行されたタスクがなんらかの理由で利用不可能になった時に、そのタスクが同一のアプリケーションを実行している別のプロセスで処理されることです。これを可能にするためには、オリジナルのタスクの状態が新しいプロセスで利用できなければなりません。異なるプロセスにオリジナルのタスクを再格納することができるように、アプリケーション・サーバーは、アプリケーション状態をコピーするためのメカニズムを提供しています。

• 図15のサーバー・ログ
• ログ・ディレクトリー(例：C:\WebSphere\DeploymentManager\logs\ dmgr\dmgr.pid)の.pidファイル
• WebSphereのAdministrative Consoleのサーバー・ランタイム情報

• クラスター内でクローンをkillしても、他のクローンに影響はしません。アプリケーション・サーバーのプロセスがkillされると、自動的にリスタートされることに気付いてください。ノード・エージェントはノード内で起動しているアプリケーション・サーバーを監視しており、いかなる理由でもプロセスがなくなったことを検知したら(意図的にkillされたり、クラッシュであっても)、ノード・エージェントはそのノードをリスタートします。
• ノード・マネージャーをkillしても、実行中のクローンには影響しません。
• デプロイメント・マネージャーをkillすることは、クラスターの実行時には影響しませんが、WebSphereのAdministrative Consoleによりセルの管理を抑制します。

テストを行うことで、クラスター内に障害が１つもないことを確認できます。

デプロイメント・マネージャーおよびノード・エージェントを開始するために、表1のコマンドを参照してください。

クラスター生成手順により、それぞれのクローンでReplication DomainとReplication Entryが作成されています。WebSphereは、プロセス間のHTTPセション・データをレプリケートすることができ、HTTPセションを保持しているプロセスが失敗したらHTTPセションを回復することができるレプリケーション・サービスを提供しています。

1. ブラウザーを立ち上げて、URLに http://TP1/hitcountを入力してください。
   図16. ヒット・カウントのデモンストレーション
   
   
2. セション状態を選択(必要ならば作成)して、Incrementをクリックしてください。ヒット・カウントが5になるまで、オペレーションを数回繰り返してください。
3. 同じブラウザーで、URLをhttp://TP1/snoopに変更してください。
4. Reloadを数回クリックして、常に同じクローンがリクエストを実行していることを理解してください。

デフォルトでは、WebSphere はSession Affinityを使用しています。HTTPセッションがアプリケーションによって作成されると、HTTPプラグインは後のすべてのリクエストに対してはじめは同じクローンで対処しようとします。

クローンが利用不可能である場合に、何が起こるかを確かめてください。

1. snoop servletを実行するクローンのプロセスIDを見つけて、それをkillしてください。
2. URLがhttp://TP1/snoopであるブラウザーをreloadしてください。新しいクローンIDを取得するはずです。
3. 同じブラウザーで、URLをhttp://TP1hitcountに変更してください。
4. セション状態を選択(必要ならば作成)して、Incrementをクリックしてください。ヒット・カウントは6であるはずです。

これにより、クローンがkillされた時HTTPセションが失われず、レプリケーション・サービスが予想通りに動作した、ということが分かります。

上に戻る

結論

この記事では、IBM WebSphere Application Server Version 5で、ロード・バランシングおよびフェイルオーバーを備えたクラスターを設定する方法を説明いたしました。

参考文献

• IBM RedbookであるIBM WebSphere Application Server V5.0 System Management and Configuration: WebSphere Handbook Seriesは、WebSphere Application Server製品について詳細な情報の提供のために作られたシリーズです。
  
  
• WebSphereでは、開発者のための多くの技術記事、チュートリアル、トライアル・ダウンロードを用意していますので、ご参照ください。
  

著者について

		Laurent Feliciは、IBMのビジネス・パートナーへの教育、補助、コンサルティングを行う組織であるIBM Developer Relations Technical Consulting (別名The dragonslayers) に勤務しています。彼は1995年のはじめからJavaを使い始め、2000年にIBMに入社しました。Laurentは、WebSphere 2.0で資格を取得して以来WebSphereのスペシャリストとして働いています。Laurent の連絡先はlaurentfelici@fr.ibm.comです。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る