Autonomic load balancing, Part 1: Cisco Content Switching Module

System and workload management frameworks have proven to be valuable utilities, used to monitor and manage enterprise applications and the systems they run on. While these systems may have a great deal of knowledge about these applications, they generally have little ability to control the rate at which these applications receive work. In contrast, load balancers can control this rate, but typically have little information about the application's ability to successfully handle the request.

This article describes a cooperative effort between one of IBM's workload management products, the Enterprise Workload Manager (EWLM), and one of CISCO's load balancing products, the Content Switching Module (CSM), to provide an effective load balancing solution based on application performance and the ability of the applications to achieve business-level goals.

To facilitate interaction between server load balancers such as the CSM and workload managing entities such as EWLM, the Server/Application State Protocol (SASP) was developed. EWLM monitors the health and load of the servers and their applications in a configured cluster and makes decisions as to which servers or applications are best suited to handle client requests successfully. As part of this monitoring process, EWLM assigns a relative weight to each server in a cluster and sends these weights to the load balancer. The load balancer can then use these weights to balance client traffic to the most appropriate server.

This article demonstrates the interaction between these two products with the goal of load balancing and shows how to configure this interaction. Future articles will describe the interactions between EWLM and other load balancers.

About the components

The first Cisco load balancer to support SASP is the Content Switching Module; the first IBM products to communicate with the CSM using SASP are the Enterprise Workload Manager and the z/OS® Load Balancing Advisor. This article only discusses the interaction between EWLM and the CSM. Appropriate z/OS documentation should be consulted for similar information about the interaction between the z/OS Load Balancing Advisor and the CSM.

The CSM gets server state information using a single, dedicated SASP connection to EWLM. SASP not only allows EWLM to provide relative weights for servers, but also allows the CSM or EWLM to remove a server from service. This may happen when the server is either configured out of service or when a failure is detected for that server.

Figure 1 displays a diagram showing the interaction of the CSM and EWLM.

Overview of the CISCO CSM

The CSM distributes new connections to the server farm according to an administrator-selected algorithm. If round-robin or least connections are chosen as the load balancing algorithm, a weight is also associated with each server in the server farm to let the administrator or third-party managers (such as EWLM) provide the load balancer with distribution characteristics. When balancing according to one of these weighted algorithms, the CSM balances client traffic to the servers so that the ratio of the number of client connections serviced by each server matches the ratio of the weights.

For example, if three servers (A, B, and C) have weights (2, 3, and 1) respectively, the order in which traffic is distributed to the servers would be: A, B, C, A, B, B.

Notice that during the initial server farm creation, the CSM assigned a static weight to the server. By default, this weight is 8, but can be set to a different value by the administrator.

For a server farm in which EWLM has been associated, the weights that the CSM receives from EWLM override any static weights. However, in the event that the EWLM becomes unreachable (due to either network failure or system failure), the CSM uses the weights that were configured when the server was first created to perform the load balancing scheme.

Overview of EWLM's load balancing recommendations

EWLM's Domain Manager has a birds-eye view of the application topology to which the load balancer distributes traffic. The Domain Manager uses the application-level and system-level statistics it gets from the applications of the transaction topology to compose weights for the server farm describing the distribution that the load balancer should use for the next interval. These weights are formed to increase the likelihood that this work will be completed successfully while meeting the performance goals set by the administrator.

EWLM computes new weights for the server farm every 30 seconds. Some of the application and system factors used in the computation include:

• Remaining capacity
• Current application failure rates
• History of the application to meet its goals
• Importance level of the work currently running

Notice that all of EWLM's statistics come from its Managed Server component, which must be installed on the machines of the server farm. If this component is not running, EWLM thinks that the machine is down and returns a corresponding weight of 0. The CSM treats this weight of 0 as an indication that the server is no longer in service and removes it from load balancing consideration (see the section on Configuring EWLM for load balancing).

SASP, the Server/Application State Protocol

EWLM sends weights to the load balancer using the Server/Application State Protocol (SASP). SASP is a binary protocol comprised of several request-reply interactions. Control of these protocol interactions remains at the load balancer unless the load balancer explicitly releases its control. We've briefly described the message types of SASP:

