• No results found

Load balancing settings

Reset X-Forwarded- For header to last

2. Load balancing

2.3. Load balancing settings

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

When checked Web Security Manager will issue a cookie when a user first connects to the virtual host being proxied / load balanced.

Web Security Man- ager COOKIE based session persistence

Check box

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 en- abled in their browser.

Despite the name this feature works equally well with HTTPS and HTTP. 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 based ses- sion persistence

Check box

The header to use for calculating load balancing hash when header based session persistence is selected.

Header

Input field

Valid input

An HTTP-header sent by the client. Default value

User-Agent

When checked Web Security Manager will bind the user session to the real server based on the visitors source IP.

SOURCE IP based session persistence

Check box 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.

The mask to be applied to the visitors source ip address when calculating destination real server based on source hashing.

IP mask:

Drop down list

The mask and resulting number of IP addresses within each "load bal- ancing 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)

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.

Enable real server failover

Check box

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 restart- ing the browser).

Maximum failover attempts in case a real server fails.

Max real server fail- over attempts

Input field

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

Specifies for how long a failed real server should be kept in error state before trying to connect again.

Real server retry in- terval (seconds)

Input field 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 re- sponding correctly (as configured) it is disabled until it responds correctly again.

Enable / disable health checking

Enable real server health checking

Check box

Default: <disabled>

How often the health check daemon should check the server.

Request interval

Input field Valid input

Number in range 10 - 60 Default value

10

Max time to wait for real server to respond before marking the attempt as failed. Request timeout input field Valid input Number in range 1 - 30 Default value 2

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

Error threshold

Valid input

Number in range 1 - 10 Default value

3

What method should be used for health checking.

Request method

drop-down list 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 check- sum. 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.

The resource to request when health checking.

Request

Input field 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>

When request method GET is selected, when settings are saved Web Security Manager request the configured resource on all real servers

Force checksum re- generation

Check box 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 check- sum 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>