|
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:
- Before
making software changes, measure performance on the production
and test bed environments.
- 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.
- 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.
- 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.>
- Use
standard tools and the documented procedure from step 2
to install the changes on the production system.
|
