Cisco Validated Design Guide, Cisco WebEx Social Release 3.3
Load Balancer Deployment
Downloads: This chapterpdf (PDF - 499.0KB) The complete bookPDF (PDF - 2.35MB) | Feedback

Load Balancer Deployment

Table Of Contents

Load Balancer Deployment

Load Balancer

Load Balancing Configuration

Secure Load Balancer (SSL Termination)

Sample ACE Configuration

DMZ Design

Load Balancer Deployment

Cisco WebEx Social often requires several App Nodes for larger deployments. With the deployment of multiple App Nodes, a load balancer is necessary to balance traffic across the App Nodes. This chapter describes the possible deployment options when using multiple App Nodes in a large deployment.

This chapter includes these topics:

Load Balancer

Secure Load Balancer (SSL Termination)

DMZ Design

Load Balancer

Load balancers can be used for larger deployments that require multiple App Servers. A load balancer can be placed in front of the App Servers to balance user traffic across the nodes. Load balancing always uses Network Address Translation (NAT).

For related information, see the "Load Balancer Information" section in Cisco WebEx Social Installation and Upgrade Guide.

An App Server supports up to 1,500 concurrent user sessions. To support a larger number of concurrent sessions, a Cisco ACE in bridged or routed mode can be used to load balance access to Cisco WebEx Social. In addition, multiple Cisco ACEs can be clustered to provide high availability.

In Figure 4-1, a user tries to access the Cisco WebEx Social cluster that is running on The DNS server resolves the A-record to the virtual IP (VIP), which is configured either on a single Cisco ACE instance or on a clustered Cisco ACE instance. The user session is forwarded to one App Server. With persistent sessions, the Cisco ACE keeps the active user session on one App Server to ensure that the user login session does not expire. Persistent sessions, also called IP stickiness, are required because a Cisco ACE reads an HTTP request and stores the source IP of the request (the IP address of the end user device) in a local database.

Figure 4-1 Load Balancing

A layer 4 load balancing policy must be configured to ensure that only traffic on a specific port, typically HTTP port 80, is forwarded to the App Servers.

Cisco recommends the use of round robin load balancing, which is the default configuration for load balancing with the Cisco ACE.

Load Balancing Configuration

Access control lists (ACLs) must be configured in the firewall to allow traffic into the Cisco ACE data plane. After the ACL checks are passed, a service policy, which is applied to the interface, is used to classify traffic that is destined for a virtual IP address (VIP). The VIP is associated with a load-balancing action within the multimatch policy.The load-balancing action instructs the Cisco ACE how to process traffic that has been directed to a VIP. All traffic is sent to a server farm by the ACE, where it is distributed in round-robin fashion by default to an App Servers. The included HTTP probe that is included in the ACE configuration file ensures that traffic is only forwarded to App Servers that are in service.

The Cisco ACE configuration occurs in layers. Due to this layered structure, it is optimal to create the configuration by working backward from the way the flow is processed. To enable server load balancing with a Cisco ACE that has been configured to use routing mode, follow these general steps, which are explained in detail in this section. (These steps assume knowledge of Cisco ACE configuration.)

1. Configure and enable ACLs and the HTTP probe.

2. Set up the server farm on the Cisco ACE.

3. Define the VIP address and traffic handling.

4. Create client- and server-facing interfaces and apply the service policies.

Step 1 Configure an ACL and the HTTP probe.

To begin load balancing configuration, on the Cisco ACE, create an ACL that permits client connections. Use port 80 to forward only required traffic to the App Servers.

The following ACL configuration example shows that traffic is matched by an ACL called WXS. Traffic is allowed on port 80 (the default is to deny all traffic coming to the Cisco ACE).

ACE (config)# access-list WXS extended permit tcp any eq 80

To set up the HTTP probe, configure an expected status code. If the Cisco ACE receives this status code in the server response, the server is marked as passed. If the Cisco ACE does not receive this status code, the server is marked as failed.

The following HTTP probe configuration shows the configuration of the expected status code 200. This configuration causes the probe to try to receive the favicon.ico file every 15 seconds. The expected status code 200 indicates that an HTTP request is successful and the requested file (favion.ico) can be read by the App Server.

ACE (config)#
	probe http WXS_PROBE
	Interval 15
	passdetect interval 60
	request method get url /html/favicon.ico
	expect status 200 200
	open 1

Note Before continuing to next step, use a small file to verify the health of the App server. The favicon file is typically used because this file is only a few KB in size and does not require significant server resources to process.

Step 2 Set up the Server Farm on the Cisco ACE.

