Veritas Software's HA Solaris 4.1

Veritas' Storage Foundation offering integrates with the vendor's Cluster Server and Volume Replicator products. Cluster Server is used to create and manage multiple servers as an entity to deliver high-availability applications. With Volume Replicator, you can replicate Storage Foundation volumes across fiber or IP connections to a completely different set of machines.

Initial Setup

At Syracuse University, I designated one location as my main facility and another as my DR (disaster-recovery) site. In the main facility, I connected two Solaris 10 servers to a shared Sun StorEdge D2 disk array, for purposes of configuring the two hosts as a single NFS (Network File System) application service in HA mode. At the DR site, I configured one server to another StorEdge D2 disk array running Solaris 10.

I installed all three Veritas products on each server. Using Veritas Enterprise Administrator from my Windows desktop, I connected to the first host in the main-site cluster to configure Storage Foundation. I created a disk group for all the disks within the shared StorEdge D2, as well as a 5-GB, RAID 0+1 NFS volume formatted with VxFS (Veritas File System). To use Volume Replicator later, I also created a 5-GB, RAID 0+1 transaction logging volume. At the DR site, I created two volumes identical to those at the main site.

Next, I configured the volume replication between the main site and the DR facility to ensure that the data would be synced instantly. With a few clicks, the volumes began syncing data.

In such a setup, user data exists in volumes at both the main site and DR facility but is activated at only one location. The two transaction log volumes are used to keep track of the replication in case of link failure; the transaction log volume at the DR site won't come into play unless a disaster occurs. In a worst-case scenario, you'd need four times as much disk space as you have data.

I fired up the Cluster Server Administrator Console on the XP workstation to configure the clusters and services. I created two service groups at the main site, one for NFS and one to fail the volume replication to the other node. Unlike most clustering products, Veritas Cluster Server doesn't require professional services to create application failover (or service groups, as Veritas calls it). Using the two preconfigured templates and with little help from Veritas support, I was on my way to creating the cluster within an hour. Using an export from the main site, I created the one-node cluster required at the DR site with minor modification of the export data.

Testing

Setup, including data replication over our LAN, took me less than three hours. Using the Cluster Server Administrator tool, I was able to fail NFS from one machine to another. Simulating a NIC card failure on one machine caused the cluster to migrate the NFS service to working node in the cluster automatically. NFS failover took less than two minutes in all tests.

With the Cluster Server Administrator, I could switch the NFS service group from the main site to the DR site. The only thing left to do was modify the NFS server information on all clients. Veritas claims this can be done automatically using small TTL (time-to-live) values in DNS and then letting Veritas Cluster Server change the DNS entry for the host. No matter where my data was housed, replication ensured that it was always consistent and accurate. Veritas even has a Fire Drills feature that lets you simulate the failover of an application while it's in production.Christopher T. Beers is a Lead Unix Architect at Syracuse University. Write to him at [email protected]. Post a comment or question on this story at www.nwc.com/go/ask.html.