• Register Request/Reply: Used by the load balancer or application member to register an application with EWLM.
• DeRegistration Request/Reply: Used by the load balancer or application member to deregister an application with EWLM.
• Set Member State Request/Reply: Used by the load balancer or application member to quiesce or reactivate members of the server farm.
• Set Load Balancer State Request/Reply: Used by the load balancer to configure the SASP interaction and let application members use registration, deregistration, and set member state messages.
• Get Weights Request/Reply: Used by the load balancer to get the current weights for the members of the server farm.
• Send Weights Message: This is the only message sent from EWLM without first receiving a corresponding request. If the load balancer configures EWLM to do so, EWLM sends this message containing the newest weights when it deems necessary.

Specific details about SASP can be found in the SASP Internet Draft (see Resources). Cisco was a significant external contributor to IBM's development of the SASP specification.

Configuring load balancing with EWLM and the CSM

Configuring EWLM to work with the CSM and vice versa is normally done after setting up the EWLM management and the CSM load balancing domains. It is important to note that the configurations and screenshots included in this document are from EWLM Release 1 and we assume that you have installed the Virtualization Engine fix pack 1.1.020 or higher. Configurations and screenshots from later versions of EWLM will be in future articles.

A typical EWLM management domain setup procedure looks like:

1. Install and configure EWLM Domain Manager.
2. Configure EWLM Control Center.
3. Install and configure EWLM Managed Server on each managed node.
4. Enable ARM instrumentation in supported middleware. (For more on this, see the eServer Information Center and "Performance monitoring with Enterprise Workload Manager" in Resources.)
5. Create a domain policy to set a business goal for each managed application.

Refer to the EWLM InfoCenter for complete instructions on setting up EWLM.

A typical CSM load balancing domain setup procedure will look like:

1. Basic setup of the Catalyst 6500 series switch or 7500 series router (our CSM was in a Catalyst 6509 switch).
2. Connect the servers to the appropriate ports.
3. Create VLANs depending on applications needs.
4. Configure routing on the switch to allow communication to and from the servers.
5. Logically group servers together as server farms based on the applications they are serving.
6. Define virtual IP addresses for incoming traffic to reach these server farms.
7. Choose a load balancing algorithm for each server farm and optionally assign static weight to real servers.
8. Optionally define probes and sticky group policies.

Refer to the Cisco CSM user guide for complete instructions on setting up CSM and load balancing.

This article assumes that you've refered to the referenced documentation mentioned for details on basic setup for both the CSM and EWLM. Another assumption made is that the you already have a working EWLM management domain and a working CSM load balancing domain; this lets us focus on the changes to both configurations to facilitate EWLM load balancing with the CSM.

Cisco CSM literature may use the term Group Workload Manager (GWM) to refer to any software that can give dynamic weights to members of a server farm using the SASP protocol. In this case, EWLM is a type of Group Workload Manager.

Configuring the Catalyst 6509 and the CSM for EWLM

This section describes what must be done to an existing valid CSM configuration to enable EWLM to provide load balancing weights for the server farm.

1. First, make sure you have the right CSM firmware release, 4.1.2 or higher, and a supported IOS release.
2. Configure an agent for the SASP EWLM connection.
3. Associate that agent with the appropriate server farms.

Configuring an agent for the SASP/EWLM connection

A special DFP agent must be configured, signified by a special bind id. If this bind id falls into the range of bind ids allocated for SASP communication, the CSM knows that the connection is to use SASP for communication. For example:

Router(config-slb-dfp)# agent 64.100.235.159 3860 65520

where the syntax is:

Router(config-slb-dfp)# agent <ip address> <port> <bind id>

The CSM identifies the bind id as a GWM bind id through the use of environment variables. The environment variables SASP_FIRST_BIND_ID and SASP_GWM_BIND_ID_MAX identify the first GWM bind id and the maximum number of bind ids, respectively. So, if a DFP agent is created with a bind id between SASP_FIRST_BIND_ID and SASP_FIRST_BIND_ID + SASP_GWM_BIND_ID_MAX, the agent uses SASP as the communication protocol to the GWM.

Port 3860 is registered with IANA for SASP (IANA Port Number Assignments). Using this port reduces the likelihood of port conflicts when configuring SASP communication.

The CSM configures the SASP parameters to have EWLM automatically send server weights to the CSM whenever a change of weights occurs. However, to ensure that communication with EWLM has not been lost, if weights are not received after a retry interval, the CSM sends a load balancer state message to EWLM. If the overall system is performing correctly, the CSM receives a load balancer state response message from EWLM. The retry interval defaults to 180 seconds, but can be configured when the connection is created. In addition, there is a retry count parameter that specifies how many times the CSM sends the load balancer state message to EWLM before giving up. The default of 0 means the CSM tries indefinitely. For example:

