Managing Serviceguard Fifteenth Edition, reprinted May 2008

Designing Highly Available Cluster Applications
Minimizing Planned Downtime
Appendix C474
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.