Planned downtime

»

HP Tru64 UNIX

Tru64 UNIX

» Tru64 UNIX V5.1B-6
» Tru64 UNIX V5.1B-5
» Documentation
» Information library
» Software web index
» Software products library
» Patch database
» Services
» Developer & Solution Partner Program
» Send us your comments
» Support Statements

Evolving business value

» Tru64 UNIX to HP-UX 11i transition benefits calculator
» Alpha RetainTrust Program
» Transition

Related links

» Alpha systems
» HP-UX 11i
» Integrity servers
» Linux
» HP storage
» HP solutions
HP-UX 11i: measurably better TCO!

Definition

Planned downtime is caused by the decision of an administrator or service person. Examples of planned downtime are hardware or software reconfiguration, or an off line upgrade or patch procedure due to system limitations.

Customer problem

In today’s NonStop eBusiness computing environment, planned downtime activities contribute to over 60% of system downtime, and software has become the predominant opportunity for improvement!

HP's answer

HP is cognizant of this trend and is solving this dilemma in real time. In August 2003, DH Brown published its review of current UNIX cluster offerings, "Superior TruCluster Technology Combined with AdvFS Yields High Availability and Lower Infrastructure Cost of Ownership". DH Brown concluded, "HP TruCluster Server software Version 5.1B exceeds the high-availability expectations of clusters, offering a Cluster File System (CFS) with a shared root directory and other advanced features that ensure the easiest cluster management." Further, DH Brown notes the unique cost-savings characteristic of TruCluster Server software: “… once the cluster is established, it manages with a “fixed management cost” roughly equivalent to a single system. The more nodes, the greater the advantage to the IT infrastructure.”

Here's how Tru64 UNIX keeps planned downtime to a minimum, making your AlphaServer system the most reliable UNIX platform on the market:

Managing multiple systems as one: Using TruCluster Server software to manage your multiple systems, you can perform routine maintenance tasks without any downtime. Just take down one node while the rest of the cluster is running and perform the operation once for the entire cluster. You're saving time with minimum effort and keeping the availability at the service level you agreed to.

Rolling upgrades: Install patches on a cluster without disrupting operations. Individual members of the cluster which are not being patched initially, are set up so that changes to the shared cluster file system do not impact the overall availability of the cluster. The cluster member being patched can be removed from the cluster, patch(es) applied, member re-booted, and tested with the end user's application to verify that the patch(es) can be applied to the other members of the cluster. All this is being done while your applications continue to run on the remaining members of the cluster.

Online tuning: Tune system parameters as needed without rebooting the system and optimize your applications performance. It's fast, it's easy, and it keeps the level of availability as high as you need it while boosting performance.

Multi-user mode dupatch: Install patches on a system while applications are still running and available to users (in multi-user mode). Patches can be installed remotely thereby guaranteeing that the network capabilities of the system cannot be disabled during the patch operation. The integrity of the running system is not compromised while installing patches. More specifically, patches will not overwrite files currently in use. Applications running on the target system operate while patches are being installed. Patches can be backed out and/or removed. dupatch is capable of running in a single system configuration as well as in clusters.

On-line Insertion and on-line removal: Add capacity to the system, remove components for upgrades, alter system configurations, and replace components while the system is running. Components may be storage devices, power supplies, CPUs, and so on.