Managing HP Serviceguard for Linux, Sixth Edition, August 2006

Designing Highly Available Cluster Applications
Minimizing Planned Downtime
Appendix B 319
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.
Provide for Rolling Upgrades
Provide for a “rolling upgrade” in a client/server environment. For a
system with many components, the typical scenario is to bring down the
entire system, upgrade every node to the new version of the software,
and then restart the application on all the affected nodes. For large
systems, this could result in a long downtime. An alternative is to
provide for a rolling upgrade. A rolling upgrade rolls out the new
software in a phased approach by upgrading only one component at a
time. For example, the database server is upgraded on Monday, causing a
15 minute downtime. Then on Tuesday, the application server on two of
the nodes is upgraded, which leaves the application servers on the
remaining nodes online and causes no downtime. On Wednesday, two
more application servers are upgraded, and so on. With this approach,
you avoid the problem where everything changes at once, plus you
minimize long outages.
The trade-off is that the application software must operate with different
revisions of the software. In the above example, the database server
might be at revision 5.0 while the some of the application servers are at
revision 4.0. The application must be designed to handle this type of
situation.