CARACTERISTICAS DE DISPERSION

This chapter describes HTTP load balancing and how to configure it.

Overview

HTTP load balancing manages HTTP traffic across a Web server farm.

Figure 32 shows an example of an HTTP load balancing deployment.

Note: The network topologies in application examples such as this one are sim-plified to focus on the application. For example, the Internet router con-necting the clients to the AX device is not shown here. Likewise, a single AX is shown. Your configuration might use an AX pair for High Avail-ability (HA).

FIGURE 32 HTTP Load Balancing

In this example, a server farm consisting of three servers provides content for Web site www.example.com. Clients access the site through its virtual IP address, 192.168.10.11. When the AX device receives a client request for the HTTP port (80) on 192.168.10.11, the AX device selects a real server and sends the client request to the server.

For simplicity in this example, the real servers use the default protocol port number for HTTP (80). The port numbers on the real and virtual servers are not required to match.

The client is unaware of the real IP address of the real server, nor is the cli-ent aware that the site actually consists of multiple servers. After selecting a real server, the AX device automatically performs the necessary Network Address Translation (NAT) to send the client request to the server, receive the reply from the server, and send the reply to the client. From the client’s perspective, the Web session is between the client and port 80 on 192.168.10.11.

S

G

A service group contains a set of real servers from which the AX device can select to service a client request.

This example uses a single service group that contains all the real servers and the applicable service port (80). During configuration, you bind the ser-vice group to the virtual port(s) on the virtual server.

The AX device selects a server based on the load balancing method used by the service group, and on additional criteria relevant to the load balancing method.

In this example, the default load balancing method, round robin, is used.

The round robin method selects servers in rotation. For example, the first client request is sent to server web-2, the next client request is sent to server web-3, and so on.

V

S

The virtual server in this example has IP address 192.168.10.11 and virtual service port 80. When you configure a virtual service port, you specify the protocol port number for the port. You also specify the service type. The AX device supports the following service types for HTTP ports:

• HTTP – Complete TCP stack. Use this service type if you plan to cus-tomize any templates. For example, if you plan to use SSL (HTTPS load balancing or SSL offload), or customize the HTTP template to change information in the HTTP headers of server replies, use the HTTP service

type. Also use this service type for stream-based applications such as RAM Caching and compression.

• Fast-HTTP – Streamlined hybrid stack for high performance. If you do not plan to offload SSL or customize any templates, use Fast-HTTP.

(For a complete list of the service types, see “Virtual Service Port Parame-ters” on page 877.)

T

Templates are sets of configuration parameters that apply to specific service types or to servers and service ports. This example uses the default settings for each of the templates that are automatically applied to the HTTP service type and to the real and virtual servers and ports. The rest of the information in this section is for reference but is not required reading to continue with this example.

For some of types of templates, the AX configuration has a “default” tem-plate that is automatically applied to a service port unless you apply another template of the same type instead. (See “Service Template Parameters” on page 819.)

Service Templates

For HTTP, the AX configuration applies “default” templates of each of the following template types to HTTP service ports:

• TCP-Proxy – TCP-proxy templates control TCP stack settings, includ-ing the idle timeout for TCP connections. Unless you need to change the setting for a TCP/IP stack parameter, you can safely allow the AX device to apply the default TCP-proxy template to the service types that use it.

• HTTP – HTTP templates provide many options, including options to change information in the HTTP header, enable compression, and select a service group based on the URL requested by the client. By default, all the options in this template are disabled or not set, so you can safely allow the AX device to apply the default for this template type too.

• Connection Reuse – Allows TCP connections between the AX device and real servers to be reused for multiple clients instead of terminating a connection and starting a new one for each new client. Although the default connection reuse template is automatically applied, the default settings in the template disable connection reuse. Unless you want to use connection reuse, you can ignore this template. (Connection reuse requires additional configuration. See “Connection Reuse” on page 609.)

The following types of templates also can be used with HTTP service ports.

However, these types of templates do not have “default” templates that are applied automatically.

• Cookie Persistence – Inserts a cookie in the HTTP header of a server reply before sending the reply to the client. The cookie ensures that sub-sequent requests from the client for the same virtual server and virtual port are directed to the same service group, real server, or real service port.

• Source-IP Persistence – Similar to cookie persistence, except the AX device does not insert cookies. Instead, clients are directed to the same resource in the server farm for every request, for the duration of a con-figurable timer on the AX device. The granularity of the persistence can be set to always use the same real server port, the same real server, or the same service group.

(For an example that uses a source-IP persistence template, see “Layer 4 TCP/UDP Load Balancing” on page 255.)

Server and Port Templates

The AX device uses templates for configuration of some commonly used server and port parameters. By default, the following templates are applied:

• Default server template – Contains configuration parameters for real servers

• Default port template – Contains configuration parameters for real ser-vice ports

• Default virtual-server template – Contains configuration parameters for virtual servers

• Default virtual-port template – Contains configuration parameters for virtual service ports

Each of the default templates is named “default”.

For more information about server and port templates, see the following:

• “Server and Port Templates” on page 353 in this guide

• “Config Commands: SLB Templates” chapter in the AX Series CLI Ref-erence

• “Config > Service > SLB > Template” section in the “Config Mode”

chapter of the AX Series GUI Reference

H

M

This example uses the following types of health monitors to check the real servers:

• Ping – A Layer 3 health method that sends an ICMP echo request to the real server’s IP address. The server passes the health check if the AX device receives a ping reply.

• TCP – By default, every 30 seconds the AX device sends a connection request (TCP SYN) to each load balanced TCP port on each server, in this case ports 80 and 443. A TCP port passes the health check if the server replies to the AX device by sending a TCP SYN ACK. By default, the AX device completes the TCP handshake.

In addition to these default health checks, you can configure health monitors for specific service types. This example uses an HTTP health monitor, with the following default settings.

• Every 30 seconds, the AX device sends an HTTP GET request for the default index page.

• The HTTP service port passes the health check if the requested page is present on the server and the server replies with an OK message (200).

(For more information about health monitors and their configurable options, see “Health Monitoring” on page 373.)