新しいハードウェアタイプモデルへの移行 - Support and Troubleshooting

新しいハードウェアタイプモデルへの移行 .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: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } }

説明 この 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.クラウドデータセンターに単一のハードウェアタイプを使用する プロパティを開き、その値を true に設定します [ 更新] をクリックします。 注意: このプロパティを有効にすると、今後の検出で新しいモデルテーブル (cmdb_ci_cloud_hardware_type) にレコードが入力されます。

制限事項と重要な注意事項:

バージョン 1.6.0 以降では 次のパターンは 更新されなくなります 。新しいモデルパターンのみが更新されます。 「Amazon AWS - ハードウェアタイプ (LP)」 「Azure - ハードウェアタイプ (LP)」 2. プロパティを有効にすると、 false に戻すことはできません .(新しいモデルから古いモデルに戻す 切り替え できません)。

古いモデルハードウェアタイプレコードをクリーニングする手順 これらの手順は、新しいハードウェアタイプのモデルに移行し、cmdb_ci_compute_templateテーブルから古いモデルレコードを削除する場合にのみ実行します。

新しいモデルに移行してクラウドディスカバリーを実行した後に、古いモデルのハードウェアタイプのレコードが削除されていない場合、CMDB に古いモデルのレコードと関係が表示されることがあります。

クリーンアップ手順

古いモデルのハードウェアタイプのレコードを削除するには、次の手順に従います。

更新セットをインポートします。 グローバルスコープで 更新セット をインポートします インポートしたら、変更を適用する更新セットを 収容 します。 スケジュール済みジョブのアクティブ化 [ システム定義 -> スケジュール済みジョブ] に移動します。 「 古いハードウェアタイプのモデルレコード 不在としてマークする」という名前のジョブを検索します スケジュールジョブを開き、[ アクティブ ] ボックスをオンにします [ 更新 ] をクリックして変更を保存します。 仕組み このスケジュール済みジョブは、(cmdb_ci_compute_templateテーブルからの) 古いモデルの CI を定期的に 不在 のステータスとしてマークします。 不在としてマークされると、テーブルクリーナーはこれらのレコードを自動的に削除します。 注意 ：

繰り返し間隔 を調整し、システムプロパティ値に従うことで、パフォーマンスを最適化できます。 ただし、次のシステムプロパティは「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) クラウド 新しいパターン 対応する古いパターン AWS Amazon AWS - クラウドハードウェアタイプ (LP) Amazon AWS - ハードウェアタイプ (LP) Azure Azure:クラウドハードウェアタイプ (LP) Azure:ハードウェアタイプ (LP)

1.6.0 リリースより前は、AWS と Azure のお客様は修正スクリプトを実行して、オーケストレーションに必要な変更を実装していました。移行シナリオによっては、顧客に次の動作が見られる場合があります。

シナリオ 古いパターンの動作 新しいパターン動作 新しいハードウェアタイプのモデルに移行されていません パターンを処理する パターンは起動されません バージョン 1.6.0 より前の新しいハードウェアタイプモデルに移行 (修正スクリプト経由) パターンを処理する パターンは起動されません 新しいハードウェアタイプのモデルバージョン 1.6.0 以降に移行しました パターンは起動されません パターンを処理する フロー図:

終わり******