各クラウドサービスプロバイダーから、t1.micro (AWS) や など、各種の事前定義された VM ハードウェアタイプが提供されています。独自の VM ハードウェアタイプを作成することもできます。デフォルトでは、ディスカバリー は検出された VM ハードウェアタイプをハードウェアタイプ [cmdb_ci_compute_template] テーブルに保存します。このテーブルは、cmdb_ci_logical_datacenter クラスの依存クラスです。このモデルでは、検出された VM ハードウェアタイプごとに、次のような多数の重複レコードが作成されます。

検出された各 VM ハードウェアタイプのレコード数 = サービスアカウントの数 x 論理データセンターの数。

したがって、組織に数百個のサービスアカウントがある場合、ディスカバリー によって数千個の VM ハードウェアタイプレコードが作成されるため、ディスカバリーやその他の関連フローの速度が低下する可能性があります。

たとえば、組織の AWS アカウントに t1.micro VM が含まれているとします。組織には、3000 個のサービスアカウントと 10 個の LDC (米国西部など) があります。次のスキャン中に、ディスカバリー が VM ハードウェアタイプを検出し、ハードウェアタイプ [cmdb_ci_compute_template] テーブルに 30,000 個の t1.micro VM タイプレコードを作成します。

クラウドのハードウェアタイプ [cmdb_ci_cloud_hardware_type] テーブルに AWS と GCP の定義済み VM ハードウェアタイプを保存すると、これらの問題を回避できます。このテーブルは、既存のハードウェアタイプ [cmdb_ci_compute_template] テーブルを拡張するものです。ただし、LDC やサービスアカウントには関連付けられていません。したがって、複数のサービスアカウントがある場合でも、ディスカバリー によってハードウェアタイプ [cmdb_ci_compute_template] テーブルに膨大な数の VM ハードウェアタイプのレコードが追加されることはありません。このテーブルでは、識別ルール内の object_id フィールドおよび provider フィールドを使用します。

Azure ハードウェアタイプのディスカバリーの詳細については、「パターンを使用した Microsoft Azure コンポーネントの検出」を参照してください。