2. Load balancing


Prev	Chapter 4. Application Delivery Controller (ADC)	Next

2.1. Real web servers

Real server protocol Drop down list	HTTP or HTTPS Valid input Options from the drop down list `HTTP` or `HTTPS` HTTPS is only available if website virtual host is SSL-enabled. Default value The protocol initially set when the website proxy was created.
Real host Input field	Hostname or IP address of the web-server(s) Web Security Manager is proxying requests for. Valid input Fully qualified hostname (FQDN) or IP address. Input example `web1.mycompany.com` `10.10.10.10` Default value `<none>`
Port Input	The port number the real server is listening to. Valid input A valid TCP/IP Port number Default value `80`
Role Drop down list	Define the servers role in the load balancing set. Active The server is operative and accepts requests. Backup The server is operative but should only be sent requests if none of the other servers in the load balancing set are available. Down The server is nor operative and will not respond to requests.
Status Read only	The status of the real server. enabled or disabled.
X (delete) Button	Mark the real server for deletion. The server will not be deleted until the button Save settings in the lower button bar is activated.

2.2. Timeouts

Real server CONNECT timeout (seconds) Input field	Max time to wait for connection to the backend web server to succeed. Unit Seconds Valid input Number in range 2 - 7200 Default value `10`
Real server SEND timeout Input field	Max time to wait for sending request to backend web server to complete. Unit Seconds Valid input Number in range 2 - 7200 Default value `60`
Real server READ timeout input field	Max time to wait for reading response from backend web server. Unit Seconds Valid input Number in range 2 - 7200 Default value `60`

2.3. Load balancing settings

The load balancing settings control the behaviour of the Load Balancer.

Web Security Manager COOKIE based session persistence Check box	When checked Web Security Manager will issue a cookie when a user first connects to the virtual host being proxied / load balanced. The cookie binds the session to the real server selected by the load balancer ensuring that the users session with the real server is not broken. This method requires that visitors have support for cookies enabled in their browser. Despite the name this feature works equally well with HTTPS and HTTP.
HEADER based session persistence Check box	When checked Web Security Manager will bind the user session to the real server based on a hash of a selected client request header.
Header Input field	The header to use for calculating load balancing hash when header based session persistence is selected. Valid input An HTTP-header sent by the client. Default value User-Agent
SOURCE IP based session persistence Check box	When checked Web Security Manager will bind the user session to the real server based on the visitors source IP. This method ensures that requests from visitors with cookie support disabled will be sent to the same server every time. To compensate for visitors changing IP address during the session (for instance because their requests are sent through different forward proxies) a mask is applied to the users source address (below). Applying a mask ensures that even if the users IP address changes the same server is selected.
IP mask: Drop down list	The mask to be applied to the visitors source ip address when calculating destination real server based on source hashing. The mask and resulting number of IP addresses within each "load balancing address chunk" is displayed in the drop down. Valid input Options from the drop down list Default value 255.255.240.000 (4,096 hosts)
Enable real server failover Check box	When checked Web Security Manager will attempt to redirect a request to another real server in case the real server to which the session is bound fails. Disabling real server failover only is effective when session persistence is enabled. If real server failover is disabled the user will receive an error message and the session will have to be restarted (usually by closing and restarting the browser).
Max real server failover attempts Input field	Maximum failover attempts in case a real server fails. This value defines how many times Web Security Manager should try other real servers in case a real server fails. Valid input Number in range 1 - (number of real servers -1) Input example `1` Default value `1`
Real server retry interval (seconds) Input field	Specifies for how long a failed real server should be kept in error state before trying to connect again. Valid input Number in range 1 - Input example `20` Default value `60`

2.4. Health Checking

Health checking checks the real (backend) servers for errors and availability. If a server is not responding correctly (as configured) it is disabled until it responds correctly again.

Enable real server health checking

Check box

Enable / disable health checking

Default: <disabled>

Request interval

Input field

How often the health check daemon should check the server.

Valid input: Number in range 10 - 60
Default value: 10

Request timeout

input field

Max time to wait for real server to respond before marking the attempt as failed.

Valid input: Number in range 1 - 30
Default value: 2

Error threshold

Input field

Specifies how many failed health checks should be recorded before the server is disabled.

Valid input: Number in range 1 - 10
Default value: 3

Request method

drop-down list

What method should be used for health checking.

Valid input: HEAD or GET
Default value: HEAD

The HEAD method only checks the server response code. If the server returns 200 OK within the configured timeout the request is a success.

