This document lists the procedure to decouple the TCSA Core and the DMs.
Note: It is recommended to decouple TCSA DM from TCSA Core prior to the upgrade of TCSA 2.4 Domain Managers to Smarts 24.3.13.
TCSA Deployments
Steps that need to be followed on TCSA Core
Launch the TCSA URL and navigate to Administration tab > Configurations > Domain Settings.
Delete all the configured Domain settings.
Navigate to Administration tab > Configurations > Collectors and Connectors > Collectors section.
Delete all configured collectors.
Navigate to Administration tab > Configurations > Collectors and Connectors > 5G Integration section.
Delete all the 5G Integrations.
Navigate to Administration tab > Configurations > Collectors and Connectors > Smarts Integration section.
Delete all the Smarts Integrations.
Note:
In TCSA 2.4, the Fault collectors are pointed to TCSA Core DCF and TCSA Edge Kafa. These settings should be unconfigured and pointed to Standalone DCF and Standalone Kafka post the DM upgrade.
Decoupling Steps for TCSA Domain Managers 2.4:
Note:
Smarts 24.3.13/24.3.10 supports following Fault collectors. If any of the below collectors are configured in TCSA DM 2.4, then the settings need to be unconfigured and reconfigured back post upgrade to 24.3.13/24.3.10
Follow the below steps on the TCSA 2.4 DMs to unconfigure the fault collectors.
Cisco ACI Fault Collector:
Follow the below steps if Cisco ACI Fault collector is configured:
a) Launch the Domain Manager Administrator Console of the IP Server where the Cisco ACI device is discovered.
b) Delete the Control Cluster Instance from the IP Domain Manager. All the Cisco ACI related classes will be deleted. If there are any stale instances of Cisco ACI classes, then those instances need to be deleted.
c) Run the following dmctl command to delete the Collector IDs of Cisco ACI in the IP Domain Manager.
<IP-BaseDir>/smarts/bin/dmctl -s <IP-Server_Name> invoke ICF_PersistentDataSet :: ACICollectorIDs get - List all the Collector IDs.
<IP-BaseDir>/smarts/bin/dmctl -s <IP-Server_Name> invoke ICF_PersistentDataSet :: ACICollectorIDs clear - Removes all the Collector IDs.
d) Navigate to the IP Server Polling and Thresholds Window > Device Access Tab. If there are any new Device Access Groups (non-default access groups) created for Cisco ACI Settings, Kafka Settings and DCF Settings, then those device access groups need to be deleted. Refer to the screenshot below.
e) If the Cisco ACI settings are configured using the default Cisco ACI Access group, Kafka Bus Access Group and Data Collector Access Group, then “Remove” the Cisco ACI Access Setting, Kafka Access Setting and Data Collector Access Setting from their respective groups and “Add” those settings back. Refer to the screenshot below. This will ensure that all the configured settings are deleted for the respective groups and default settings are restored.
VCD Fault Collector:
Follow the below steps if VCD Fault collector is configured:
a)Launch the Domain Manager Administrator Console of the ESM Server where the VCD device is discovered.
b) Delete the Cloud Controller Instance from the ESM Domain Manager. All the VCD related classes will be deleted. If there are any stale instances of VCD related classes, then delete those instances.
c) Run the following dmctl commands to delete the Collector IDs of VCD in the ESM Domain Manager.
<ESM-BaseDir>/smarts/bin/dmctl -s <ESM-ServerName> invoke ICF_PersistentDataSet :: VCDCollectorInstanceIds get - List all the VCD Collector IDs.
<ESM-BaseDir>/smarts/bin/dmctl -s <ESM-ServerName> invoke ICF_PersistentDataSet :: VCDCollectorInstanceIds clear - Removes all the VCD Collector IDs.
d) Navigate to the Polling and Thresholds Window of the ESM Server > DeviceAccess Tab. If there are any new device access groups (non-default access groups) created for VCD Settings, Kafka Settings and DCF Settings. Then delete those Device Access Groups. Refer the screenshot below.
e) If the settings are configured using the default VCD Access group, Kafka Bus Access Group and Data Collector Access Group, then “Remove” the VCD Access Setting, Kafka Access Setting and Data Collector Access Setting from their respective devices access groups and then “Add” those settings back. Refer to the screenshot below. This will ensure that all the configured settings are deleted for the respective groups and default settings are restored.
VMware Aria Alerts Collector:
Follow the below steps if VMware Aria Alerts Collector is configured:
a)Navigate to the INCHARGE-OI Install bin directory where the VMware Aria Alerts Collector is configured and run the following dmctl commands to remove the VMware Aria Alerts setting, Kafka Settings and DCF Settings.
<SAM-BaseDir>/smarts/bin/dmctl -s <OI-ServerName> getI Vrops_AccessSetting - Lists the VMware Aria Access Setting Instance
<SAM-BaseDir>/smarts/bin/dmctl -s <OI-ServerName> delete Vrops_AccessSetting::<Vrops_AccessSetting-Instance> - Deletes the VMware Aria Access Setting.
<SAM-BaseDir>/smarts/bin/dmctl -s <OI-ServerName> getI Kafka_AccessSetting - List the Kafka Access Setting
<SAM-BaseDir>/smarts/bin/dmctl -s <OI-ServerName> delete Kafka_AccessSetting::<Kafka_AccessSetting-Instance> - Deletes the Kafka Access Setting
<SAM-BaseDir>/smarts/bin/dmctl -s <OI-ServerName> getI DataCollector_AccessSetting - List the Data Collector Access Setting
<SAM-BaseDir>/smarts/bin/dmctl -s <OI-ServerName> delete DataCollector_AccessSetting::<DataCollector_AccessSetting-Instance> - Deletes the Data Collector Access Setting
Post Decoupling procedure:
After performing the decoupling procedure, the TCSA Core will be decoupled from TCSA DMs. The user then needs to follow the Upgrade procedure documented in the Domain Manager Install guide to upgrade the Domain Managers. Once the upgrade is successful, the user needs to follow the steps mentioned in Deployment Scenario guide to re-configure any of the Cisco ACI, VMware Aria Alerts and VCD features.