前のトピック: リソースおよびリソース管理次のトピック: カスタム属性


リソース ライフ サイクルについて

リソースは、時間の経過に伴ってその特性を変更できる物理的または論理的なエンティティです。 リソースは、ある時点で、特定のサービス コンポーネント、契約関係者などに配置され、その後、将来ある時点で再配置される場合があります。 任意の時点で計算を実行できるようにするために、その正確な時間のリソースの設定および配置に基づいて、これらの変更または再配置はそれぞれ CA Business Service Insight によってキャプチャされます。

リソースの変更またはその配置はいつでも行なうことができますが、そのリソースの新バージョンを作成する必要があります。 新しいバージョンにはそれぞれ発効日(変更が発生する日)を設定する必要があります。 その後、変更は将来に引き継がれます。ただし、その同じリソースの後続バージョンで追加の変更が発生した場合はこの限りではありません。 この新しいバージョンがアクティブにされて有効になった後は、計算エンジンのみがすべての変更を認識および利用することができます。 このプロセスは、リソースの「コミット」と呼ばれます。

CA Business Service Insight では、1 つの手順で複数のリソース配置を処理する方法もあります。 この方法では「変更セット」が使用されます。 変更セットにより、トランザクション データベースが動作する方法と同様に、単一の「トランザクション」で大量のリソース変更を行うことできます。 変更セットに配置されているすべてのリソースに対してすべての変更を行なうには、変更セット全体に対する操作を実行した後に、1 つの手順で変更セットをコミットします。

リソースおよびそれらの変更を処理する際に、計算エンジンについて以下の点を考慮することをお勧めします。

上記の例はリソースを直接扱うものではなく、リソースの機能や場所(上記の例ではリソースの機能(データ センター サーバ))への論理的な配置を通じてリソースを扱っています。

データ センターに保持された個別のサーバごとにイベントがリクエストされる場合、登録リクエストは非常に煩雑になる可能性があります。 1 つの問題は、参照されるリソースの数です。 もう 1 つの問題は、データ センターのインフラストラクチャが定期的に変更されることです。その結果、データ センターに含まれていたサーバが現在はそこに存在しなくなったり、新しいサーバが追加されていたりする場合があります。 そのため、動的なリストにする必要があります。

上記の例に基づいて、論理的なエンティティ(論理グループ)を介してリソースを扱うことができるように、論理グループにリソースを添付する必要があることは明らかです。 さらに、論理グループが常に変更されている場合は、論理グループ自体の管理が必要になることもあります。

リソース配置は、リソースのタグ付けに関する CA Business Service Insight の方法です。 リソースは、複数のグループ、リソース タイプ、契約関係者、またはサービスに配置することができます。 リソース配置は CA Business Service Insight バージョン コントロールによって管理されます。

計算に含めるために利用できるリソースは、システム内で現在有効になっているリソースによって決まります(その時点で計算されている時間範囲に関連します)。

ここで上記の例に戻ります。

データ センター サーバの全体的なダウンタイム数

システムでは、データ センターはデータ センター内のすべてのサーバが配置されるサービスとして表すことができます。 また、「データ センター サーバ」と呼ばれるリソース グループとして定義することもできます。 これらは、この特定のケースでリソース配置のために選択できる 2 つの代替方法ですが、利用可能なオプションはほかにもあります。

以下の図は、リソースが添付される可能性のあるエンティティ、およびそれらの論理的な用途を示します。

リソースおよびリソース管理

リソース グループは、計算に必要なリソースの要素(リソースの場所やリソースに含まれる技術など)をすべて反映できます。

これらのエンティティにリソースを配置する主な目的は、計算要件を満たすこと、およびモデルを可能な限り動的な状態に維持することです。