Router(config-slb-dfp)# agent 64.100.235.159 3860 65520 0 120

where the syntax is:

 
Router(config-slb-dfp)# agent <ip address> <port> <bind id> <retry count> <retry interval>

Associating the SASP agent with a server farm

After the EWLM connection is initialized, the server farm can then be associated with the SASP/EWLM agent. Using the bind id assigned to the SASP/EWLM agent, the server farm becomes bound to EWLM.

At this point, the CSM registers the servers in the server farm with EWLM and queries EWLM for weights representing the server state. The bind ID represents a connection with the EWLM Domain Manager, so more than one server farm can use the same bind ID if each server farm is managed by the same Domain Manager.

For example:

Router(config-slb-sfarm)# bindid 65520

At this point, the health of the real servers in the server farm is adjusted according to the feedback received from EWLM.

An important note: Make sure the associated virtual server has an IP protocol and port set in order for EWLM to map the incoming requests to a particular PID on each real server. This allows application-level statistics to be made available to calculate better weights. If the protocol or port is not set or the target application is not ARM instrumented, then weight calculation still works but will be based on systemwide statistics instead of application related statistics.

Supporting environment variables

Although some of the necessary environment variables were mentioned previously, Table 1 contains a list of the variables.

The variables in Table 1 are changed with the following command:

Router(config-module-csm)# variable <variable name> <value>

Configuring EWLM for load balancing

After you have a working EWLM management domain, to enable dynamic weight generation for load balancing, you only need to specify a listening port for SASP messages:

changeDM [.bat | .sh] workingDir -lbp xxxx

where xxxx is a valid TCP/IP port number or set to "Off" to disable weight generation.

At the startup of EWLM Domain Manager, if a valid load balancing port is specified, the weight manager is activated and waits for connections from load balancers. After getting connected and valid groups are registered, the Domain Manager sends weight updates to CSM whenever there is a change. If the Domain Manager detects that a Managed Server is no longer online or the target application is down, it also sends CSM a weight of 0 indicating that the real server is offline and no traffic should forwarded to it.

Failover considerations

There are two failover considerations that should concern you:

• CSM failure
• EWLM failure

In CSM failure, two CSMs configured in an active/standby configuration can guarantee synchronized server state information by connecting to the same EWLM to receive identical dynamic weight updates. However, in order for this configuration to work, the two CSMs must be distinguishable to the EWLM; thus, they must hold different values in their SASP_CSM_UNIQUE_ID fields. For example, one CSM can have the SASP_CSM_UNIQUE_ID value of "CSM-1" while the other CSM would require a different value, such as "CSM-2."

For EWLM failure: On the CSM, only a single EWLM is expected to be associated with a given server farm. In other words, no backup EWLM is configured. Consequently, if the CSM loses connectivity to EWLM, it is no longer able to obtain dynamic weights for servers. Thus, as described in the earlier sections, the CSM uses the statically configured weights to perform the appropriate weighted load balancing algorithm.

It is important to note that the CSM continuallys attempt to contact the EWLM in the background. If the EWLM communication is re-established, it is able to immediately use the dynamically learned weights. This attempt to re-establish a broken connection channel happens once every 20 seconds (as defined in the specification).

Configuration example

This section provides an example topology and configuration used to run a test load balancing scenario. This scenario consists of a CSM balancing over four transaction paths, each containing a Web server (IBM HTTP Server), application server (WebSphere® Application Server), and a database (IBM DB2®). Two of the paths consist of AIX® machines, the third path uses Windows® machines, and the fourth path uses Solaris systems. The Domain Manager is running on a dedicated Linux® machine. The load balancer is a CSM module in the third slot of a CISCO Catalyst 6509 Switch.

Figure 2 demonstrates the network and application topology.

Now let's look a some load balancing configurations.

EWLM configurations

After the EWLM management domain is working properly, meaning:

1. Managed Servers are connected to the Domain Manager. In the EWLM screen shot (Figure 3), you can see which Managed Servers are currently connected and being used.
   Figure 3. Connected and used Managed Servers
   
   

   In Figure 4, you can see the environment setup of this case study. You may notice in this configuration example that each hop in the transaction flow (IHS > WebSphere > DB2) are on the same machine (same IP address). This made the example easier, but certainly does not have to be the case.

   
   Figure 4. The sample environment
   
   
2. All the supported middleware are ARM instrumented.
3. The Control Center is showing transaction statistics.

   Steps 2 and 3 are not an absolute requirement, but would greatly improve the weight calculation algorithm if available.

