All cluster nodes must run the same version and patch level of the platform operating system, Veritas Cluster Server, and Rational ClearCase or Rational ClearCase MultiSite® software. Rational ClearCase views, VOBs, registry database files and Rational ClearCase MultiSite data must use shared network storage (dual-ported, multi-initiated, or SAN-attached). Rational ClearCase MultiSite shipping configuration on all cluster nodes must be identical; scheduled jobs in MultiSite environments must have identical parameters on all machines in the cluster. Failover of view servers with views exported for non-ClearCase access are not supported in high-availability environments.
Rational ClearCase high availability is supported for asymmetric (active/standby) configurations, where Rational ClearCase is active on only one cluster node at a time. The failover node must have Rational ClearCase installed, but not running. VCS failover service groups enforce this behavior. In the event of a failover or switchover, VCS stops Rational ClearCase on the master node and starts Rational ClearCase on the failover node. Failover is 1x1 (server to server).
Restoration of normal service (to the original cluster configuration) after a failover requires manual intervention by an administrator. Rational ClearCase clients who access servers protected by a VCS cluster must use the virtual host names provided by VCS for those servers. From the Rational ClearCase client’s point of view, a failover/switchover will look the same as a temporary network interruption. Some client commands might recover before the RPC timeout expires; if they do not, an RPC timeout error or connection failure is reported, and the client must try the command again.