LSLB | Farms | Update | HTTP Profile

  • Blog
  • LSLB | Farms | Update | HTTP Profile

Knowledge Base

Scaling Site Reliability Knowledge

LSLB | Farms | Update | HTTP Profile

Table of Contents

Global Settings for HTTP Farm Profile #

This profile manages content switching at layer-7 application delivery for both HTTP and HTTPS protocols.

The Farm Status is represented using color indicators as described below:

  • Green: Means UP. The farm is running and all backends are UP or the redirect is configured.
  • Red: Means DOWN. The farm is stopped.
  • Black: Indicates a CRITICAL damage. The farm is UP but there is no backend available or they are in maintenance mode.
  • Blue: Means there is a PROBLEM. The farm is running but at least one backend is down.
  • Orange: Means MAINTENANCE. The farm is running but at least one backend is in maintenance mode.

Those color codes are the same all over the graphical user interface. Find a concise explanation about these colors in the LSLB Farm Section.

In the HTTP(S) farms profile, the HTTP header X-Forwarded-For is filled by default with the client IP address.

Each HTTP(S) farm (or virtual service) manages several services like a reverse proxy, therefore one HTTP virtual IP and port pair can handle more than one load-balanced web service. Therefore, there is a section called service under an HTTP farm to offer virtual host flexibility and allow the creation of a list of backends for each service.

Each HTTP(S) service uses a combination of regular expressions (for virtual host and URL pattern) in PCRE to manage all the incoming connections whose HTTP header matches both.

Basic configuration #

The following are the basic parameters for the HTTP/S farm profile.

Name. This is a name that easily identifies a farm. To change a name of a given farm, you have to stop it first. Ensure that a new name is not already in use.

Virtual IP and Port. These are the virtual IP addresses and port pairs from which the farm will listen for incoming connections. The new IP address and port combination must be unused and available before being configured.

Listener. This field specifies the protocol to be managed at layer-7 for content switching.

  • HTTP. The virtual service will only understand plain HTTP content.
  • HTTPS. The virtual service will understand Secure HTTP content, manage SSL handshakes, handle secure cipher configurations, SSL certificates (wildcard or SNI), etc, to perform SSL offload and relieve the real application servers from these heavy tasks.

HTTPS Parameters #

HTTPS Parameters can be found below.

HTTPS Parameters

Disable SSLV2, Disable SSLV3, Disable TLSV1, Disable TLSV1.1, Disable TLSV1.2 selectable buttons if selected, avoid using those given protocols. Once a protocol is disabled, its ciphers will also be disabled.

Ciphers. This field is used to build a list of ciphers accepted by SSL connections to harden that connection. Before a client and server can begin to exchange information protected by TLS, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data.

To configure a cipher for use, 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. This command enables the following ciphers: 
    kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

    Which they’ll be enough to pass through an A+ in SSL Labs .

  • Custom security. This command allows setting your own allowed ciphers through the Custom ciphers field.
  • Custom ciphers. This allows you to customize which ciphers will be allowed or forbidden to be used by the SSL connection. It must be a string in the same format as in OpenSSL ciphers . This command will be displayed if Custom security is set.

Available certificates. These are the available SSL certificates installed on the device. To enable one of them, either select the certificate and click the arrow button or simply drag and drop it from the Available box to the Enabled box. You can also enable/disable multiple certificates or even all of them.

Enabled certificates. In this list, you will manage the certificates that are currently in use by the farm. You may move them to the top or bottom with the double top/down arrows or even disable all of them. Take into account the order of the certificates. In case you configure a wildcard certificate before a host certificate, then the wildcard will be used first.

Advanced settings #

Rewrite Location headers. If enabled, the farm is forced to modify the Location and Content-location headers in response to the clients. If they have the value of the backend itself or the VIP but with a different protocol, the response will be modified to show the virtual host in the request. If the toggle button, enabled and compare backends is enabled, only the backend IP address will be compared. This is essential in redirecting a request to an HTTPS listener on the same server as the HTTP listener. If this field is configured in the service section, then this directive will be ignored for that service.

