新しいハードウェアタイプモデルへの移行説明 この KB 記事では、新しいハードウェアタイプのモデルに移行するプロセスについて説明します。 インデックス 概要リリースバージョン前提条件新しいハードウェアタイプモデルに移行する手順古いモデルハードウェアタイプレコードをクリーニングする手順1.6.0 より前の更新セットソリューションに関する問題パターン実行フロー 概要 ハードウェアタイプは、クラウドベンダーが提供する事前定義された仮想マシンタイプを表す構成アイテム (CI) です。クラウドベンダーは、数百ものすぐに利用可能なタイプを提供しています。ほとんどの場合、お客様はすぐに利用可能なタイプ (例:AWS の t2.nano、t2.micro、t2.large) を使用しています。 古いハードウェアタイプモデル このモデルでは、クラス cmdb_ci_compute_template (ラベル: Hardware Type) を使用します。このクラスは、cmdb_ci_logical_datacenter の依存クラスです。このモデリングの結果、すぐに利用可能な各ハードウェアタイプが CMDB で N 回モデル化されます。ここでN = サービスアカウントの数 * 論理データセンターの数。数百のサービスアカウントを持つ顧客は、CMDB で何百万ものハードウェアタイプのレコードを検出することになります。これにより、パフォーマンスの問題を引き起こす可能性があるディスカバリーやその他の関連フローの速度が低下します。したがって、クラウドに存在する何百ものハードウェアタイプ (AWS、AZURE、GCP) によって、何百万ものレコードが CMDB に永続化されるという事実に、顧客は困惑しています。 新しいハードウェアタイプモデル このモデルでは、CMDB のハードウェアタイプレコードの数が削減されます。ハードウェアタイプは cmdb_ci_cloud_hardware_type (ラベル:クラウドハードウェアタイプ) に入力されます。これは独立したクラスです。 サービスアカウントとデータセンターに関係なく、ハードウェアタイプごとに 1 つのレコードが作成されます。これにより、数百万のハードウェアタイプのレコードが数百のレコードに削減されます。 リリースバージョン この機能は、以下から利用できます。 リリースバージョン: ディスカバリーとサービスマッピングパターンストアアプリのバージョン 1.6.0 (2023 年 6 月) 以降。 手記： ディスカバリーとサービスマッピングパターンストアアプリをバージョン 1.6.0 以降にアップグレードして、新しいソリューションを採用して新しいモデルに移行することをお勧めします1.6.0 より前のバージョンでは、AWS、Azure、および GCP のハードウェアタイプモデルに移行するための更新セットが提供されていました。更新セットを使用して既に移行している場合は、 これ以上のアクションは必要ありません 。 前提条件 新しいモデルに移行する前に、次の基準を満たす必要があります。 ディスカバリーとサービスマッピングパターンストアアプリ:アクティブで、バージョン 1.6.0 以降である必要がありますAWS/Azure のお客様: この新しいモデルは、CPG からパターンに既に移行しているお客様にのみ適用されます。GCP は CPG から移行せずに直接パターンフローに従うため、この前提条件は GCP のお客様には適用されません。クラウドインサイトストアアプリ: クラウドインサイトアプリがアクティブな場合、プラグインバージョン 2.2.0 以降ではこの機能がサポートされます。 新しいハードウェアタイプモデルを移行する手順 このソリューションは、 AWS、Azure、GCP のお客様に適用されます。 移行手順: 1.システムプロパティを設定します。新しいハードウェアタイプモデルに移行するには、システムプロパティ「sn_itom_pattern.クラウドデータセンターに単一のハードウェアタイプを使用」をtrueに設定します。 これを行うには、[フィルターナビゲーター] に移動します。> sys_properties.list と入力します > クラウドデータセンターに単一のハードウェアタイプを使用する sn_itom_pattern.use a single hardware type for cloud data center 注意: このプロパティを有効にすると、今後の検出で新しいモデルテーブル (cmdb_ci_cloud_hardware_type) にレコードが入力されます。 制限事項と重要な注意事項: リリースバージョン 1.6.0 以降、「Amazon AWS - ハードウェアタイプ (LP)」と「Azure - ハードウェアタイプ (LP)」は更新されなくなります。反転してシステムプロパティ「sn_itom_pattern.use a single hardware type for cloud data centers」を true から false に変更することはできません (新しいモデルから古いモデルへの変更を意味します)。 古いモデルハードウェアタイプレコードをクリーニングする手順 古いテーブル (cmdb_ci_compute_template) からレコードを削除する必要がある場合にのみ、次の手順を実行します。 古いモデルのハードウェアタイプのレコードを削除し、新しいモデルに移行してクラウドディスカバリーを実行していない場合、CMDB で古いモデルのレコードと関係の両方が観測される可能性があります。 古いモデルのハードウェアタイプのレコードを削除するには、グローバルスコープで 更新セット をインポートしてコミットします。更新セットがコミットされたら、以下の手順に従います。 フィルターナビゲーターから移動 -> システム定義 -> スケジュール済みジョブ -> 「古いハードウェアタイプ モデルレコード 不在としてマーク」という名前のジョブを検索します。[Active] をクリックしてスケジュール済みジョブをアクティブ化し、[Update] をクリックしますこのスケジュール済みジョブは、古いモデルの CI ステータスを定期的に cmdb_ci_compute_template [不在 として更新します。その後、 テーブルクリーナー は、cmdb_ci_compute_templateテーブルの不在レコードを削除します。 注意： 繰り返し間隔 を調整し、システムプロパティ値に従うことで、パフォーマンスを最適化できます。ただし、次のシステムプロパティは「sys_properties」テーブルにリストされていないことに注意してください。これらのプロパティを更新する場合は、「sys_properties」テーブルに追加するか、スケジュール済みジョブスクリプト内の値を直接変更できます。 sn_itom_pattern_delete_old_hardware_type_job_count:同時に実行されるジョブの数を定義します。デフォルト値は 10 に設定されています。sn_itom_pattern_delete_old_hardware_type_batch_size:各ジョブで処理されるレコードの数を指定します。デフォルト値は 10000 に設定されています。 「古いハードウェアタイプのモデルレコードを不在としてマークする」スケジュール済みジョブを実行する際の考慮事項: 古いハードウェアタイプのモデルレコードを「なし」としてマークするスケジュール済みジョブを実行する場合は、潜在的なパフォーマンスの問題を回避するために次の点を考慮してください。 システムリソース管理: 大規模なデータセットを使用するインスタンスの場合は、システムの負荷を軽減するために、オフピーク時にこのジョブをスケジュールします。他のスケジュール済みジョブが同時に実行されていないことを確認し、インスタンスに十分なリソースが利用可能であることを確認します。テーブルクリーナー操作: レコードが不在としてマークされると、テーブルクリーナープロセスはこれらのレコードを継続的にスキャンして削除します。一定の間隔で機能しますが、この一定のバックグラウンドアクティビティは、特に多数のレコードを処理する必要がある場合は、パフォーマンスの低下につながる可能性があります。パフォーマンスへの影響: テーブルクリーナーは存在しないレコードの処理に時間がかかる場合があるため、インスタンスに追加の負荷がかかり、全体的なパフォーマンスに影響を与える可能性があります。 ベストプラクティス: パフォーマンスリスクを軽減し、インスタンスパフォーマンスへのさらなる影響を防ぐために、アクティビティの少ない期間 (理想的にはシステム負荷が最小の数時間) にこのジョブを手動でスケジュールします。すべての CI を一度に不在としてマークするのではなく、ジョブを複数の間隔に分割し、テーブルクリーナーの各実行中にデータの小さなバッチを処理します。このアプローチにより、パフォーマンスの大幅な低下を回避できます。 1.6.0 より前の更新セットソリューションに関する問題 1.6.0より前のバージョンの場合、更新セットを使用して新しいハードウェアタイプモデルに移行するには、更新セットで提供される修正スクリプトを実行する必要があります。修正スクリプトは次のことを行います。 システムプロパティ「クラウドデータセンターに単一のハードウェアタイプsn_itom_pattern.use a single hardware types」を有効にする。AWS (Amazon AWS - ハードウェアタイプ (LP)) および Azure (Azure - ハードウェアタイプ (LP)) パターンに必要なオーケストレーション変更を実装します。 重要: 修正スクリプトによって行われた変更はカスタマイズとして扱われ、将来の更新には含まれません。これらのカスタマイズは個別に管理する必要があることに注意してください。 パターン実行フロー 注意: GCP クラウドディスカバリー 古いフローと新しいフローの両方に「Google Cloud Platform (GCP):仮想サーバー」パターンを使用し、システムプロパティ値に基づいてcmdb_ci_compute_templateテーブルとcmdb_ci_cloud_hardware_typeテーブルに入力します。 1.6.0 バージョンでは、2 つの新しいパターンが導入されました。 Amazon AWS - クラウドハードウェアタイプ (LP)Azure:クラウドハードウェアタイプ (LP) クラウド新しいパターン対応する古いパターンAWSAmazon AWS - クラウドハードウェアタイプ (LP)Amazon AWS - ハードウェアタイプ (LP)AzureAzure:クラウドハードウェアタイプ (LP)Azure:ハードウェアタイプ (LP) 1.6.0 リリースより前は、AWS と Azure のお客様は修正スクリプトを実行して、オーケストレーションに必要な変更を実装していました。移行シナリオによっては、顧客に次の動作が見られる場合があります。 シナリオ 古いパターンの動作新しいパターン動作新しいハードウェアタイプのモデルに移行されていませんパターンを処理するパターンを適切に終了するバージョン 1.6.0 より前の新しいハードウェアタイプモデルに移行 (修正スクリプト経由)パターンを処理するパターンを適切に終了する新しいハードウェアタイプのモデルバージョン 1.6.0 以降に移行しましたパターンを適切に終了するパターンを処理する フロー図: 終わり******