Relocating targets with EM 12c

Multi-Agent targets

Some targets (like RAC databases, clusters, FMW domains etc) are considered 'clustered' and have failover build into them 'by design'.

Enterprise Manager handles those targets in a special way:

• They are marked as 'multi-Agent' targets: They are discovered on all Agents of the 'cluster' or 'set of hosts' they can run on.
• The OMS will decide which Agent will do the actual 'monitoring' of that target in question. (OMS mediation)
• If that Agent goes down or becomes 'unavailable', the OMS will choose another Agent from the discovered set to take responsibility of that target and continue the monitoring.

For these targets, the 'relocate_target' functionality should not be used, since the OMS will take care of the failover, and move the monitoring to a 'surviving Agent' in case a failover is needed.
Forcing a target to get moved to another Agent should also not be done with 'relocate' functionality, since the target is in almost all cases linked to other targets (like CRS or cluster targets) which have to have known associations with these targets.

To see which targets are considered 'OMS mediated', run this query in the repository:

  SELECT host_name, entity_type, entity_name
  FROM   em_manageable_entities
  WHERE  manage_status   = 2  -- Managed
    AND  promote_status  = 3  -- Promoted
    AND  monitoring_mode = 1  -- OMS mediated
  ORDER BY host_name, entity_type, entity_name
  ;

To be able to see the list of Agents that have discovered these OMS mediated targets, and can assume monitoring of them, use these REPVFY commands:

• To see which Agents can monitor an OMS mediated target:
  $ repvfy show master_agent -name "<name_of_target>" -type "<type_of_target>"
• To see the last 10 Agent failovers for a given target:
  $ repvfy show master_agent_history -name "<name_of_target>" -type "<type_of_target>"
• To see which Agents can monitor the various components of a Database Machine (Exadata):
  $ repvfy show exadata_master_agent -name "<name_of_the_dbmachinetarget>"
• For debugging/maintenance purposes, a special routine exists in REPVFY to force an OMS mediated failover:
  SQL> exec gc_diag3_ext.ForceFailover("<name_of_target>","<type_of_target>");

For more information on EMDIAG, see:421053.1: EMDIAG Master Index

Manual relocation of targets

In case a 'regular' target needs to get moved to another Agent, a special EMCLI verb exists to move the definition and monitoring settings of a target from one Agent to another Agent:

  $ emcli relocate_targets 
          -src_agent=<source_agent_target_name>
          -dest_agent=<dest_agent_target_name>
          -target_name=<name_of_target_to_be_relocated>
          -target_type=<type_of_target_to_be_relocated>
          -copy_from_src -force=yes

Gotchas:

• For targets that have known 'associations' (services like FMW, EBiz, etc) the '-force' flag will move all related targets together with the main service to the new Agent.
• For those targets that have monitoring settings that are host/Agent specific, the values of those properties will have to get updated when the target moves
  $ emcli relocate_targets <...options...> -changed_param=<propName>:<propValue>
• If there is 'clock skew' between the source and the destination Agent, the availability of the target might be impacted when the target gets moved from the old to the new Agent.
  To force the new time of the target, the 'ignoreTimeSkew' parameter can be used, to make the repository 'accept' the 'older' time from the new Agent:
  $ emcli relocate_targets <...options...> -ignoreTimeSkew=yes

Automated relocation of targets

For cold failover cluster (CFC), the EMCLI way of moving a target from one Agent to another Agent will not work because of the interactive nature of EMCLI (and the password requirement)

For those setups, there is an EMCTL command to take ownership of a target.

• An Agent can only assume control over a target.
  It can not give a target 'away' or push a target on another Agent
• For security reason, the list of Agents that can 'assume' control over a given target need to get registered first in the repository.
• For every target requiring automated failover (emctl failover), run this EMCLI command once to setup the list of possible Agents:
  

     $ emcli set_standby_agent 
             -src_agent=<source_agent_target_name>
             -dest_agent=<dest_agent_target_name>
             -target_name=<name_of_target_to_be_relocated>
             -target_type=<type_of_target_to_be_relocated>

• If more than 2 Agents are needed, run multiple EMCLI commands for each target, each time with a new Agent specified for the '-dest_agent' parameter.

Once the setup has been done, an Agent can take control over a target by running this command:

   $ emctl relocate_target agent "<name_of_target>""<type_of_target>"

Using this EMCTL command, the cluster scripts that are run before and after the failover of a node can then be enhanced with these EMCTL commands to let the Agent on the new (surviving) node assume control over the desired targets.

There is no build-in way in EM today to visualize or retrieve the failover configuration of a target.
To be able to see the setup done for a particular target, the following commands have been added to REPVFY:

• To see which Agents can 'assume' control over a target:
  $ repvfy show agent_failover -name "<name_of_target>" -type "<type_of_target>"

For more information on EMDIAG, see:421053.1: EMDIAG Master Index

Stay Connected with Oracle Enterprise Manager:

Twitter | Facebook | YouTube | Linkedin | Newsletter