Summary

So, now we've seen the first real application of content switchingserver load balancing. From the examples given in this chapter, you'll have been able to build up a picture of the types of issues that server load balancing, even in its most basic guise, can address. Many areas of additional value can be gained from making object servers and the applications which run on them scalable and resilient. Some of the less obvious advantages of server load balancing, such as the elimination of operational issues, can provide great drivers for deploying exactly this type of technology. In Chapter 6 we'll take a look at how we can further extend the advantages of server load balancing with greater application intelligencelooking at Layer 7 information.

Case Study: Layer 4 Server Load Balancing

Foocorp Inc., like most large organizations, has started to Web enable their applications. They also have many traditional applications that use TCP/IP. Their initial requirements are:

• Centralize access to each application.

• Provide resilience in case of a server failure.

• Use private address space for serversthis provides security and minimizes their limited private address pool.

• Ensure that certain applications are sent to the correct servers.

This provides Foocorp the advantage of having a centralized data center or server farm that can share the resources associated with deploying the hardware such as power, cabling, cooling, and so forth.

Deploying Load Balancing

Foocorp has also decided to deploy the content switches in high availability mode for resilience. Here is a checklist of the most important steps:

1. Ensure that you have enough private IP addresses to cover interfaces, VIPs, VRRP addresses, and so forth.

2. If you are going to use different VLANs for the different services, ensure that your upstream firewall has a route to them. Typically, this will be via the VRRP addresses of the content switches.

3. Ensure that you update the DNS with the new VIP addresses that will be used for the service(s).

4. Configure the real servers to be part of a group, and associate the VIP and its necessary service to that group .

5. Ensure that the servers are listening on the correct port for the service(s) they are load balancing. The health checks will show whether this is the case.

6. Make sure that you select the correct load balancing metric. This will be key if you require Layer 3 persistence.

7. Ensure that you set up VRRP for not only the Layer 3 information, but also the Layer 4 if possible.

8. Ensure that you have routes to any internal networks and that they have a route or routes back to the content switches and associated VIPs.

9. Test failure of a switch using VRRP to ensure that you do not have an asymmetric route, as the content switch will need to see the return packet in order to manipulate it back to its original form.

We can see how this has been achieved in Figure 5-16.

Figure 5-16. Foocorp, Inc. Layer 4 load balancing.

By deploying Layer 4 load balancing, Foocorp has been able to achieve the following:

• Increase user response time.

• Minimize disruption caused by server failure or critical upgrades during the business day.

• Ensure that servers can be added or decommissioned with no change to the user or to DNS.

• Allow statistics of server and application usage to be centrally located and analyzed .

• Secure their servers by using private IP address space and only allowing access to them for the configured service.

• Allow new services and applications to be deployed with no or very little new hardware.

The options and benefits are endless. What this has allowed Foocorp to achieve is the ability to scale and add new and exciting applications with very little disruption to the existing environment.