ワークロードのバランシング

アプリケーション・サーバーのワークロードをモニターおよび 管理するには、サーバー・クラスターおよびクラスター・メンバーを使用する 必要があります。

始める前に

アプリケーション・サーバーを構成するためのオプションについて 知っておく必要があります。ワークロードを管理するために、クラスターを構成して使用するための方法を理解するには、 以下のシナリオについて検討してください。 クライアント要求は、単一のマシン上のクラスター・メンバー間に配布されます。クライアント とは、 エンド・ユーザーとアクセス対象のアプリケーション・サーバーを 接続する、任意のサーブレット、Java™ アプリケーション、またはその他のプログラムまたはコンポーネントを指します。

[AIX Solaris HP-UX Linux Windows]ワークロードの管理がより複雑なシナリオにおいては、 クラスター・メンバーをリモート・マシンに分散できます。

[z/OS]ワークロードの管理がより複雑なシナリオにおいては、 クラスター・メンバーを同一のシスプレックス内に分散できます。

このタスクについて

ワークロードのバランスをとるためにクラスターの使用を決めた場合は、以下のステップを実行します。

手順

  1. クラスターを作成するアプリケーション・サーバーを決定します。
  2. データを複製するかどうかを決定します。 複製は、アプリケーション・サーバー間でデータ、オブジェクト、またはイベントを転送するサービスです。

    クラスターの作成時に複製ドメインを作成することができます。

  3. アプリケーション・サーバーにアプリケーションをデプロイします。
  4. クラスターを作成します。

    アプリケーション・サーバーとアプリケーション・コンポーネントを意図したとおり正確に構成した後、クラスターを作成します。 元のサーバー・インスタンスは、クラスターを介して管理されるクラスター・メンバーとなります。

  5. 1 つ以上のクラスター・メンバーを作成します。
  6. [AIX Solaris HP-UX Linux Windows][IBM i]バックアップ・クラスターを構成します。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 以下の環境で実行されているクライアントがあるとします。
    • Java シン・クライアントが含まれている
    • 要求が複数のセル間でルーティングされている
    • 要求が以前のバージョンの製品のノードが含まれている単一のセル内でルーティングされている
    この場合は、ターゲット・クラスターのクラスター・メンバーに関するポート情報が無効になる状況が突然発生することがあります。

    この状況が最もよく起こるのは、 すべてのクラスター・メンバーのポートが動的ポートで、要求が送信されていない期間中にそれらのすべてのクラスター・メンバーが再始動された場合です。 このような場合、クライアント・プロセスは、結果的に、 ノード・エージェントにルーティングしてクラスター・メンバーの新しいポート・データを受信し、 その新しいポート・データを使用してクラスター・メンバーにルーティングしようとします。

    クライアントがノード・エージェントと通信する際に問題が発生した場合、 あるいは新しいポート・データをクラスター・メンバーとノード・エージェントの間で伝搬する際に問題が発生した場合、 クライアントで要求が失敗する可能性があります。 これらの失敗は、一時的なものにすぎない場合もあります。 しかし、場合によっては、失敗を解決するために 1 つ以上のプロセスを再始動する必要があります。

    このような場合に発生する可能性があるクライアントのルーティング問題を回避するためには、 クラスター・メンバーで静的ポートを構成するようにします。 静的ポートを構成すると、 クライアント・プロセスがクラスター・メンバーに関する情報を取得する際にポート・データが変わることはありません。 クラスター・メンバーが再始動された場合や、 プロセス間で通信あるいはデータ伝搬の問題が発生した場合でも、クライアントが保持しているポート・データは引き続き有効です。 この回避策によって、 必ずしも通信やデータ伝搬の根本的な問題が解決されるわけではありませんが、 クライアントにより予期しないあるいは不規則なルーティングが決定される症状は回避されます。

    gotcha

    1 次クラスターに障害が発生した場合は、バックアップ・クラスターが要求を処理します。

  7. クラスターを始動する。

    クラスターを始動すると、そのクラスターのメンバーであるアプリケーション・サーバーのすべてが始動します。 ワークロード管理は、クラスター・メンバーが始動した後に自動的に開始されます。

  8. クラスターが実行されると、以下のタスクを実行できます。
    • クラスターを停止します。
    • クラスター・メンバーにインストールされているアプリケーションをアップグレードします。
    • サーバー・クラスターやそのワークロードに関する問題を検出して処理します。
    • クライアントのワークロード管理状態をリフレッシュする頻度を変更します。

      com.ibm.CORBA.RequestTimeout JVM プロパティーのデフォルト・タイムアウト値は、 0 で、これはいつまでも待機することを意味します。 このデフォルト値はフェイルオーバー状態になるため、適切な設定ではありません。したがって、 アプリケーションでタイムアウトの問題が発生するか、またはシステムが フェイルオーバー状態になるように構成した場合は、LaunchClient コマンドで -CCD オプションを使用して、 このプロパティーにゼロ以外の適切な値を設定します。

      クライアントのワークロード管理状態のリフレッシュが早過ぎたり遅過ぎたりする場合は、JVM カスタム・プロパティー com.ibm.websphere.wlm.unusable.interval の間隔の設定を変更します。

[IBM i][AIX Solaris HP-UX Linux Windows]

次のタスク

スタンドアロンの Java クライアントの場合は、ブートストラップ・ホストを定義する必要があります。スタンドアロン Java クライアントは、管理サーバーのないアプリケーション・サーバーとは別のマシン上に配置されているクライアントです。 クライアントの Java 仮想マシン (JVM) 引数に、次の行を追加してください。
-Dcom.ibm.CORBA.BootstrapHost=machine_name
ここで、machine_name は、管理サーバーが稼働しているマシンの名前です。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_wlm
ファイル名:trun_wlm.html