Following are the steps to configure the EWLM Domain Manager to listen and respond to SASP messages:

1. Stop the Domain Manager.
2. Check the Domain Manager configuration: ./displayDM.sh /usr/EWLMDM.
3. Add the load balancing port to the configuration table: ./changeDM.sh /usr/EWLMDM -lbp 3860.
4. If your Domain Manager has two IP addresses and you need to use both IP addresses for Managed Servers and load balancing, make sure your -ma IP parameter is 0.0.0.0 instead of a specific IP address, because -mp xxxx and -lbp xxxx ports both use the -ma IP parameter as the IP address to bind to. To change that, use this command: ./changeDM.sh /usr/EWLMDM -ma 0.0.0.0. You can combine the previous command and this one into one single command.
5. Start the Domain Manager again.
6. Make sure the Domain Manager is now listening on the load balancing port. The command in Windows is: => netstat -na. Look for this:

  TCP    0.0.0.0:3860           0.0.0.0:0              LISTENING 

CSM configurations

All of these steps must be done as privilege 15, either by using login or enable commands at the console.

1. Verify the default SASP variables.

   esvt6509#sh mod csm 3 variable variable value ---------------------------------------------------------------- ... SASP_CSM_UNIQUE_ID Cisco-CSM SASP_FIRST_BIND_ID 65520 SASP_GWM_BIND_ID_MAX 1 ...

   
   
2. Change the value of a variable.

   esvt6509#configure terminal esvt6509(config)#mod csm 3

   
   
3. Create a server farm.

   esvt6509(config-module-csm)#serverfarm testfarm esvt6509(config-slb-sfarm)#nat server esvt6509(config-slb-sfarm)#no nat client esvt6509(config-slb-sfarm)#predictor leastconns esvt6509(config-slb-sfarm)#bindid 65520 esvt6509(config-slb-sfarm)#real 192.168.200.84 esvt6509(config-slb-real)#inservice esvt6509(config-slb-real)#real 192.168.200.170 esvt6509(config-slb-real)#inservice esvt6509(config-slb-real)#real 192.168.200.104 esvt6509(config-slb-real)#inservice esvt6509(config-slb-real)#real 192.168.200.13 esvt6509(config-slb-real)#inservice

   
   
4. Create a virtual server.

   esvt6509(config-module-csm)#vserver testvserver esvt6509(config-slb-vserver)#virtual 192.168.100.251 tcp www esvt6509(config-slb-vserver)#serverfarm testfarm esvt6509(config-slb-vserver)#persistent rebalance esvt6509(config-slb-vserver)#inservice

   
   
5. Create a DFP agent.

   esvt6509(config-module-csm)#dfp esvt6509(config-slb-dfp)#agent 192.168.200.173 3860 65520 esvt6509(config-slb-dfp)#end

   
   
6. Verify the server farm.

   esvt6509#sh mod csm 3 serverfarms detail TESTFARM, type = SLB, predictor = LeastConns nat = SERVER virtuals inservice = 1, reals = 4, bind id = 66520, fail action=none inband health config: <none> retcode map = <none> Real servers: 192.168.200.84, weight = 56, OPERATIONAL, conns = 0 192.168.200.170, weight = 56, OPERATIONAL, conns = 0 192.168.200.104, weight = 56, OPERATIONAL, conns = 0 192.168.200.13, weight = 56, OPERATIONAL, conns = 0 Total connections = 0

   
   
7. Verify the real servers.

   esvt6509#sh mod csm 3 reals real server farm weight state conns/hits ---------------------------------------------------------------------- 192.168.200.84 TESTFARM 56 OPERATIONAL 0 192.168.200.170 TESTFARM 56 OPERATIONAL 0 192.168.200.104 TESTFARM 56 OPERATIONAL 0 192.168.200.13 TESTFARM 56 OPERATIONAL 0

   
   
8. Verify the virtual server.

   esvt6509#sh mod csm 3 vservers detail TESTVSERVER, type = SLB, state = OPERATIONAL, v_index = 14 virtual = 192.168.100.251/32:80 bidir, TCP, service = NONE, advertise = FALSE idle = 3600, replicate csrp = none, vlan = ALL, pending = 30, layer 4 max parse len = 2000, persist rebalance = TRUE ssl sticky offset = 0, length = 32 conns = 0, total conns = 0 Default policy: server farm = TESTFARM, backup = <not assigned> sticky: timer = 0, subnet = 0.0.0.0, group id = 0 Policy Tot matches Client pkts Server pkts ----------------------------------------------------- (default) 0 0 0

   
   
