重複する CMDB CI レコードIssue 「識別および調整」(IRE) モジュールは、さまざまなデータソースからのデータを識別して調整するための一元化されたフレームワークを提供します。複数のデータソースを使用して CI レコードを作成および更新するときに CMDB の完全性を維持するのに役立ちます。IRE は、識別ルール、調整ルール、関係などを介して、組織のニーズをより適切に満たすようにカスタマイズできます。IRE の詳細については、以下を参照してください。 CMDB 識別および調整 構成によっては、「重複した」レコードが作成される可能性があります。IRE に従って「重複」レコードとは何かを理解することが重要です。IRE は識別ルールを使用して、CMDB 階層に従って CI を検索します。したがって、識別ルールに従って代わりに CI を更新する必要があるときに、重複レコードが作成されます。[Configuration > CI Class Manager (CI クラスマネージャーの構成)] に移動して、特定のクラスに使用されるルールを確認します。 たとえば、次の画像には、Windows Server で使用される OOB 識別子が表示されています。以下では、次のことがわかります。 識別子は、親クラス (この場合はcmdb_ci_hardware) から継承されたことを意味する「派生」です。独立している。つまり、他の CI との関係に依存しません。最初の一致基準として「相関 ID」がある。 上記の識別子の場合、識別エンジンによって同じ「相関 ID」を持つ 2 つの Windows サーバーが重複していると見なされます。 注: CMDB はドメインセパレーションをサポートしています。したがって、同じ相関 ID を持つそれぞれのドメインに作成されたサーバーは一意であると見なされます。 構成管理データベース (CMDB) におけるドメインセパレーション 次の画像は、Windows Server 用に作成されたカスタム識別子を示しています。 「派生」は存在しなくなりました。一意性を判断するためにシリアル番号のみが使用されます。 同じ相関 ID を持つ 2 つの Windows サーバーは、上の画像の構成では重複とは見なされません。 注:場合によっては、新しい識別子を作成すると、関連するエントリも作成する必要があります。cmdb_ci_hardware の子クラスにカスタム識別子が必要な場合は、カスタム識別子を作成する前に、例として次のリンクを参照してください。 特定のサブクラスのハードウェアルール CMDB 識別子をコピーする方法 簡単に言うと、IRE は独立 CI に対して以下のロジックに従います。 「ペイロード」が IRE に渡されます。ペイロード CI と関係を検証します。ペイロードは有効ですか? はい：続行しますいいえ:エラーを出力し、エラーをログに記録します。 識別ルールをループして CMDB にクエリーを実行する。CI は見つかりましたか? はい:このクラスの包含ルールで CI はアクティブですか? はい： このクラスに調整ルールがありますか。 はい:調整ルールは、このソースに CI の更新を許可しますか? はい:CI フィールドを更新する。いいえ:CI を更新しない。 いいえ:CI フィールドを更新する。 いいえ:CI の作成 いいえ:試行する識別ルールは他にもありますか? はい:次の識別ルールに進むいいえ:CI の作成 注:例外として、vCenter のディスカバリーでは IRE は使用されません。詳細については、vCenter ディスカバリーの次のリンクを参照してください。 vCenter ディスカバリー IRE のしくみの詳細については、以下を参照してください。 CI を (ペイロードとして) createOrUpdateCi() に渡すときの CMDB 識別および調整エンジンの動作 依存型 CI 依存 CI も識別ルールを使用します。ただし、依存関係性ルールは、これらのサービス定義における CI タイプと関係タイプの依存関係構造を定義することで、CI の識別およびビジネスサービスマップの構築に役立ちます。CI 識別の間、検査されている CI のペアは、少なくとも 1 つのホスティングルールを満たす必要があります。 たとえば、「Configuration > Identification/Reconciliation > Metadata Editor」から、Kubernetesポッドの次のルールが表示されます。 [Configuration > CI Class Manager] から、Kubernetes ポッドの次の識別ルールが表示されます。 識別ルールとホスティングルールの組み合わせから、Kubernetes ポッドを一意にするには、次の条件が必要であることがわかります。 一意の「Kubernetes UID」があるKubernetes クラスターとの「包含者」関係を持つ唯一の Kubernetes ポッドであること したがって、次の 2 つの Kubernetes ポッドは一意になります。 UID Y で Kubernetes クラスター A との「Contained by」関係を持つ Kubernetes ポッド AUID Y および Kubernetes クラスター B との「Contained by」関係を持つ Kubernetes ポッド B 上記では、両方のポッドのUIDは同じですが、異なるkubernetesクラスタに含まれています。 CMDB 依存関係性ルール依存関係性ルールの作成Releaseすべてのリリース。Cause異なるドメインにある CI は、データが同じであっても重複とは見なされません。 場合によっては、次のいずれかの要因によって識別エンジンから CI が「非表示」になると、重複が作成されることがあります。 包含ルールクエリビジネスルールACL IRE は、IRE を呼び出すユーザーのコンテキストで CMDB を照会します。上記の要因のいずれかによって CI が IRE から「非表示」になると、CI は見つからず、新しい CI が作成されます。上記の症状の例としては、同じサーバーが検出されたり、IRE API が呼び出されたりするたびに重複 CI が作成されることが挙げられます。 さらに、リリースによっては、次の場合に IRE は CI を認識しません。 duplicate_ofフィールドが空ではないdiscovery_sourceは「重複」です 遅いビジネスルールは、同じ依存 CI を持つ複数のペイロードが処理されるときに、重複する依存 CI の作成の原因となる可能性があります。これは、別々のディスカバリーで同じ CI を同時に検出した場合、または同じディスカバリーのペイロードの複数のペイロードにそのような依存 CI が含まれている場合に発生する可能性があります。これは競合状態であり、一般的ではありません。Resolution包含ルール [Configuration > Identification/Reconciliation > Identification Inclusion Rules] に移動します。クラスまたはその親テーブルの 1 つに適用される包含ルールを検索します包含ルールを適宜調整します 注:cmdb_ci_hardwareなどの親クラスの包含ルールを作成し、「class」を含む条件を設定すると、重複が作成されます。包含ルールはすべての子クラスに使用されます。したがって、条件に含まれていない IRE に渡された子クラスは「認識」されません。包含ルールの条件として「クラス」は使用しないことをお勧めします。 健全性包含ルールの詳細については、以下を参照してください。 健全性包含ルールの作成 BR と ACL のクエリ 影響を受けるテーブルのカスタムクエリ BR と ACL を検索して無効にします問題の再現を試みますBR または ACL を無効にして問題を解決し、根本原因を確認するカスタム構成を確認し、それに応じて調整します 注:デフォルト設定では、IRE に影響を与えるクエリ BR または ACL は CMDB テーブルにありません。 次のリンクは、BR および ACL の問題のトラブルシューティングに役立つ場合があります。 ビジネスルールのデバッグACL デバッグツール 遅いビジネスルール - 依存 CI このようなビジネスルールのパフォーマンスを向上させる可能であれば、ビジネスルールを非同期に実行しますパターンに、インスタンスに送り返される前に重複を削除するステップを追加しますディスカバリーのみ:複数ページのペイロードを並列に処理するかどうかをglide.discovery.multi_page_serial_mode制御します ペイロードが順次処理されるようにするには、「true」に設定します。これにより、検出による重複の作成が回避されます Related Linksツール 識別シミュレーションを使用したペイロード実行の生成とシミュレーションCMDB API (CMDB SDK)IdentificationEngineScriptableApi - グローバル トラブルシューティングのヒント 問題を再現するための明確な手順があるトラブルシューティングを簡素化するために最小のペイロードセットを使用します (必要な CI のみ)可能であれば、別のユーザーでペイロードをテストします (さまざまな権限をテストするため)CI クラスマネージャーを使用して識別ルールをチェックし、CI が実際に重複と見なされることを確認します。CI クラスマネージャーを介して包含ルールを確認スクリプトバックグラウンドを介して次の KB の説明に従って IRE 実行をデバッグし、BR が CI クエリに影響を与える可能性があるかどうかを確認します スクリプトバックグラウンドでのスクリプトを使用した識別および調整エンジンのデバッグ