For the ACE to load balance across the Cisco WebEx Social Application Servers, the group of servers, or server farm, must be configured in the ACE.

All App Servers must be configured on Cisco ACE before grouping them into a server farm. The following sample configuration adds two App Servers, named WXS-APP-1 and WXS-APP-2, to the ACE, then groups them into a server farm named WXS-FARM.

ACE (config)#
rserver host WXS-APP-1
	ip address
rserver host WXS-APP-2
	ip address
serverfarm host WXS-FARM
	probe WXS-PROBE
	rserver WXS-APP-1 80
	rserver WXS-APP-2 80

Cisco ACE needs to know the IP address of the servers that are available to process client connections. The rserver command defines the IP address of the service. In addition, each rserver must be placed in service before an App Server can be used. The benefit of this design is that no matter how many applications or services an rserver hosts, the entire real server can be completely removed from the load-balancing rotation by issuing a single no inservice or no inservice-standby command at the rserver level. The rserver structure is beneficial for upgrading or patching an rserver because you no longer have to go to each application and remove each instance of the rserver.

After the App Servers have been added to the ACE configuration, group the rservers to be used to process client connections into a server farm with the command serverfarm. The rserver must be placed in service. Add the destination port to each rserver instance. The service management allows a single instance of an rserver to be manually removed from rotation. Also add the previously configured probe to the server farm.

Step 3 Configure the VIP address and traffic handling.

After the server farm has been set on the ACE, configure the Virtual IP addresses to handle incoming traffic to be balanced across the App Servers. Set up the VIP address and how Cisco ACE should process incoming client requests as described in this section.

a. Configure a Layer 4 VIP. For example:

Class-map match-any L4-WKS-HTTP
Match virtual-address tcp eq www

b. Configure the policy maps with persistent sessions. For example:

Sticky ip-netmask address source STICKY
timeout 720
replicate sticky
serverfarm WKS_FARM
policy-map type loadbalance http first-match L7_WKS
	class class-default
		sticky-serverfarm STICKY
policy-map multi-match L4_WKS_POLICY
	loadbalance vip inservice
	loadbalance policy STICKY

Use a class map to define the VIP to which clients send their requests. In the sample code shown above, the VIP is considered a to be Layer 4 address because there is a match on the HTTP port. If the VIP were to match any port, the match would be considered as a Layer 3 VIP.

c. Define the IP sticky configuration to match to a single IP address using the netmask Map the sticky configuration to the previously configured server farm (called WKS-FARM in the sample code shown above).

d. Define the action to take when a new client request arrives. In the sample code shown above, all traffic is sent to the server farm WKS-FARM. Because the VIPs and load-balancing actions are defined independently, they must be associated so that Cisco ACE knows how to process traffic that is destined for a VIP. The association is made by using a multimatch policy map. Multimatch policy maps are applied to interfaces as service policies. Add these service policies to the multimatch policy, which is called L4_WKS_POLICY in the sample configuration shown above, and enable the stickiness configuration to enable persistent load balanced sessions.

Step 4 Create client and server interfaces

Configuring the client and server interfaces of Cisco ACE define which interfaces are directed to the App Servers and which interfaces are directed to the client.

a. Create the interfaces with a NAT pool.

b. Create interface VLANs to interconnect Cisco ACE to the client side of the network and to the App Servers. In the following sample configuration, the VLAN interface 15 and 30 are used. The VLAN interface is the internal server side interface, while the VLAN 30 interface is the client side interface, which is connected to the Internet. Add a NAT configuration to enable Cisco ACE to route traffic between both networks. Map the service-policy to the outside interface VLAN 30 as well as the initially configured ACL.

The following shows a sample configuration:

	policy-map multi-match NAT-POLICY
		class NAT-CLASS
			nat dynamic 1 vlan 30
interface vlan 15
	description internal
	ip address
	access-group input INTERN
	service-policy input NAT-POLICY
	no shutdown
interface vlan 30
	description outside
	ip address
	access-group input W/S
	nat-pool 1 netmask pag
	Service-policy input L$_WKS_POLICY
	no shutdown

Secure Load Balancer (SSL Termination)

For Cisco ACE to be able to terminate SSL sessions, the ACE must be configured with both an SSL certificate and a corresponding SSL key. After the certificates are imported to the ACE, these SSL files are associated with an SSL proxy service that is applied to the VIP to enable SSL termination. The certificate and key can either be generated by using a tool such as OpenSSL or be requested from a certificate authority such as Verisign or GoDaddy.

