VCS has long provided the ability to create service group dependencies by which a VCS cluster can be directed to start one service group before another, keep service groups together (or separate) on one node, and the like.  This is great for applications running in the same cluster, but what if there's an application running in one cluster that's got a relationship to a service group running in a different cluster?  Worse yet, what if the clusters are on different OS platforms?  The RemoteGroup resource introduced with VCS 5.0 was built to address these situations.

Let's look at a scenario where we have a VCS 5.0 cluster running Linux, with an Apache web server under control of  VCS.  The web server accesses data held in an Oracle database running on Solaris, and made highly available with VCS 5.0.  This is an example of a simple two-tiered application.  The web server isn't functional without the Oracle database, and the Oracle database is useless without the client front end access provided by the web server.  We'll call the web server service group on the Linux cluster ApacheSG, and the Oracle service group on the Solaris cluster OraSG.

On start up, a java app in our web server attempts to connect to the database server.  If the database isn't running, the java app fails, but the web server keeps running.  This can lead to a situation where everything appears fine from the web server perspective, but users are unable to access the database even though the web server appears to be up and running.

Enter the RemoteGroup agent.  Visualizing a typical VCS service group with a DiskGroup or some other storage resource at the bottom of the dependency tree, we add as a new bottom-level resource a RemoteGroup resource.  Since the Oracle service group (OraSG) isn't dependent upon anything, we don't need to add one here.  But since our web service group (ApacheSG) is dependent upon OraSG, here's where we'll add the RemoteGroup resource.

In addition to telling the RemoteGroup agent how to access the remote cluster (the Solaris cluster, in our example), we have to tell the agent how we want to manage that remote service group.  This is done with the ControlMode attribute.  This attribute has the following options:

OnOff
The RemoteGroup resource brings the remote service group online or takes it offline.  In other words, when ApacheSG goes offline, the last resource to go offline, the RemoteGroup resource, takes OraSG offline in the remote cluster.  Likewise the reverse when ApacheSG goes online.

MonitorOnly
The RemoteGroup resource only monitors the state of the remote service group.  This will keep the local group (ApacheSG) from going online until the remote group (OraSG) is online.  Also, if OraSG is taken offline for whatever reason, the RemoteGroup resource in ApacheSG will fault, taking ApacheSG offline.

OnlineOnly
The RemoteGroup resource only brings the remote service group online.  So when ApacheSG goes offline, it takes no action on OraSG running on the Solaris cluster.

You can read more about the RemoteGroup resource in the Bundled Agents Reference Guide.