This chapter is from the book
This chapter is from the book
This chapter is from the book
Hardware Load-Balancing Options
How Hardware Load Balancing Works
Hardware load balancing, similar to ClusterCATS software balancing, manages traffic within a Web cluster according to a specified load-balancing algorithm (such as round robin or least connection). However, unlike ClusterCATS, hardware-based load-balancing devices sit in front of the Web cluster, meaning that all traffic destined for the Web cluster must pass through the load-balancing device.
For example, if you were configuring a Cisco LocalDirector to load-balance the www.mycompany.com domain, which contains three Web servers and a database server, you would configure the load balancer with the IP address that corresponds DNS-wise to www.mycompany.com. This address is called the virtual Web server address. On the LocalDirector, you would also configure the addresses of the three Web servers behind the LocalDirector and a load-balancing algorithm, such as least connections. LocalDirector would assign users to the server with the least load. Figure 3.24 shows the basic network configuration of the load balancer.
)
Figure 3.24 Cisco LocalDirector contains the virtual Web server www.mycompany.com
directing traffic to three clustered servers.
LocalDirector
Cisco LocalDirector can be set up to maintain network address translation (NAT). This feature ensures that Web servers in a cluster are not directly accessible by a public IP address, thus ensuring security. In this model, LocalDirector maintains the IP address that corresponds to www.mycompany.com, however, LocalDirector has another interface on a switch that is shared by the three Web servers. LocalDirector acts as the gateway for Web servers in a cluster.
NOTE
An advantage to hardware-based load balancing is that users never know that the site is behind a load balancer (each server is not required to have its own DNS name). This feature is especially useful when dealing with bookmarks. On a ClusterCATS-balanced site, users can easily bookmark www1.mycompany.com because that is the address that is displayed in the users' browser. This can cause problems if the www1.mycompany.com has problems or is permanently taken off line.
Load-Balancing Algorithms
Adding hardware load balancing gives you flexibility in how you manage traffic, but the load-balancing method or algorithm you choose has impact on the efficiency of your site. The wide array of load balancers available vary slightly in their operations, but as a guideline, a few basic methods can be used:
Round Robin. Similar to round robin DNS, this method assigns each server connections in the alternation fashion (the load balancer starts with server #1 and assigns each user to the next server in order, and then starts again with #1). Unlike round robin DNS, no traffic is directed to servers that have failed; these servers are automatically removed form the cluster until they have recovered. The basic round robin method does not distribute traffic according to the number of server connections.
Round Robin with Least Connections. This method works in the same way as round robin, but the load balancer monitors how many connections each server has. As new users connect to the site, the load balancer sends the users to the server that has the least amount of connections, even if that server is not next in the round robin order.
Ratio. This type of load balancing distributes traffic between servers depending on a predetermined connection ratio. The ratio is set by the administrator and can be based on forecasted load for each server in the cluster. You could configure your cluster so that two servers handled five users each to one user for the third server. This approach would allow the third server to handle back-end processing or secure transaction processing. Priority. Similar to the ratio method, this method configures servers with a specific priority. Users are sent to servers with a higher priority first.
Fastest. Traffic is sent to the server with the fastest response.
NOTE
Ratio and priority are useful in situation in which all servers in a cluster are not of equal performance capability.
Integrating LocalDirector with ColdFusion MX and ClusterCATS
After you have set up your LocalDirector and it has connectivity, you can configure ClusterCATS to work with LocalDirector. ColdFusion will communicate with LocalDirector using Cisco's proprietary dynamic feedback protocol (DFP). This protocol enables ColdFusion to tell the LocalDirector to remove a server from the cluster when a system probe returns false.
To set up Cisco LocalDirector in ColdFusion, you will want to know the LocalDirector IP address and the DFP agent listen port. This is the managing IP address for LocalDirector. See Figure 3.25 for configuring LocalDirector in ClusterCATS Explorer.
)
Figure 3.25 Configuring Cisco LocalDirector in ClusterCATS Explorer.
NOTE
If you are running Unix, you cannot take advantage of ClusterCATS support for LocalDirector with ClusterCATS Web Explorer. This capability is available only with ClusterCATS Explorer.
There are some additional configurations to consider when integrating LocalDirector with Cluster-CATS. These configurations allow ClusterCATS to interact with LocalDirector properly. When integrating LocalDirector with ClusterCATS, Macromedia has produced comprehensive materials and several articles for creating this configuration. It is best to review these materials before attempting this setup. Here is a partial list of important considerations:
Use Cisco LocalDirector 3.14 software or later. ClusterCATS interaction with LocalDirector will not function properly with an older version.
Set the state of each clustered server to passive mode in ClusterCATS. This allows LocalDirector to control load balancing, not ClusterCATS.
Turn off ClusterCATS gradual redirection feature so that LocalDirector will control redirection and load balancing.
Do not use ClusterCATS dynamic addressing feature. If a server fails and dynamic IP addressing is being used, LocalDirector will not be able to recover the failed-over IP address.
Use the same DFP agent Listen Port number on each server in the cluster. See Figure 3.25 for setting the DFP Agent Listen Port number.
NOTE
Do not use the dynamic-feedback-pw command for setting dynamic feedback between LocalDirector and ClusterCATS. ClusterCATS does not support secure DFP hosts. Use the dynamic -feedback command instead.
Big IP
Another widely used series of load-balancing devices is F5's BigIP series. These devices are different from LocalDirector—rather than running Cisco's proprietary operating system, they run OpenBSD Unix, which has many security features inherent in its design. BigIP load balancers can be configured through a Web interface running SSL or by connecting to the BigIP server through secure shell (SSH). Because the BigIP is running OpenBSD, it can act as a load balancer, a packet filtering firewall, and masquerading firewall. However, implementing these features has an impact of the efficiency of the devices.
If you are using F5's BigIP series, there are additional load-balancing algorithms called Observed and Predictive are also available. The load balancer analyzes performance trends of the clustered servers over time. Traffic is distributed based on trend data collected.