7.1.2 IBM WebSphere Edge Components Load Balancer
IBM WebSphere Edge Components Load Balancer consists of multiple components that can be used separately or together.
For IP spraying, we only need to use the Dispatcher component. See Chapter 4, "Introduction to IBM WebSphere Edge Components," in WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392, for a detailed introduction to Load Balancer as part of IBM WebSphere Edge Components.
Note: We only describe the features that are essentially necessary for our scenarios. We do not cover optional features that are deprecated when using IBM WebSphere Application Server Network Deployment V6.1. Most of the features of IBM WebSphere Edge Components V6.0 are deprecated in V6.1, where they are provided by the IBM WebSphere Application Server Network Deployment proxy server and the IBM HTTP Server Plug-in.
Deprecated features include all components except Dispatcher, and all Dispatcher forwarding methods except MAC. As at the time of writing this book, WebSphere Commerce does not support IBM WebSphere Application Server Network Deployment V6.1, though we still describe some features that are deprecated with V6.1.
For a complete list of deprecated features in IBM WebSphere Application Server Network Deployment V6.1, visit the following URL of the V6.1 Info Center:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rmig_deprecationlist.html
Dispatcher has internal components that are responsible for various load balancing tasks. The components and tasks are:
- Executor is the core component of Dispatcher, and is responsible for the load distribution.
- Manager is the component responsible for providing weight values of each balanced server to Executor, so it can make its load balancing decision.
- Advisors are lightweight clients that run on the Dispatcher server, and they are aware of the protocol used by the back-end servers. Load Balancer provides advisors for HTTP, HTTPS, FTP, and LDAP, among others. Advisors periodically measure the response time for each server and provide the results to the manager as input for calculating server weights.
- Metric Server is a component that is installed and runs in each back-end server (for example, Web server) and that provides values for the server where it is running (for example, memory and CPU usage), which are then also sent to the manager.
- Dispatcher can be administered through a command-line interface (dscontrol) and through a GUI (lbadmin).
Figure 7-2 shows the Dispatcher components and their interactions.
Figure 7-2 Dispatcher components interaction (from WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392)
All requests are routed to Dispatcher, which in turn sprays them among the members of the Web server cluster (IP spraying). The Web server cluster consists of identical Web servers running on different physical machines (or in different LPARs). All Web servers need to be set up in the same way to serve static content and route requests to the application server tier for WebSphere Commerce. See 11.1, Add additional Web servers. In the event of a failure of one of the Web servers, Dispatcher discontinues directing work to the failed server. Dispatcher provides two IP spraying methods:
1.xxxx
MAC forwarding is the fastest forwarding method because Dispatcher receives only the incoming traffic. All outbound traffic is sent directly from the balanced server to the client. Each Web server in the topology is configured with at least one physical IP address and a loopback alias configured with a shared virtual IP address, also called the cluster address. The cluster address is configured as an alias of the Load Balancer's network interface. HTTP clients make HTTP requests to this virtual IP address, and Dispatcher forwards the requests to the Web servers by changing the source and destination MAC address of the packet. The IP addresses remain the same. Because the IP header is not changed, the Web servers send their responses directly to the client, as shown in Figure 7-3.
Figure 7-3 MAC forwarding - network flow (from WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392)
However, the Load Balancer and the Web servers must all be on the same IP subnet. Also, for server affinity, which is a useful feature in performance tuning (see Chapter 19, Monitor and tune Load Balancer), source IP affinity (across multiple ports) is the only available option.
2.xxxx
Network Address Translation (NAT) and Content Based Routing (CBR) allow the Load Balancer and the Web servers to be on different IP subnets. Cookie and SSL session ID based server affinity are also possible.
This method does not use loopback aliases. Instead, a return address is configured as an additional alias of the Load Balancer's network interface. The requests made to the cluster address are changed at the IP layer, such that the Web server's IP address is put into the request as the destination and the return address as the source for each packet. The packets can then be routed to the Web server, and the Web server will send the response back to the Load Balancer, which needs to change the IP headers of the response packets so that they can be routed back to the client, as shown in Figure 7-4.
Figure 7-4 NAT forwarding - network flow (from WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392)
We describe how to set up Load Balancer for our scenario in 8.6, Install Load Balancer. For detailed instructions on how to set up the two different forwarding methods, refer to 11.2.1, MAC forwarding, and 11.2.2, NAT forwarding.
| xxxx |