Oracle Blog

Wednesday Apr 03, 2013

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:

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:

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>"