リソース モデルの分離が十分でない

サービス リソースの欠落は確かに、不正確なサービス モデルの 1 つの一般的な原因です。サービス モデルの不正確さのもう 1 つの原因は、分離が十分でないリソース モデルです。通常、CA Spectrum はかなりのハイレベルでデバイスを監視し、非常に基本的な条件に基づいて、その「状態」をレポートします。たとえば、SNMP トラフィックに応答し、CPU およびメモリ使用量が正常なホスト モデルは、「稼働」または「正常」とみなすことができます。
casp1032jp
サービス リソースの欠落は確かに、不正確なサービス モデルの 1 つの一般的な原因です。サービス モデルの不正確さのもう 1 つの原因は、分離が十分でないリソース モデルです。通常、CA Spectrum はかなりのハイレベルでデバイスを監視し、非常に基本的な条件に基づいて、その「状態」をレポートします。たとえば、SNMP トラフィックに応答し、CPU およびメモリ使用量が正常なホスト モデルは、「稼働」または「正常」とみなすことができます。
Web アプリケーションのサービス例に戻って、Web アプリケーションが動作しているかどうか判断するために、単純なホスト監視が適切な場合を検討します。webserver 1 で、クリティカルなファイル システムがいっぱいになった場合に、実際の Web サーバに対する Web サーバでプロセスが実行されていないとします。この場合、ユーザは Web アプリケーション サービスを使用できませんが、特定の基本的なホスト監視では、サービス モデルのヘルスは「稼働」状態であることを示します。
アクセス可能なホストに加え、その他のさまざまな様相を監視して、Web アプリケーションが実行されているかどうかを決定できます。アプリケーション ステータスを確定するには、以下の共通コンポーネントを使用できます。
  • クリティカルなプロセスの監視
  • クリティカルなファイル システムの監視
  • アプリケーションの接続およびレスポンス時間の監視
各 Web サーバを見て、以下の例を使用して、障害マトリックスを定義できます。
ホスト
プロセス
ファイル システム
アプリ接続
サービス ヘルス
稼働
稼働
稼働
稼働
稼働
ダウン
ダウン
ダウン
ダウン
ダウン
稼働
ダウン
稼働
ダウン
ダウン
稼働
稼働
ダウン
稼働
ダウン
稼働
稼働
稼働
ダウン
ダウン
前掲の簡略なマトリックスでは、Web サーバが「稼働」しているとみなされるには、単なるホスト モデル以上のことを考慮する必要があります。Web サーバ プロセス、クリティカルなファイル システムおよび Web アプリケーションは、接続およびリクエストにも反応することがあります。
各 Web サーバは単なるホスト モデルではなく、それ自体が実際のサービスであることがわかります。前の例から、3 つのリソース モニタを持つサービスを想定することができます。
ホスト RM は単にホスト モデルの「状態」を監視します。プロセスおよびファイル システム(FS) RM は、プロセス モデルおよびファイル システム モデルの「状態」 を監視します。アプリ接続 RM は、サーバにリクエストを送信する、一連のレスポンス時間テストのステータスを監視します。
最初に、ホスト RM と、プロセスおよび FS RM が両方とも「状態」属性を監視しているとすると、この 2 つの RM を組み合わせて、単一のリソース モニタにすることができます。リソース モデルを、異なるモデル クラスを表す 2 つのリソース モニタに分けることができます。次のセクションでは、独自のモニタ内でホスト モデルを分離すると、ホスト関連の(サービスに影響を与えない)アラームを除外する機能が提供されます。
ホスト RM、およびプロセス/FS RM モデルにはシンプルな障害マトリックス テーブルがあります。
ホスト RM モデルの場合:
ホスト
サービス ヘルス
稼働
稼働
ダウン
ダウン
プロセスおよび FS RM モデルの場合:
プロセス
ファイル システム
サービス ヘルス
稼働
稼働
稼働
ダウン
稼働
ダウン
稼働
ダウン
ダウン
ダウン
ダウン
ダウン
アプリ接続 RM は、レスポンス時間監視に基づいています。CA Spectrum Service Performance Manager のマルチレベルしきい値機能を使って、より多くのヘルス値を作成するかどうかは、ユーザの裁量に任されています。わかりやすくするため、[タイムアウト]、[重大しきい値]および[メジャーしきい値]設定を見ます。以下のマトリックスは、レスポンス時間テスト値の簡潔なセットを表しています。
応答時間
サービス ヘルス
正常
稼働
タイムアウト
ダウン
重大しきい値
ダウン
メジャーしきい値
低下
単一の Web サーバに対して、以下の障害マトリックスを考慮します。
ホスト RM
プロセスおよび FS RM
アプリ接続 RM
サービス ヘルス
稼働
稼働
稼働
稼働
ダウン
ダウン
ダウン
ダウン
稼働
ダウン
ダウン
ダウン
稼働
稼働
ダウン
ダウン
稼働
稼働
低下
低下
Web サーバが「稼働」しているとみなされるにはすべてのリソース モニタが「稼働」している必要があることを決定できます。これは、単一の Web サーバに対する障害動作であることを忘れないでください。
以前、レビューで、データベース RM と Web サーバ RM という 2 つのリソース モニタを含むように、アプリケーション サービスを拡張しました。このとき、Web サーバ RM は、2 つのホスト モデルの「状態」を監視していました。前掲のマトリックスから識別できることは、2 つのホスト モデルではなく、おのおのが 3 つのリソース モニタを持つ 2 つのサービス モデルして Web サーバを表すことができるということです。前の設定が引き続き適用されますが、現在、Web サーバ RM は、2 つのホストの「状態」ではなく、2 つのサービス モデルのサービス ヘルス属性を監視しています。Web アプリケーション サービスの精度が大幅に向上したにもかかわらず、サービスの構造は変更されていないことがわかります。初期に決定された障害マトリックスは正確なままです。
データベース RM
Web サーバ RM
サービス ヘルス
稼働
稼働
稼働
ダウン
稼働
ダウン
ダウン
わずかに低下
ダウン
ダウン
ダウン
ダウン
稼働
ダウン
ダウン
稼働
わずかに低下
わずかに低下
改善された点は、Web サーバ RM に対する「稼働」の定義です。