Commander Commander
Commander
185 views

[OBM] When adding a secondary management server, can I transfer all nodes to it automatically?

Jump to solution

If I add a new OBM manager as a secondary manager using Flexible Management policy, is there a way to automatically add the nodes (Agents) monitored by the primary OBM to the secondary OBM? I mean that they would appear under Monitored Nodes automatically and become monitored without the need to manually re-add agent by agent, while also stay monitored by the primary.

1 Solution

Accepted Solutions
Commander Commander
Commander

Thank you @Shawn Tripet, your solution helped me a lot.

 

When using Linux servers, the method is much easier and can be done by executing one command line on each server, and no need for a Perl script nor converting to CSV.

 

Solution on Linux:

From OBM1:

 

./opr-node -username <username> -password <password> -list_nodes | grep 'Primary DNS Name' | awk '{print $5}' > /tmp/node_list

 

 

After that, copy the result file to the second OBM server, then execute the following command on OBM2:

 

cat /tmp/node_list | xargs -n1 ./opr-node -username <username> -password <password> -add_node -node_name

 

 

You might need to wait sometime depending on the number of nodes to be added.

 

Make sure that OBM2 knows the hostnames of the nodes in OBM1, such as through /etc/hosts or a common local DNS server.

View solution in original post

5 Replies
Admiral Admiral
Admiral

@MahmoudJ:

I have not found a way to do this easily, so I have created scripts to somewhat automate it. It is VERY frustrating that we do not have a Tool provided to help us with this.

Below is a summary of how we handle this:

1)  Run on the source server:  opr-node -username actualusernamehere -password actualpasswordhere -list_node -filter_name "actualnodefiltername">C:\temp\nodelist.txt

2) I created and ran a perl script to parse the output file C:\temp\nodelist.txt which creates a .csv file with one node record per line.  So, run the parse script against the C:\temp\nodelist.txt to get csv output file C:\temp\omi_nodelist.csv

"D:\Program Files\HP\HP BTO Software\nonOV\perl\a\bin\perl.exe" .\parse_omi_node_list.pl "C:\\temp\\nodelist.txt"

3) I then copied the .csv output file C:\temp\omi_nodelist.csv to the destination OBM server

4)  I then created and ran a batch script on the destination server to automatically add the nodes from the C:\temp\omi_nodelist.csv input file using the opr-node CLI

<directorypathhere>\add_nodes_inputfile.bat "C:\temp\omi_nodelist.csv"

(Note:  If a node already exists it will act like it adds the node and tells you the operation succeeded but it will not add a duplicate node object so no big deal)

However, in our case, the above process only handles ci types of "node" (agentless) and "nt" (Windows), and so I am not sure how to handle ci types of cluster and cluster_resource_group. 

Then, if you also have Node Groups (Ci Collections) to sync, you will want to add the same node groups tree onto the destination server, then you can automate adding the nodes into node groups on the destination server.  To do that, created yet another batch script which runs on the source server via Task Scheduler periodically which checks the nodes in node groups on the source server and then checks if the nodes exist in that same node group on the destination server, and if not it adds the nodes to the node group.  This script uses the opr-node CLI

This is ugly. 

If there is an easier way to do this I would also appreciate some help with this too. 

In our case we have two OBM 2020.10 Combined/Single servers using embedded PostgreSQL DB and we use Flexible Mgt policy.  One of these servers acts as the DR hot standby server.  In general, config changes we make on the normally active OBM server we manually do on the DR hot standby server.  We are basically trying to get this environment to work similar to how it used to work in the old HPOM.  Some of it can be automated with Content Packs but most operations require manual setup and it takes too long set up in my opinion.  We do not use Load Balancer and have no desire to do so.

"Read-Aim-Fire, NOT Ready-Fire-Aim"
Micro Focus Expert
Micro Focus Expert

Hello Mahmoud and Shawn,

There are basically following ways to deal with this:

1. When you add a connected server (for the other OBM), you can select to forward topology data.

This should work well in case the second server is just DR and thus you don't have to worry too much about back and forth syncing.

You enable that by checking the "Forward dynamic topology" box of the connected server.

This will not forward existing CIs, only new CIs.

2. Similar to other integrations (e.g. the APM integration), you could use UCMDB mechanisms.

This is easy said, but unfortunately not so easy done. You would need to install a Data Flow Probe and then set up integration job(s) with TQL queries to pull the CIs from one side and add them on the other.

3. Automatic node CI creation

If you're just interested in having node CIs without having all the topology, you could enable the "Dynamic Node Generation Enabled" infrastructure setting.

That works well for example if a lot of events come via NNMi but you don't want all NNMi nodes.

Best regards,
Tobias

Commander Commander
Commander

Thank you @Shawn Tripet, your solution helped me a lot.

 

When using Linux servers, the method is much easier and can be done by executing one command line on each server, and no need for a Perl script nor converting to CSV.

 

Solution on Linux:

From OBM1:

 

./opr-node -username <username> -password <password> -list_nodes | grep 'Primary DNS Name' | awk '{print $5}' > /tmp/node_list

 

 

After that, copy the result file to the second OBM server, then execute the following command on OBM2:

 

cat /tmp/node_list | xargs -n1 ./opr-node -username <username> -password <password> -add_node -node_name

 

 

You might need to wait sometime depending on the number of nodes to be added.

 

Make sure that OBM2 knows the hostnames of the nodes in OBM1, such as through /etc/hosts or a common local DNS server.

View solution in original post

Admiral Admiral
Admiral

@tobias_m 

I tried method 1) and it does not work.  On the source OBM server I created the OBM connected server for the Dr OBM server, and checked forward dynamic topolgy then enabled it.  I then added a node onto the source OBM server, and the next day that node does not exist in OBM on the DR server.

I do have trusted relationships set up between both servers as we are using Flexible Management policy.

When do the topo sync updates occur?  My experience is that this method does not work and when I add nodes to the source OBM server they do not get added to the OBM server which has a connected server with "Forward Dynamic Topolgy" checked. 

Questions I have:  What am I missing?  Why doesn't this work?  What is the schedule?  How often does it sync?

Another comment I have is that we want this to work for both existing and new CI's added.  I simply want to have the same nodes on both servers and it seems like there should be a simple tool to allow us to export and import nodes to and from OBM servers.

"Read-Aim-Fire, NOT Ready-Fire-Aim"
0 Likes
Micro Focus Expert
Micro Focus Expert

Hello Shawn,

 

It turns out the "Forward dynamic topology" will only forward discovery data that came in via service discovery. (e.g. agent checking in). It does not cover existing CIs and it does not cover manually added nodes in OBM.

 

I was told that "Forward dynamic topology" is for a limited use case (OBM to OML forwarding, which is a very exotic use case, because usually topo is forwarded from OML to OBM, not the other way around).

 

That means, UCMDB sync via integration job is pretty much the only option. Would need something similar as for APM integration (it has a job to sync all which runs not that often, and a job for delta that runs more frequently).

Best regards,
Tobias

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.