Level: Intermediate Alan Bivens (jbivens@us.ibm.com), Research Staff Member, IBM
Kayed Al-Masarweh (kalmas@us.ibm.com), IT Architect, Senior Certified IT Specialist, IBM, Intel, Microsoft,HP
Pavitra Ghanta (pavitra@us.ibm.com), Software Engineer, IBM, Intel, Microsoft,HP
23 Jan 2007 Learn how to enable the Server/Application State Protocol (SASP) protocol to be used in local high-availability load-balancing environments that contain multiple load balancers and a single workload manager. This article explains local high-availability load-balancing environments and describes how existing SASP implementations can be applied. The article also provides an example of this environment using the IBM® Enterprise Workload Manager (EWLM) and two Cisco Content Switching Modules (CSM).
The growth of today's data centers has fueled the industry of high-end load balancers to distribute heavy workloads over a pool of available services. New management technologies, such as the IBM Enterprise Workload Manager (EWLM), have also emerged to closely monitor and dynamically manage the transactional performance of workloads as they hop through the components of the data center.
In addition, the Server/Application State Protocol (SASP) was developed to align the strengths of these technologies, leveraging the detailed transactional and application knowledge of the workload manager to advise the load balancer as to the best workload distribution. This article addresses how SASP can be used in local high-availability load-balancing scenarios using multiple load balancers. Such a local environment typically exists in a single data center. Using SASP in a global load-balancing environment (load balancing between data centers) is not the focus of this article.
This article will be of interest to you if you work as: load balancing vendors, workload management vendors, or administrators of computing environments.
Configurations of high-availability environments
The use of high-end load-balancing solutions is prevalent in today's data center because of the magnitude of traffic the data center must handle. The growth of today's data centers in both size and complexity has spawned an industry of enterprise level workload managers (like EWLM) to assist administrators in monitoring and managing the data center's complex workloads and applications. Due to the detailed information that enterprise-level workload managers have about the systems and the applications running on them, SASP was created to permit the workload managers to advise the load balancer as to the best distribution for the upcoming workload.
A single load balancer provides high availability for the services to which it distributes through basic health checks and interoperating with enterprise-level workload managers. However, the environment is still vulnerable to failures at the load balancer.
To address this problem, load balancing vendors have implemented various strategies involving redundant local load balancers. These efforts can usually be organized into two categories:
- Active-standby
- Active-active
This article addresses how to extend SASP-oriented load balancing to various high-availability redundant load balancer setups.
Now let's look at details of these two high-availability environments and how to use SASP configurations appropriately within them. Then we'll discuss some considerations you need to keep in mind before deploying SASP-oriented load balancing in these environments.
Active-standby configurations
In active-standby configurations two load balancers are used in a manner in which one stands by to take over for the primary after it determines that the primary is no longer functional. In this configuration, both load balancers are configured to listen for connections for the same virtual IP address, but only the primary load balancer advertises this virtual IP address to upstream routing components.
After the primary load balancer fails, the standby load balancer takes over and begins advertising the same virtual IP address. This causes upstream routing components to route work to the standby load balancer. This architecture is illustrated in Figure 1.
Figure 1. The active-standby configuration
In Figure 1, the connection between the upstream routing component and the standby load balancer is shown as a dotted line because it is only present after the primary load balancer has failed. A dotted line between the primary standby load balancer and the downstream layer 2 switch is also dotted for the same reason.
Notice that Figure 1 also shows a communication path between the primary load balancer and the standby load balancer. This communication is typically used by the standby load balancer to determine if the active primary has failed.
Active-active configurations
In active-active configurations, both load balancers are actively receiving connections to balance. If one load balancer fails, the other one picks up the load for both. This configuration is popular because it increases performance by having both load balancers working at the same time.
One of the most popular active-active configurations uses different virtual IP addresses for each load balancer and makes each load balancer a standby for the virtual IP of the other load balancer. For example, in Figure 2, LB1 may be configured to actively load balance connections to VIP1 and LB2 may be configured to actively load balance connections to VIP2.
Figure 2. The active-active configuration
At the same time, LB1 would be configured to operate in standby mode for VIP2 and LB2 would be configured to operate in standby mode for VIP1. One method of splitting connections for a single application across these two VIPs is DNS (Domain Name System) round robin. Domain Name Systems translate URLs (like http://www.ibm.com) to an IP address. When splitting connections across more than one IP address, the DNS can be used to resolve repeating URL requests to alternating IP addresses.
Now let's look at some things to consider when deploying SASP in these environments.
Considerations for SASP-oriented load balancing in high-availability environments
With small configuration changes, SASP can handle both active-standby and active-active high-availability load-balancing configurations. SASP configurations typically happen at the load balancer with the administrator configuring the IP address and port of the SASP-enabled manager (the SASP term for this manager is the group workload manager). After it's configured and activated, the load balancer connects to the SASP-enabled manager and begins the process of registration and weight retrieval.
SASP identifies a load balancer by a UTF-8 string called a load balancing unique identifier or LBUID. When a SASP-enabled manager receives a connection from a load balancer containing messages with a particular LBUID, it associates this LBUID with the connection for the remainder of its duration. Because there is no guarantee that the TCP connection will realize when the connection has failed, if another connection is made to the SASP-enabled manager with the same LBUID, the SASP-enabled manager will assume that the previous connection with that LBUID has failed and the load balancer is now reconnecting. This causes the SASP-enabled manager to forcefully close the previous connection (thinking that it is a bad connection) and take the new connection as the connection from the active load balancer.
This scenario fits well with the classical active-standby environment. If the active load balancer uses LBUID1 and the standby load balancer does not attempt to make a SASP connection until it determines that the active primary has failed, the standby should also use the same value (in this case LBUID1), when taking over for the failed primary. The SASP-enabled manager will see the new connection as the valid connection and forcibly close the previous connection using that LBUID.
Likewise, if the SASP-enabled manager detects that the primary SASP connection failed, it may keep the load balancer's information and continue to calculate weights for some time to stay current in the event that the load balancer (or the load balancer's standby with the same LBUID) attempts to reconnect. The length of time that a SASP-enabled manager will keep calculating weights for load balancing groups after detecting a connection failure is specific to the individual product. The IBM EWLM continues to calculate weights for 15 minutes after detecting a failed SASP connection (the 15 minute value is an internal parameter that cannot be changed), providing for failover scenarios to occur without losing any of the configuration or learned weights.
An easy alternative exists for classical active-active scenarios in which both load balancers create SASP connections to the SASP-enabled manager. When this happens, the load balancers would register the same load balancing group members and get the same weights. The only SASP-related configuration needed for this is different LBUID values for each load balancer. This simply appears to be two different load balancers to the SASP-enabled manager.
To summarize the SASP configurations for high-availability scenarios, consider the following points:
- In classical active-standby environments, the active load balancer and standby load balancer should both share the same LBUID. When the standby load balancer detects the failure of the active load balancer, it uses the shared LBUID and takes over the primary SASP connection.
- In classical active-active environments, each load balancer should use different LBUIDs. In this case, both load balancers create SASP connections to the SASP-enabled manager and get the same SASP weights for the same group of members.
After talking with several load balancing vendors, we have found that the anticipated standby activity of no action until the standby load balancer has detected the failure of the active load balancer does not always extend to the standby load balancer's SASP implementation. If the standby load balancer also creates a SASP connection to the SASP-enabled manager using the same LBUID as the active load balancer, the active load balancer's connection will be broken. This should be detectable by observing the user interface of the SASP-enabled manager.
During this period, the administrator sees only one load balancer connected to the SASP-enabled manager, but the load balancer's information on the other end changes periodically as the two load balancers continue to take over each other's connections. In this case, the standby load balancer's SASP implementation is acting more like that of an active load balancer requiring the administrator to give the standby load balancer a different LBUID, just as it would in the active-active scenario.
Table 1 describes whether the particular load balancer requires the use of different LBUIDs or the same LBUIDs for each high availability load balancing setup. The information for this table was created from information gathered from product documentation and vendor product development teams.
Table 1. Whether to use different or the same LBUIDs
| Load balancer | Active-standby configuration | Active-active configuration |
|---|
| Cisco CSM | different LBUIDs | different LBUIDs |
|---|
| Nortel Alteon | different LBUIDs | different LBUIDs |
|---|
| F5 Big IP Switch | different LBUIDs | different LBUIDs |
|---|
| NetScaler | single shared LBUID | |
|---|
Of note, the F5 Big IP switch doesn't permit the administrator to change the LBUID value used. The F5 Big IP switch uses the hardware address of a particular hardware interface as its LBUID, so this value will be unique and fits well with high-availability SASP scenarios.
Many variations exist for the active-standby and active-active scenarios we've described; however, the SASP configurations described in this section should be applicable for these variations.
An example configuration
Let's look at an example configuration involving two Cisco CSMs and EWLM.
CSM configurations
For this example, the active-standby CSM architecture was used. (For details about setting up such an environment, see the "Catalyst 6500 Series Switch Content Switching Module Configuration Note" in Resources.) In Cisco CSM active-standby high-availability environments, both the active and standby Cisco CSMs create SASP connections and must be given different LBUIDs (as described in Table 1). If the passive CSM assumes control, it knows the status of the servers because of the weights it has received.
EWLM configurations
After load balancing is enabled in EWLM, the two Cisco CSMs can connect to EWLM, register their group members, and receive weights. (See "Autonomic load balancing, Part 1" in Resources for a detailed description of how to set up load balancing for EWLM and Cisco CSMs.) Figure 3 shows the Load Balancing Panel from the EWLM Control Center where redundant Cisco CSMs have been configured to receive SASP weights from EWLM. Two load balancing entries with slightly different LBUIDs (the hexadecimal strings found before the IP address of the load balancer) can be seen on this panel.
Figure 3. Redundant Cisco CSMs are configured to get SASP weights from EWLM
In conclusion
The magnitude of traffic data centers will have to manage continues to grow, so continued investment in the development and refinement of enterprise-level workload managers will proceed. At the same time, the expectations and demands of data centers and their clients for high availability and performance have caused vendors to introduce high-availability scenarios involving redundant load balancers and related components. In this article, we've addressed how SASP (a protocol aimed toward aligning the strengths of workload managers and load balancers) can be used in popular high-availability load balancing scenarios. We have also presented an example of such a configuration with the IBM Enterprise Workload Manager and Cisco Content Switching Modules.
Resources - Participate in the discussion forum.
-
"Server/Application State Protocol v1," RFC 4678, September 2006: This protocol from the Network Working Group describes the the SASP protocol.
-
"Autonomic load balancing, Part 1: Cisco Content Switching Module" (developerWorks, April 2006): In this article, get a demonstration of how administrators may use a Cisco Content Switching Module and the IBM Enterprise Workload Manager to create an efficient, dynamic load balancing environment.
-
Catalyst 6500 Series Switch Content Switching Module (CSM) Installation and Configuration Note, Software Release 4.2(x): See how the CSM provides high-performance server load balancing for clusters of network devices, such as Web servers, firewalls, and caches.
-
RHI on the Content Switching Module Configuration Example: This Cisco document provides a configuration example for router health injection on a Cisco CSM.
-
Troubleshooting NetScaler High Availability Issues: Learn how to troubleshoot this technology.
-
IBM Enterprise Workload Manager V2.1 (IBM Redbooks, September 2006): This Redbook provides an introduction to the EWLM 2.1. In addition to describing the overall product concept and functions, it presents a detailed discussion of the elements that comprise an EWLM solution.
-
Configuration Guide for Local Traffic Management: Get step-by-step procedures on how to configure the BIG-IP Local Traffic Management system for directing traffic to the WebSphere servers.
-
Load Balancing Servers, Firewalls, and Caches (Wiley, 2002): This document takes a close look at high-performance, end-to-end switching solutions.
-
Nortel Application Switch Operating System 23.2 Application Guide: This guide provides product basics for this technology.
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. |
| | | Kayed Al-Masarweh, an IT Architect and a Senior Certified IT Specialist, joined IBM in 1998. He has many years of consulting and deployment experience in the areas of system products and infrastructure solutions and is certified in Microsoft® technologies, as well as Linux® and IBM technologies. Kayed is focused on emerging technologies like virtualization, grid, and on demand offerings. |
| | | Pavitra Ghanta is a software engineer with the systems group at the IBM T.J. Watson Research Center. She has over six years of experience in development, administration, and testing of system applications. She is currently working on the load-balancing module of the IBM Enterprise Workload Manager. |
Rate this page
| 
