IT Operations Management (ITOM)
cancel

Evolve to OMi: How to smoothly move hundreds of Operations Agents to OMi

Evolve to OMi: How to smoothly move hundreds of Operations Agents to OMi

VolkerGaertner

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.

 

Overview

 

You can find complete details for moving Operations Agents to HP OMi in the Operations Bridge Evolution Guide, but here is a quick overview of the five recommended steps:

 

  1. 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.
  2. Next, choose a group or type of nodes to move over, for example, all your Oracle Database systems
    1. 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.
    2. After a successful test, roll out the configuration to the remaining nodes of that type, either manually or by using automatic assignment rules.
  3. 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.
  4. Repeat steps 2–3 until all nodes are managed by OMi.
  5. 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.

  1. 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 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 HP OMi. You might also want to delete the node from HP Operations Manager, or at least disable HBP 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.

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.

  • operations bridge
About the Author

VolkerGaertner