9. Verify the DFP agent.

   esvt6509#sh mod csm 3 dfp detail DFP Agent 192.168.200.173:3860 Connection state: Connected Keepalive = 65520 Retry Count = 0 Interval = 180 (Default) Security errors = 0 Last message received: 16:12:14 EST 06/22/04 Last reported Real weights for Protocol TCP, Port www Host 192.168.200.84 Bind ID 65520 Weight 56 Host 192.168.200.170 Bind ID 65520 Weight 56 Host 192.168.200.104 Bind ID 65520 Weight 56 Host 192.168.200.13 Bind ID 65520 Weight 56 DFP manager listen port not configured. No weights to report to managers.

   
   

Lessons learned

This section describes what we learned while testing and running case studies of the CSM's usage of EWLM weights. It is included in this article because we think it should be used as a reference for tips to provide more effective load balancing with EWLM and the CISCO CSM.

Best practices

We discovered four major best practices from our experiences:

1. It is recommended to start with a functional EWLM management domain and a functional CSM load balancing domain first, then enable the communication between the EWLM Domain Manager and CSM.
2. In most of our tests, the weighted least-connection algorithm yields better performance than the weighted round-robin algorithm.
3. Beware of bottlenecks and single points of failure when using the EWLM Firewall Broker. A firewall broker acts as a proxy server, accepting connections from all the Managed Servers in the same IP subnet and channels them to the Domain Manager. If the Firewall Broker machine or process is not available, all the Managed Servers relying on it are disconnected from the Domain Manager. Normally, the fact that the Managed Servers are disconnected from the Domain Manager won't affect the functioning of any middleware; however, if EWLM load balancing is enabled at the CSM, the Domain Manager senses that a Managed Server is offline and sends a weight 0 to the CSM, stopping traffic from being forwarded to that server. If the Firewall Broker is suddenly unavailable then the Domain Manager and CSM could believe that the entire server farm is unavailable.
4. The most reliable topology is to have the least hops possible between the Domain Manager and Managed Servers.

Special EWLM benefits to load balancing

EWLM load balancing weights help the CSM get better performance in typical load balancing scenarios. There are also several special scenarios where EWLM can provide exceptional benefit:

• When the server farm contains servers of different capacities and hardware architectures in a single tier, EWLM can sense the application level capacity of these systems and adjust weights as they change.
• When the server farm contains servers performing multiple types of work in addition to the work being load balanced, EWLM can be sensitive to the effect the other work has on the load balanced work. Furthermore, if the other work is properly instrumented, EWLM can try to manage the rate in which load balanced work arrives in a way to achieve the business goals of all work on the system.
• When the work running on the server farm machines has varying importance levels, EWLM is aware of the importance level of the work and favors machines running less important work to preserve the resources on the systems that are currently running more important work.
• When the work running on the server farm machines has specific goals to be met, EWLM is aware of these goals and favors machines that have a history of achieving such goals.
• When the applications receiving the load balanced work encounter failures (even downstream failures), EWLM is made aware of such application-level failures and heavily favors machines not experiencing these failures. The applications experiencing such failures continue to have minimal weights until EWLM is assured that they have recovered.

Troubleshooting

Here is what we learned in troubleshooting:

1. Setting up a load balancing domain in the CSM and installing and configuring EWLM in sophisticated enterprise environments can be quite complex. If load balancing problems arise in this environment, eliminating problem sources should begin with removing the DFP agent pointing to the EWLM Domain Manager.

   Usually the Domain Manager would only change the weight of the real servers in CSM, but won't prevent traffic from flowing back and forth. The only time where it may prevent traffic from flowing is when the Domain Manager thinks that a Managed Server is offline or the ARM instrumented edge application is shutdown. In this case, the Domain Manager sends a weight of 0 to tell CSM not to send any more traffic to that application. Use the command sh mod csm 3 reals to see if you have any real servers in the DFP_THROTTLED state (assuming that your CSM is installed in slot 3).

   If you do have this problem, check the EWLM Control Center to find out what's wrong. Then check the Managed Server to see if everything is running properly, especially the Managed Server Java process, the middleware, and the network connectivity to the Domain Manager. After you restore everything back to order, check the EWLM Control Center to make sure that managed server is working properly again.

2. Logging may prove quite useful in troubleshooting SASP problems. Log messages are stored in the Catalyst's buffer and you may choose to use an external syslog daemon for more flexibility and storage options.

   To display all the messages in the Catalyst's buffer, use: show logging. To set up logging to remote syslog, refer to the Catalyst's user guide and your operating system's manuals.

   All the SASP error messages and return codes are logged in the logging buffer or remote syslog if appropriately configured. Successful return codes are not logged.

