アプリケーション・サーバーのワークロードをモニターおよび
管理するには、サーバー・クラスターおよびクラスター・メンバーを使用する
必要があります。
始める前に
アプリケーション・サーバーを構成するためのオプションについて
知っておく必要があります。ワークロードを管理するために、クラスターを構成して使用するための方法を理解するには、
以下のシナリオについて検討してください。
クライアント要求は、単一のマシン上のクラスター・メンバー間に配布されます。クライアント とは、
エンド・ユーザーとアクセス対象のアプリケーション・サーバーを
接続する、任意のサーブレット、Java™ アプリケーション、またはその他のプログラムまたはコンポーネントを指します。
ワークロードの管理がより複雑なシナリオにおいては、
クラスター・メンバーをリモート・マシンに分散できます。
ワークロードの管理がより複雑なシナリオにおいては、
クラスター・メンバーを同一のシスプレックス内に分散できます。
このタスクについて
ワークロードのバランスをとるためにクラスターの使用を決めた場合は、以下のステップを実行します。
手順
- クラスターを作成するアプリケーション・サーバーを決定します。
- データを複製するかどうかを決定します。
複製は、アプリケーション・サーバー間でデータ、オブジェクト、またはイベントを転送するサービスです。
クラスターの作成時に複製ドメインを作成することができます。
- アプリケーション・サーバーにアプリケーションをデプロイします。
- クラスターを作成します。
アプリケーション・サーバーとアプリケーション・コンポーネントを意図したとおり正確に構成した後、クラスターを作成します。
元のサーバー・インスタンスは、クラスターを介して管理されるクラスター・メンバーとなります。
- 1 つ以上のクラスター・メンバーを作成します。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
バックアップ・クラスターを構成します。
トラブルの回避 (Avoid trouble): 以下の環境で実行されているクライアントがあるとします。
- Java シン・クライアントが含まれている
- 要求が複数のセル間でルーティングされている
- 要求が以前のバージョンの製品のノードが含まれている単一のセル内でルーティングされている
この場合は、ターゲット・クラスターのクラスター・メンバーに関するポート情報が無効になる状況が突然発生することがあります。
この状況が最もよく起こるのは、
すべてのクラスター・メンバーのポートが動的ポートで、要求が送信されていない期間中にそれらのすべてのクラスター・メンバーが再始動された場合です。
このような場合、クライアント・プロセスは、結果的に、
ノード・エージェントにルーティングしてクラスター・メンバーの新しいポート・データを受信し、
その新しいポート・データを使用してクラスター・メンバーにルーティングしようとします。
クライアントがノード・エージェントと通信する際に問題が発生した場合、
あるいは新しいポート・データをクラスター・メンバーとノード・エージェントの間で伝搬する際に問題が発生した場合、
クライアントで要求が失敗する可能性があります。
これらの失敗は、一時的なものにすぎない場合もあります。
しかし、場合によっては、失敗を解決するために 1 つ以上のプロセスを再始動する必要があります。
このような場合に発生する可能性があるクライアントのルーティング問題を回避するためには、
クラスター・メンバーで静的ポートを構成するようにします。
静的ポートを構成すると、
クライアント・プロセスがクラスター・メンバーに関する情報を取得する際にポート・データが変わることはありません。
クラスター・メンバーが再始動された場合や、
プロセス間で通信あるいはデータ伝搬の問題が発生した場合でも、クライアントが保持しているポート・データは引き続き有効です。
この回避策によって、
必ずしも通信やデータ伝搬の根本的な問題が解決されるわけではありませんが、
クライアントにより予期しないあるいは不規則なルーティングが決定される症状は回避されます。
gotcha
1 次クラスターに障害が発生した場合は、バックアップ・クラスターが要求を処理します。
- クラスターを始動する。
クラスターを始動すると、そのクラスターのメンバーであるアプリケーション・サーバーのすべてが始動します。
ワークロード管理は、クラスター・メンバーが始動した後に自動的に開始されます。
- クラスターが実行されると、以下のタスクを実行できます。
- クラスターを停止します。
- クラスター・メンバーにインストールされているアプリケーションをアップグレードします。
- サーバー・クラスターやそのワークロードに関する問題を検出して処理します。
- クライアントのワークロード管理状態をリフレッシュする頻度を変更します。
com.ibm.CORBA.RequestTimeout JVM プロパティーのデフォルト・タイムアウト値は、
0 で、これはいつまでも待機することを意味します。
このデフォルト値はフェイルオーバー状態になるため、適切な設定ではありません。したがって、
アプリケーションでタイムアウトの問題が発生するか、またはシステムが
フェイルオーバー状態になるように構成した場合は、LaunchClient コマンドで -CCD オプションを使用して、
このプロパティーにゼロ以外の適切な値を設定します。
クライアントのワークロード管理状態のリフレッシュが早過ぎたり遅過ぎたりする場合は、JVM カスタム・プロパティー com.ibm.websphere.wlm.unusable.interval の間隔の設定を変更します。
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
次のタスク
スタンドアロンの Java クライアントの場合は、ブートストラップ・ホストを定義する必要があります。スタンドアロン Java クライアントは、管理サーバーのないアプリケーション・サーバーとは別のマシン上に配置されているクライアントです。
クライアントの Java 仮想マシン (JVM) 引数に、次の行を追加してください。
-Dcom.ibm.CORBA.BootstrapHost=machine_name
ここで、
machine_name は、管理サーバーが稼働しているマシンの名前です。