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 サーバー定義がデプロイメント・マネージャーに 作成済みであることを想定しています。



アプリケーション・サーバー・ノードの追加

以下のステップを実行して、アプリケーション・サーバー・ノードをセルに追加します。


  1. デプロイメント・マネージャーを開始する。
  2. アプリケーション・サーバーがインストールされているマシンのうちの 1 つで、 次のコマンドをコマンド行から入力する (install_root/bin がご使用の PATH 環境中に 指定されている必要があります。install_root は、WebSphere Application Server Base インストール・ルートです)。

    Windows プラットフォームの場合:
    addNode <deploymgr host>

    Linux および UNIX プラットフォームの場合:
    addNode.sh <deploymgr host>

    iSeries プラットフォームの場合:
    install_root/bin/addNode <deploymgr host> <deploymgr port> -profileName <profileName> -startingport <portblock>

    ここで、
    <deploymgr host> は、デプロイメント・マネージャーを実行中のホストの名前です。
    <deploymgr port> は、デプロイメント・マネージャー用の SOAP コネクター・ポートです。
    <profileName> は、デプロイメント・マネージャーに追加されるアプリケーション・サーバーの profileName です。
    <portblock> は、未使用ポートのブロックです。複数インスタンス環境での競合を回避するために使用されます。

  3. 2 番目の WebSphere Application Server インスタンスがインストールされているマシンで、この手順を繰り返す。

これで、アプリケーション・サーバーがセルに取り込まれました。



Web コンテナー・クラスターの作成

MyWebCluster クラスターは、ワークロード・バランシングと、サーブレットのフェイルオーバーを提供します。

以下のステップを実行して、MyWebCluster クラスターを作成します。


  1. ブラウザーで、管理コンソールの Web アドレス http://<host_name>:9060/ibm/console をオープンする。 ここで、<host_name> はデプロイメント・マネージャーが稼働している ホスト名または IP アドレスです。
  2. 管理コンソールで、「サーバー」>「クラスター」をクリックする。
  3. 新規作成」をクリックする。
  4. 「クラスター名」フィールドに MyWebCluster を入力する。
  5. 次へ」をクリックする。
  6. 以下の値を入力する。
  7. 次へ」をクリックする。
  8. 以下の値を入力する。
  9. 適用」をクリックする。
  10. 次へ」をクリックする。
  11. 終了」をクリックする。
  12. 管理コンソールのメインパネル上部にある「保存」をクリックする。
  13. 変更をノードと同期する」チェック・ボックスを選択する。
  14. 保存」をクリックする。

これで、MyWebCluster が作成されました。



EJB コンテナー・クラスターの作成

MyEJBCluster クラスターは、ワークロード・バランシングと、エンタープライズ Bean のフェイルオーバーを提供します。

以下のステップを実行して、MyEJBCluster クラスターを作成します。


  1. 「サーバー」>「クラスター」をクリックする。
  2. 新規作成」をクリックする。
  3. 「クラスター名」フィールドに MyEJBCluster を入力する。
  4. ローカル使用可能を優先」チェック・ボックスをクリアする。

    注: 分散プラットフォームで「ローカルを優先」オプションを選択することは、ローカル・ノードで実行中の エンタープライズ Bean に (使用可能な場合) 要求を送付することを指定します。 EJB 要求のワークロード管理のデモンストレーションのため、「ローカルを優先」オプションは、サンプル構成では使用不可にされています。

  5. 次へ」をクリックする。
  6. 以下の値を入力する。
  7. 次へ」をクリックする。
  8. 以下の値を入力する。
  9. 適用」をクリックする。
  10. 次へ」をクリックする。
  11. 終了」をクリックする。
  12. 管理コンソールのメインパネル上部にある「保存」をクリックする。
  13. 保存」をクリックする。

これで MyEJBCluster クラスターが作成されました。



仮想ホストの更新

