WebSphere Enterprise Service Bus バージョン 6.2.0 オペレーティング・システム: AIX、HP-UX、i5/OS、Linux、Solaris、Windows


システムの状態の評価

異常状態が発生したときに取るべき最初の行動は、システム全体の動向 を調べ、システムはどの程度稼働しているのか、および何であれその状態を引き起こした外部要因によってどれほどのシステム要素が「サービス停止」となったのかを把握することです。

事前定義した質問セットに答えて、障害の範囲を見積もります。以下に、適切な情報の収集に役立つように考案された事前定義の質問の例を示します。
  1. このシステムは依然として稼働しているか?

    システムが依然として稼働しているかどうかを判別します。多くの場合、システムは稼働可能でも、過負荷、不適切なチューニング、あるいはその両方の理由により、タスクを迅速に完了していないか、実際には失敗する処理を実行しようとしています。

    これらの質問のそれぞれに対するリトマス試験は、デプロイされているソリューションの性質に固有のものです。

  2. アプリケーションに組み込まれている特別なエラー処理サポート機能は何か?

    数多くの自動化再試行およびさまざまなサポート・ロジックが存在する場合は、アプリケーション自体が、一部のエラーを隠して IT オペレーターに明示されないようにすることがあります。

    このような状態は、リカバリー・チームが参照できるよう、周知および文書化される必要があります。

システムの状態を見積もるのに役立つタスクを以下に示します。
  1. サーバーが少なくとも動作しているかどうかを調べます。

    管理コンソールを介して、PID が表示されたか、または Deployment Manager から肯定のフィードバックを取得しましたか?

  2. データベース内にロックが存在するかどうか、または異常なデータベース・トラフィックが存在するかどうかを調べます。
    ほとんどのデータベースには、ロックを検出する機能があります。デプロイメント・トポロジーに応じて、複数のデータベースが存在する可能性があります。
    • メッセージング・エンジン・データベース
    • Business Process Container データベース
    • WebSphere® Process Server 共通データベース (失敗したイベントおよびリレーションシップ・データ)
  3. メッセージング・システムの状況を調べます。
    以下の場所にイベントまたはメッセージがあるかどうかを確認します。
    • Business Process Choreographer の保留宛先と保存宛先
    • 失敗したイベントの数
    • ソリューション・モジュール宛先のメッセージの数
  4. データベースが機能しているかどうかを調べます。

    アンロックされたデータで、何らかの単純な SELECT オペレーションを妥当な時間内に実行することができますか?

  5. データベース・ログにエラーがあるかどうかを調べます。

データベースが正常に稼働していない場合は、データベースをリカバリーする (これにより、少なくともロック解除され、単純な選択オペレーションを実行できるようになります) ことがシステムのリカバリーにとっても重要です。

メッセージング・システムが正常に稼働していない場合は、メッセージング・サブシステムをリカバリーして最低でも表示および管理できるようにすることが、システムのリカバリーにとっても重要です。

注: 「ボトムアップ」方式が必ずしも確実な方法とは限りません。しかし、リカバリーを正常に実行できる確率は、これらの基本的なアクティビティーに基づいています。

このような基本的な手順および正常性検査の類に含まれるアクティビティーから始めて、いくつかの固有のシチュエーションを探し出す必要があります。パターンについて説明され、仕様が定められ、水面下で進行している状況に関する洞察が与えられます。

このシチュエーション分析は、読み取り専用アクティビティーであることを認識してください。 この分析により、適切なリカバリー・アクションを判別するための重要な情報が提供されますが、検討中のシステムの状態は変更されません。システム障害について考えられる原因すべてを予測し、アクションの規定を設けることは不可能です。例えば、以下のデシジョン・ツリーについて考慮してみます。

リカバリーに対応する場合のデシジョン・ツリーを示した図。

計画外の停止イベントでは、調査するカテゴリーが広範に及びます。これらの広範なカテゴリーには、サブカテゴリーなども含まれています。各ノードとその後続ノードについて規定のアクションを定義することは、各調査の結果に依存します。このタイプのリレーションシップは文書形式で伝達することが難しいため、IBM® Guided Activity Assist などのサポート・ツールを活用し、調査および決定プロセス全体を対話式に処理することをお勧めします。最上位から各子ノードに進むにつれ、適切なレベルのシチュエーション分析を実施することが重要になります。


concept 概念トピック

ご利用条件 | フィードバック


タイムスタンプ・アイコン 最終更新: 2010/07/05


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cpln_assess_sys_state.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
このインフォメーション・センターでは Eclipse テクノロジーが採用されています (http://www.eclipse.org)。