Configuring HCL VersionVault for high availability
- View servers (except for exported Views)
- VOB servers
- Registry server
- License server
- MultiSite servers
All cluster nodes must run the same version and patch level of the platform operating system, Veritas Cluster Server, and HCL VersionVault or HCL VersionVault MultiSite software. HCL VersionVault views, VOBs, registry database files and HCL VersionVault MultiSite data must use shared network storage (dual-ported, multi-initiated, or SAN-attached). HCL VersionVault 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-VersionVault access are not supported in high-availability environments.
HCL VersionVault high availability is supported for asymmetric (active/standby) configurations, where HCL VersionVault is active on only one cluster node at a time. The failover node must have HCL VersionVault installed, but not running. VCS failover service groups enforce this behavior. In the event of a failover or switchover, VCS stops HCL VersionVault on the master node and starts HCL VersionVault 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. HCL VersionVault clients who access servers protected by a VCS cluster must use the virtual host names provided by VCS for those servers. From the HCL VersionVault 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.