Managing Serviceguard 11th Edition, Version A.11.16, Second Printing June 2004

Designing Highly Available Cluster Applications
Minimizing Planned Downtime
Appendix C384
Minimizing Planned Downtime
Planned downtime (as opposed to unplanned downtime) is scheduled;
examples include backups, systems upgrades to new operating system
revisions, or hardware replacements. For planned downtime, application
designers should consider:
• Reducing the time needed for application upgrades/patches.
Can an administrator install a new version of the application
without scheduling downtime? Can different revisions of an
application operate within a system? Can different revisions of a
client and server operate within a system?
• Providing for online application reconfiguration.
Can the configuration information used by the application be
changed without bringing down the application?
• Documenting maintenance operations.
Does an operator know how to handle maintenance operations?
When discussing highly available systems, unplanned failures are often
the main point of discussion. However, if it takes 2 weeks to upgrade a
system to a new revision of software, there are bound to be a large
number of complaints.
The following sections discuss ways of handling the different types of
planned downtime.
Reducing Time Needed for Application Upgrades and
Patches
Once a year or so, a new revision of an application is released. How long
does it take for the end-user to upgrade to this new revision? This
answer is the amount of planned downtime a user must take to upgrade
their application. The following guidelines reduce this time.