MyWebCluster クラスターの作成中に、それぞれの新規クラスター・メンバーに対して「固有の HTTP ポートを生成する」オプションが選択されます。 このオプションを選択すると、作成されたそれぞれの新規アプリケーション・サーバーごとに固有のポート値を作成することにより、HTTP ポートの競合が回避されます。

以下のステップを実行して、動的に作成された各 HTTP ポート値に、default_host 仮想ホスト用に構成されたホスト別名エントリーが関連付けられていることを確認します。


  1. 管理コンソールで、「サーバー」>「アプリケーション・サーバー」>「WebServer1」>「Web コンテナー設定」>「Web コンテナー・トランスポート・チェーン」>「WCInboundDefault」の順にクリックする。
  2. SSL が無効になっているエントリーのホストおよびポート値をメモする。
  3. 「環境」>「仮想ホスト」>「default_host」>「ホスト別名」をクリックする。
  4. 「ホスト別名」リストに、ステップ 2 からのホスト名とポート値が含まれていることを確認する。リストされていない値について、以下のステップを実行してください。
    1. 新規作成」をクリックする。
    2. 前に記しておいた値を使用して、ホスト名とポートを入力する。
    3. 適用」をクリックする。
    4. 管理コンソールのメインパネル上部にある「保存」をクリックする。
    5. 保存」をクリックする。
  5. この手順を WebServer2 について繰り返す。

これで、仮想ホストが更新されました。



WebSphere 構成サービスの使用可能化

WebSphere 構成サービスは、デフォルトではアプリケーション・サーバーに対して使用可能にされていません。 サンプルは、プログラマチックに WebSphere Application Server 構成ファイルを読み取って環境情報を取得するために、 このサービスを必要とします。

以下のステップを実行して、WebSphere 構成サービスを使用可能にします。


  1. 「サーバー」>「アプリケーション・サーバー」>「WebServer1」>「サーバー・インフラストラクチャー」>「管理」>「管理サービス」>「カスタム・プロパティー」の順にクリックする。
  2. 新規作成」をクリックする。
  3. 以下の値を入力する。
  4. 適用」をクリックする。
  5. 管理コンソールのメインパネル上部にある「保存」をクリックする。
  6. 保存」をクリックする。
  7. この手順を WebServer2 について繰り返す。

これで、WebSphere 構成サービスが使用可能になりました。



BeenThere.ear ファイルのインストール

以下のステップを実行して、BeenThere.ear ファイルをインストールします。


  1. 管理コンソールで、「アプリケーション」>「新規アプリケーションのインストール」をクリックする。
  2. リモート・ファイル・システム」を選択し、次に「参照...」を選択する。
  3. デプロイメント・マネージャー用のノードを選択する。
  4. <install_root>/samples/lib/BeenThere/BeenThere.ear ファイルを選択する。 ここで、<install_root> は、デプロイメント・マネージャーのインストール・ディレクトリーです。
  5. OK」をクリックする。
  6. 次へ」をクリックする。
  7. Web モジュールおよび default_host に対して、仮想ホストが Default 仮想ホスト名に設定されていることを検証する。
  8. 次へ」をクリックする。
  9. 続行」をクリックする。
  10. モジュールをサーバーへマップする」ステップを選択する。
  11. 「クラスターおよびサーバー」リストから MyWebCluster クラスターおよび Web サーバーを選択する。
  12. BeenThere WAR モジュールを選択する。
  13. 適用」をクリックする。
  14. 「クラスターおよびサーバー」リストから MyEJBCluster クラスターおよび Web サーバーを選択する。
  15. BeenThere EJB モジュールを選択する。
  16. 適用」をクリックする。
  17. ステップ 8」(要約) をクリックする。
  18. 終了」をクリックする。
  19. マスター構成に保存」をクリックする。
  20. 保存」をクリックする。


セキュリティーの構成 (オプショナル)

セキュリティー付きで BeenThere を使用したくない場合は、このセクションをスキップできます。 セキュリティーを可能にした BeenThere を使用する場合は、ここをクリックして、セキュリティーの構成手順を参照してください。



サーバーの開始

