TruCluster Server High Availability Case Study Test Bed Software

Tru64 UNIX documentation

Tech tips and white papers

» Best practices
» Technical updates
» White papers & tech tips
» Send us your comments

Tru64 UNIX documentation

» Tru64 UNIX operating system
» TruCluster software
» Advanced Printing Software
» Advanced Server for UNIX
» Device driver
» Internet Express
» New hardware delivery
» Patch kits
» Porting guides
» POSIX conformance
» secure shell
» Windows 2000 single
sign-on

Related links

» Tru64 UNIX home
» Tru64 UNIX QuickSpecs and software product descriptions
» TruCluster Server high availability case study
 

The High Availability Software Configuration table lists the operating system, network, and services software configured on the production-level cluster.

The test bed software configuration duplicates the production-level environment's operating system version and patch level and the NFS service, disk service, and tape service. The TruCluster Production Server Version 1.6 test bed used LSM extensively to mirror the root (/), /usr, and /var file systems. When we upgraded to TruCluster Server Version 5.0A, we went to hardware RAID to mirror these file systems because Version 5.0A does not support LSM mirroring of root (/), swap, member boot disks, or the quorum disk.

The test environment does not duplicate all of the system software running on the production system; nor does it run every software application.

Our use of the production-level cluster and the test bed environment led to the following conclusions:

  • It is more important to synchronize the test bed system with the versions of a select group of software than it is for the test bed to duplicate everything on the production-level cluster. You select the software based on the needs of your critical applications or on the functions being exercised (for instance, networking, security, etc.).
  • Configure the test bed such that you can run load tests that simulate actual usage in the production environment.

In addition to testing, you must develop a consistent roll-out procedure for quickly deploying software changes from the test bed to your production-level cluster.

The test bed roll-out procedure that we use with the production-level cluster includes the following:

  1. Before making software changes, measure performance on the production and test bed environments.
  2. To modify the test bed, use standard tools, document each step, and record the down time. For example, to patch system code or a TruCluster Software product, use the dupatch utility to install an aggregate Patch Kit on the test bed.
  3. Run the test bed system. Depending on the complexity of the change, we run the test bed system for 10 to 20 days. For example, after installing a patch kit, we run the test bed for 10 days. After upgrading the operating system, we run the test bed for 20 days. Running the test bed includes the following activities:
    • Load tests that cover typical workloads as well as atypical situations (such as the simulation of low memory or full disks).
    • Executing key business applications.
    • Standard and automated tests that exercise the subsystems that were changed.
  4. Upon completion of step 3, re-measure test bed performance and compare it against the initial measurement. If satisfactory, use the downtime records to schedule the deployment of the changed software to the production environment.>
  5. Use standard tools and the documented procedure from step 2 to install the changes on the production system.