DX UIM environment shutdown and start up process

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

We plan to do some maintenance or updates, or otherwise have a need to reboot the UIM infrastructure servers.

Which UIM components need to be shut down/stopped/disabled during this period and in what order should they be shut down?  And in what order would you start up the UIM components?

Environment

• Any UIM release

Resolution

Here are some suggested guidelines for shutting down UIM components.

1.  On all robots where the UMP, Unified Reporter, Operator Console, and/or CABI components are deployed, stop the DX UIM Nimsoft Robot Watcher service.
2.  If an HA backup hub exists in the UIM domain, stop the service on this hub
3   Stop the UIM service on the Primary hub

All UIM messages (QoS, alarm, probeDiscovery, etc) will back up on the robots and all other hubs in the UIM domain.

• These messages will be stored in local queue files on these systems until the Primary hub is back up and running.
• If there is a risk of running out of disk space on any of these devices, then it is recommended that the UIM service be stopped on these systems as well. This will result in a gap in the QoS metrics collected from the probes on these devices.
• You may also choose to deactivate one or more, or all of the Queues on any given hub where monitoring is taking place and QOS/alarms are being generated.
At the robot/source, probe-level, whether a local or remote monitoring probe, you can also choose to NOT generate (publish) QOS or alarms by modifying the probe configuration(s) and deselecting QOS/alarms.

At the robot/source, probe-level, whether a local or remote monitoring probe, you can also choose to NOT generate (publish) QOS or alarms by modifying the probe configuration(s) and deselecting QOS / alarm publishing options.

If there are a number of "collector" hubs in the UIM domain (secondary hubs that are collecting messages from robots managed by this hub or other downstream hubs to be funneled to the Primary hub), it would be a good idea to set up a means of blocking the traffic from these hubs to the primary hub so that when the Primary hub comes back on-line, it is not flooded with the build-up of messages from all of these hubs all at once.

Activate the UIM monitoring environment/Nimsoft Services in the reverse order:

1.  Start the UIM service on the Primary hub.  Verify that there are no issues with connecting to the database manager but test the connection from the data_engine probe's Configure GUI.
2.  Start the UIM service on the HA backup hub where/when applicable.
3.  Start the UIM service on all of the UMP, Operator Console, Unified Reporter, and/or CABI robots.

If you have multiple collector hubs in the UIM domain, unblock the traffic from these hubs to the Primary hub one at a time.  When the "ATTACH" queues to the Primary hub are drained from one collector hub, then do the same on the next until all messages are flowing from all collector hubs to the Primary hub.

Note: For robot systems (non-hub) it is generally not necessary to do any manual process; a normal system reboot will be fine, and the robot will be restarted as a matter of course by the operating system.  The above only applies to UIM hubs, or Infrastructure components such as UMP/OC/CABI, not normal robots.

Additional Information

On Windows systems, Stop and Start the Nimsoft Robot Watcher service from the Windows services.msc utility to Stop/Start the UIM service.

On Linux/UNIX systems you Stop and Start the UIM service by executing the following commands from a root user login shell:

To Stop the UIM service:
service nimbus stop or ./niminit stop

To Start the UIM service:
service nimbus start or ./niminit start

To check for running or stopped Nimsoft processes issue the command:

ps -ef | grep nim