以下のステップを実行して、サーバーを開始します。


  1. 「サーバー」>「クラスター」をクリックする。
  2. MyWebCluster および MyEJBCluster クラスターを選択する。
  3. 開始」をクリックする。

これで、サーバーが開始されました。



サンプルの実行

サンプルを実行するには、ブラウザーで BeenThere Web アドレス http://<host_name>/wlm/BeenThere をオープンします。 ここで、<host_name> は、IBM HTTP Server が稼働中のホスト名または IP アドレスです。





サンプル構成の検証

WebSphere バージョン 6 以降では、環境全体のスループットを最大化するように設計されている新規機能が含まれています。 つまり、このことは、これらのバージョンで BeenThere Sample をテストするときに、Workload Management コンポーネントが要求をウェイトの厳密値に正確に送付されないことがあるということを意味します。ウェイトは、以下の検証方式が正しくない場合に、実行時に変わることがあります。 これらのシナリオでは、WLM 機能の最良の検証方法は、ウェイトによって 厳密に割り当てられるかどうかではなく、それらの要求がすべてのクラスター・メンバー に確実に送付されるようにすることです。これらのフィードバック・メカニズムを使用不可にする方法もあります。 必要であれば、詳細を IBM サポートにお問い合わせください。


以下のステップを実行して、Web コンテナー・ワークロード管理が構成されている通りに正しく機能していることを検証します。


  1. ブラウザーで BeenThere Web アドレス http://<host_name>/wlm/BeenThere をオープンする。 ここで、<host_name> は、IBM HTTP Server が稼働中のホスト名または IP アドレスです。

  2. サーブレット実行サマリーに示された値をメモする。以下はこの要約の例です。

  3. ブラウザーで BeenThere ページを再ロードする。

    サーブレット実行サマリーに示された値が、以下の例のように変わります。


    サーブレット・ノードは、この時点では app1 の代わりに app2 になっているはずです。 結果は、IBM HTTP Server が HTTP 要求を、MyWebCluster クラスターの他のメンバー、つまり app2 上の WebServer2 にディスパッチしたことを示します。 サーブレットを繰り返し実行すると、MyWebCluster クラスターのクラスター・メンバーに対して構成されたウェイト値に基づいた、HTTP 要求のワークロード管理動作が明らかになります。

これで、Web コンテナー・ワークロード管理構成が検証されました。


以下のステップを実行して、EJB コンテナー・ワークロード管理が構成されている通りに正しく機能していることを検証します。


  1. BeenThere サーブレットの実行に対して「サーブレットおよび Bean 実行サマリーの表示」オプションを選択する。
  2. Bean 起動」フィールドに 7 を入力する。
  3. 実行」をクリックする。

    分散プラットフォームの場合、Bean 実行サマリーに示される値は、以下のようになります。


    この例から、MyEJBCluster クラスターのクラスター・メンバーに対して構成されたウェイト値に基づいた、エンタープライズ Bean の ワークロード管理実行動作を見ることができます。app1 上での 1 回の実行ごとに、app2上で実行する エンタープライズ Bean が 3 回呼び出されます。

    z/OS プラットフォームでは、ウェイト値は HTTP 要求のバランスを取るために使用されますが、Internet Inter-ORB Protocol (IIOP) 要求のバランスを取るためには使用されません。

これで、EJB コンテナー・ワークロード管理構成が検証されました。


以下のステップを実行して、Bean クラスターのメンバー・ウェイトが、構成の通りに正しく設定されていることを検証します。


  1. BeenThere サーブレットの実行に対して「Bean クラスター・メンバー・ウェイトの表示」オプションを選択する。
  2. 実行」をクリックする。

    結果を以下の例と比較します。


    結果は、MyEJBCluster クラスターのすべてのメンバーのウェイト値を表示します。EJBServer1 のウェイトは 1 で、EJBServer2 のウェイトは 3 です。

これで、Bean クラスター・メンバーのウェイトが検証されました。


これで、ワークロード管理を実際に見て、BeenThere サンプルが構成された通りに正しく機能することを検証することができました。