219 lines
17 KiB
Markdown
219 lines
17 KiB
Markdown
# Set-up-Native-SACM-for-SaaS_688996404
|
|
## Introduction
|
|
|
|
This topic guides you through the steps to prepare Native SACM in a SaaS environment.
|
|
|
|
## Prerequisites
|
|
|
|
Manually add an **unknown** value to the **OsFamily** attribute in UCMDB. If you have a custom **OS type** in SMAX, you must also create a corresponding **OsFamily** value in UCMDB. For more information about how to do it, see [Federation between SMA OS type and UCMDB OsFamily](https://rndwiki.houston.softwaregrp.net/itom/ESM:Main/TsNativeSacmOstype).
|
|
|
|
## Push data from UCMDB on-premises to ESM SaaS
|
|
|
|
To migrate data from UCMDB on-premises to ESM SaaS, contact SaaS Operations.
|
|
|
|
## Data pre-check before data migration
|
|
|
|
This section summarizes the preparation steps to handle the potential CI data issues (e.g., data configuration and format) that might exist in both SMAX and CMS before Native SACM can be activated.
|
|
We recommend that you manually fix these potential data issues before starting the Native SACM migration for the first time in Suite Administration.
|
|
|
|
### Manual Pre-check on CI data
|
|
|
|
#### Step 1. Pre-check SMAX data domain and CMS tenant definition
|
|
|
|
There are 3 scenarios:
|
|
|
|
##### Scenario 1. SMAX has the "Public" domain only and CMS Multi-Tenant has not been enabled
|
|
|
|
No action is needed if the SMAX version is 2021.05 or greater.
|
|
|
|
For earlier versions of SMAX, please contact support for a hotfix.
|
|
|
|
##### Scenario 2. SMAX has additional domains (e.g., IT, HR, Finance) and CMS Multi-Tenant has not been enabled
|
|
|
|
If multiple data domains exist in SMAX, you must enable CMS Multi-Tenancy first. To do this, go to the UCMDB JMX Console, disable the CI owner tenant, and then call the **enableTenant** method with the **tenantName** parameter set to **All Tenants**.
|
|
|
|
##### Scenario 3. SMAX has additional domains (e.g., IT, HR, Finance) and CMS Multi-Tenancy has been enabled
|
|
|
|
When SMAX has multiple data domains and CMS has multiple tenants configured, you must align the default UCMDB tenant setting with the SMAX **Public** domain. To do this, follow these steps:
|
|
|
|
1. In the UCMDB JMX Console, call the **setGlobalDefaultTenant** method to change the system default tenant to **All Tenants**. Note that this name is fixed and unchangeable.
|
|
This action sets **All Tenants** as the default tenant at the system level and the change will take effect for newly created customers. You can view the global default tenant by invoking the **getGlobalDefaultTenant** JMX method.
|
|
2. If one or more customers already exist, perform the following steps for each of them:
|
|
1. Call the **setTenantAsDefault** JMX method to change the default tenant to **All Tenants**.
|
|
2. You can view the default tenant of a consumer customer by invoking the **getDefaultTenant** JMX method.
|
|
3. Use an enrichment rule to move CIs from the original default tenant to **All Tenants** as needed.
|
|
4. If the **System Default Tenant** exists, move CIs owned by this tenant to other tenants, and then delete it.
|
|
|
|
**Note:** For UCMDB customers, be aware that CIs assigned to **All Tenants** are accessible to all users.
|
|
|
|
#### Step 2. Pre-check CI data information in SMAX and CMS
|
|
|
|
All following steps are strongly recommended **before** the data migration.
|
|
|
|
##### Step 2.1. Global ID check for CMS CIs
|
|
|
|
The CMS Global ID serves as the key linkage field between SMAX and CMS which means that all CMS CIs without global IDs will be ignored during the migration. Therefore, make sure all federated CMS CIs have global IDs so that they can be properly synchronized to SMAX. Federated CMS CIs include the following CI types (including all sub-CI types).
|
|
|
|
- Service
|
|
- Business Application
|
|
- Application Resource
|
|
- Application System
|
|
- Running Software
|
|
- Cloud Service
|
|
- Node
|
|
|
|
|
|
Note:
|
|
For data push integrations of multiple CMS servers, for example, during SaaS onboarding process, you need to ensure that the CIs' global IDs will not be overwritten after the CIs are pushed from the source CMS server to the target CMS server. To do this, you can:
|
|
|
|
1. Access to the JMX console.
|
|
2. Use the `getGlobalID` command in the UCMDB JMX Quick Search page.
|
|
3. Make sure that the `getGlobalID` command returns "All" in the response.
|
|
4. If the result is not "All", you need to do these steps:
|
|
1. Go to JMX console > **setAsGlobalIdGenerator**
|
|
2. Fill in **customerID**; Leave **dbTimeout** as empty; Set **overWriteE** **xistingGlobalIDs** as **False**.
|
|
3. Click **Invoke**.
|
|
|
|
##### Step 2.2. ENUM consistency check
|
|
|
|
You need to make sure all ENUM values are aligned between SMAX and CMS. A typical out-of-the-box example is SMAX OsType and CMS OsFamily. By default, there is "Unknown" defined in SMAX OsType, which is not defined on the CMS side. You must manually add this value to the CMS OsFamily ENUM to make them consistent.
|
|
|
|
This also applies to any other customized ENUM values in SMAX OsType and CMS OsFamily.
|
|
|
|
For the migration process, only the SMAX OSType and CMS OsFamily are required to be aligned.
|
|
|
|
##### Step 2.3. Complex type data format check
|
|
|
|
In SMAX, there are 6 complex-type fields for the SMAX Device record type, which are CPUs, DiskDevices, FileSystems, IpAddresses, NetworkCards, and RunningSoftwares. All sub-attributes of these fields are of the string type, which is not accepted by the corresponding CMS attribute definition. You must detect unaligned data values and correct them in SMAX prior to the migration.
|
|
|
|
|
|
|
|
The following table covers the sub-attributes of complex type fields which need special attention.
|
|
|
|
| SN | Complex Type Attributes | Data Format Required by CMS |
|
|
| --- | --- | --- |
|
|
| 1 | IP address type | IpV4 or IpV6 only, as they are ENUM values in CMS. |
|
|
| 2 | IP address value | Keep 4 segments (e.g. 192.168.56.33) for IpV4, and 8 segments for IpV6 (e.g., 2001:3CA1:010F:001A:121B:0000:0000:0010), otherwise they will not be accepted by CMS. |
|
|
| 3 | CPU ID | String type **Note:** This field is mandatory. |
|
|
| 4 | CPU clock speed | Integer only |
|
|
| 5 | Disk device size | Integer only |
|
|
| 6 | File system size | Double only |
|
|
| 7 | Network speed | Integer only |
|
|
| 8 | Running software ports | Integer only, single port only **Note:** Multiple ports are not supported by the migration. |
|
|
|
|
##### Step 2.4. Empty display label check for SMAX CIs
|
|
|
|
SMAX allows for creating CIs via REST call or importing via.csv, so some SMAX local CIs may have empty display labels even though this field will always be set via UI. However, in many cases, an empty CI name is not supported by CMS, which is mapped by SMAX CI display label during migration. Therefore, you need to find every SMAX local CI with an empty display label and set a proper value, especially for Actual Service, Service Component, and System Element.
|
|
|
|
For Device, CMS has reconciliation rules to uniquely identify one CI with different attributes, for example, BIOS UUID, BIOS Serial Number, or BIOS Asset Tag.
|
|
|
|
In order for a successful migration, you need to make sure at least one of these key attributes in SMAX Device is not empty. For example:
|
|
|
|
- Hostname
|
|
- Serial number
|
|
- BIOS UUID
|
|
- BIOS serial number
|
|
- BIOS asset tag
|
|
- Net BIOS name
|
|
|
|
Specifically, for the display label, you can use one SMAX business rule that figures out the display label. As shown in the example below, you can set the hostname or other attributes which will be copied as the display label.
|
|
|
|
|
|
|
|
##### Step 2.5. Duplicate display labels check for SMAX CIs
|
|
|
|
SMAX locally allows duplicated display labels for all SACM records, the current logic during migration maps the SMAX CI display label to the UCMDB CI name for Device, Service Component, Actual Service, and the CMS CI discovered product name (for SMAX system element). However, UCMDB by default doesn't accept identical names among different CIs, therefore the duplicated CIs existing on the SMAX side will be rejected by UCMDB.
|
|
|
|
In a real-world environment, duplicated CIs existing on the SMAX side are mostly caused by the old OPB-based integration and have been moved to **End of Life** or **Final** metaphase already. Hence, if these SMAX CIs are rejected by UCMDB, the migration mechanism will automatically re-push them to UCMDB with the **discovery\_state** attribute set to **Purgeable**, thiswill bypass the UCMDB reconciliation and will be accepted by UCMDB. This solution reduces the orphan CIs left in SMAX, thus improving the CI consistency between SMAX and UCMDB.
|
|
|
|
Note that for any existing CI in UCMDB before the migration, no **Purgeable** flag will be set during the migration. Instead, the flag will be set by UCMDB when these CIs have aged with the enhanced CI lifecycle after Native SACM is enabled.
|
|
|
|
If the duplicated CIs exist on the SMAX side aren't at **End of Life** or **Final** metaphases, additional steps are still needed according to different record types.
|
|
|
|
- For Actual Services and Business Applications, you need to update their display labels to different ones, or remove the duplicate CIs, or move them to the **Final** metaphase, or perform the following steps to remove UCMDB identification rule before the migration:
|
|
1. Go to the CMS CI Type Manager.
|
|
2. Select the **BusinessService** CI Type.
|
|
3. In the **Identification** pane, set the identification method to **No identification**.
|
|
4. Save the change.
|
|
5. Repeat step 2 to step 4 for the **InfrastructureService** and **BusinessApplication** CI Type.
|
|
- For System Elements, currently, only SMAX Running Software will be migrated to UCMDB, and duplicated discovered product names aren't allowed among multiple Running Software associated with one single node in UCMDB. Therefore, we recommend that you update their display labels to different ones, or remove the duplicated CIs, or move them to **End of Life** metaphase before the migration.
|
|
- For Devices, similarly, we recommend that you update their display labels to different ones, or remove the duplicated CIs, or move them to **End of Life** metaphase before the migration.
|
|
|
|
Step 2.6. Review SMAX Business Rules
|
|
|
|
Some custom business rules may conflict with the CI notification of Native SACM, please review the following types of business rules and make adjustments as needed.
|
|
|
|
- The business rule **Define field as mandatory**. For example, if a customer defines any field as mandatory for Device through this rule, all UCMDB nodes can't be synchronized to SMAX (either creating or updating) when UCMDB can't populate the mandatory field values (e.g., any SMAX local fields such as "Owner"). To avoid this, please make sure all mandatory fields will be set by default for newly created devices in SMAX and all existing SMAX devices have all mandatory fields populated before enabling Native SACM.
|
|
- The business rule **Define field as read-only**. For example, if a customer defines any federation fields (e.g., "Serial number" or "Subtype") as read-only for Device through this rule, UCMDB nodes can be synchronized to SMAX. However, after Native SACM is enabled, any CI notifications including "Serial number" or "Subtype" will fail and cause CI inconsistency. To avoid this, please remove/disable relative read-only rules or exclude all federation fields from the rules.
|
|
- The business rule **Restrict editing of fields**. For example, if a customer restricts editing of any federation fields (e.g., "Serial number" or "Subtype") for Device through this rule, all UCMDB nodes can't be synchronized to SMAX (either creating or updating). To avoid this, please remove/disable relative restrict editing rules or exclude all federation fields from the rules.
|
|
|
|
#### Step 3. Configure Native SACM settings and trigger Migration in Suite Administration
|
|
|
|
By now you have fixed the known data issues and you can start to configure the Native SACM settings in Suite Administration.
|
|
|
|
It is expected that there is a data mismatch of CIs between SMAX and CMS. You will get the following popup window.
|
|
|
|
|
|
|
|
The popup window indicates that SMAX detects CIs that are different between SMAX and CMS, so a data migration is needed. Since you have already fixed the known data issues in SMAX and CMS, you can go ahead to click **MIGRATE** to start the migration. If all issues are resolved the migration will succeed and Native SACM will be automatically enabled and set to active.
|
|
|
|
In case the migration identifies errors, the errors will be tracked in the migration report. You can download and review the report and fix the issues according to your actual business needs. You are recommended but not forced to fix all the issues. For example, if some SMAX local CI relationships fail to be migrated, and if you believe UD can discover those CI relationships in a more accurate manner and this error can be accepted anyway, it is okay for you to leave it as is.
|
|
|
|
Do not click the **Enable** button until all issues are resolved or you can accept all remaining issues, as you CANNOT start the migration again and the data will not be in a synchronized state.
|
|
|
|
## Migration limitations
|
|
|
|
There are some migration limitations because CMS has different CI and CI relationship characters with SMAX.
|
|
|
|
#### Limitation 1. Standalone system element is not supported for the migration
|
|
|
|
CMS does not allow standalone "Running Software" to which SMAX System Element is mapped, so all standalone SMAX system element CIs will not be migrated.
|
|
|
|
#### Limitation 2. System elements of limited OOB subtypes are supported by the migration
|
|
|
|
SMAX system elements have 13 OOB subtypes as shown in the following screenshot, and only system elements of 4 of them (Running Software, Web Server, Database, and Application Server) are allowed to be migrated to CMS CIs of the same CI Type names if each system element is already linked to one existing device.
|
|
|
|
|
|
|
|
System elements of all other 9 out-of-the-box subtypes are not supported by the migration, due to the following reasons.
|
|
|
|
- Mapped peer CMS CI Type is abstract (e.g., Application System, Application Resource, AWS Resource, and WebService Resource), which cannot be instantiated in CMS.
|
|
- Not supported by the current mapping file between SMAX Subtype and CMS CI type (e.g., Virtualization, CI collection, and Other), and the mapping file cannot be customized in SaaS.
|
|
- Not business applicable (e.g., Database Resource and Cloud Service).
|
|
|
|
System elements with customized or empty subtypes will not be migrated either, due to the following reasons.
|
|
|
|
- The CMS CI type mapped with SMAX subtype does not follow a certain pattern, it is hard to guarantee the migration of system elements of customized subtypes will succeed. Currently, it is not supported.
|
|
- The base CI Type mapped to System Element is "Infrastructure Element," which is abstract and cannot be instantiated in CMS.
|
|
|
|
#### Limitation 3: Devices of the "Cluster resource group" subtype are not supported by the migration
|
|
|
|
CMS does not support a standalone "ClusterResourceGroup," which has to be linked with at least one cluster CI. Hence, devices of the "Cluster resource group" subtype in SMAX will not be migrated as SMAX does not support the migration of any cluster CIs in System Elements. To work around it, you may change the "ClusterResourceGroup" subtype of the device to "Other" in order to migrate it to CMS.
|
|
|
|
## Enable enrichment rules in UCMDB
|
|
|
|
When a CI of a federated CI type is created or discovered in UCMDB, enrichment rules are implemented for mapping Subtypes of SMA. The `SMAX` folder contains preset enrichment rules for the federated CI types. By default, these enrichment rules are inactive, we recommend that you activate them all and don't make any changes unless you have customized Subtypes. To do this, open **Enrichment Manager** in UCMDB and activate all enrichment rules in the `SMAX` folder.
|
|
|
|
## UCMDB Browser
|
|
|
|
To build an end-to-end topology, it's required to connect the logic with the physical elements. To do so, you can use the Assisted Service Modelling feature from the UCMDB browser. The UCMDB browser is directly accessible from the SMA UI by using the “Explore” functionality.
|
|
|
|
**Note:** You need to have the **Enable 'Explore' in CI details** permission enabled in the user role. For details about how to enable this permission, see [Roles](https://rndwiki.houston.softwaregrp.net/itom/ESM:Main/pplRoles).
|
|
|
|
**Related pages**
|
|
|
|
- Page:
|
|
[ESM Cloud Farm Version Tracking](/display/ICSD/ESM+Cloud+Farm+Version+Tracking)
|
|
- Page:
|
|
[How to get an Opentext Confluence account](/display/ICSD/How+to+get+an+Opentext+Confluence+account)
|
|
- Page:
|
|
[ITOM APM AppPluse Cloud Farm Information](/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information)
|
|
- Page:
|
|
[ITOM Cloud Service Ops Doc Management Process](/display/ICSD/ITOM+Cloud+Service+Ops+Doc+Management+Process)
|
|
- Page:
|
|
[ITOM ESM Cloud Service Catalog](/display/ICSD/ITOM+ESM+Cloud+Service+Catalog)
|
|
- Page:
|
|
[ITOM OpsB NOM Cloud Service Catalog](/display/ICSD/ITOM+OpsB+NOM+Cloud+Service+Catalog)
|
|
- Page:
|
|
[OpsB and NOM Cloud Deployments Version Tracking](/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking)
|