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