リソース モデルが存在しない
サービス モデルを構築する場合の最も一般的な問題は、すべてのサービス リソースを識別できないことです。この根本原因は、通常、エンド ユーザに直接サービスを提供しているリソースを識別し、そのリソースが依存している機能を識別しないことです。
casp1032jp
サービス モデルを構築する場合の最も一般的な問題は、すべてのサービス リソースを識別できないことです。この根本原因は、通常、エンド ユーザに直接サービスを提供しているリソースを識別し、そのリソースが依存している機能を識別しないことです。
ユーザ側のアプリケーションに焦点を当てることが多い、Web ベースのアプリケーションの例を続けましょう。まず、アプリケーションをホストするサーバについて説明します。これは大きな出発点ですが、アプリケーションをサポートするサーバを見逃していたことに気づく場合もあります。コンテンツを提供するため、Web アプリケーションがデータベースにどのように依存しているかを検討します。以下のテーブルは、障害マトリックスの変更を示します。
データベース | サーバ 1 | サーバ 2 | サービス ヘルス |
稼働 | 稼働 | 稼働 | 稼働 |
ダウン | 稼働 | 稼働 | ダウン |
ダウン | ダウン | 稼働 | ダウン |
ダウン | 稼働 | ダウン | ダウン |
ダウン | ダウン | ダウン | ダウン |
稼働 | ダウン | 稼働 | わずかに低下 |
稼働 | 稼働 | ダウン | わずかに低下 |
稼働 | ダウン | ダウン | ダウン |
このテーブルは少し複雑ですが、データベースが追加されたことで、以前特定したルール セットが機能しなくなったことがわかります。データベースがダウンした場合、サーバ 1 とサーバ 2 のステータスにかかわらず、サービスは「ダウン」です。
このタイプのパターンはよく見られます。また、サービスが、Web サーバよりも多くのリソースに依存するため、Web サーバとは動作が異なる予備のリソースが必要となります。この新しいリソース セットをサポートするには、「リソース監視」という名前の新しいモデル タイプを使用します。
リソース モニタのジョブは、単一のポリシーで容易にキャプチャできる動作パターンに従わない、多様なリソース セットを管理することです。リソース モニタは、ポリシーを一連のリソース値に適用して、自分のヘルスを決定するという点で、サービスに類似しています。リソース モニタを一種のサブサービスのタイプとみなすと役立つことがあります。リソース モニタ自体は、論理サービスではなく、倫理サービスのクリティカルな様相を表しています。
この例では、どのようにリソース モニタを使用できるかを確認できます。Web サーバ、およびサービスのヘルスに対する Web サーバの関係に対して、以下の動作がキャプチャされます。
サーバ 1 | サーバ 2 | サービス ヘルス |
稼働 | 稼働 | 稼働 |
ダウン | 稼働 | わずかに低下 |
稼働 | ダウン | わずかに低下 |
ダウン | ダウン | ダウン |
データベースがサービスにどのような影響を与えるかを特に検討する場合、単純なマトリックスが作成されることがあります。
データベース | サービス ヘルス |
稼働 | 稼働 |
ダウン | ダウン |
これらの各パターンは独自のリソース モニタにキャプチャします。
データベース RM は、以下のルールを使ってデータベース リソースを監視します。
- すべてのリソースがダウンした場合、サービスは「ダウン」です
Web サーバ RM は、次のルール セットを使って Web サーバを監視します。
- いずれか 1 つのリソースが「ダウン」の場合、サービスは「やや低下」です
- すべてのリソースがダウンした場合、サービスは「ダウン」です
サービスは 2 つのリソース モニタを監視します。また、サービス ヘルスは、最低のリソース モニタのステータスを反映します。次の表は、サービスの障害マトリックスを表しています。
データベース RM | Web サーバ RM | サービス ヘルス |
稼働 | 稼働 | 稼働 |
ダウン | 稼働 | ダウン |
ダウン | わずかに低下 | ダウン |
ダウン | ダウン | ダウン |
稼働 | ダウン | ダウン |
稼働 | わずかに低下 | わずかに低下 |
このマトリックスから、サービス用の以下のルール セットを参照できます。
- いずれか 1 つのリソースがダウンした場合、サービスは「ダウン」になります。
- いずれか 1 つのリソースがわずかに低下した場合、サービスは「やや低下」になります。
2 つのホスト モデルの条件の監視から、2 つのリソース モニタのヘルスの監視にサービスを拡張することによって、サービス モデルの正確性を改善しました。データベース リソースがホスト モデルまたはデータベース サーバとして参照されないということを確認できます これは、データベースがサービス自体である可能性が高いためです。
リソースが欠落しているというこのシナリオは一般的なため、サービス モデルの作成時に検討できます。データベース サーバが初期段階でサービス リソースとして識別されなかった場合でも、サービスは今までどおり Web サーバ用の単一のリソース モニタを監視するために作成できます。後の段階で、新たなリソースが識別されるにつれて、サービス自体に新しいリソース モニタを簡単に追加できます。