HTTP profile farms

HTTP EDIT GLOBAL PARAMETERS

In this panel you’ll be able to set the parameters to improve your farms performance and your virtual service custom features for HTTP and HTTPS farms.

The vast majority of parameters that you’ll be able to configure in a HTTP/S farm, it will need a manual farm service restart in order to apply the changes, so a TIP message will be shown to alert the administrator that there are global parameters or backend changes that needs to restart the service through the icon before to be applied. The system administrator is able to modify whatever parameters are needed and then restart the farm service to apply all them at the same time.

Note that in the HTTP farms profile, the HTTP header X-Forwarded-For is included by default with the IP client address data.

By contrast with the TCP or UDP farms profile, the HTTP profile use a weight algorithm implicitly.

Additionally, every HTTP farm profile could manage several web services through the same HTTP farm, therefore one http virtual IP and port could handle more than one load balanced web service. For that reason, the “service” under a HTTP farm is a new concept in order to offer virtual host possibilities and then a list of backends will be shown for each service created.

The HTTP/HTTPS farm profile provides a distribution panel with the following parameters:

Farm’s name. It’s the identification field and a description for the virtual service. In order to change this item you’ve to modify the name field and press the Modify button. The load balancing service will be restarted automatically after applying this operation. Ensure that the new farm name is available, in another case an error message will appear.

Farm Virtual IP and Virtual Port. These are the virtual IP address and/or virtual port(s) in which the virtual service for the farm will be bound and listening in the load balancer system. To make changes in these fields, ensure that the new virtual IP and virtual port are not in use. In order to apply for HTTP and HTTPS, the farm needs to be restarted manually through the restart icon .

Backend connection timeout secs. This value indicates how long the farm is going to wait for a connection to the backend in seconds. Usually, it will be the socket opening time wait. By default, this value will be set to 20 seconds.

Backend response timeout secs. This value indicates how long the farm is going to wait for a response from the backends in seconds. By default, this value will be set to 45 seconds.

Frequency to check resurrected backends secs. This value in seconds is the period to get out a blacklisted real server and checks if is alive. The farm will be checking the backend periodically once the real server is marked as down, regardless of whether there is a new client connection or not. By default, this value will be set to 10 seconds.

Client request timeout. This value indicates how long the farm is going to wait for a client request in seconds. Once this timeout is reached without getting any data from the client, the connection will be closed. By default, this value will be set to 30 seconds.

Rewrite Location headers. If enabled, the farm is forced to modify the Location: and Content-location: headers in responses to clients. If they point to the backend itself or to the VIP (but with a different protocol) the response will be modified to show the virtual host in the request. If the option enabled and compare backends is selected then only the backend ip address is compared, this could be useful for redirecting a request to an HTTPS listener on the same server as the HTTP listener.

HTTP verbs accepted. This field indicates the operations that will be permitted to the HTTP client requests. If a not permitted verb is requested an error will be shown to the client.

