ワークロード管理 |
BeenThere サンプルの構成と実行 |
始めに |
アプリケーション・サーバー・ノードの追加 |
Web コンテナー・クラスターの作成 |
EJB コンテナー・クラスターの作成 |
仮想ホストの更新 |
WebSphere 構成サービスの使用可能化 |
BeenThere.ear ファイルのインストール |
セキュリティーの構成 (オプショナル) |
サーバーの開始 |
サンプルの実行 |
サンプル構成の検証 |
このセクションでは、図 1 に示すような環境を構成するための ステップと、BeenThere サンプルをインストールし実行するためのステップについて説明します。 以下のソフトウェアが既にインストール済みであると想定します。
マシン名 | インストール済みソフトウェア |
web |
IBM HTTP Server IBM HTTP Server プラグイン |
app1 | IBM WebSphere Application Server |
app2 | IBM WebSphere Application Server |
dm | IBM WebSphere Application Server Deployment Manager |
注:以下の手順では、Web サーバーおよびその管理サービスが実行中であり、 自動的に plugin-cfg.xml ファイルを伝搬するための Web サーバー定義がデプロイメント・マネージャーに 作成済みであることを想定しています。
以下のステップを実行して、アプリケーション・サーバー・ノードをセルに追加します。
addNode <deploymgr host>
addNode.sh <deploymgr host>
install_root/bin/addNode <deploymgr host> <deploymgr port> -profileName <profileName> -startingport <portblock>
これで、アプリケーション・サーバーがセルに取り込まれました。
MyWebCluster クラスターは、ワークロード・バランシングと、サーブレットのフェイルオーバーを提供します。
以下のステップを実行して、MyWebCluster クラスターを作成します。
これで、MyWebCluster が作成されました。
MyEJBCluster クラスターは、ワークロード・バランシングと、エンタープライズ Bean のフェイルオーバーを提供します。
以下のステップを実行して、MyEJBCluster クラスターを作成します。
注: 分散プラットフォームで「ローカルを優先」オプションを選択することは、ローカル・ノードで実行中の エンタープライズ Bean に (使用可能な場合) 要求を送付することを指定します。 EJB 要求のワークロード管理のデモンストレーションのため、「ローカルを優先」オプションは、サンプル構成では使用不可にされています。
これで MyEJBCluster クラスターが作成されました。
MyWebCluster クラスターの作成中に、それぞれの新規クラスター・メンバーに対して「固有の HTTP ポートを生成する」オプションが選択されます。 このオプションを選択すると、作成されたそれぞれの新規アプリケーション・サーバーごとに固有のポート値を作成することにより、HTTP ポートの競合が回避されます。
以下のステップを実行して、動的に作成された各 HTTP ポート値に、default_host 仮想ホスト用に構成されたホスト別名エントリーが関連付けられていることを確認します。
これで、仮想ホストが更新されました。
WebSphere 構成サービスは、デフォルトではアプリケーション・サーバーに対して使用可能にされていません。 サンプルは、プログラマチックに WebSphere Application Server 構成ファイルを読み取って環境情報を取得するために、 このサービスを必要とします。
以下のステップを実行して、WebSphere 構成サービスを使用可能にします。
これで、WebSphere 構成サービスが使用可能になりました。
以下のステップを実行して、BeenThere.ear ファイルをインストールします。
セキュリティー付きで BeenThere を使用したくない場合は、このセクションをスキップできます。 セキュリティーを可能にした BeenThere を使用する場合は、ここをクリックして、セキュリティーの構成手順を参照してください。
以下のステップを実行して、サーバーを開始します。
これで、サーバーが開始されました。
サンプルを実行するには、ブラウザーで BeenThere Web アドレス http://<host_name>/wlm/BeenThere をオープンします。 ここで、<host_name> は、IBM HTTP Server が稼働中のホスト名または IP アドレスです。
WebSphere バージョン 6 以降では、環境全体のスループットを最大化するように設計されている新規機能が含まれています。 つまり、このことは、これらのバージョンで BeenThere Sample をテストするときに、Workload Management コンポーネントが要求をウェイトの厳密値に正確に送付されないことがあるということを意味します。ウェイトは、以下の検証方式が正しくない場合に、実行時に変わることがあります。 これらのシナリオでは、WLM 機能の最良の検証方法は、ウェイトによって 厳密に割り当てられるかどうかではなく、それらの要求がすべてのクラスター・メンバー に確実に送付されるようにすることです。これらのフィードバック・メカニズムを使用不可にする方法もあります。 必要であれば、詳細を IBM サポートにお問い合わせください。
以下のステップを実行して、Web コンテナー・ワークロード管理が構成されている通りに正しく機能していることを検証します。
ブラウザーで BeenThere Web アドレス http://<host_name>/wlm/BeenThere をオープンする。 ここで、<host_name> は、IBM HTTP Server が稼働中のホスト名または IP アドレスです。
サーブレット実行サマリーに示された値が、以下の例のように変わります。
サーブレット・ノードは、この時点では app1 の代わりに app2 になっているはずです。 結果は、IBM HTTP Server が HTTP 要求を、MyWebCluster クラスターの他のメンバー、つまり app2 上の WebServer2 にディスパッチしたことを示します。 サーブレットを繰り返し実行すると、MyWebCluster クラスターのクラスター・メンバーに対して構成されたウェイト値に基づいた、HTTP 要求のワークロード管理動作が明らかになります。
これで、Web コンテナー・ワークロード管理構成が検証されました。
以下のステップを実行して、EJB コンテナー・ワークロード管理が構成されている通りに正しく機能していることを検証します。
分散プラットフォームの場合、Bean 実行サマリーに示される値は、以下のようになります。
この例から、MyEJBCluster クラスターのクラスター・メンバーに対して構成されたウェイト値に基づいた、エンタープライズ Bean の ワークロード管理実行動作を見ることができます。app1 上での 1 回の実行ごとに、app2上で実行する エンタープライズ Bean が 3 回呼び出されます。
z/OS プラットフォームでは、ウェイト値は HTTP 要求のバランスを取るために使用されますが、Internet Inter-ORB Protocol (IIOP) 要求のバランスを取るためには使用されません。
これで、EJB コンテナー・ワークロード管理構成が検証されました。
以下のステップを実行して、Bean クラスターのメンバー・ウェイトが、構成の通りに正しく設定されていることを検証します。
結果を以下の例と比較します。
結果は、MyEJBCluster クラスターのすべてのメンバーのウェイト値を表示します。EJBServer1 のウェイトは 1 で、EJBServer2 のウェイトは 3 です。
これで、Bean クラスター・メンバーのウェイトが検証されました。
これで、ワークロード管理を実際に見て、BeenThere サンプルが構成された通りに正しく機能することを検証することができました。