The GET method validates the page the server returns using a checksum. If the content of the page has changed (compared to the stored checksum) the request is marked as failed.

	Note
	If the request method is GET and the content of the requested resource is changed on all servers, all servers will be disabled as they will fail the checksum check. be sure to run a checksum re-generation immediately after such an update.

Request

Input field

The resource to request when health checking.

Valid input

A string starting with / specifying an application, static page, graphic or other content on the web server.

Input example

/testpage.php

/index.aspx?showpage=999999

/graphics/1x1.gif

Default value

<none>

Force checksum re-generation

Check box

When request method GET is selected, when settings are saved Web Security Manager request the configured resource on all real servers to calculate a checksum which will be stored for further health checking. If the checksum is not the same on all servers Web Security Manager will return an error and the new settings will not be saved.

The checksum is only generated when things change, like when a new Request is configured or method is changed to GET.

There can be situations though where it is desirable to have the checksum re-generated, for instance if the content of the request page has changed.

If this option is checked the checksum will be re-generated.

Default: <disabled>

2.5. Insert request headers

These settings allows for inserting new headers with either a static value or with the value of different request variables.

Enable insert request headers Check box	Enable/disable request headers insert. Default: <disabled>
Header Input field	The name of the request header to insert Valid input Alphanumeric and - Input example `Foo-Bar` `Client-IP` Default value `<none>`
Value type Drop down	Specify the type of input entered in the value field. variable Specifies that the string entered in the value value field is to be interpreted as the name of a request variable, the value of which will be inserted in the request with the header name specified. literal Specifies that the string entered in the value field is to be inserted "as is". So if "foo" is entered the value "foo" will be inserted.
Value Input field	The value to insert in the new header field. Can be literal or variable. Valid input If literal selected: alphanumeric, space, dash, underscore, space and comma. If variable selected: See list below. Input example `remote_addr` - the IP address of the client Default value `<none>`

2.5.1. Request header variables

The variables below can be inserted in a header and forwarded to the backend server.

args: This variable is the GET parameters in request line, e.g. foo=123&bar=blahblah.
cookie_COOKIE: The value of the cookie COOKIE, e.g. to forward the value of the cookie SESSID enter cookie_SESSID or cookie_sessid as match is case insensitive.
hostname: Set to the hostname of the Web Security Manager node.
http_HEADER: The value of the HTTP header HEADER when converted to lowercase and with dashes converted to underscores, e.g. User-Agent = http_user_agent, Referer = http_referer...
remote_addr: The IP address of the client.
remote_port: The port of the client.
request_method: The method of request, usually GET or POST.
request_uri: The original request URI as received from the client including the args.
scheme: The HTTP scheme (i.e. http, https).
server_name: The virtual host server name of the website proxy handling the request(i.e. www.alertlogic.com).
server_port: The port of the server, to which the request arrived.
server_protocol: The protocol of the request, e.g. HTTP/1.0 or HTTP/1.1.
uri: The URI in the request without arguments, those are in the variable args.

2.6. Advanced settings

These settings specify request time out, keep alive behavior. Also web application behavior is specified here.

Add HTTP/1.1 VIA header information

Check box

Enable/disable support for HTTP/1.1 VIA header sending information.

Íf enabled, Web Security Manager will append the Via header in each forwarded request indicating to the backend server that the request if coming through a proxy server.

Default: <disabled>

Proxy buffering enable

Check box

Proxy buffering.

By default Web Security Manager buffers the response from the backend web server in order for the web server to be able to deliver the request as fast as possible no matter how slow the connection to the client is. This ensures that server resources will not be consumed by clients on slow connections.

However, some applications are known to have problems with this behaviour, Comet applications for instance.

To account for such problems disable proxy buffering.

Default: <enabled>

Upstream SSL session reuse enable

Check box

SSL session reuse to backend servers.

When Web Security Manager connects to a backend server over SSL, the server creates a session for that connection. This session ID is sent as a part of the backend Server Hello message. To make things efficient Web Security Manager can behave as a normal HTTP client (a browser) and reuse that session ID next time it connects to the backend server. Thus the time spent in verifying the certificates and negotiating the keys is saved.

If the backend web server is configured to not support SSL session reuse pages will not load or not load correctly - typically stylesheets, images, javascript files, etc will not load.

To account for such problems disable upstream SSL session reuse

Default: <enabled>

2.7. Lower button panel

Save settings

Click Save settings to save settings.

Prev	Up	Next
1. Virtual host	Home	3. Caching