In a previous post, I explained why it makes sense for customers using HP Operations Manager (HPOM) for Windows, HP-UX, Solaris or Linux to move to Operations Manager i (OMi) for a single pane of glass view. I also provided an overview of the recommended technical steps to take, and I outlined how to import and reuse existing HPOM policies in OMi.
Today I want to have a closer look at when and how to switch Operations Agents to OMi, because that’s one of the necessary steps in the Evolution.
You can find complete details for moving Operations Agents to OMi in the Operations Bridge Evolution Guide available from the Operations Bridge Evolution Resource page, but here is a quick overview of the five recommended steps:
- Start by configuring all agents in your existing HPOM environment with a flexible management template that allows the new OMi server to configure your agents.
- Next, choose a group or type of nodes to move over, for example, all your Oracle Database systems
- Test policy and aspect deployment and tool execution from OMi on a representative node of that type. This might include importing HPOM policies and creating OMi aspects and management templates as I have outlined in one of my previous posts.
- After a successful test, roll out the configuration to the remaining nodes of that type, either manually or by using automatic assignment rules.
- Switch the primary manager and target server to OMi. Doing so still allows configuration from both OMi and HPOM servers. This is the first “switch” of agents.
- Repeat steps 2–3 until all nodes are managed by OMi.
- Before switching off the HPOM server, switch the agents to OMi completely, and clean up old HPOM policies if necessary. This is the second and final switch of agents.
Let me explain each these steps a little bit more.
Step 1: Configure all agents with a Flexible Management template
Flexible management templates define which management servers are authorized by the agent. We use the same concept now to grant the OMi server the permission to configure the existing Operations Agents.
- Create a policy like the following ON THE HPOM SERVER. You can use the ManagementResponsibilitySwitch example as starting point:
Of course you have to replace hpom.example.net and omi.example.net with your server names
# # Configuration file # defines management responsibility switching # TIMETEMPLATES #none RESPMGRCONFIGS RESPMGRCONFIG DESCRIPTION "OM and OMi as responsible mgrs" SECONDARYMANAGERS SECONDARYMANAGER NODE IP 0.0.0.0 "omi.example.net" DESCRIPTION "OMi" SECONDARYMANAGER NODE IP 0.0.0.0 "hpom.example.net" DESCRIPTION "OM" ACTIONALLOWMANAGERS ACTIONALLOWMANAGER NODE IP 0.0.0.0 "hpom.example.net" DESCRIPTION "OM" ACTIONALLOWMANAGER NODE IP 0.0.0.0 "omi.example.net" DESCRIPTION "OMi" ACTIONALLOWMANAGER NODE IP 0.0.0.0 "$OPC_PRIMARY_MGR" DESCRIPTION "current primary manager" MSGTARGETRULES MSGTARGETRULE DESCRIPTION "always send all messages to current primary manager" MSGTARGETRULECONDS MSGTARGETMANAGERS MSGTARGETMANAGER TIMETEMPLATE "$OPC_ALWAYS" OPCMGR IP 0.0.0.0 "$OPC_PRIMARY_MGR"
2. Deploy the policy from the HPOM server to all nodes. With that the OMi server can configure all the existing Operations Agents.
Step 2: Test and roll out configuration from OMi
These steps are about the assignment of aspects from OMi, first to one node and then to multiple nodes. For details, please see the Operations Bridge Evolution Guide available from the Operations Bridge Evolution Resource page or my previous post (in which I partially covered this aspect as well).
Let me point out an important fact here: The test and rollout can be done while the old policies deployed from HPOM are still active. This assures ongoing monitoring of your business critical applications! New policies deployed from OMi that have the same name replace the existing policies from HPOM.
Step 3: Switch the primary manager and target server
To verify that all server-based correlation features of OMi are working as expected, including duplicate suppression and event storm suppression, it is recommended that you change the target server for events to OMi as well.
With the earlier mentioned flexible management policy, you can switch the target server by switching the primary manager of a node, because the flexible management policy contains the following as message target rule:
MSGTARGETMANAGER TIMETEMPLATE "$OPC_ALWAYS" OPCMGR IP 0.0.0.0 "$OPC_PRIMARY_MGR"
You can switch the primary manager from OMi using:
opr-ragt -username admin -primmgr <node selection>
<node selection> can be a comma-separated list of nodes, a node group or a view. For example, if in step 2b you used a view MyOracleSystems to deploy configuration to all nodes running Oracle, then you can use that same view to switch the primary manager of those nodes:
opr-ragt -username admin –primmgr –view_name MyOracleSystems
Step 4: Repeat for other types of nodes
Repeat steps two and three until all nodes are managed by OMi. You might also want to delete the node from Operations Manager, or at least disable heart beat polling since health checks should be completed by OMi now.
When this step is completed, all nodes are configured by OMi and send their events to OMi directly.
Step 4: Switch the agent
To be able to switch off the HPOM server, the agents need to be reconfigured so that they use the OMi server as their server, even when the flexible management template is removed. This can be done using the opr-agt -switch_manager option. It changes the following settings on the agent:
sec.cm.client CERTIFICATE_SERVER sec.core.auth MANAGER sec.core.auth MANAGER_ID eaagt.lic.mgrs GENERAL_LICMGR
Again, you can use a view name to switch certain nodes, for example, from OMi you could use something like:
opr-agt -switch_manager –view_name All_agents_mgd_by_OMi -username admin Make sure that this view only contains those nodes you want to switch. Especially make sure that the HPOM server node is not part of that view. As an alternative use the –node_list option:
opr-agt -switch_manager –node_list node1fqdn,node2fqdn,node3fqdn
Optional Step: clean up old HPOM policies
In case you decided not to reuse all HPOM policies, there might be some old HPOM policies still installed on the nodes. To remove these, simply call this command on your OMi server:
opr-agt –deploy -clean <node selection> -username admin
This deletes all existing policies on the nodes, including the flexible management template that grants rights to both OMi and HPOM servers, and then deploys all policies that are assigned to the nodes in OMi.
The result of a –switch_manager call followed by a –clean call is that the agent is completely managed by OMi.
Learn more about switching to OMi
I hope this short overview of how to move an agent to OMi was useful.
- Get all the specific technical details in the Operations Bridge Evolution Guide available from the Operations Bridge Evolution Resource page
- Learn more about what OMi has to offer
Please let me know if you have questions about this process. Simply post a comment below and I will try to address it in my reply or in an upcoming blog post.
Learn more about Operations Manager and Operations Manager i here.
You can also download trials of the software to experience them for yourself.
The OM-to-Opsbridge evolution program including license exchange details is now live. Search on the tag OM2OpsBridge to find blogs discussing this program and evolution to OpsBridge. Search on OMiContent for other blogs on management packs and connectors.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.