Migrating to a New Hardware Type Model - Support and Troubleshooting

Migrating to a New Hardware Type Model Description This KB article explains the process for migrating to the new hardware type model.

Index

Overview Release Version Prerequisites Steps to Migrate to New Hardware Type Model Steps to clean the old Model hardware type records Issue with the Update set solution prior to 1.6.0 Pattern Execution Flow

Overview Hardware types are configuration items (CI)s that represent pre-defined virtual machine types provided by cloud vendors. Cloud vendors provide several hundreds of out-of-box types. In most cases, customers are using the out-of-box types(Example- t2.nano, t2.micro, t2.large in AWS). Old Hardware Type Model

This model uses the class cmdb_ci_compute_template (label: Hardware Type). This class is a dependent class on cmdb_ci_logical_datacenter. The result of this modeling is that each out-of-box hardware type is modeled in the CMDB N times where N = number of service accounts * number of logical datacenters. Customers with hundreds of service accounts end up discovering millions of hardware type records in the CMDB. This slows down discovery and other related flows that can cause performance issues. Hence, customers are puzzled by the fact that hundreds of hardware types present in the cloud (AWS, AZURE, GCP) result in millions of records being persisted in the CMDB. New Hardware Type Model

This model reduces the number of hardware type records in the CMDB. Hardware types are populated in cmdb_ci_cloud_hardware_type (label: Cloud Hardware Type). This is an independent class. It will create one record for each hardware type irrespective of the Service account and data center. This will reduce the millions of hardware type records to hundreds of records. Release Version This feature is available starting from:

Release Version: Discovery and Service Mapping Patterns store app version 1.6.0 (June 2023) or later. Note:

We recommend upgrading the discovery and Service Mapping Patterns store app to version 1.6.0 or later to adopt the new solution to migrate to New Model For versions prior to 1.6.0 , an Update Set was provided to migrate to a hardware type model for AWS, Azure, and GCP. If you have already migrated using the Update Set, no further action is required.

Prerequisites Before migrating to the new model, the following criteria should be met:

Discovery and Service Mapping Patterns Store App : It should be Active and at version 1.6.0 or later AWS/Azure Customers: This new model is applicable only to customers who have already migrated from CPG to Patterns. This prerequisite is not applicable to GCP customers, as GCP follows a direct Patterns flow without a migration from CPG. Cloud Insights Store App: If the Cloud Insights app is active, it supports this feature starting from plugin version 2.2.0 or later.

Steps to Migrate New Hardware Type Model This solution is applicable for AWS, Azure, and GCP customers.

Migration Steps:

1. Set the System Property: To migrate to a new hardware type model, set the System Property " sn_itom_pattern.use a single hardware type for cloud data centers" to true.

To do this, Navigate to Filter Navigator -> enter sys_properties.list -> Search for sn_itom_pattern.use a single hardware type for cloud data centers Note: Once this property is enabled, future discoveries will populate records in the new model table (cmdb_ci_cloud_hardware_type).

Restrictions and Important Notes:

Release version 1.6.0 onwards, "Amazon AWS - Hardware Type (LP)" and "Azure - Hardware Type (LP)" will no longer receive updates. Changing the System property " sn_itom_pattern.use a single hardware type for cloud data centers " from true to false by flipping it is not supported (It means New model to Old model).

Steps to clean the old Model hardware type records Follow these steps only if you need to delete records from old table (cmdb_ci_compute_template):

If you haven't deleted old model hardware type records, migrated to a new model and run cloud discovery, you may observe both old and new model records and relations in CMDB.

To Delete old model Hardware type records, import the update set in Global Scope and commit it. Once the update set has been committed, follow the steps below:

Navigate from the Filter Navigator -> System Definition -> Scheduled Jobs -> Search for job Named " Old Hardware Types Model records Mark as Absent" Activate the Scheduled job by clicking on " Active " and then click on " Update " This Schedule Job will periodically update the old model(cmdb_ci_compute_template) cis status as Absent . Subsequently, Table cleaner will delete the Absent records in cmdb_ci_compute_template table. Note :

You can adjust the repeat interval and follow system property values to optimize the performance. However, please note that the following system properties are not listed in the 'sys_properties' table. Should you wish to update these properties, you can either add them to the 'sys_properties' table or directly modify values within the scheduled job script.

sn_itom_pattern_delete_old_hardware_type_job_count - Defines the number of jobs executed simultaneously. The default value is set to 10 sn_itom_pattern_delete_old_hardware_type_batch_size - Specifies the number of records processed by each job. The default value set to 10000 Considerations for Running the 'Old Hardware Types Model records Mark as Absent' Scheduled Job:

When running the scheduled job that marks old hardware type model records as absent, consider the following to avoid potential performance issues:

System Resource Management: For instances with large datasets, schedule this job during off-peak times to reduce the load on the system. Ensure that no other scheduled jobs are running concurrently, and verify that the instance has adequate resources available. Table Cleaner Operation: Once records are marked as absent, the Table Cleaner process will continuously scan and remove these records. Although it works in regular intervals, this constant background activity may lead to performance degradation, especially if a large number of records need to be processed. Performance Impact: Since the Table Cleaner may take time to process absent records, it can put additional load on your instance, potentially affecting overall performance. Best Practice: To reduce performance risks and prevent further impact on instance performance, manually schedule this job during low-activity periods, ideally for couple of hours when system load is minimal. Rather than marking all CIs as absent at once, break the job into multiple intervals, processing smaller batches of data during each run for the Table Cleaner. This approach helps avoid significant performance degradation.

Issue with the Update set solution prior to 1.6.0 For versions prior to 1.6.0, migrating to the new hardware type model using the Update Set requires the execution of a fix script provided in the update set. The fix script will: Enable the system property " sn_itom_pattern.use a single hardware type for cloud data centers" Implement necessary orchestration changes to AWS (Amazon AWS - Hardware Type (LP)) and Azure (Azure - Hardware Type (LP)) patterns. Important: Any changes made by the fix script will be treated as customizations and will not be included in future updates. Be aware that these customizations will need to be maintained separately.

Pattern Execution Flow Note: GCP cloud discovery use the 'Google Cloud Platform (GCP) - Virtual Server' pattern for both old and new flows to populate the cmdb_ci_compute_template and cmdb_ci_cloud_hardware_type table based on System property value.

In the 1.6.0 version, two new patterns were introduced:

Amazon AWS - Cloud Hardware Type (LP) Azure - Cloud Hardware Type (LP) Cloud New Pattern Corresponding Old Pattern AWS Amazon AWS - Cloud Hardware Type (LP) Amazon AWS - Hardware Type (LP) Azure Azure - Cloud Hardware Type (LP) Azure - Hardware Type (LP)

Before the 1.6.0 release, AWS and Azure customers executed a fix script to implement the necessary orchestration changes. Depending on the migration scenario, customers may observe the following behaviors:

Scenario Old Pattern Behaviour New Pattern Behaviour Not migrated to New hardware type model Process the pattern Gracefully terminate the pattern Migrated to New hardware type model before 1.6.0 version (via Fix Scripts) Process the pattern Gracefully terminate the pattern Migrated to New hardware type model version 1.6.0 or later Gracefully terminate the pattern Process the pattern Flow Diagram:

***** END ******