リソース モデルの分離が十分でない
サービス リソースの欠落は確かに、不正確なサービス モデルの 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 に対する「稼働」の定義です。