Installing HVR in a Cluster
A cluster is a group of nodes which share a 'virtual' IP address and also have a shared file system. Both an HVR hub and an HVR location can be put in cluster package. And if an HVR location is in a cluster, then there are different ways for the HVR hub to connect to it. The three common scenarios are:
HVR Hub in a Cluster
When the HVR hub runs inside the cluster, make sure that only one HVR Scheduler is running at a time (i.e. active/passive not active/active) and ensure that the $HVR_CONFIG directory is shared between all nodes. $HVR_HOME should either be shared between all nodes, or an identical copy should be reachable with the same path from all nodes. Directory $HVR_TMP can be local. The DBMS of the hub database must also be inside the same 'cluster resource' or at least be reachable with the same name from each cluster node.
On Windows, the commands hvrscheduler and hvrremotelistener can be enrolled in Windows cluster services using option –c. These services must be recreated on each node. Once these services are enrolled in the cluster, then they should only be controlled by stopping and starting the cluster group (instead of using option –as).
Command hvrmaint should be scheduled so it runs on whichever is machine active.
If the hub database is inside an Oracle RAC, then enroll the HVR services in the Oracle RAC cluster using command crs_profile for script hvr_boot.
Location with HVR 'Inside the Cluster'
This means HVR will connect with its own protocol to a remote listener (configured using inetd on Unix) which is configured to run inside all cluster nodes simultaneously. The hub then connects to the remote location using its relocateable virtual IP address.
If this remote location is a file location, then these nodes must share the same file location top directory and state directory.
Log based capture from an Oracle RAC requires this approach with a single capture location for the Oracle RAC. This location should be defined using the relocatable IP address of the Oracle RAC cluster.
On Windows, the command hvrremotelistener can be enrolled in Windows cluster services using option –c. This service must be recreated on each node. Once the service is enrolled in the cluster, then it should only be controlled by stopping and starting the cluster group (instead of using option –as).
Directory $HVR_HOME and $HVR_CONFIG should exist on both machines, but does not normally need to be shared. But for log based capture, if command hvrlogrelease is used, then $HVR_CONFIG must be shared between all nodes. If $HVR_TMP is defined, then it should not be shared. Command hvrlogrelease should then be scheduled to run on both machines, but this scheduling should be 'interleaved' so it does not run simultaneously. For example, on one machine it could run at '0, 20, 40' past each hour and on the other machine it could run at '10, 30, 50' past each hour.
Location with HVR 'Outside the Cluster'
This means that HVR connects using the DBMS's network protocol (e.g. a TNS alias) as if it were a normal SQL client. This means that it is unaware that the database is really in a cluster.
This is not supported for file locations. A benefit is that HVR does not need to be installed inside the cluster at all; a disadvantage is that the DBMS protocol is not as efficient as HVR's protocol because it does not have compression. HVR log based capture does not work in this situation; it must be installed 'inside' the cluster.