Web Server Failover and High Availability

As I discussed earlier in this chapter, the Web server is a critical component in any Web-based WebSphere environment. In Chapter 5 I discussed possible topological architectures that involve multiple load-balanced Web servers. In this section you'll look at what options are available to facilitate those topological architectures presented in Chapter 5.

Web Server Overview

Due to its inherent application and protocol simplicity, the Web server tier is a noncomplex environment to work with. Because of the technology's inherent simplicity, it provides an easy platform for implementing solutions in high-availability forms.

In the most basic form, you'll have a single Web server servicing requests from end users. Through the use of the WebSphere HTTP plug-in that is installed into your chosen Web server product, you'll be able to route requests to the backend application servers with ease. To achieve failover and high availability with this component of your topology, as discussed in Chapter 5, always use more than one Web server.

Web servers are commodity systems and don't need to be high powered if you're using a thin WebSphere model. Many Unix vendors are now producing low-end machines below US$1,500 that can perform this job perfectly fine. All you need is 256MB to 512MB of memory, a pair of redundant mirrored disks, a couple of Fast Ethernet or Gigabit Ethernet ports, and you're off and running.

It's possible and quite valid to mix your platform vendor for your environments. That is, there's nothing wrong with using x86 (Intel/AMD)-based servers running Solaris x86, BSD, or Linux, mixed in with higher-end Unix-based systems for the backend servers. This can reduce costs considerably or provide a budget to purchase more commodity-based Web servers.

Web Server Implementation

Figure 7-7 shows an approach to Web server high availability.

Figure 7-7: Web server failover and high availability model

The configuration in Figure 7-7 uses a mixture of DNS round- robin , hardware-based load-balancers, and the WLM (clustering) aspects of WebSphere via HTTP Web server plug-ins.

The DNS round-robin configuration is a very simplistic approach to achieving redundancy in your load balancers. It's a common issue I see in which sites have purchased a load-balancer device (e.g., a Cisco CS series, Alteon, Radware, etc.), but it poses as a single point of failure (how very ironic!).

Best practice in this configuration is to use something such as DNS round-robining, which is a simplistic but robust mechanism for sending requests to more than one ingress point in your network. Essentially, in your DNS you configure your site name to have multiple "A"-type entries in your zone files so that when a request is made for www.mysite.com , for example, the DNS responds with an IP or host name that is contained as one of the A entries in your www.mysite.com zone file.

Another approach is to use distributed or geographically load-balanced sites, in which there is more than one pipe or connection into your network. Using Internet routing protocols such as Border Gateway Protocol (BGP) and Open Shortest Path First (OSPF), you can distribute your traffic to multiple locations, based on availability and serviceability.

Figure 7-8 shows an example of two businesses accessing a Web site (frontend to a WebSphere application platform) via two different geographically distributed border sites, Seattle and Washington. This method provides quasi-load balancing. It's fairly static most of the time, but the load is distributed. The value in this approach is that there's a high degree of failover capability within the design.

Figure 7-8: Global routing example

As you can see, each business goes through a different route path to get to the www.mysite.com environment. If, however, ISP N failed, OSPF and BGP routing would immediately reroute the traffic to another route path, and ultimately direct all traffic via ISP P (see Figure 7-9).

Figure 7-9: Global routing example failover scenario

Let's now look at the next most common tier in a WebSphere platform: the Web container.