HTTP verbs accepted. This field indicates the HTTP methods that will be used to validate HTTP client requests. If the client request is not allowed, an error will be shown to the client. Each verb has additional lower levels of verbs.

  • Standard HTTP request. Standard HTTP requests (GET, POST, HEAD).
  • + extended HTTP request. extended HTTP requests (PUT, DELETE).
  • + options HTTP verb. extended HTTP requests (PUT, DELETE).
  • + standard WebDAV verbs. standard WebDAV verbs (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
  • + MS extensions WebDAV verbs. MS extensions WebDAV verbs (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
  • + MS RPC extensions verbs. MS RPC extensions verbs (RPC_IN_DATA, RPC_OUT_DATA).

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

Frequency to check resurrected backends. This is how often the load balancer will wait to check if a backend is reachable and to get out a blacklisted real server if it is up. 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.

Backend response timeout. This value indicates the time the farm will have to wait for a response from the backends in seconds. By default, this value will be set to 45 seconds.

Client request timeout. This value indicates the time the farm will have to wait for a client request. Once this timeout is reached without getting any data from the client, the connection will get terminated. By default, this value will be set to 30 seconds.

HTTP error messages #

Personalized error messages. The farm service will display a custom message on your site when a web code error is detected from the real servers. A personalized HTML page will be shown for error codes 414, 500, 501, and 503.

  • 414: Request-URI Too Long. This is the error message by the HTTP/S profile if the URI reaches the maximum number of characters allowed. If you receive this error, reduce the length of the URL.
  • 500: Internal Server Error. This is the error message by the HTTP/S profile if the backend encounters an unexpected command
  • 501: Not Implemented. This is the error message by the HTTP/S profile if the request verb isn’t managed or known by the proxy or backend.
  • 503: Service Unavailable. This is the error message by the HTTP/S profile if the proxy doesn’t find an available backend for the request. This might happen when all backends or servers are down, or because the regular expression in the request doesn’t match with any configured service.
  • WAF 403: Forbidden. This is the error message by the HTTP/S profile if the WAF is enabled and the WAF engine rejects the request.

Headers #

In this section, we can add, modify or delete requests and response headers globally, applying actions to all the configured services. If a header is configured in the service section, that configuration will be discarded.

The actions to use in this section include:

Create rule. A global header will be created.
Delete. A global header will be deleted.

This section allows us to add, modify or create Header requests and responses as shown in the image below.

Type.

  • Request: remove header. Header pattern that will be removed from the client HTTP requests.
  • Request: modify header. Modify the header from the client HTTP requests.
  • Request: add header. The header that will be added to the client HTTP requests.
  • Response: remove header. Header pattern that will be removed from the Backend HTTP response.
  • Response: modify header. Modify the header from the Backend HTTP response.
  • Response: add header. The header that will be added to the Backend HTTP response.

Services Settings #

The services within an LSLB farm with an HTTP profile provide content-switching capabilities for web virtual services to deliver multiple web services and applications through the same virtual IP and PORT. This helps to unify web applications through a single domain, manage virtual hosts, manage URLs, configure redirects, configure persistence and backends per service. Each service within an LSLB farm has different properties, health checks, persistence, Header management, and a backend list. Regular expressions may be used to match conditions that will specify the service to be used per request.

Each service match condition will be checked by the HTTP farm profile core in priority mode (that can be altered if needed). If no service is matched then the farm core will return an error (HTTP error 503). For this reason, specific multiple-service definitions are allowed. If URL and Host’s fields are not defined, all requests will match. The HTTP service conditions will be determined by a virtual host and/or a URL pattern.

First, it is required that you create at least one service to add a backend. Once the new service is applied, the HTTP services will be evaluated from top to bottom in the list order. The first service to match in Host and/or URL field will process the request. Those service conditions are determined by URL or Host patterns.

The service conditions to be matched are:

Virtual Host. This field specifies the condition determined by the domain name through the same virtual IP and port defined by an HTTP farm. To discard this condition, leave it empty. This field supports regular expressions in PCRE format.

URL pattern. This field determines a web service by the URL the client is requesting through. This URL will be checked using a specific URL pattern which will be syntactically checked. To discard this condition, leave it empty. This field supports regular expressions in PCRE format.

The Virtual Host and URL pattern values are regular expressions. If left empty, any value will match. Both fields must match or it’ll skip to the next service. It is recommended to use at least one, serving as the default if there is no match detected at the bottom.

Rewrite Location headers. If enabled, the service is forced to modify the Location and Content-location headers in response to the clients. If they have the value of the backend itself or the VIP (but with a different protocol) the response will be modified to show the virtual host in the request. If the toggle button enabled and compare backends is enabled, then only the backend IP address is compared. This is essential when redirecting requests to an HTTPS listener on the same server as the HTTP listener. When enable and compare backends is selected, a flag called Enable path for Rewrite location Headers will be available. Enable this flag if you are working with Rewrite URLs. This value will force you to check the URL responses and will change the response to the original if a rule is configured in Rewrite URLs. If this field is enabled, it will override the same directive in the global section.

Load balancing scheduler. This field specifies the load balancing algorithm to be used for determining the backend server. By default, the weight algorithm will be the default selected algorithm.

  • Weight: connection linear dispatching by weight. Balances the connections depending on the weight value that has been assigned to each backend. The requests are delivered using a probabilistic algorithm using the defined weight.
  • Least Response: dynamic weight according to the backend response. Dynamically rescaling of the backend weight in response to the performance times from the backends. Faster response times result in increased connections to these actual servers.

Redirect #

If the service has the redirect option enabled, backend servers may not be used as all the requests will be sent to the specified URL.

Redirect Type. There are two redirect types: Default and Append. With the Default type, the URL is taken as an absolute host and path to redirect to. With the Append type, the original request path will be appended to the host and the path you specified.

Redirect URL. This parameter controls where the client will be redirected after a request is answered. The client request is answered automatically by redirecting to a new URL. If you configure a redirect value, DON’T configure backends in this service. If the Virtual Host and the URL pattern match, the appliance will send an HTTP Location Header response to the client in order to be redirected to the configured URL.

Redirect Code. Several redirect HTTP codes could be used: 301 (Moved Permanently), 302 (Moved Temporarily), or 307 (Temporary Redirect).

Persistence #

Persistence. This parameter defines how the HTTP service will manage the client session and which HTTP connection has to be controlled to maintain safe client sessions. When a type of persistence session is selected, its Time To Live TTL(seconds) will be shown.

  • No persistence. The farm service won’t control the client sessions. The HTTP or HTTPS requests will be delivered to real servers.
  • IP: Client address. The client IP address will be used to keep the client sessions open 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 requests a basic authentication from the client, an 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 as an ID for the session to identify the client session.

  • PARM: A URI parameter. Another way to identify a client session is through a URI parameter separated from a semicolon character that is used as a user session identifier. In the example http://www.example.com/private.php;EFD4Y7 the parameter will be used as the session identifier.
  • URL: A request parameter. When the session ID is sent through a GET parameter with the URL, this parameter indicates that the name associated with the client session ID will be possible. For example, a client request like http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 should be configured with the parameter Persistence Session Identifier (sid value in this example) and the persistence session time to life (TTL)
  • COOKIE: . You’ will be able to select an HTTP cookie variable to read from the HTTP Headers and use it to maintain client sessions for a given time. The configured cookie name in the persistence session identifier field is created by a programmer and embedded into a webpage to identify the client session, for example: 
                    GET /spec.html HTTP/1.1
                Host: www.example.org
                Cookie: sessionidexample=75HRSd4356SDBfrte

    Additionally, Persistence session Time To Life(TTL) should be configured. This value manages the time that the load balancer saves when the client and the backend go without any activity.

  • HEADER: a request header. An HTTP header custom field could be used to identify the client session. The persistence session time to life and persistence session identifier is required to be configured. For example: 
                   GET /index.html HTTP/1.1
               Host: www.example.org
               X-sess: 75HRSd4356SDBfrte

Farmguardian #

HTTP farms provide a basic and native backend health check but the Farmguardian configuration is recommended for smarter heuristics backend health checks to ensure that the application is healthy.

Some built-in or customized advanced health checks can be assigned to this service from the already created farmguardian checks.

For further Farmguardian information go to the Monitoring >> Farmguardian section.

Notice that after selecting the farmguardian, it will be automatically applied to the farm.

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

Backends #

Regarding the Backends, the HTTP farm profile allows the configuration of the following properties: All the backends must be IPv4 or IPv6, and with the same IP version as the Farm VIP.

ACTIONS. Use the following actions to manage the backends:
For already created backends:

  • Enable Maintenance. Use this action if the backend was previously disabled. Placing a real server in maintenance mode means that no new connections will be redirected to it. There are two methods for enabling the maintenance mode:
    • Drain Mode. Keeps established connections and persistence if enabled, but will not admit new connections.
    • Cut Mode. Drops all active connections against the backend
  • Disable Maintenance. Use this action when the backend is in maintenance mode. Enable new connections to the real server again after disabling maintenance mode.
  • Delete. Remove configurations of a selected virtual service.

IP. The IP address of a given backend.
PORT. The port number of the current real server.
TIMEOUT. The time a backend takes to respond. This value overrides the parameter of the global Backend connection timeout but it is limited to this selected farm.
WEIGHT. The weight value for the current real server. More weight indicates more connections delivered to the current backend. By default, a weight value of 1 will be set. The values range available is from 1 to 9.
PRIORITY. The priority value for the current real server (accepted values are 1 or 2). Lower values have more priority and the default value is 1, so the backend will be used anytime it is available. If all backends with priority 1 are down or in maintenance, the backend with priority 2 is enabled to maintain the service available. Only one backend with priority 2 is allowed currently.

You will be able to configure the same parameters as described before, and then click the Save button to create the backend.

Through the Actions menu button, the following actions are available for one or more selected backends:
Add Backend. This command opens the backend creation form.
The actions mentioned above: Enable maintenance (Drain and Cut mode), Disable maintenance and Delete.

Add backend form:

Extras #

Check out our video to know how easy is to configure an HTTPS redirection with Relianoid.

SHARE ON:

Powered by BetterDocs