Before configuring the SSL termination, you must generate an RSA key and the certificate signing request (CSR) and import the signed certificate. The SSL termination configuration begins by defining a VIP and corresponding server farm and rservers, similar to the basic Layer 4 load balancing configuration. Although the VIP can be configured with any port, Cisco ACE performs a TCP reset on any non-SSL connections. To prevent the TCP reset, Cisco recommends that you bind the VIP to a port. In the examples in this section, the IP address and port 443 are used.

To enable HTTPS termination with the Cisco ACE, the following tasks must be performed. These tasks are explained in detail in this section.

1. Generate an RSA key and a certificate signing request

2. Import the certificates

3. Configure the ACL and VIP

4. Set up the SSL proxy

Step 1 Generate an RSA key and a certificate signing request (CSR).

To configure SSL termination, an RSA key and CSR must be generated:

a. Generate the RSA key from within the ACE. After the key is generated, copy the file to the App Server under /etc/pki/tls/private:

crypto generate key 1024 key.pem

b. Use Cisco ACE to create a CSR from the key that is generated in the previous step. On Cisco ACE, the CSR and key generation is a two-step process. First, a CSR parameter map must be created with the command crypto generate csr WKS key.pem. Then a CSR is generated from the key and the CSR parameter map. Cisco ACE returns the CSR request, which can be copied to the web form provided by the signing certificate authority (CA) and to and to the /etc/pki/tls/certs directory on the App Server.

For example:

		crypto csr-params WKS
			country DE
			state Berlin
			locality Berlin
			organization-name Cisco
			organization-unit ECP-BU
			serial-number 1
		crypto generate csr WKS key.pem

Step 2 Import the CSR.

Most SSL termination configurations begin by importing the certificate and key to Cisco ACE. The easiest way to accomplish the file upload is by placing the two files onto a Secure FTP (SFTP) or FTP server so they can be transferred to Cisco ACE. For example:

	crypto import ftp cisco cert .pem cert.pem
	crypto import ftp cisco key .pem key.pem

Verify the files and ensure that the keypair matches. For example:

	show crypto files
	Filename         File    File    Expor    Key/
	                 Size    Type    table    Cert
	cert .pem        1354    PEM     Yes      CERT
	key.pem          887     PEM     Yes      KEY
	crypto to verify key.pem and cert.pem
	keypair in key.pem matches certificate in cert.pem

Note If the files are in privacy enhanced mail (PEM) format, you can cut and paste to import the SSL file by using the crypto import command.

After the SSL files have been imported, check the SSL files to ensure that they were uploaded properly and to verify that SSL files match. If the two files do not match, the RSA key cannot be exchanged and Cisco ACE cannot properly terminate client connections.

Step 3 Configure the ACL and VIP.

To configure SSL termination, adjust the ACL and VIP ACE configuration that ia described in the "Load Balancing Configuration" procedure to include the HTTP required configuration elements.

a. Extend the ACL to allow HTTPS traffic. Use the previously configured ACL and add a new statement. If unsecure traffic should be blocked, remove the previous ACL statement with the port 80. Here is a sample ACE configuration:

	access-list WXS extended permind tcp any eq 443

b. Add HTTPS to the VIP. Without the Layer 4 configuration, the VIP forwards any traffic. The port statement in the previously configured server farm redirects the traffic to HTTP port 80. Here is a sample ACE configuration:

class-map match-any L4_WKS_HPPTS
match virtual-address tcp eq 443
Access-list WXS extended permind tcp any any eq 443

The VIP that is shown in this sample configuration allows Cisco ACE to accept connections on port 443 and forward them to a real server on port 80, which was configured as described in the "Load Balancing Configuration" section.

Note If the port is not provided, the VIP port will be preserved.

Step 4 Set up the SSL proxy and policy map.

Configure the SSL proxy and adjust the policy map that was configured as described in the "Load Balancing Configuration" section.

a. Set up an SSL proxy to terminate HTTPS connections. Here is a sample ACE configuration:

	ssl-proxy service WKS-HTTPS
	key key.pem
			cert cert.pem

b. Add the SSL proxy command to the previously configured policy map. Here is a sample ACE configuration:

	policy-map multi-match L4_WKS_POLICY
			loadbalance vip inservice
			loadbalance policy STICKY
			ssl-proxy server WKS_HTTPS

c. Make a test connection to the VIP address by using HTTPS in a web browser and ensure that you see a response from one of the App Servers.

Cisco ACE can be configured with an SSL proxy service, which is a logical grouping of the certificates, key, and SSL parameters that are used to define the characteristics of SSL termination on Cisco ACE. Within Cisco ACE, all SSL termination is fully integrated. Therefore, there is no need to configure internal VLANs or IP addresses to process decrypted traffic. All that is required to enable SSL termination is to attach the SSL proxy service that is configured above to a VIP in a service policy. At this point, Cisco ACE should be configured with a working SSL termination configuration.

