識別および調整の基礎<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 目次 概要IRE の概要IRE コンポーネント独立 VS 依存Duplicates (重複)再分類部分的なアイテムIRE フローIRE ツール片付けるプロパティ 概要 このナレッジベース記事の目的は、識別および調整エンジン (IRE) の主な概念について説明し、新規ユーザーに理解してもらうことです。 IRE の概要 識別および調整エンジンとは? 識別および調整エンジンは、構成管理データベース (CMDB) を維持するためにペイロードを処理するフレームワークです。これには、新しい構成アイテム (CI) の作成や既存の CI の更新が含まれます。 しかし、なぜIREが必要なのでしょうか? 一元化されたフレームワークを使用せずに複数のソースが独自のロジックで CMDB を更新すると、重複 CI、望ましくない更新、および属性フラッピング (複数のソースが異なる値で同じフィールドを継続的に更新する) が発生する可能性があります。 CMDB に重複がなく、最も関連性の高い情報が最新であることを保証するには、一元化されたフレームワークが必要です。 注意: CMDB への更新を直接ブロックして IRE をバイパスするロジックはありません。ただし、CMDB を直接更新すると、IRE を使用するメリットが失われます。このため、CMDB の更新は IRE を介して行うことをお勧めします。 IRE コンポーネント 識別子 識別子は、CI が CMDB に既に存在するかどうかを判断するために IRE が使用するクラスの一連のルールです。クラスに識別子がない場合は、階層から継承します。たとえば、cmdb_ci_hardware の子分岐の 1 つにあるほとんどのクラスは、「Hardware」識別子を継承します。 識別ルール 識別ルールは、IRE が CMDB 内の CI を検索するために使用するものです。各識別ルールは、CMDB で一致を検索するために使用される一連の属性で構成されます。 IRE は受信したペイロードを分析し、優先度順に識別ルールを使用して CMDB 内の CI を検索します。CI が見つからない場合は、新しい CI が作成されます。 包含ルール 包含ルールは、識別プロセスに含める CI の範囲を絞り込むために使用されます。 包含ルールによって設定された基準に一致しない CI は、IRE によって使用されません。 したがって、最初に識別ルールを使用して CMDB 内の CI を検索し、次に包含ルールを使用してそれらの CI を使用できるかどうかを確認します。 しかし、そもそもなぜインクルージョンルールがあるのでしょうか? たとえば、CMDB 内の廃止された Windows サーバーをデータソースによって更新してはならないという環境要件があるとします。包含ルールを使用して、廃止されたサーバーが IRE によって使用/更新されないようにすることができます。包含ルールの欠点は、適切に構成されていない場合、CI が「重複」する可能性があることです。 注意: クラス別に CI を除外するように包含ルールを構成すると、重複が発生します。 識別ルール、包含ルール、およびそれらの構成方法の詳細については、以下を参照してください。 識別ルール 調整ルール IRE は調整ルールを使用して、どのデータソースを優先すべきかを決定します。最も優先度の高いデータソースによって、属性値がどうあるべきかが決定されます。これにより、信頼性の低いデータソースがクラス内のフィールドを更新するのを防ぐことができます。調整ルールがないと、データソースは互いの更新を上書きします。 このようにして、複数のデータソースが同じ CI 属性を何度も更新するのを防ぐことができます。 調整ルール、およびさまざまなタイプの調整ルール (動的または静的) の詳細については、以下を参照してください。 調整ルール データ更新ルール CI を最後に更新した優先度の高いデータソースからの更新がなくなった場合はどうなるでしょうか? 時間が経つにつれて、そのデータは関連性がなくなる可能性があります。これが発生したときに、他のソースがそれらのレコードを更新できるようにする方法が必要です。 データ更新ルールは、CI のデータが古くなっているかどうかを指定します。これが発生すると、優先度の低い他の許可されたデータソースがそれらの CI を更新できます。 注意: 動的調整ルールが有効な場合、データ更新ルールは影響を与えません。データ更新ルールは、静的調整ルールと組み合わせて使用します。 データ更新ルールの詳細については、以下を参照してください。 データ更新ルール マルチソース CMDB マルチソース CMDB は、CI 属性の更新に関連するディスカバリーソースと提案された値に関する完全な履歴を保持します。マルチソース CMDB データを使用すると、さまざまなディスカバリーソースによる CMDB への入力方法を CI 属性レベルで追跡できます。また、特定の検出ソースからの CI の更新を元に戻したり、更新された調整ルールを使用して属性値を再計算したりすることもできます。 複数のディスカバリーソースが同じ CI 属性を更新しようとすると、Identification and Reconciliation Engine (IRE) は調整ルールを使用して、更新を行うディスカバリーソースを 1 つ選択します。マルチソース CMDB がない場合、値が却下された優先度の低い検出ソースに関する詳細は破棄されます。また、マルチソース CMDB がない場合は、属性値のソースを特定することも難しくなります。 マルチソース CMDB を使用すると、すべての検出ソースと CI の組み合わせの生の詳細が、更新に選択された検出ソースとそうでない他のすべての検出ソースの両方について保持されます。各検出ソースと CI の組み合わせのレコードで構成されるマルチソース CMDB データは、CMDB マルチソースデータ [cmdb_multisource_data] テーブルに格納されます。このマルチソース CMDB データストアは、調べたり、照会したり、レポートしたりすることができます。 マルチソース CMDB の詳細とその設定方法については、以下を参照してください。 マルチソース CMDB 独立 VS 依存 CI の依存関係は、CI クラスマネージャーで CI のクラスの依存関係ルールによって指定されます。 独立型 CI 独自に存在し、他の CI に依存しないサーバー CI などの CI です。 依存型 CI 別の CI との関係に依存し、依存関係がないと単独では存在できない CI です。 例： ネットワークアダプター CI は、それらを含むハードウェア CI なしでは意味のある存在にはなりません。 アプリケーション CI は、ホストされているサーバー CI がなければ単独では存在できません。 次の画像では、Tomcatクラスに必要な「依存関係」を示しています。 依存 CI を識別する手順は、独立 CI を識別する手順とは異なる場合があります。この違いは、依存識別ルールと独立識別ルールの違いに反映されています。 必要な関係性を持たない依存 CI ペイロードが処理された場合、IRE はエラーを返します。上の画像では、Tomcat ペイロードがハードウェア CI と「実行日」の関係を持つ必要があることがわかります。 IRE フレームワークを直接操作する場合は、識別シミュレーションをツールとして使用して、ペイロードにコンポーネントが欠落していないかどうかを確認できます。以下を参照してください。 識別および調整エンジンペイロードのビルド方法 識別ルール: 独立識別子 他の CI または関係とは無関係に、CI 自身の属性に基づいて CI を識別する識別子。 扶養家族識別子 CI を識別するために最初に独立 CI を識別する必要がある識別子。CI は 1 つ以上の CI に依存することができ、依存 CI は 1 つの親 CI のみと依存関係を持つことができます。CI とその依存 CI 間の関係タイプも識別プロセスに含まれます。依存 CI の識別プロセスを支援するため、CI タイプ内の依存関係チェーンを定義する従属関係を作成します。 依存 CI の識別に使用されるペイロードには、修飾子チェーンとの関係を含めることができます。このような関係では、一致する親子ペアが存在する場合、ペイロード内の修飾子チェーンはデータベース内の CI の修飾子チェーンと比較されます。相違がある場合、データベース内の修飾子チェーンは、その関係のペイロード内の修飾子チェーンと一致するように更新されます。 次の画像では、ペイロードの作成に識別シミュレーションが使用されているのがわかります。 作成されたペイロードには次のものがあることに注意してください。 独立した CI、これはcmdb_ci_win_serverです依存 CI、これはcmdb_ci_network_adapterです関係性。これは、ネットワークアダプタに必要な「Owns::Owned by」関係です 重複 IRE API が呼び出されると、重複が見つかる場合があります。重複が見つかった場合は、重複排除タスクが作成されます。 重複排除タスクを使用して重複 CI を解決する方法については、以下を参照してください。 重複排除タスクのレビュー重複排除タスクの修正手動で重複排除タスクを作成重複 CI の検出 重複 CI のトラブルシューティングについては、以下を参照してください。 重複する CMDB CI レコード 重複は、CMDB ヘルス正確性ジョブによっても検出される場合があります。このジョブの詳細については、次のドキュメントを参照してください。 CMDB ヘルス - 重複するメトリクス - アルゴリズム 再分類 CI はアップグレード、ダウングレード、および切り替えることができます。 アップグレードの例 (階層を上へ): サーバー→ Windows サーバー ダウングレードの例 (階層を下へ移動) Linux サーバー → サーバー 注意: CI クラスのダウングレードと CI クラスの切り替え操作は、データが失われる可能性があるため避けてください。自動 CI 再分類が有効 (デフォルト) になっている場合、識別プロセスの結果として自動再分類が行われ、データが失われる可能性があります。 スイッチの例 (階層の別の分岐に移動) プリンター→スイッチ ターゲットクラスに存在しないフィールドのデータは失われます この動作を制御する詳細とプロパティについては、以下を参照してください。 IRE 処理中の CI の再分類 部分的なアイテム ペイロードアイテムは、一意の識別に必要なデータが含まれており、次のいずれかのエラーがある場合、部分的なアイテムであると判断されます。一意の識別では、ペイロードアイテムにsource_nameとsource_native_keyの値を含むsys_object_source_infoセクション、または CI クラスに指定された識別基準属性の完全なセット、あるいはその両方が必要です。 部分的なアイテムの IRE エラー： MISSING_MATCHING_ATTRIBUTES：アイテムに、1 つ以上の識別子エントリで照合に使用するための識別基準属性がありません。REQUIRED_ATTRIBUTE_EMPTY：必要な属性が欠落しており、CI を作成できません。MISSING_DEPENDENCY：依存型 CI に、ペイロードで指定された依存関係がありません。INSERT_NOT_ALLOWED_FOR_SOURCE：IRE のデータソースルールにより、指定されたデータソースは指定されたクラスの CI を作成できません。 ペイロードアイテムが部分的なアイテムであると判断されたために処理が失敗した場合、部分的なアイテムは、以後に行われる可能性がある処理のために、部分的ペイロードとして CMDB IRE 部分のペイロード [cmdb_ire_partial_payloads] テーブルに JSON 形式で保存されます。IRE は識別子キーを使用して、受信ペイロードと保存された部分的ペイロードとの照合を試みます。 後でデータソースが部分的なアイテムから欠落していたデータを送信した場合、IRE は受信ペイロードを保存された部分的ペイロードと照合します。次に、IRE は、一致する部分的ペイロードを受信ペイロードと結合します。競合する属性を解決するために、IRE はsource_recency_timestamp (source_native_keyとsource_nameが同じ場合) またはクラスに指定された静的調整ルールのいずれかを使用します。結果は完全かつ有効なペイロードで、その後 IRE が処理してそれぞれの CI を作成または更新します。 90 日より古い部分的ペイロードは、CMDB IRE 部分のペイロード [cmdb_ire_partial_payloads] テーブルから削除されます。 IRE フロー CI を渡すときの CMDB 識別および調整エンジンの仕組み IRE ツール CI クラスマネージャー CI クラスマネージャーは、IRE で利用可能なツールを構成するためのワンストップショップです CI クラスマネージャーを開くには、次に移動します: [Configuration] > [CI Class Manager] 次の画像では、CI クラスマネージャー、識別ルールの構成、およびクラス「Windows Server」の包含ルールを示しています 識別シミュレーション 識別シミュレーションを開くには、次の場所に移動します。 構成>識別/調整>識別シミュレーション 識別シミュレーションを使用して IRE ペイロードを作成する方法については、次の KB を参照してください。 識別および調整エンジンペイロードのビルド方法 識別および調整のデバッグ 識別および調整エンジンのデバッグ方法の詳細については、次を参照してください。 スクリプトバックグラウンドでのスクリプトを使用した識別および調整エンジンのデバッグ IRE エラーのリスト: https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/identification-simulation.html#id-engine-error-messages 片付ける 重複した CMDB CI 関係レコード、孤立関係があるか親/子関係が欠落しているレコードを特定して削除する方法 プロパティ IRE プロパティの包括的なリストについては、以下を参照してください。 識別および調整のプロパティ