3. Another common problem seen in testing occurs when the DFP agent is not using the SASP protocol to communicate with EWLM Domain Manager. You do not see any logging messages at either end when this happens. In the output of sh mod csm 3 dfp detail, you'll see the DFP agent state as Not connected or Trying to connect (assuming that your CSM is installed in slot 3). To fix this, you need to check your configuration again. Pay special attention to the SASP agent to make sure its bind ID is between SASP_FIRST_BIND_ID and SASP_FIRST_BIND_ID + SASP_GWM_BIND_ID_MAX.

In conclusion

Through advanced resource and statistics gathering techniques, EWLM can make intelligent weight assignments based on the relative load and availability of servers within a cluster. With the use of SASP, EWLM is then able to pass this relative state information on to the CSM, which in turn is able to balance client requests to the most appropriate server. The result is a well-balanced, highly efficient distribution of traffic that ensures the best utilization of available resources as defined by the administrator.

Resources

Learn

• Server/Application State Protocol version 1 (SASPv1) draft: Describes how the SASP protocol provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members.
  
  
• IBM Systems Information Centers: This is a good place to find information on hardware, software, and eServers.
  
  
• "Performance monitoring with Enterprise Workload Manager" (developerWorks, March 2006): Learn how to enable ARM instrumentation for end-to-end performance monitoring in IBM middleware on AIX and Linux.
  
  
• z/OS Load Balancing Advisor documentation: Provides you with updates to the z/OS Communications Server.
  
  
• "Fit components together to manage resources and workloads" (developerWorks, February 2005): This article explains how to use three products -- EWLM, Tivoli Provisioning Manager, and Tivoli Intelligent Orchestrator (plus ARM and SASP) -- to provide a cohesive infrastructure.
  
  
• developerWorks Linux zone: This zone contains many articles and tutorials on load balancing.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

• IBM Enterprise Workload Manager SDK: Try EWLM to aid in the development and test of Application Response Measurement 4.0-level instrumentation in applications and middleware, and the development and test of EWLM ARM Adapter library implementations.
  
  
• Cisco CSM: Adds advanced layer 4 to layer 7 content switching capabilities to the Cisco Catalyst 6500 Series Switch or the Cisco 7600 Series Router; this provides layer 4 to layer 7 load balancing to existing layer 2 and layer 3 features of the Catalyst platforms.
  
  
• IBM trial products for download: Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

Discuss

• developerWorks blogs: Participate in developerWorks blogs and get involved in the developerWorks community.
  
  
• Join the discussion: Drop in on the "Autonomic computing: an insider's perspective" discussion forum.
  
  

About the authors

Alan Bivens, PhD, is a research staff member at the IBM T.J. Watson Research Center where he creates autonomic workload management capabilities to allow datacenters to be self-healing and self-optimizing. His current work deals with load balancing, power management, and coordination between autonomic managers.

CheKim Chhuor currently works at IBM Poughkeepsie in the System Verification Test team. He has many years of Web infrastructure consulting experience, and holds many IBM WebSphere, DB2, and e-business certifications. His current focus is on grid and autonomic computing. You can contact him at chhuor@us.ibm.com.

Donna Dillenberger joined IBM in 1988 and has worked on future hardware simulations, mainframe operating systems, workload management, scalable JVMs, scalable Web servers, stream servers, and EJB containers. She is a Distinguished Engineer, IBM's Chief Architect of IT Optimization solutions, a Master Inventor, a member of the IBM Academy, and an Adjunct Professor at Columbia University. She is currently working on Enterprise Workload Management and mainframe hypervisors.

Greg Ferris works at the IBM Poughkeepsie, New York, site in System Verification Test on the Virtualization Engine project. Before that he spent several years working in the performance testing area for zSeries. On the VE project he is current involved with EWLM, load balancing, and automation.

John Fenton is a technical leader at Cisco Systems. He has spent several years developing and designing various communication protocols. His current focus is on software development for network processors which provide advanced communication services.

Wesley Chou is an engineering manager with Cisco Systems' Application Delivery Business Unit. He focuses on software development for load balancing technologies.

Comments

Back to top

Trademarks

Table of contents

• About the components
• Configuring load balancing with EWLM and the CSM
• Configuration example
• Lessons learned
• In conclusion
• Resources
• About the authors
• Comments