Standard HTTP request. Accept only standard HTTP requests (GET, POST, HEAD).
+ extended HTTP request. Additionally allow extended HTTP requests (PUT, DELETE).
+ standard WebDAV verbs. Additionally allow standard WebDAV verbs (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
+ MS extensions WebDAV verbs. Additionally allow MS extensions WebDAV verbs (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
+ MS RPC extensions verbs. Additionally allow MS RPC extensions verbs (RPC_IN_DATA, RPC_OUT_DATA).
To apply any of these options, press the Modify Button and restart the farm service.

Farm listener. A listener defines how the farm is going to play with the requests from the clients. The listeners available are the following.

HTTP. This listener accepts only request in plain HTTP protocol from clients.
HTTPS. This listener accepts only request in secure HTTP protocol (HTTPS) from clients. This option will configure this farm to act as SSL offloading machine.

HTTPS Certificate. The SSL certificate is only available for HTTP farm profiles with HTTPS listener enabled, and a list of certificates will be shown to be selected for the current farm. This list could be modified under the Manage::Certificates section.

Ciphers. This field is used to build a list of ciphers accepted by SSL connections in order to harden the SSL connection. In order to make use of ciphers please select one of the following options.

ALL. This item indicates that all ciphers are allowed to be managed by the HTTPS listener. This is the default setting.
HIGH security / PCI compliance. This option set by default the ciphers “RC4-SHA” which they’ll be enough to passthrough a PCI compliance validation.
Custom security. This option allows to set your own allowed ciphers through the Customize your ciphers field.

Customize your ciphers. This is the allowed customized list of ciphers that will be accepted by the SSL connection, which it’s a string in the same format as in OpenSSL ciphers.

Add service. This field is used to add a new service through the same virtual IP and port, which specify how the requests from the clients are managed and delivered. It’s mandatory to insert at least one service in order to add backends to it. Once the services are inserted, the HTTP farm core will parse every service conditions in order to match the correspondant service in each client request. Those services conditions could be determined by URL patterns, specific headers or redirection and allows to identify several web services in through the same farm. Additionally, each service provide their own backends servers. Please refer to the Edit Service and Real Servers in order to get further information regarding the services options.

Personalized error messages. Through the personalized error messages, the farm service is able to answer a custom message of your site when a web code error is detected from the real servers. A personalized HTML page will be shown.

HTTP EDIT SERVICE AND REAL SERVERS

The services within a HTTP farm provides a content switching method to deliver several web services with different properties, backends or even persistence methods, through some deterministic conditions used by the farm core in order to match the correct service for every client request. This service definition will be used by the farm in order to determine the backends servers that could deliver the response to the client.

Every service will be tried by the HTTP farm core in priority mode and if none service is matched then the farm core will return an error. For this reason specific multiple service definitions are allowed. If no URL is defined then every request will match.

The HTTP service conditions will be determined by virtual host and/or url pattern. All of these will be explained with details below.

The service conditions and options for HTTP farms profile are shown below.

Virtual Host. This field specifies the condition determined by the domain name through the same virtual IP and port defined by a HTTP farm. In order to discard this condition just leave it empty.

Url pattern. This field allows to determine a web service regarding the URL the client is requesting through a specific URL pattern which will be syntactically checked. In order to discard this condition just leave it empty.

Redirect. This field behaves as a special backend, as the client request is answered by a redirect to a new URL automatically.

Persistence session. This parameter defines how the HTTP service is going to manage the client session and which HTTP connection field has to be controlled to maintain safe client sessions. When a type of persistence session is selected a persistence session TTL will appear.

No persistence. The farm service won’t control the client sessions and the HTTP or HTTPS requests will be free delivered to real servers.
IP – client address. The IP client address will be used to maintain the client sessions through the real servers.
BASIC – basic authentication. The HTTP basic authentication header will be used to control the client sessions.
For example, when a web page request a basic authentication to the client a HTTP header will contain a string like the following:

		HTTP/1.1 401 Authorization Required
		Server: HTTPd/1.0
		Date: Sat, 27 Nov 2011 10:18:15 GMT
		WWW-Authenticate: Basic realm="Secure Area"
		Content-Type: text/html
		Content-Length: 31

Then the client answer with the header:

GET /private/index.html HTTP/1.1
		Host: localhost
		Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

This basic authentication string is used like an ID for the session to identify the client session.

URL – a request parameter. When the session ID is sent through a GET parameter with the URL will be possible to use this option indicating the parameter name associated with the client session ID. For example, a client request like ” http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 ” has be configured as shown below:

In order to configure the URL session persistence, you’ve to select this option in the Persistence Session field and then press the Modify Button. Later, two new fields will be shown:

Persistence session time to live (TTL). This value indicates the max time of life for an inactive client session (max session age) in seconds.
Persistence session identifier. This field is the URL parameter name that will be analyzed by the farm service and will manage the client session.

PARM – a URI parameter. Another way to identify a client session is done through a URI parameter. This is a field separated by a semicolon like the following ” http://www.example.com/private.php;EFD4Y7 “

In order to configure this kind of persistence will be sufficient to select the PARM option and press the Modify Button.

COOKIE – a certain cookie. Also, you’ll be able to select a http cookie variable to maintain the client session through the COOKIE option. A cookie has to be created by the programmer into the webpage to identify the client session, for example:

With this specification, the following configuration will be needed:

After configuring this items and pressed the Modify Button on all of them, it’s needed to restart the farm service to apply the changes.

HEADER – a certain request header. A HTTP header custom field could be used to identify the client session. For example:

With this specification, the following configuration will be needed:

After configuring this items and pressed the Modify Button on all of them, it’s needed to restart the farm service to apply the changes.

HTTPS Backends. This checkbox indicates to the farm that the backends servers defined in the current service are using the HTTPS language and then the data will be encrypted before to be sent.

Use farmguardian to check backend servers. Checking this box will enable a more advanced monitoring state for backends and totally personalized for your own scripts for the current service. When a problem is detected by farmguardian automatically disables the real server and will be marked as blacklisted. This is an independent service so you don’t have need to restart the farm. A farmguardian server will be launched per HTTP services defined in the farm, if this option is enabled. To get more details about this service, please read the FarmGuardian section.

Once a new farm is created, you’ve to include the servers within at least one http service in order to deliver the client connections.

Under the real IP servers table configuration you’ll be able to include the backends for every service and their specific parameters.

The options available in this case are:

Server. It’s an automatic ID established to be an index for the real server. The system administrator can’t change this value.
Address. It’s the real server IP address.
Port. It’s the real server port in which the backend service is listening on.
Timeout. It’s the backend timeout to respond a certain request.
Weight. It’s the backend weight assigned in order to deliver connections according to a weighted algorithm.

With the Save Real Server button you’ll apply the new configuration, or you’ll be able to cancel the process through the button. A message with the result will be displayed.

Once the real server configuration is entered, you’ll be able to edit the config throught the Edit button, delete the configuration with the Delete Real Server button, enable the maintenance mode for the backend in order to stop sending requests to the current server or disable the maintenance mode for the current backend in order to start again to send requests to the seleted server.

The server index is useful to identify the real server configuration for the current farm.

The changes of the real servers configuration for HTTP farms require a manual restart.

HTTP VIEW STATUS

This action shows the actual state of backends, clients and connections that are being delivered from the virtual service to the real servers.

Refresh stats option will allow to refresh the status view every 10, 30, 60 or 120 seconds. It must be used with caution as this feature could overload the load balancer.

The Real Server Status table shows the state of every backend:

Service. It’s the http service name where the backend is serving the application.
Server. It’s the backend identification number within the service if defined.
Address. It’s the real server IP address.
Port. It’s the port number where the real service of the current real server is listening on.
Status. A red dot means that the current real server is down or blacklisted (it could be due to a connection error or due to farmguardian advanced checking), meanwhile a green dot means that the backend is online and delivering connections. A yellow dot means that the backend is in maintenance mode.
Pending Conns. This is the number of pending connections in the system that are on SYN state for the current backend, indepently of farm service.
Established Conns. This is the number of established connections in the system that are on ESTABLISHED state for the current backend, indepently of farm service.
Closed Conns. This is the number of closed connections in the system that are on TIME_WAIT state for the current backend, indepently of farm service.
Weight. It’s the weight value established for every backend.

In order to analyze with details the clients, sessions and connections to the backends, you’ve to expand the Client sessions status or Active connections tables to show all this information pressing the Maximize button.

Service. It’s the http service name where the backend is serving the application.
Client. It’s the client IP address.
Session ID. It’s the session identification for the persistence.
Server. It’s the backend identification number within the service if defined.

Note that for very high load farms showing this table could slowdown the machine and could be shown a very large table.