名前と説明

サービス名および説明によってサービス モデルを識別します。サービスの説明が一意であれば、名前が同じサービスを複数定義できます。サービス名を定義することに対してルールがありません。ただし、サービス管理階層外でサービス モデルに遭遇する場合、サービス モデルを識別できる特定の命名スキームまたは命名規則を使用することをお勧めします。一部の命名スキームには、サービスを地理的または組織的に分類できる複数のパートが含まれています。その他の命名スキームは、サービスを特定のカスタマや機能に関連付けます。サービスの説明でおけるサービス役割を記述することは、有益なプラクティスです。サービス役割は計画段階で決定され、サービス モデルの機能および目的を説明します。

重大度

サービスの重大度は、低（10）から高（30）の範囲の列挙値です。サービス重大度のすべてまたは一部は、サービスに影響を与える任意のリソース アラームの影響度値に追加できます。サービスが停止した場合は、値がそのまま計算に組み込まれます。リソース アラームの結果としてサービスが「低下」した場合、そのサービスの重大度の値の 1/2 が、アラームの影響度計算に組み込まれます。サービスが「やや低下」した場合、その値の 1/5 が計算に組み込まれます。以下の重大度値を確認します。

低（デフォルト）= 10
やや低 = 15
中 = 20
やや高 = 25
高 = 30

たとえば、「低下 - 高重大度」サービスは、(50%) * 30 = 15 の影響度になり、「ダウン - 低重大度」サービスは、(100%) * 10 = 10 の影響度になります。「低下 - 高重大度」サービスを生じさせたアラームは、「ダウン - 低重大度」サービスを生じさせたアラームと比べてより大きい影響があります。アラームが影響度値によって並べ替えられ、優先順位が付けられる場合、最もクリティカルなサービスに影響を与えるアラームは最高優先度を与えられます。

ランドスケープ

［ランドスケープ］フィールドは、サービス モデルが存在するランドスケープを指定します。ランドスケープ オプションは、分散環境で複数の SpectroSERVER が展開されている場合にのみ表示されます。パフォーマンスを最適化するには、すべてのリソースまたはほとんどのリソースが存在するランドスケープにサービスを作成します。サービスに複数のランドスケープにまたがるリソースが存在する場合は、「DSS 環境内のサービス モデル」を参照してください。

保守モード

サービス モデルは、CA Spectrum での他の多数のモデルと同様に、メンテナンス モードをサポートします。サービスが「保守モード」の場合、リソースをアクティブに監視していません。サービス階層の構築とリソースの特定の実行中に、サービス停止の発生を回避するため、サービスを保守モードで作成できます。この保守機能では、サービスが建築中であることを示すためにモデルが使用されます。サービス モデルは定期保守もサポートします。定期保守は、サービスがリソースのアクティブな監視を停止する、事前設定済みの期間を定義します。一般的に、サービス レベル アグリーメントは、サービス保守に対して予約済み期間を指定します。

サービス アラームの生成

各サービスは、サービス ヘルスの変化に対応するアラームを生成するように設定できます。サービス用のアラーム生成を無効にすることは、アラームを生成できないことを意味しますが、サービス ヘルスはこれまでと同様、ポリシー評価に基づいて変更されます。OneClick コンソールとサービス ダッシュボード内のすべてのアイコンは、アラームが生成されたかどうかにかかわらず、サービス ヘルスに対応する色を表示します。サービス アラームの生成の設定にかかわらず、サービスの重大度のすべてまたは一部は、サービス ヘルスに影響を与える任意のリソース アラームに追加されます。サービス モデル自体に対してアラームが生成されない場合でも、サービスは該当するリソース アラームのサービス影響度テーブルに表示されます。サービスに関連付けられたすべての保証モデルは、停止に関するアラームが生成されたかどうかにかかわらず、停止時間を追跡します。サービス アラームの生成を無効にするには、いくつかの理由があります。まずは、CA Spectrum で生成されるアラームの数を減らすためです。すべてのリソース アラームがサービス影響度を示していることが確実な場合、サービス アラームは不要と考えられます。サービス アラームを無効にするもう 1 つの理由は、アラームが冗長的な場合です。通常、同じリソースを多数監視していても、役割が異なるサービスが複数作成されます。たとえば、サービスのリアルタイム ステータスに焦点を当てて、アラームを生成できるサービス モデルを作成できます。その他のサービス モデルは、SLA 目的でサービス モデルの特定の様相またはリソースを監視し、アラームを生成されないように設定できます。

コンテナ

コンテナの設定は、指定されたリソースが一種のコンテナ モデルである場合、サービスがどのようにそのリソースを監視するかを指定します。この設定は、タイプがコンテナで、コンテナ以外のリソースには使われないリソースにのみ適用されます。別のタイプのコンテナをサービスに追加できます。コンテナのタイプに応じて、コンテナ モデル自体を監視するサービスや、コンテナの内容を設定できます。［コンテンツの監視］（デフォルト）に設定すると、サービスはコンテナ内のモデルにポリシーを適用します。［コンテナの監視］を使用する場合、サービスはコンテナ自体にポリシーを適用します。［コンテンツの監視］が指定されると、サービスは、コンテナ モデルの包含関係を監視し、モデルがコンテナを対象に追加または削除されると、そのリソースを更新します。たとえば、ネットワークのアップグレードで、ルータを物理的に削除し、新しいルータに取り換えた場合の影響について考えてみます。Service Manager が監視するコンテナ モデルで、ルータ モデルが置換されると、元のルータ モデルはサービスから自動的に削除されます。同じコンテナに新しいルータが設置されると、新しいルータは、サービスの一部として自動的に監視されます。多くの環境は、動的な傾向（サービス リソースが定期的に変更される可能性）があります。容量を増加させて、失敗のリスクを緩和する、新しいインフラストラクチャ コンポーネントの追加を検討します。これらのリソースがサービスに追加されるにつれて、これらのリソースを考慮に入れることができます。構造化されたコンテナおよびサービスは、このような種類の変更に容易に適合できます。OneClick コンソールまたはサービス ダッシュボードの［情報］ビューで、［リソースを提供するコンテナ］の下に、サービス内のコンテナの一覧を表示できます。以下のイメージを検証します。

サービス ポリシー

計画フェーズでは、監視するリソース属性と、サービス ヘルスを決定するルール セットを識別しました。この動作に一致する既存のポリシーを選択することも、新しいポリシーを作成することもできます。ポリシーには、サービスが監視するリソースの動作を反映させる必要があります。まずリソース属性を監視できるポリシーを選択し、次にリソースの動作をまとめて最善に反映するポリシーを選択できます。たとえば、サービスが 1 組の冗長サーバを監視している場合、冗長性タイプ ポリシーが適切になります。単一のポリシーがリソースの動作を正確に反映していないことを判明した場合、特定の監視要件に基づいてリソースを整理するため、複数のリソース モニタを作成できます。Service Manager には、一般的なサービス監視の要件に合う標準のポリシー セットが用意されています。これを使用して、特別な要件に合うカスタム ポリシーを作成できます。