MACROMEDIA COLDFUSION 5-ADVANCED ADMINISTRATION, Manual

Page: 255 / 372

What is Web Site Availability? 237
Failover considerations
The ability to fail over servers that have become unavailable to redundant servers is a
cornerstone of any mission-critical application, one that ensures an application’s
continuous and reliable operation. Such disaster planning and recovery can be
broken down into:
•
“Hardware planning” on page 237
•
“Systems monitoring” on page 238
•
“Corrective actions” on page 238
Review the following considerations to ensure that you have a sound failover strategy
in place—one that guarantees your Web site’s availability.
Hardware planning
As illustrated in the availability example above, it’s important to acquire all of the
necessary hardware and configure it before you deploy the application. All Web sites
have different requirements, feature sets, purposes, audiences, and budgets. It all
translates into determining appropriate needs. However, if your site is a
business-critical system that affects your company’s bottom line, you must ensure an
appropriate redundancy strategy by having two or more redundant systems in place.
In fact, Allaire recommends that you use a minimum of three servers to support any
critical Web site so that you can take one server offline to perform update and
maintenance tasks while maintaining at least two servers in production at all times.
This scheme provides administrative flexibility while simultaneously protecting your
site from hardware or software failures.
The two predominant redundancy models used today are:
•
Primary/Backup Servers
An example of this model would be an important Web application that receives
relatively little traffic. For instance, a corporate intranet. Typically, this
redundancy model uses an expensive, high-capacity server for the primary server
and uses an inexpensive, lower quality server for the backup server in case the
primary server fails.
•
Parallel Servers
This model is known as a classic load balancing/redundancy model and is used
most often for business-critical applications. Unlike the primary/secondary
scheme discussed above, the multiple servers used in a parallel scheme are
considered peers and are grouped together as a single entity to support one or
more applications.
You can use identical cloned hardware for creating your server clusters, or you
can mix hardware sizes and models. Cloned, higher capacity, higher-end
hardware may have greater up-front hardware costs but will help minimize
administration costs down the line. Conversely, mixing hardware models and
capacities may be less expensive up-front but can add administrative costs later
on.