予想外のアプリケーション配置の動作が発生する場合があります。
このトピックでは、アプリケーション配置が予期したとおりに機能しない場合に確認する、よくある質問および一般的な事項について説明します。
アプリケーション配置コントローラーはどこで実行されているのか?
アプリケーション配置コントローラーが実行されている場所を見つけるには、管理コンソールまたはスクリプティングを使用することができます。管理コンソールでその場所を確認する場合は、をクリックします。また、checkPlacementLocation.jacl スクリプトを実行することによっても、アプリケーション配置コントローラーが実行されているサーバーが表示されます。
どのような場合にアプリケーション配置コントローラーはサーバーを始動するのか?
アプリケーション配置コントローラーは、以下の場合にサーバーを始動します。
- 動的クラスターに定義されたアプリケーション・インスタンスの最小数を満たす場合。
- 要求が、オンデマンド要求ルーターにより、非アクティブな動的クラスターに対してルーティングされた場合。
- 動的クラスターが、追加能力により利益が得られる可能性がある場合。
オートノミック要求フロー・マネージャーによって、追加能力の設定が動的クラスターにいかに有益であるかを示すシグナルが通知され、動的クラスターに対する追加インスタンスが開始されます。
アプリケーション配置コントローラーが識別できる所で何が実行されているかを確認するには、
SystemOut.log メッセージを参照してください。
どのような場合にアプリケーション配置コントローラーはサーバーを停止するのか?
アプリケーション配置コントローラーは、以下の場合にサーバーを停止します。
- ノードにメモリー制約がある場合。アプリケーション配置コントローラーは、動的クラスターに対する最小、またはその動的クラスターに必要な容量とシステムのプロセッサー制約およびメモリー制約を識別します。あるノードの使用可能メモリーが低くなると、アプリケーション配置コントローラーは、インスタンスを停止して、そのノードがスワッピングしないようにします。
- 動的クラスターが、アプリケーションの遅延スタートおよび積極的なアイドル停止用に構成され、動的クラスターに要求がない場合。動的クラスターに要求がない場合、アプリケーション配置コントローラーは、そのクラスターのインスタンスを停止し、非アクティブな動的クラスターのリソース消費をなくそうとします。
どのような場合にアプリケーション配置コントローラーはサーバーを始動しないのか?
アプリケーション配置コントローラーは、以下のいずれかの場合にサーバーが開始されたことを表示しないことがあります。
- 構成が動的アプリケーション配置を使用可能にしていない場合
- 配置コントローラーが有効になっているか確認します。管理コンソールで、をクリックします。
- 1 つまたは複数のサブジェクト・クラスターが動的クラスターであるか確認します。アプリケーション配置コントローラーが機能するのは動的クラスター上のみです。
管理コンソールで、
をクリックします。
個々のサブジェクト・クラスターの「動作モード」フィールドが 「自動」になっているか確認します。
自動になっていない場合は、動的クラスターを選択し、
「自動」をクリックします。
動的クラスターの「自動」を選択した後、
「Set Mode」をクリックします。
- 配置変更パラメーター間の構成済み最小時間が
過大に設定されていないか確認します。
管理コンソールで、をクリックします。
「Minimum time between placement changes」フィールドの値を
適切な値に設定します。許容値は 1 分
から 24 時間までです。
- サーバー操作タイムアウト値の設定が低すぎる場合
時として、サーバー操作がタイムアウトになったために、アプリケーション配置コントローラーがサーバーを始動しないことがあります。管理コンソールで、タイムアウトが発生するまでの時間を構成することができます。
とクリックします。「サーバー操作タイムアウト」フィールドを編集します。
セルが大きい、システムが遅い、または、システムのワークロードが高い場合は、このフィールドを高い値に設定します。この値は、各サーバーが始動するまでの時間を表しますが、タイムアウトは、セル内のサーバー数に基づいて発生します。例えば、サーバーが 5 基あり、この値を 10 分に設定すると、タイムアウトは 50 分後に発生します。
- 使用可能なメモリーが十分にない場合
十分なメモリーが使用可能でない場合は、SystemOut.log ファイルの失敗した始動を参照すれば診断できます。
アプリケーション配置コントローラーでは、次の数式を使用して動的クラスター・メンバーのメモリー消費を計算します。
動的クラスター・インスタンスが実行されていない場合 (コールド・スタート):サーバー・メモリー消費 = 1.2 × maxHeapSize + 64 MB
他の動的クラスター・インスタンスが実行されている場合は、アプリケーション配置コントローラーのメモリー・プロファイラーでは次の数式を使用します:サーバー・メモリー消費 = 0.667 × 常駐メモリー・サイズ + 0.333 × 仮想メモリー・サイズ
メモリー・プロファイルは、アプリケーション配置コントローラーが再始動すると保持されません。
デバッグを行う場合は、memoryProfile.isDisabled カスタム・プロパティーを true に設定すれば、アプリケーション配置コントローラーのメモリー・プロファイラーを無効にできます。
失敗した始動情報の表示
要確認: 失敗した始動リストは、アプリケーション配置コントローラーが再始動する場合、またはノード間を移動する場合は保持されません。
失敗した始動情報は、次のいずれかのオプションにより確認できます。
- PlacementControllerProcs.jacl スクリプトを使用して、失敗したサーバー操作を照会する。
以下のコマンドを実行します。
./wsadmin.sh -profile PlacementControllerProcs.jacl -c "anyFailedServerOperations"
- wsadmin ツールを使用して、失敗した始動を表示する。
例えば、次のコマンドを実行します。
wsadmin>apc = AdminControl.queryNames('WebSphere:type=PlacementControllerMBean,process=dmgr,*')
wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations')
サーバーが使用可能になると、始動失敗フラグは外されます。次の wsadmin ツール・コマンドを使用すれば、始動失敗フラグが有効になっているサーバーをリストすることができます。
wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations') OpsManTestCell/xdblade09b09/DC1_xdblade09b09
- SystemOut.log ファイルの失敗した始動を確認する。
なぜアプリケーション配置サーバーが、予期したよりも多くのサーバーを始動したのか?
ネットワークまたは通信問題により、サーバーが始動したことを示す確認を、アプリケーション配置コントローラーが受信できない場合、予期したよりも多くのサーバーが始動することがあります。アプリケーション配置コントローラーが確認を受信しないと、追加のサーバーを始動する場合があります。
アプリケーション配置コントローラーがアクションを完了した場合、あるいは、これからアクションを実行する場合、それをどのようにすれば知ることができるか?
アプリケーション配置コントローラーのアクションは、ランタイム・タスクで確認することができます。ランタイム・タスクを表示するには、とクリックします。
ランタイム・タスクのリストには、アプリケーション配置コントローラーが実行しているタスク、および変更が行われた場合の確認が含まれます。各ランタイム・タスクには、成功、失敗、または、不明という状況が設定されます。「不明」状況は、タスクが成功したかどうかが確認されなかったことを示しています。
アプリケーション配置コントローラーに干渉せずにサーバーを始動または停止するにはどのようにすればよいか?
動的クラスターが自動モードの場合に、サーバーを始動または停止すると、アプリケーション配置コントローラーが、ユーザー・アクションを変更する決定を行う場合があります。サーバーの始動または停止時に、アプリケーション配置コントローラーに干渉しないようにするには、動的クラスターを手動モードにしてからサーバーを始動または停止してください。
異機種混合のシステム (混合ハードウェアまたはオペレーティング・システム) では、アプリケーション配置コントローラーはどのようにサーバーの始動場所を選択するのか?
動的クラスターのメンバーシップ・ポリシーにより、サーバーが始動できる適格なノードが定義されます。
アプリケーション配置コントローラーは、使用可能なプロセッサーおよびメモリー容量などのシステム制約を考慮して、このノードの集合からサーバーを始動するノードを選択します。オペレーティング・システムに基づいてサーバー配置に関する決定を行うことはありません。
使用している動的クラスターが負荷下にある時、どのような場合にアプリケーション配置コントローラーは別のサーバーを始動するのか?
アプリケーション配置コントローラーは、オートノミック要求フロー・マネージャー (ARFM)、および定義済みのサービス・ポリシーと連携して、サーバーを始動する時点を決定します。サービス・ポリシーは、アプリケーションのパフォーマンスおよび優先順位を最大に設定し、トラフィック・シェーピングおよび能力プロビジョニングの決定において、オートノミック・コントローラーをガイドします。サービス・ポリシーの目標は、間接的にアプリケーション配置コントローラーが行うアクションに影響します。アプリケーション配置コントローラーは、ARFM キューによってサービスを受けている同時要求の数に対して必要な能力に関する ARFM からの情報に応じて、追加サーバーを設定します。この数は、各要求がサービス提供される時にどのくらいの能力を使用し、ARFM がいくつの同時要求が適当と判別するかに基づいて決定されます。同時要求の数は、アプリケーションの優先度、目標などに基づきます。
サービス・ポリシーによって定義されるパフォーマンスの目標は、保証にはなりません。WebSphere® Virtual Enterpriseは、その限度よりも速くアプリケーションに応答させることはできません。さらに、サービス・ポリシーの目標が満たされていなくても、要求に見合う十分な能力が既に供給されている場合は、追加能力は供給されません。WebSphere Virtual Enterprise は、非現実的なサービス・ポリシーの目標によって環境が不安定にならないようにする場合があります。
アプリケーション配置コントローラーは、サーバーの最大ヒープ・サイズをどのように決定するのか?
サーバーのヒープ・サイズは、動的クラスター・テンプレートで変更することができます。詳しくは、
JVM ヒープ・サイズの変更
を参照してください。
アプリケーション配置コントローラーは、どのように Compute Grid と連携して機能するか、特にジョブのディスパッチ、およびエンドポイントの選択はどうなるか?
アプリケーション配置コントローラーと Compute Grid が連携するように構成されている場合、Compute Grid は、エンドポイントの選択タスクを配置コントローラーに委任します。ジョブが実行依頼されると、Compute Grid は、配置コントローラーにそのジョブを実行するエンドポイントの選択を要求します。Compute Grid では、アプリケーション配置コントローラーに対するこの要求に、ジョブのクラス、完了時刻の目標、およびジョブが実行を許可されるノード、クラスター、またはサーバーを情報として組み込みます。アプリケーション配置コントローラーがエンドポイントを選択すると、その情報は、ジョブの開始を受け持つ Compute Grid に戻されます。アプリケーション配置コントローラーがエンドポイントを選択する際には、ジョブの完了時刻の目標、システム内の使用可能なリソース、同クラスの以前のジョブの実行プロファイル、およびシステムが処理する必要がある他の作業 (トランザクション処理、バッチ処理の両方を含む) が考慮されます。
アプリケーション配置コントローラーでは、ジョブが完了時刻の目標どおり、あるいはそれより早く完了するために十分なリソースが供給されるようにエンドポイントを選択しようとします。必要な選択プロセスがあるため、ジョブのエンドポイントの選択は、必ずしも即時に行われるとは限りません。
そのような場合、ジョブはすぐには開始されません。このような遅れが発生するのは、システムが小さい場合、他のトランザクションまたはバッチ処理がある場合、およびジョブの完了時刻目標に余裕がある場合です。
アプリケーション配置コントローラーは、どのように WebSphere eXtreme Scale 連携して機能するのか?
アプリケーション配置コントローラーは、
WebSphere eXtreme Scale と統合することができます。具体的には、コンテナー・サーバーを含む動的クラスター・メンバーを停止する前に、アプリケーション配置コントローラーは、そのコンテナー・サーバーに接触して実行中の作業をすべて静止し、必要に応じて重要データをバックアップ・ロケーションに移動します。
カタログ・サービスでは、自動的に構成されたデプロイメント・マネージャーを始動します。カタログ・サービスに対してフェイルオーバーを構成したい場合は、カタログ・サービス・グリッドを作成できます。詳しくは、WebSphere Application Server 環境でのカタログ・サービス・プロセスの開始を参照してください。
アプリケーション配置では、WebSphere eXtreme Scale の複製ゾーンという概念も認識されます。アプリケーション配置コントローラーは、動的クラスターの複数のインスタンスが必要な場合には、それらのインスタンスが複数の複製ゾーンにまたがって配置されるようにします。
この機能を得るには、動的クラスターを複数の複製ゾーン・ノード・グループにマップする必要があります。詳しくは、レプリカ配置のためのゾーンの使用を参照してください。
なぜ動的クラスター・メンバーが、テンプレートからプロパティーを継承しないのか?
サーバー・テンプレートを変更する前に、動的クラスターをマスター・リポジトリーに保存する必要があります。
テンプレートからプロパティーを継承しない
動的クラスター・メンバーを持っている場合は、
サーバー・テンプレートが保存されないワークスペースで変更されていた
可能性があります。この問題を修正するには、
動的クラスターを削除して、再作成します。
変更内容はマスター・リポジトリーに保存します。
上部フレームのメッセージ・ウィンドウで「終了」をクリックしてから「保存」をクリックすると、変更内容をマスター・リポジトリーに確実に保存できます。「マスター構成に保存」ウィンドウで、再び「保存」をクリックします。「変更をノードと同期する」をクリックします。
動的クラスターのアクティブ・サーバーが少なすぎるのはなぜか?
動的クラスター内で稼働しているサーバーが不足している場所で
問題が発生している場合は、以下の操作を試みてください。
- ノード・グループ内のノードが十分に使用されていないときは、
サービス・ポリシーが満たされていることを確認します。
ポリシーが明確に定義されない場合でも、予想に反して、システムが適合できることがあります。
管理コンソールでサービス・ポリシーを確認または変更するには、「動作ポリシー」>「サービス・ポリシー」>「Select an existing policy」をクリックします。
ポリシーの目標タイプ、目標値、および重要度を確認し、
必要な変更を行います。
- ノード・グループのノードが十分に使用されている場合は、
このクラスターのサービス・ポリシー目標と、
ほかのアクティブ・クラスターのサービス・ポリシー目標とを比較します。
このクラスターに属すトラフィックがその他のクラスターと比べて
重要度が低いか、またはターゲット・サービス目標が緩い場合は、
システムは台数の減少したこのクラスター用サーバーをインスタンス化する
傾向が強くなります。
管理コンソールでサービス・ポリシーを確認または変更するには、「動作ポリシー」>「サービス・ポリシー」>「Select an existing policy」をクリックします。
- ノード・グループに余力があるように見えるが、サービス・ポリシーは満たされていない場合は、動的クラスターの構成設定値を確認してください。
maxInstances ポリシー設定の結果として作成された動的クラスターの
インスタンスが過小になっている可能性があります。