Figure 4-2 shows the flow of HTTPS traffic after SSL termination is configured.

Figure 4-2 Flow Diagram for WebEx Social Load Balancing for HTTPS Traffic

This figure illustrates the following flow:

1. User initiates a request to Cisco WebEx Social by specifying the Cisco WebEx Social URL on a browser.

2. The load balancer receives the request and processes the URL according to the rules that are specified. If the request is received on an HTTPS virtual server, traffic is proxied out to an App Server. If the request is received on an HTTP virtual server, the traffic is automatically redirected to the HTTPS virtual server, and the HTTPS virtual server proxies the request to the Asset Web Server pool.

3. The user browser session is auto redirected to

4. In a round robin fashion, App Servers receive and process each connection, distributing the load across nodes.

Note Cisco recommends terminating SSL on the ACE.

For SSL termination on the ACE to work with Cisco WebEx Social, the portal property web.server.protocol must be set to web.server.protocol=https. For information about setting portal properties, see the "Advanced Portal Properties" section in Cisco WebEx Social Administration Guide.

Sample ACE Configuration

The following is a sample ACE configuration segment for SSL termination. This sample was built in a lab environment. Your configurations may vary depending upon your network environment.

 ssl-proxy service ssl-proxy
  key quadkey.pem
  cert quadcert2.pem
  policy-map multi-match client-vips
  class quad-vip
    loadbalance vip inservice
    loadbalance policy HTTP-WMB-REDIRECT
    appl-parameter http advanced-options long-header
  class https-quad-vip
    loadbalance vip inservice
    loadbalance policy L7_COOKIE
    loadbalance vip icmp-reply active
    appl-parameter http advanced-options long-header
    ssl-proxy server ssl-proxy
  class class-default

DMZ Design

Figure 4-3 shows an example DMZ deployment with load balancing and sample configurations. All SSL connections are terminated on the Cisco ACE. Your topology may vary depending upon your network environment.

Figure 4-3 DMZ Deployment Topology

In this figure, red connections represent SSL, and orange connections are clear.

The outside interfaces on the App Nodes are for web traffic only. The inside interfaces are required to allow all communications to the other WebEx Social nodes. The external firewall allows only the traffic that is required for a Cisco WebEx Social user, other traffic is denied. The inside firewall allows all traffic that is required for WebEx Social to function correctly. Other traffic is denied.

The following steps provide an overview of the requirements for deploying Cisco WebEx Social in a DMZ environment:

1. The inside (data center) and outside (DMZ) Cisco WebEx Social nodes must be on separate Layer 3 domains. Cisco recommends that you create three VLANs on a Layer 3 switch. One for the internal data center, one for the internal facing App Node interfaces, and one for the external facing App Node Interfaces.

2. Install and configure all nodes except the App Nodes within the data center as described in Cisco WebEx Social Installation and Upgrade Guide.

3. Install and configure the App Nodes within the DMZ. See Cisco WebEx Social Installation and Upgrade Guide.

4. Configure ACE with SSL terminating on the ACE. See the "Secure Load Balancer (SSL Termination)" procedure.

After completing these steps, all traffic from the inside interface of App Servers should go through the internal firewall. This traffic is controlled by source and destination IP addresses and ports and protocols that are used between the App Servers. ACLs must be written in a way to allow only the required traffic based on the ports as described "Port Usage." To integrate Secure Active Directory (SLDAP), WebEx Meeting Center, and WebEx (Cloud) Messenger with Cisco WebEx Social, the App Server must be able to communicate through the appropriate ports. Traffic from App Servers to the Internet should flow through some outbound traffic HTTP feed, such as a proxy or firewall.

A DMZ deployment requires the following:

Chain up SSL Certificate

Expand maxparse field to allow full package

Set up session as cookie sticky

Appendix B shows a sample lab ACE configuration.

Chain up the SSL certificate sample configuration

crypto chaingroup wxschain
  cert CiscoSSCA2.cer
  cert DSTRootCAX3.cer
ssl-proxy service WXS-SSL-PROXY
  key wxstme.key
  chaingroup wxschain

Expand maxparse field to allow full package sample configuration

parameter-map type http long-header
  header modify per-request
  set header-maxparse-length 65535

Set up session as cookie sticky sample configuration

sticky http-cookie wsxcookie STICKY-WXS-SF
  cookie insert browser-expire
  timeout 480
  replicate sticky
  serverfarm WXS-SF