クラスターのメンバーを管理するには、このページを使用します。 アプリケーション・サーバーのクラスターはまとめて管理され、ワークロード管理に参加します。
ユーザーが作成する最初のクラスター・メンバーのコピーは、 クラスター・データの一部として保管され、 作成するすべての追加クラスター・メンバーに対するテンプレートになります。
クラスター・メンバーに対して行う個々の構成変更は、 クラスター・メンバーのテンプレートの構成設定には影響しません。wsadmin コマンドを使用すると、クラスター・メンバー・テンプレートを変更できます。または、「サーバー」>「クラスター」>「WebSphere アプリケーション・サーバー・クラスター (WebSphere application server clusters)」> 「cluster_name」 >「クラスター・メンバー」>「テンプレート」とクリックすることもできます。 テンプレートに対して行ういずれの変更も、 既存のクラスター・メンバーには影響しません。
この管理コンソール・ページを表示するには、「サーバー」>「クラスター」>「WebSphere アプリケーション・サーバー・クラスター (WebSphere application server clusters)」>「cluster_name」とクリックします。
「構成」タブで、フィールドを編集することができます。「インストール済みアプリケーション」をクリックして、このサーバーで実行中のアプリケーションの状況を表示することもできます。 クラスター・メンバーが実行しているときのみ表示される「ランタイム」タブに、 このクラスター・メンバーの情報を表示することができます。ただし、このページに表示される情報は読み取り専用です。 表示する設定を変更するには、「構成」タブに戻る必要があります。
クラスター・メンバーが稼働しているノードの名前を指定します。
クラスター内のアプリケーション・サーバーの名前を指定します。ほとんどのプラットフォームでは、 サーバーの名前はプロセス名です。メンバー名は、アプリケーション・サーバー・ページにリストされているサーバーのいずれかの名前と一致している必要があります。
アプリケーション・サーバーに送信される要求の数を制御します。 サーバーのウェイトとして 0 から 20 までの値を指定しても、 サーバーに割り当てられるウェイトは、 サーバーに割り当てられたウェイトが分子、クラスターのすべてのメンバーの ウェイトの合計が分母となる比率となります。
新規メンバーをクラスターに追加すると、 そのクラスター内の各サーバーに送信される要求の数は減少します (クラスターに着信する要求の数が同一であると仮定した場合)。 同様に、クラスターから新規メンバーを除去すると、 そのクラスター内の各サーバーに送信される要求の数は増加します (クラスターに着信する要求の数が同一であると仮定した場合)。
例えば、メンバー A、B、および C から構成されるクラスターがあり、 それぞれのウェイトが 2、3、および 4 である場合、要求の 2/9 はメンバー A に割り当てられ、 3/9 はメンバー B に、4/9 はメンバー C に割り当てられます。 新規メンバー D がこのクラスターに追加され、メンバー D のウェイトが 5 であれば、 メンバー A は要求の 2/14 を取得し、メンバー B は 3/14、メンバー C は 4/14、メンバー D は 5/14 を取得することになります。
データ型 | 整数 |
範囲 | 0 から 20 |
クラスター内で固有なアプリケーション・サーバーの数値 ID を指定します。 この ID は類縁に使用されます。
データ型 | 整数 |
データ型 | 16 進数 |
このクラスター・メンバーのショート・ネームを指定します。このフィールドは、z/OS で実行している場合にのみ表示されます。
ショート・ネームは、デフォルトの z/OS ジョブ名であり、Workload Manager (WLM)、自動リスタート・マネージャー、SAF (例えば RACF®)、始動済みタスク制御などのオペレーティング・システム固有の機能に対してクラスター・メンバーを識別します。
ショート・ネームを指定しない場合、システムは、セル内で自動的に固有となるデフォルトのショート・ネームを割り当てます。ご使用の命名規則に準拠させるように、生成されたショート・ネームを変更することができます。
データ型 | ストリング |
このオプションを使用可能にすると、アプリケーション・サーバーの起動時間が短縮されることがあります。 これには、バイトコード検証の使用不可化やジャストインタイム (JIT) コンパイラーのコンパイル・コストの削減など、 Java™ 仮想マシン (JVM) 設定が含まれることがあります。 実働サーバーでは、 この設定を使用可能にしないでください。この設定は、バージョン 6.0 以降のセルで稼働しているアプリケーション・サーバー上でのみ使用可能です。
このオプションは、i5/OS® 環境ではサポートされていません。
開始時に JVM 設定 -Xverify および -Xquickstart を使用することを指定します。 このオプションを選択した後、構成を保管し、サーバーを再始動して開発モードを活動化します。
このオプションのデフォルト設定は false であり、 サーバーが開発モードでは始動しないことを示しています。 このオプションを true に設定すると、サーバーはサーバー起動時間を短縮する設定を使用して開発モードで開始されます。
データ型 | ブール |
デフォルト | false |
複数のスレッドでサーバーを始動するかどうかを指定します。マルチスレッド上でサーバーを開始すると、サーバー・コンポーネント、サービス、およびアプリケーションは、順次ではなく並列に開始するので、起動時間が短くなる場合があります。
このオプションのデフォルト設定は true であり、 サーバーは始動時にマルチスレッドを使用することを示しています。 このオプションを false に設定すると、 サーバーは始動時に単一スレッドを使用するように指定されます。 これにより、起動時間が長くなる可能性があります。
アプリケーションが開始する順序は、ユーザーがそれぞれのアプリケーションに割り当てるウェイトに従います。 開始ウェイトが最も小さいアプリケーションが最初に始動します。開始ウェイトが同じアプリケーションは、パラレルで開始します。アプリケーションの開始ウェイトを設定するには、管理コンソールの「アプリケーション」>「アプリケーション・タイプ」>「WebSphere エンタープライズ・アプリケーション (WebSphere enterprise applications)」>「application_name」>「始動の動作」ページにある「開始ウェイト」フィールドを使用します。
データ型 | ブール |
デフォルト | true |
このクラスター・メンバーで実行中のアプリケーションが必要とするときにクラスター・メンバー・コンポーネントを開始させる場合は、このフィールドを選択します。
このプロパティーを選択すると、クラスター・メンバー・コンポーネントは 必要に応じて動的に開始されます。このプロパティーを選択しないと、クラスターの 開始プロセス中にすべてのクラスター・メンバー・コンポーネントが開始されます。したがって、このオプションを選択すると、開始プロセス時に開始されるコンポーネントの数が減るので、 起動時間が改善され、クラスター・メンバーのメモリー使用量が削減されます。
クラスター上でデプロイされるアプリケーションがすべて同じタイプである場合は、必要に応じてコンポーネントを起動することが最も効果的です。 例えば、使用中のアプリケーションがすべて、サーブレットおよび JavaServer Pages (JSP) を使用する Web アプリケーションである場合は、このオプションの使用は効果的です。 使用中のアプリケーションが、サーブレット、JSP、および Enterprise JavaBeans™ (EJB) を使用している場合は、このオプションを使用してもそれほど効果的ではありません。
アプリケーション・サーバーが 64 ビット・モードで実行するように指定します。これは、デフォルト設定です。 64 ビット・モードで実行すると、追加の仮想ストレージがユーザー・アプリケーションに提供されます。 このフィールドは、z/OS で実行している場合にのみ表示されます。
アプリケーション・サーバーを 31 ビット・モードで実行する必要がある場合は、この設定を選択解除することができます。
さまざまなサーバーを実行しているモード間に相互依存関係はありません。 したがって、サーバーのいくつかを 64 ビット・モードで実行し、いくつかを 31 ビット・モードで実行することができます。 ただし、最終的にすべてのサーバーを 64 ビット・モードで実行するように変換する必要があります。 それは、31 ビット・モードで稼働するサーバーに対するサポートが推奨されないためです。
このサーバーで実行しているアプリケーションが多数のサーバー実装クラスにアクセスできるかどうかを指定します。
「Allow」を選択した場合、アプリケーションは、ほとんどのサーバー実装クラスにアクセスできるようになります。 「Restrict」を選択した場合、アプリケーションは、サーバー実装クラスにはアクセスできません。 アプリケーションは、これらのクラスへのアクセスを試みると、ClassNotFoundException エラーを受け取ります。
通常の場合、このプロパティーには Restrict を選択します。 それは、ほとんどのアプリケーションはサポートされる API を使用し、どの内部クラスにもアクセスする必要がないためです。 しかし、アプリケーションが 1 つ以上の内部サーバー・クラスを使用する必要がある場合は、 このプロパティーの値として Allow を選択します。
このプロパティーのデフォルト値は Allow です。
単一のクラス・ローダーですべてのアプリケーションをロードするか、 または異なるクラス・ローダーで各アプリケーションをロードするかを指定します。
クラス・ローダーが、クラスをロードする際に、 最初に親クラス・ローダーを検索するのか、 あるいはアプリケーション・クラス・ローダーを検索するのかを指定します。 Developer Kit のクラス・ローダーおよび製品のクラス・ローダーの標準は、「最初に親クラス・ローダーをロードしたクラス」です。
このフィールドは、「クラス・ローダー・ポリシー」フィールドを「単一 (Single)」に設定した場合にのみ適用されます。
「最初にローカル・クラス・ローダーをロードしたクラス (親が最後) (Classes loaded with local class loader first (parent last))」を選択した場合、アプリケーションは、親クラス・ローダーに含まれるクラスをオーバーライドできますが、オーバーライドされたクラスとオーバーライドされていないクラスを一緒に使用した場合、このアクションにより、ClassCastException またはリンケージ・エラーが発生する可能性があります。
クラスター内のアプリケーション・サーバーの名前を指定します。ほとんどのプラットフォームでは、 サーバーの名前はプロセス名です。メンバー名は、アプリケーション・サーバー・ページにリストされているサーバーのいずれかの名前と一致している必要があります。
アプリケーション・サーバーに送信される要求の数を制御します。 サーバーのウェイトとして 0 から 20 までの値を指定しても、 サーバーに割り当てられるウェイトは、 サーバーに割り当てられたウェイトが分子、クラスターのすべてのメンバーの ウェイトの合計が分母となる比率となります。
新規メンバーをクラスターに追加すると、 そのクラスター内の各サーバーに送信される要求の数は減少します (クラスターに着信する要求の数が同一であると仮定した場合)。 同様に、クラスターから新規メンバーを除去すると、 そのクラスター内の各サーバーに送信される要求の数は増加します (クラスターに着信する要求の数が同一であると仮定した場合)。
例えば、メンバー A、B、および C から構成されるクラスターがあり、 それぞれのウェイトが 2、3、および 4 である場合、要求の 2/9 はメンバー A に割り当てられ、 3/9 はメンバー B に、4/9 はメンバー C に割り当てられます。 新規メンバー D がこのクラスターに追加され、メンバー D のウェイトが 5 であれば、 メンバー A は要求の 2/14 を取得し、メンバー B は 3/14、メンバー C は 4/14、メンバー D は 5/14 を取得することになります。
データ型 | 整数 |
範囲 | 0 から 20 |
このサーバーにネイティブ・オペレーティング・システムのプロセス ID を指定します。
プロセス ID プロパティーは、読み取り専用です。この値は、自動的に生成されます。
このサーバーが稼働しているセルの名前を指定します。
「セル名」プロパティーは、読み取り専用です。
このサーバーが稼働しているノードの名前を指定します。
「ノード名」プロパティーは、読み取り専用です。
このサーバーのランタイム状態を指定します。
「状態」プロパティーは、読み取り専用です。