ODI RAC Clustering

Introduction
One of their requirements was for the agents that ODI uses to be
deployed in a high-availability environment, so that for example:
More than one agent was running at one time, to spread the load and ensure
that at least one was available at all times to run ETL jobs
If an agent is scheduled to run an ETL job but its not available, another one
can run the job instead
Their Oracle RAC database was fully-used, so that if one database node was
down, the other could still provide the repository and be the target for ETL
jobs
ODI for some time has had a basic load-balancing capability, so that
for example you can register two or more agents as part of a load-
balancing group, like this:
But load-balancing isnt high-availability, and if you submit an agent
execution request to a standalone agent thats part of such a load-
balancing group, but that agent isnt actually running, then the
request will fail.
In addition, if a particular standalone agent has a scheduled ELT job
associated with it, but the agent is down when its time to run the
job, the job just wont run as theres no in-built method for another
standalone agent to be aware of this scheduled job.
Where this also gets interesting is when the database thats the host
for the ODI repositories is a RAC database, or potentially the target
database for the DW load is a RAC database.
Where do you install the agents (one per RAC node?) and can we, for
example, use the RAC VIP (virtual IP address) to reference the two
ODI agents instead of using this load balancing group, so that the RAC
VIP gives us our load balancing, and potentially high-availability?
Looking at standalone agents first, its clear that these are designed really to
support load-balancing, but not high-availability (of the agents).
When you connect agents in a load-balancing group to a repository held on a RAC
database, you make the connection using the special RAC connection syntax, and
the repository (and the RAC database) is treated as a single logical object,
regardless of the fact that there are two physical database nodes in the
background.
But the standalone agents themselves dont handle failover when a scheduled
job fails to execute or fails half-way through, and one cant substitute for the
other if an execute request comes through to a non-running agent.
To handle this situation, Oracle introduced the Java EE (JEE) agent with ODI 11g,
which runs in the WebLogic application server rather than standalone on your
server.