The Veritas Cluster Server version 5.0
Few are the experts in the IT&C industry that have not heard of the Symantec Veritas Cluster suite. It is one of the most advanced and reliable solutions on the market, partly because it has a lot of history behind it. Like most mature products, it has been polished to a great extent and the usability of the product is much higher than its younger counterparts. Nevertheless, for anyone that has not had any contact with the VCS suite before, the shocking ease of use and degree of automation embedded in the product will be a very pleasant surprise.

Like most failover cluster packages, Veritas uses the basic building blocks of the “movable system services”. The cluster is made up of a bunch of systems, called nodes, some resources (like storage devices, IPs, shares and service instances), some zones and some rules by which service migration from one computer to another is governed.

Normally, the cluster installation should take some time, even for the more experienced users that do the preparation phase flawlessly. I was pleasantly surprised to find out that it is not the case with VCS5. Within a little under one hour, the entire cluster had been installed and ready to go, on my four cluster nodes, leaving me with the only the task of configuring it. The installation itself is pretty seamless, as the automatic installation wizard does its job without generating issues.

Another feature of the installer I also enjoy is the environment pre-check process that enables you to see whether you overlooked any details during your cluster preparation phase. This feature is also available in the Windows 2003 and 2008 failover cluster suite and is a welcome addition anytime; RHCS, however, is missing this functionality.

Notes & Caveats
The only thing that comes into mind, as a word of advice to anyone looking to integrate Axigen with the VCS suite, is the way the cluster service scripts are monitored for success or failure. Normally, the exit codes of the average BASH script should be 0 in the case of a successful run. In the case of Veritas, any exit code not within 100 and 110 is considered “unknown” and therefore cannot be validated. Here is a full list of exit codes that must be used for good results:

• Less than 100: “unknown”
• Exactly 100: “offline”
• Between 101 and 110: “online with 10% - 100% confidence”
• More than 110: “unknown”

In this case, the Axigen init scripts should be edited to result in either 100, in case of startup failure, or 110, in case of success. Any other acceptable (“known”) values may be used but not to a great extent as the Axigen init scripts are not built with the concept of “confidence” in mind.

Final thoughts
The Axigen Mail Server integration with Veritas Cluster Server probably marks the end of the list when it comes to failover clustering platform support. It was a great run, but all good things must come to an end. Right now, the main concern will be to simplify the process itself, although it is very unlikely to need something like that in the case of Veritas. It is, quite simply put, one of the best failover clustering solutions on the market today. If you ever have the chance to integrate the Axigen Mail Server with it, don’t pass it up, it’s going to be a very pleasant and rewarding experience.

To continue to read this whitepaper, please visit http://www.axigen.com

Additionally, we invite you to join our free, live "Cluster Computing vs. Cloud Computing" webinar to gain a comprehensive insight on these two concepts and the benefits, opportunities or challenges that they present for businesses: http://www.axigen.com/webinars/cluster-cloud_18/

Submitted by axigen