サービスに影響を与えるリソース障害のパターン
特定のサービス リソースの関係があまりに複雑すぎて、モデルの「状態」属性を監視するだけでは関係を把握することができないリソース監視シナリオに遭遇することがあります。より具体的には、モデルの「状態」には、追加リソースの監視条件に応じて、何らかの重要性があります。
casp1032jp
特定のサービス リソースの関係があまりに複雑すぎて、モデルの「状態」属性を監視するだけでは関係を把握することができないリソース監視シナリオに遭遇することがあります。より具体的には、モデルの「状態」には、追加リソースの監視条件に応じて、何らかの重要性があります。
以下のようなシナリオについて考えてみます。リモート オフィスに勤務するアカウント管理チームは、カスタマ情報にアクセスするため、ローカル データベース サーバを使用します。ローカル システムがダウンしている場合、アカウント管理チームは本社のサーバに接続することで、必要な情報にアクセスできます。カスタマ アカウント システムを表すサービスは、以下のように機能します。
- ローカル サーバがダウンしていて、本社のサーバが稼働状態の場合、カスタマ アカウント サービスは「やや低下」と考えられます
- ローカル サーバが稼働状態で、本社のサーバがダウンしている場合、カスタマ アカウント サービスは「稼働」と考えられます。
- ローカル サーバがダウンしていて、本社のサーバがダウンしている場合、カスタマ アカウント サービスは「ダウン」と考えられます。
- ローカル サーバがダウンしていて、本社のサーバが保守状態の場合、カスタマ アカウント サービスは「ダウン」と考えられます。
- ローカル サーバが保守状態で、本社のサーバが保守状態の場合、カスタマ アカウント サービスは「ダウン」と考えられます。
サービスに影響を与えるシナリオは非常に複雑です。サービスを提供する 2 つのサーバがある場合でも、サーバは平等に処理されません。
相関ドメインを使って個々のリソースを監視する複雑さを管理するなど、リソース監視シナリオを処理する場合があります。
2 つのリソース モニタを利用するサービスを使って、この例を実装できます。まず、ローカル サーバをシンプルな障害マトリックスを使用する、独自のリソース モニタに分離します。ローカル サーバ RM は、このパターンをサポートするポリシーを使用します。
ローカル サーバ | サービス ヘルス |
稼働 | 稼働 |
ダウン | わずかに低下 |
ローカルおよびリモート ドメイン RM である、2 番目のリソース モニタには、次のようなシンプルな障害マトリックスがあります。
ローカルおよびリモート ドメイン | サービス ヘルス |
稼働 | 稼働 |
ダウン | ダウン |
ローカルおよびリモート ドメイン RM は、ローカル サーバ用のホスト モデルと、本社サーバ用のホスト モデルを含んでいる相関ドメインを監視します。
相関ドメインの「状態」の以下のステータス テーブルを確認します。
ローカル サーバ | リモート サーバ | ドメイン状態 |
正常 | 正常 | 正常 |
接続切断 | 正常 | 正常 |
正常 | 接続切断 | 正常 |
接続切断 | 接続切断 | 重大 |
接続切断 | 保守 | 重大 |
保守 | 保守 | 重大 |
保守 | 接続切断 | 重大 |
ドメインは、以下のルールのポリシー（すべてが根本原因ターゲットに対してドメインを利用する）を使用します。
- Device Contact Lost Count = 2 Implied Cause Service Impact Down
- DeviceInMaintenance Count = 2 Implied Cause Service Impact Down
- Device Contact Lost Exists AND DeviceInMaintenance Exists AND Device Contact Lost Model Does Not Equal DeviceInMaintenance Model Implied Cause Service Impact Down
カスタマ アカウント サービスは、以下の方法で 2 つのリソース モニタのサービス ヘルスを監視します。
ローカル サーバ RM | ローカルおよびリモート デーモン | サーバ ヘルス |
稼働 | 稼働 | 稼働 |
わずかに低下 | 稼働 | わずかに低下 |
わずかに低下 | ダウン | ダウン |
稼働 | ダウン | ダウン |
カスタマ アカウント サービスのヘルスは、2 つのリソース モニタのうちの最低のステータス（一般的には高感度パターン）に基づいています。
この方法を使用すると、シナリオに複雑な要件がある場合でも、サービスに対する正確なリソース監視機能を作成できます。