6.2 Understanding SLB
6.2.1 SLB Methods
The FortiBalancer appliance allows several methods of load balancing. We will briefly discuss certain methods below and situations where you would want to use them. Later in the chapter we will go over and setup each metric in detail.
Table 6-1 SLB Methods
| SLB Methods | Description |
| Round Robin (rr) | If we have three servers in Group 1with two in Group 2, and chose round robin as our metric, each request would follow the real servers in order [1,2,3, 1, 2, 3…] for Group 1 and [4,5, 4, 5…] for Group 2. |
| Least Connections
(lc) |
This metric tells SLB to select the real server with the fewest number of active connections. |
| Shortest Response
(sr) |
The server with the shortest response time will get the next request. Using this metric you can intermix fast servers with slow servers and the fast servers will get more hits initially. As load increases, and response time increases and the slower servers will start to field more requests. |
| Persistent IP (pi) | This metric ties the source IP of the request to the real server processing the request. An example application for this metric is when doing e-commerce transactions and a specific server needs to maintain state about the client’s transaction. Keep in mind that if a large ISP deploys a
Mega-Proxy, one real server could service thousands of requests. (A Mega-Proxy is used to proxy all client requests from a single IP.) |
| Persistent Cookie (pc) | Persistent cookie is used to associate a cookie name/value pair with a single real server on your backend. When setting up cookie based policies keep in mind that you need a default policy for requests that do not have |
| SLB Methods | Description |
| cookies in the HTTP header. | |
| Insert Cookie (ic) | Dynamically inserts cookies to allow the OS to maintain persistence to a server. |
| Rewrite Cookie (rc) | Rewrite Cookie rewrites server side cookies on the fly thereby allowing the backend servers to maintain persistence to a client. |
| Proximity (prox) | This method is based on SDNS proximity info and used by redirect policy only. It directs SLB to select the real server, which has lowest proximity distance with the request IP. |
| SNMP (snmp) | This method is based on the real server’s SNMP (Simple Network Management Protocol) MIB information regarding the server’s status and availability, e.g. the server’s CPU status and memory usage. |
| Embed Cookie (ec) | It embeds some information in the server side cookies, allowing the backend servers to maintain persistence to a client. |
| Hash Query (hq) | It keeps the persistence of the session by hashing the specified tag value in the query of HTTP requests, and must work with persistent url policy. |
Additional Load Balancing methods include: Persistent URL (pu), Persistent Hostname (ph), Hash
Cookie (hc), Hash Header (hh), SSL SID (sslsid), Hash IP (hi), Consistent Hash IP (chi), Consistent Hash RADIUS User Name (radchu), Consistent Hash RADIUS Session ID (radchs), and persistence (Individual Session Persistence).
For more information on these additional SLB methods, please consult the FortiBalancer CLI Reference.
6.2.2 SLB Policies
Policies are used to tie virtual services to groups. By using policies, administrators may control how load balancing decisions are made by different layer policies rules (Layer 2-7). A virtual service is bound with a group by a policy. A single group can be shared among different virtual services. In the following pages we will cover policies in depth.
SLB supports multiple policy types (see the table below):
Table 6-2 SLB Policies
| Basic Policy | Persistent Policy | QoS Policy |
| Redirect
Static Default Backup |
Persistent URL
Persistent Cookie Rewrite Cookie Insert Cookie Hash URL RADIUS Username RADIUS Session ID |
QoS Cookie
QoS Hostname QoS URL QoS Network QoS Clientport QoS Body Regular Expression Header |
Different types of policies have different priorities. Currently, multiple FortiBalancer appliance SLB policies can be configured for one SLB virtual service and the FortiBalancer appliance will route requests based on the first matched policy with the highest priority. The following is the order of priority that FortiBalancer appliance SLB will follow:
Table 6-3 SLB Policy Priority
| Priority | Policy |
| a | redirect |
| b | static |
| c | qos-clientport – qos client port |
| qos-network – qos network | |
| pu – persistent url | |
| rc – rewrite cookie | |
| Priority | Policy |
| ic – insert cookie | |
| pc – persistent cookie | |
| qos-cookie – qos cookie | |
| qos-hostname – qos hostname | |
| qos-url – qos url | |
| qos-body- qos body | |
| regex – regex url | |
| header – header | |
| hu – hash url | |
| raduname – radius username | |
| radsid – radius session id | |
| d | default |
| e | backup |
For Layer 4 SLB, only two SLB policies (qos network and qos clientport) can be used beside static, default and backup policy.
For backward compatibility, the default policy precedence is the same as before. To configure specific precedence and associate it with specific virtual service, the system administrator can use the following CLI commands:
slb policy order <order_template_name> <policy_type> <precedence> slb virtual order <virtual_service> <order_template_name>
6.2.2.1 Policy Nesting
SLB Policy Nesting is the mechanism for different policies to be nested to perform server load balancing.
In traditional SLB policy mechanisms, one policy is defined to bind a virtual service with a group. For example, in the command “slb policy qos url policy1 vs1 group1 ‘news’ 1”, the virtual service vs1 and group1 are associated by policy1. The requests that match the policy1 will be forwarded to group1.
In SLB Policy Nesting mechanism, a new object “vlink” is defined for policy nesting. A virtual service or a vlink can be associated with a group or another vlink via policies. The requests will be distributed to a group or a vlink according to the policies. For a request sent to a vlink, the system will distribute the request to a group or another vlink associated to the vlink according to the policies. Therefore, the requests will be distributed to a group associated to a vlink only when they match two or more nested policies.
Figure 6-2 Policy Nesting Limitations of SLB Policy Nesting:
- Some policies cannot be nested, such as static, redirect, filetype and external policies.
- The icookie, rcookie, persistent cookie and persistent URL policies can only associate a virtual service or a vlink with a group, but cannot be associated to a virtual service or a vlink with another vlink.
- To simplify the configuration, the policy nesting layer should be less than or equal to 3. If more than 3 layers are configured, the system will return a 503 error. Only HTTP and HTTPS protocols are supported.
6.2.3 SLB Session Persistence
The SLB module of the FortiBalancer appliance introduces a new, generally applied, and session
ID-based method for session persistence. This persistence method can either operate independently on Layer 4/7 SLB or work in collaboration with an existing Layer 7 SLB persistence policy. In the latter case, the existing policy extracts the session ID and the persistence method implements the session persistence.
The persistence method maintains a mapping table to keep track of each session ID and its associated real server. Furthermore, the persistence method dynamically processes the timeout information for each session ID to ensure independence of each session.
6.2.3.1 Session ID Types
The persistence method supports the following types of session IDs:
- ip: This session ID type is the client IP address that the persistence method extracts from the client request.
- ip+port: This session ID type is the client IP address and port number that the persistence method extracts from the client request.
- string: This session ID type is a specified string that the persistence method either extracts from the client request (or real server response) itself or obtains through extraction by an existing SLB policy. You may also specify an offset and ID length for more granular control of this session ID type.
6.2.3.2 Obtaining the Session ID
Direct extraction by the Persistence Method
When used independently, the persistence method can directly extract the following session ID types from the client request or real server response:
- Client IP address or IP address and port number from the client request.
- A specified string from the HTTP URL query, HTTP cookie, HTTP header, or HTTP body field in the client request.
- A specified string from the HTTP cookie, HTTP header, or HTTP body field in the server response. In this case, you also need to configure the FortiBalancer appliance to obtain the matching specified string from the HTTP URL query, HTTP cookie, HTTP header, or HTTP body field in the client request.
Note:
When multiple session IDs of the string type are configured, the FortiBalancer appliance will obtain the session ID in priority-descending order from the HTTP URL query, HTTP cookie, HTTP header, and HTTP body.
Indirect extraction through an existing SLB Persistence Policy
In collaboration mode, the persistence method can indirectly obtain the session ID through the following types of SLB persistence policies:
- Header
- Persistent cookie
- Persistent url
- Qos body
Note:
When a client request matches with both the persistence method and an SLB persistence policy, the FortiBalancer appliance uses only the persistence method to obtain the session ID and perform session persistence.
For more information about the collaboration of the persistence method with existing SLB persistence policies, refer to example “Persistence Method Collaborating with an SLB Persistence Policy”.
6.2.3.3 Session ID Timeout Management
The persistence method can dynamically processes the timeout information of each session ID using one of the following modes:
- idle: If the FortiBalancer appliance receives no new client requests within the specified “idle” time period, the FortiBalancer appliance will terminate the client’s session and clear its associated session ID.
- duration: If the specified “duration” of time has passed since a client’s session was created, the FortiBalancer appliance will terminate the client’s session and clear its associated session ID regardless of the arrival of any new requests.
Note:
To dynamically manage the timeout information of session IDs, you need to specify the management mode to ensure that the FortiBalancer appliance clears outdated session IDs and records and new ones.
In addition, the persistence method can statically reserve a session ID. Requests matching a statically reserved session ID will be consistently sent to the same real server.
6.2.4 SLB Health Check
The FortiBalancer appliance provides three types of health checks:
Basic health check
Basic health checks determine the application, service or server availability (Up/Down) status using a specified protocol format. FortiBalancer supports basic health check types that include ARP, ICMP (ping), TCP, TCPS, DNS, HTTP and HTTPS. The default health check is assigned with the individual real server (e.g. representing any backend physical or virtual server in the server farm) configuration. FortiBalancer will perform basic health checks on the IP/port pair of the real server to decide the real service availability. This is also called main health check.
Additional health check
Many times application or service infrastructure components are spread across multiple server types that need to be run simultaneously. For example, an application might require Web servers, application servers, and database servers to be run simultaneously. In this case determining the health of one server is not sufficient, and health checks must be performed on the entire suit of servers for determining the health of entire application infrastructure. In addition to the basic health check, multiple diverse health checks can be configured for one real server. The AND or OR relationship for multiple additional health checks can be set. FortiBalancer supports configuring additional health check name, which helps administrators easily configure and identify the additional health check. See the “health relation” command.
Script health check
There are many applications and non-standard protocols (in addition to standard TCP/IP based protocols) that follow specific request/response sequence for communication purposes. To support custom application availability check, customers can make use of scripted health check. FortiBalancer offers a generic application aware health check that runs over a TCP or UDP connection. It determines an application’s health by exchanging messages with the application in the specified format. Multiple application messages, request/response sequences can be scripted for emulating normal application communication between FortiBalancer and applications.
Two health check types are available, “script-tcp” and “script-udp” for building generic script health checks. Script health checks support the following advanced application health checks: FTP, SMTP, LDAP, RADIUS, POP3, DNS, and TELNET applications. Additional application health check can be built by importing application request and response into the FortiBalancer appliance.
6.2.4.1 Methods of Health Check
Health Check allows the FortiBalancer appliance to perform diagnostic observations on the performance of Web servers and Web server farms associated with each FortiBalancer appliance. These observations on the performance health of the real server will allow the appliance to know how the servers are performing and which backend servers can best handle the incoming client requests.
ICMP Health Check
It is a limited health check method that simply sends an ICMP echo (ping) to the server. If the server responds with an ICMP reply then the server is marked as “up”. The server is marked as “down” otherwise. This does NOT check for the running service or the quality of the service.
TCP Health Check
TCP health check simply opens a TCP connection to a specific port of the real server. If that connection fails, the server will be marked as “down”. The server will be marked as “up” if the TCP connection succeeds. This health check does not indicate if the service is actually functioning. For checking if a particular service in question is functioning correctly, a specific health check must be used (e.g. HTTP health check for Web applications).
For Layer 2 SLB, the TCP health check method needs to configure a health check reflector on another FortiBalancer appliance. The reflector will open a port and listen upon the port, and responds to health check requests. In this way, the health check process can go through the real server and check the entire link status. If the reflector is able to respond to the health check request, the real server will be marked as “UP”, else marked as “DOWN”. TCPS Health Check
TCPS health check provides an SSL health check for SLB real servers. If the SSL handshake fails, the server will be marked as “down”. If the SSL handshake succeeds, the server will be marked as “up”. This health check function will check for the availability of the real service by opening an SSL connection to a specific port of the real server or defaults to 443.
HTTP Health Check
The basic built-in HTTP health check opens a TCP connection and sends an HTTP request with one of the HTTP methods (such as GET, POST, etc.) pre-defined in the health request table. The FortiBalancer appliance expects the health response as defined in the response table. The default index chosen to reference request/response table is 0. If the response is not satisfied with the conditions configured in the response table, the server will be marked as “down”, otherwise it is marked as “up”.
HTTPS Health Check
HTTPS Health Check provides an SSL health check for real servers. If the SSL handshake succeeds, the FortiBalancer will send a pre-defined HTTP request with proper method format to real servers. If the response from the real server is the same as the expected response, the real server will be marked as “up”; otherwise, it is marked as “down”. When using HTTPS Health Check, users should pre-define HTTP requests/methods and corresponding expected responses for matching purposes. When using client certificates, the imported client certificate must be encoded by DER rules during client authentication.
Script-TCP Health Check & Script-UDP Health Check
Script-TCP and script-UDP are provided for the generic script health check. They run over TCP and UDP connection respectively. Only when the “hc_type” is set to these two types, the health check list can work while doing health check.
Script-TCPS Health Check
Script-TCPS Health Check provides an SSL health check for HTTPS real servers. It works the same way as script-TCP Health Check once the SSL handshake succeeds.
DNS Health Check
DNS health check is one of the built-in application health checks for DNS service that uses scripted health check. DNS health check opens a UDP connection and sends a DNS request to a destination DNS server, and the FortiBalancer expects a special DNS response. The DNS request and response are not configurable because they are unchangeable. If the required conditions are satisfied, then server will be marked as “UP”, otherwise, the server will be marked as “DOWN”. Radius-Auth Health Check & Radius-Acct Health Check
Radius-Auth health check and Radius-Acct health check are provided for checking the availability of the RADIUS servers.
LDAP Health Check
FortiBalancer supports health check on commonly used LDAP servers like Windows AD, OpenLDAP and SunOne Directory, to better meet the customers’ needs for health check on LDAP binding and search operations.
The LDAP additional health check is only supported for TCP real servers.
RTSP-TCP Health Check
RTSP health check opens a TCP connection and sends an RTSP “OPTIONS” (Get available methods on the streaming server) request to a RTSP real server. If the real server responds with any of the RFC-defined RTSP status codes, then the server will be marked as “up”, otherwise, it will be marked as “down”.
SIP-UDP & SIP-TCP Health Check
SIP health check opens a UDP or TCP connection and sends a SIP “OPTIONS” request to a real server. This request is used to ask the SIP server for the list of SIP methods it supports. The response may contain a set of capabilities (i.e. audio/video codecs) of the responding SIP server. If the real server responds with RFC-defined methods, the server will be marked as “up”, otherwise, it will be marked as “down”.
6.2.4.2 HC Checker and HC Checker List
When the method of health check is set as script_tcp or script_udp, HC checker and HC checker list can work while the FortiBalancer appliance does health check. An HC checker is defined as one transaction of health check. It consists of sending one message and receiving one response. A list of HC checkers can compose an HC checker list, which is identified by the HC checker list name.
Below are the commands used to define the HC checker and HC checker list:
health checker <checker_name> <request_index ><response_index> [timeout] [flag] health list <list_name>
health member <list_name> <checker_name> [place_index]
health app {real_name|add_hc_name} <list_name> [frequency] [hc_localip] [hc_localport]
6.2.4.3 HTTP Requests and Responses
By default the OS defines an HTTP health table of HTTP requests and HTTP responses to be used by the HTTP health check. The default index inside the health table for HTTP requests and responses is “0, 0”. The “show health request” command shows the table of requests defined.
Likewise “show health response” shows the responses.
For our example model:
| FortiBalancer(config)#health on
FortiBalancer(config)#show health request Row Request 0 HEAD / HTTP/1.0 1 HEAD / HTTP/1.0 2 HEAD / HTTP/1.0 3 HEAD / HTTP/1.0 4 HEAD / HTTP/1.0 5 HEAD / HTTP/1.0 6 HEAD / HTTP/1.0 7 HEAD / HTTP/1.0 8 HEAD / HTTP/1.0 9 HEAD / HTTP/1.0 10 HEAD / HTTP/1.0 11 HEAD / HTTP/1.0 12 HEAD / HTTP/1.0 13 HEAD / HTTP/1.0 14 HEAD / HTTP/1.0 15 HEAD / HTTP/1.0 FortiBalancer(config)#show health response Row Response: 0 200 OK 1 200 OK 2 200 OK 3 200 OK 4 200 OK 5 200 OK 6 200 OK 7 200 OK 8 200 OK 9 200 OK 10 200 OK 11 200 OK 12 200 OK 13 200 OK 14 200 OK 15 200 OK |
Index 0,0 in the health request table results with the following request being sent to the real server:
HEAD / HTTP/1.0
The response needed from the real server is:
200 OK
You may change the response header to accommodate your network. Refer to your Web server’s documentation on what valid HTTP responses you may use.
By default, we use a HEAD request as the health check. A HEAD request will only ask for the HEADER information for the object being requested. If we were to use the GET request, you will get the entire page back as a response. If you have a large site or content that is fairly large you should choose the HTTP response that will cause the least amount of overhead.
Changing the HTTP Health Request/Response
You can define your own HTTP requests and the responses to be used by the HTTP health check.
For example, you may simply change the request to get a CGI script that returns an HTTP status
200 OK when the database server is up and a 404 NOT FOUND when the database server is “down”. Below are the commands to use to perform this task as well as an example from our network model.
health request <request_index> <request_string> health response <response_index> <response_string> health server {real_name|add_hc_name} <req_index> <res_index> For our network example:
- Step 1 Define your own HTTP request
FortiBalancer(config)#health request 1 “GET /cgi-bin/dbstatus.pl”
- Step 2 Set the request to index 1, the response to index 0 for server2http
FortiBalancer(config)#health server server2http 1 0
Note: Index 0 in health response means returning 200 OK.
The health check provided by the OS starts with simple TCP health checks and allows you to perform advanced health checks by utilizing different health requests and responses. Keyword Health Check for Web Page
HTTP health check supports keyword matching for the specific real server response Web page. The HTTP health check daemon will check the real server’s health by searching a keyword in the server’s response content. If the keyword is found, this health check is successful. Otherwise, this health check fails.
Let’s begin a configured example for this enhancement:
The real server is 10.3.16.188:88
The Web page is index.txt
The key word is fortibalanceradmin
- Step 1 Add a real service with HTTP health check
FortiBalancer(config)#slb real http rs 10.3.16.188 88 1000 http 3 3
- Step 2 Configure HTTP health check
FortiBalancer(config)#health request 1 “GET /index.txt HTTP/1.0\r\n\r\n” FortiBalancer(config)#health response 1 “fortibalanceradmin”
- Step 3 Associate the configured HTTP health check with the real service
FortiBalancer(config)#health server rs 1 1
Note: Keyword HTTP health check can only support ASCII string search in the Web page, but not support double-byte keyword (e.g. simplified Chinese, traditional Chinese).
6.2.4.4 TCP-based SLB Virtual Service Health Check
The TCP-based SLB virtual service health check supports external devices to detect the availability of TCP-based virtual services defined in FortiBalancer appliances.
How it works
If all real services corresponding to TCP-based SLB virtual service go down, the status of the virtual service will be marked as “DOWN” and the TCP connection attempting from outside will NOT be responded to so that the other devices will know the unavailability of the detected virtual service.
Note: If WebWall is turned on for the interface (“port2” for most cases) that SLB real services are using, you will need to add an access list rule to allow traffic between the FortiBalancer appliance and the real backend servers. If you also have health check turned on for SLB real services, you will need to add corresponding access list rules to allow the health check replies. For example, if the health check type is ICMP, it needs to add the corresponding access list rules to allow ICMP echo reply messages. Otherwise, the SLB real services will fail.
6.2.4.5 Health Failover
If all real servers configured in an FortiBalancer appliance are marked as DOWN by Health Check, other FortiBalancer appliances will take over the traffic. As long as at least one real server configured in an FortiBalancer appliance is marked as UP by Health Check, the FortiBalancer appliance will take over the traffic again if its mode is preemptive.