識別ルール
CMDB 識別プロセスは、CI を一意に識別するために識別ルールに依存します。
識別ルールは CI クラスに適用され、単一の CI ID と 1 つまたは複数の識別子エントリおよび関連エントリで構成されます。エントリはそれぞれ異なる優先度を持ちます。各識別子エントリは特定の優先度を持つ一意の属性セットを定義し、各関連エントリは関連アイテムを識別するためのルールを定義します。最強の識別子エントリと関連エントリに最高の優先度が設定されている強力な識別ルールを作成します。
- 一意の属性
- CI を一意に識別するために使用できる、CI の基準属性値の指定セット。一意の属性は、同じテーブルまたは派生テーブルから取得できます。
- 必要な属性
- 空にすることができない CI の指定属性。
CMDB 階層全体での派生
子クラスに対して識別ルールが明示的に定義されていない場合、子クラスはその親クラスから、関連付けられた識別エントリおよび関連エントリを含む識別ルールを派生させます。その後、子クラスに対して独自の識別ルールを明示的に定義できます。その場合、最初に親クラスから派生した識別ルールは、関連付けられた識別エントリおよび関連エントリを含め、子クラスでは無効になります。また、子クラスで新しく作成された識別ルールに識別エントリと関連エントリを明示的に追加する必要があります。
例：Hardware クラス識別ルールには Software Instance テーブルの関連エントリがあります。Software Instance テーブルに関連付けられた関連エントリを含むこの識別ルールは、Computer クラスによって派生します。Computer クラスの新しい識別ルールを作成すると、Hardware クラスから派生した識別ルールはそれによって上書きされます。Software Instance テーブルに関連付けられた関連エントリを含む Hardware クラス識別ルールは、Computer クラスに対する効果はなくなります。同じ関連エントリが必要な場合は、Computer クラスの新しく作成された識別ルールで Software Instance テーブルの関連エントリを明示的に追加する必要があります。
識別ルール タイプ
- 独立型 CI
- 独自に存在し、他の CI に依存しないサーバー CI などの CI です。
- 依存型 CI
- 別の CI との関係に依存し、依存関係がないと単独では存在できない CI です。たとえば、
- Network Adapter CI は、それらを含む Hardware CI なしでは意味のある存在にはなりません。
- Application CI は、ホストされている Server CI がなければ単独では存在できません。
- 独立識別ルール
- 他の CI または関係とは無関係に、CI の独自の属性に基づいて CI を識別するルール。
- 依存識別ルール
- CI を識別するルールは、依存 CI を最初に識別する必要があります。CI は 1 つ以上の CI に依存することができ、依存 CI は 1 つの親 CI のみと依存関係を持つことができます。CI とその依存 CI 間の関係タイプも識別プロセスに含まれます。依存 CI の識別プロセスを支援するため、CI タイプ内の依存関係チェーンを定義する従属関係を作成します。
依存 CI の識別に使用されるペイロードには、修飾子チェーンとの関係を含めることができます。このような関係では、一致する親子ペアが存在する場合、ペイロード内の修飾子チェーンはデータベース内の CI の修飾子チェーンと比較されます。相違がある場合、データベース内の修飾子チェーンは、その関係のペイロード内の修飾子チェーンと一致するように更新されます。
識別子エントリ
CI の独自の属性 (フィールドベースの識別) に基づいているだけでなく、シリアル番号やネットワークアダプターなどの CI の関連リスト (ルックアップベースの識別) にも基づいて CI に一致するように識別子エントリを構成することができます。識別に使用されるルックアップテーブルには、cmdb_ci をポイントする参照フィールドがある必要があります。
- 通常の識別子エントリ
- 識別は CI を一意に識別する CI 自身の属性に基づきます。
- ルックアップ識別子エントリ
識別では、識別されている CI への参照を持つ任意のテーブルをルックアップテーブル (関連テーブル) として使用します。関連ルックアップテーブルを選択したら、cmdb_ci テーブル自体、またはその子孫の 1 つを参照する関連テーブルから識別子属性を選択します。
ルックアップレコードがまだ存在しない場合は、識別子エントリで参照されるルックアップテーブルに挿入されます。
- ハイブリッド識別子エントリ
- 通常の識別子エントリとルックアップ識別子エントリの両方の組み合わせです。
例：同一セットのシリアル番号がある 2 つの仮想マシンが含まれる可能性のあるクラウド環境で仮想マシンを検出した場合。[Table: Serial Number, Criterion Attributes: Serial Number, Serial Number Type] のように、ハードウェアテーブルのルックアップ識別子エントリでは、このような 2 つの仮想マシンを一意に識別できません。しかし、[Table: Serial Number, Criterion Attributes: Serial Number, Serial Number Type + (Name field from main Hardware table)] のようなハイブリッド識別子エントリでは、2 つの仮想マシンを一意に識別できます。
ルックアップ テーブルのガイドライン
- ルックアップ テーブルが cmdb_ci テーブルを参照していることを確認します。
- より強力な識別ルールのためにはカウントの完全一致を強制することが推奨されます (チェック ボックス [カウントの完全一致を強制 (ルックアップ)])。ルックアップ識別の間、このオプションは、ルックアップ レコード数の完全一致にのみ一致するように強制します。詳細は、CI 識別ルールの作成を参照してください。
- 特にルックアップベースルールでは、競合する識別ルールを作成しないでください。 例：ハードウェアクラスの CI ID では、ネットワークアダプタークラスのルックアップベースルールを指定し、ネットワークアダプタークラスの CI ID も定義します。そのテーブルで一意の CI を識別する矛盾するルールが存在するため、ネットワーク アダプター テーブルに重複が作成される可能性があります。
- 基準属性のみを参照する 1 つのルール (CI ID ルール)
- 基準属性と参照した sys_id を参照する別のルール (ルックアップ ルール)。
var payload = {
items: [{
className:'cmdb_ci_linux_server',
related: [{
className:'cmdb_ci_spkg',
values: {
name:'package1',
version:'version1'
}
}],
values: {
sys_id:'194876usytrr65378098'
}
}]
};関連エントリ
関連 CI に基づくルールである関連エントリを定義することができます。関連エントリは、識別されている CI への参照を持つ任意のテーブル (CMDB または非 CMDB) にすることができる関連テーブルに基づきます。関連エントリを使用すると、識別子エントリによって識別される CI にデータが関連付けられている他のテーブルのレコードを作成または更新できます。関連エントリは、CI を直接識別するためには使用されません。
ルールの関連テーブルを選択すると、参照済みフィールドのリストには、cmdb_ci テーブル自体、またはその子孫の 1 つを参照する関連テーブルからのフィールドが入力されます。
クラスの関連エントリは、関連エントリが指定されていない子クラスによって派生します。