6.3 SLB Configuration
6.3.1 HTTP/TCP/FTP/UDP/HTTPS/TCPS/DNS Load Balancing
This section covers more than one SLB configuration example. At first, we will give an example with basic SLB configuration. Then more configuration examples are given based on the different policies. Herein we use HTTP protocol as an example. The configurations of other protocols are similar.
6.3.1.1 Configuration Guidelines
Before you start to configure SLB, you need to get familiar with the following SLB network architecture.
Figure 6-6 SLB Netwok Architetcure
Table 6-4 General Settings of SLB
Operation | Command |
Configure real services | slb real tcp <real_name> <ip> <port> [max_conn]
[http|tcp|icmp|script-tcp|script-udp|sip-tcp|sip-udp|dns|ldap] [hc_up] [hc_down] slb real ftp <real_name> <ip> [port] [max_conn] [tcp|icmp|script-tcp|script-udp|sip-tcp|sip-udp|dns] [hc_up] [hc_down] slb real http <real_name> <ip> [port] [max_conn] [http|tcp|icmp|script-tcp|script-udp|sip-tcp|sip-udp|dns] [hc_up] [hc_down] slb real udp <real_name> <ip> <port> [max_conn] [hc_up] [hc_down] [timeout] [icmp|script-tcp|script-udp|radius-auth|radius-acct|sip-tcp|sip-udp|dns] slb real https <real_name> <ip> [port] [max_conn] [https|tcp|tcps|icmp|script-tcp|script-udp|script-tcps|sip-tcp|sip-udp|dns] [hc_up] [hc_down] slb real tcps <real_name> <ip> <port> [max_conn] [tcp|tcps|icmp|script-tcp|script-udp|script-tcps|sip-tcp|sip-udp|dns] [hc_up] [hc_down] slb real dns <real_name> <ip> <port> [max_conn] [dns|icmp|script-tcp|script-udp|sip-tcp|sip-udp|dns] [hc_up] [hc_down] [timeout] slb real health <add_hc_name> <real_name> <ip> <port> [http|https|tcp|icmp|dns|ldap|script-tcp|script-udp|script-tcps|sip-tcp|sip-u dp|rtsp-tcp] [hc_up] [hc_down] |
Define group methods | slb group method <group_name> [rr|pu|sr]
slb group method <group_name> hc [rr|sr|lc] [weight|threshold] slb group method <group_name> ic [cookie_name] [add_path] [rr|sr|lc] [threshold] slb group method <group_name> rc [cookie_name] [offset] [rr|sr|lc] [threshold] slb group method <group_name> lc [threshold] [yes|no] slb group method <group_name> hh <header_name> [rr|sr|lc] [threshold] [prefix] [delimiter] slb group method <group_name> prox [rr|sr|lc] [threshold] |
Operation | Command |
slb group method <group_name> ec <cookie_name> [rr|sr|lc] [threshold] | |
Add the real servers into the group | slb group member <group_name> <real_name> [weight] |
Define virtual services | slb virtual {http|https|dns|siptcp|sipudp} <virtual_name> <vip> [vport]
[arp|noarp] [max_conn] slb virtual {tcp|tcps|udp} <virtual_name> <vip> <vport> [arp|noarp] [max_conn] slb virtual rtsp <virtual_name> <vip> [vport] [mode] [arp|noarp] [max_conn] slb virtual {ftp|ftps} <virtual_name> <vip> [vport] [max_conn] slb virtual ip <virtual_name> <vip> slb virtual l2ip <virtual_name> <vip> [gateway_ip] |
Bind the group (or a real service) to the virtual service | slb policy default {virtual_name|vlink_name} {group_name|vlink_name} slb policy static <virtual_name> <real_name> slb policy qos url <policy_name> {virtual_name|vlink_name} {group_name|vlink_name} <qos_string> <precedence>
slb policy qos cookie <policy_name> {virtual_name|vlink_name} {group_name|vlink_name} <cookie_name=cookie_value> <precedence> slb policy persistent cookie <policy_name> {virtual_name|vlink_name} <group_name> <cookie_name> <precedence> slb policy qos hostname <policy_name> {virtual_name|vlink_name} {group_name|vlink_name} <host_name> <precedence> slb policy redirect <policy_name> <virtual_name> <group_name> <redirected_from_host> |
6.3.1.2 Configuration Example via CLI
Ø Step 1 Define real services
The first step in setting up your network architecture with the FortiBalancer appliance performing SLB tasks is to create and configure your real services. To define real services for our model, use the following command:
For setting up the first real service:
FortiBalancer(config)#slb real http service1http 192.168.10.10
When you define an HTTP real service with just the real service name and the IP address, it will use the following default values:
- Port: 80
- Max Con: 1000
- Health Check: tcp
- Consecutive up health check results before server is marked up: 1
- Consecutive down health check results before server is marked down: 1
For service2 we will define what kind of health check to use, HTTP in this case.
FortiBalancer(config)#slb real http service2http 192.168.10.11 80 1000 http 3 3
For other services, we will rely on the defaults for now.
FortiBalancer(config)#slb real http service3http 192.168.10.12
FortiBalancer(config)#slb real http service4http 192.168.10.13
FortiBalancer(config)#slb real http service5http 192.168.10.15
Now all five real services are defined for the FortiBalancer appliance. To verify the configuration, you may use the “show slb real http” command. You may either specify a service by supplying the real name, or leave this field blank and view all of your configured real services.
Additional Health Check for Real Services
For setting additional health check for the first real service:
FortiBalancer(config)#slb real health a1service1http 192.168.10.10 80 http
FortiBalancer(config)#slb real health a1service1http 192.168.10.10 8080 http
So the real server “service1http” will be healthy only when the main health check (192.168.10.10, 80, tcp), and the two additional health check servers (192.168.10.10 80 http and 192.168.10.10 8080 http), are all reported as healthy. Maintaining the Real Services
Sometimes it becomes necessary to disable a real service for maintenance or for temporary shifts in resource allocation. To disable a real service, use the “slb real disable” command:
FortiBalancer(config)#slb real disable service1http
Now verify our configuration change:
FortiBalancer(config)#show slb real all
To re-enable the real server just use the “slb enable” command.
FortiBalancer(config)#slb real enable service1http
By default, when a real service is disabled or deleted, the FortiBalancer appliance SLB shall not send session requests to the real services that have been disabled. However, for cookie-based group method and load balancing polices: PC (Persistent Cookie), IC (Insert Cookie), RC (Rewrite Cookie), SLB supports the “graceful shutdown” of real services.
Graceful Shutdown
If a real service is disabled when it is already in a cookie-based group, SLB will still send the existing session requests which match the cookie to the disabled real service. The new requests will be sent to other working real services.
Figure 6-7 Graceful Shutdown of Real Services
For example, you can configure the graceful shutdown function as follows:
FortiBalancer(config)#slb real http r1 10.3.0.20 80
FortiBalancer(config)#slb group method g1 pc
FortiBalancer(config)#slb group member g1 r1 “server1”
FortiBalancer(config)#slb real disable r1
After the above configurations, the existing session requests will still be sent to r1. Ø Step 2 Define groups
Now that the real services have been defined, it is time to assign them to groups. A group is first defined by using the “slb group method” command. Below is an example from our model.
Once the group method is defined, the method changes from rr, sr and lc methods switching to rr, sr, lc, pi, hi, and chi methods by employing the “slb group method” command can work without removing the configured method. For other method changes, the old group method has to be removed firstly, and then a new one can be added.
So for our purposes here we will employ the following command:
FortiBalancer(config)#slb group method rrgroup rr
We have just defined a group with the name of “rrgroup” and a metric of Round Robin.
- Step 3 Add the real services into the defined group
Once we have defined a group we simply add the real service by using the “slb group member” command:
FortiBalancer(config)#slb group member rrgroup server1http
FortiBalancer(config)#slb group member rrgroup server2http
FortiBalancer(config)#slb group member rrgroup server3http
FortiBalancer(config)#slb group member rrgroup server4http
FortiBalancer(config)#slb group member rrgroup server5http
- Step 4 Define virtual services
A virtual service is an access point that will service requests for the content which a group is designed for. For Layer 4 and Layer 7 SLB, a virtual service is just a (VIP, port) pair. A VIP (virtual IP) is mostly a public IP address which can be accessed from external clients. For example, if group1 is a set of image servers, then we could define a VIP of 10.10.0.10 that is tied to group1. Any requests made to this Virtual IP will be passed to either the Cache or SLB subsystem depending on your cache and SLB settings. In essence you are hiding your internal architecture by only exposing one IP and not many. Sometimes, the word “VIP” in this chapter is used for “virtual service”.
Notes:
- The VIP address cannot be the same IP as any management IP address.
- The VIP address configured must be within the same subnet with any system interface on the appliance (except the 0.0.0.0 and noarp cases). For the VIP address that does not match the subnet of any interface, the FortiBalancer appliance will not allow it to be configured.
- If a VIP address is not tied to a policy the client will get a 503 Service Unavailable response from the FortiBalancer appliance. 503 will also be returned when all real servers are down in a group.
To establish virtual services:
FortiBalancer(config)#slb virtual http virtual1http 10.10.0.10 80
We now have the IP address 10.10.0.10, listening for requests on port 80. Next we must define a policy so incoming requests will be directed to the proper group.
Ø Step 5 Define policies
The final step is to define a default policy to bind a virtual service to a Layer 4 “group”.
FortiBalancer(config)#slb policy default virtual1http rrgroup
This command sets the default policy for a request on virtual1http to be serviced from rrgroup. We now have Layer 4 load balancing using the round robin metric, live on the FortiBalancer appliance. You should be able to test the configuration by typing the HTTP URL: “http://10.10.0.10/” in a Web browser.
6.3.1.3 Policies-based SLB Configuration Example
QoS URL
Using QoS URL, we can setup policies that will look into the URL string and make a decision based upon the information housed within that string. For our next example, we will setup two groups. Group 1 will service all requests with ‘.jpg’ in the URL while Group 2 will service all requests with ‘english’ in the URL.
Group 1: URL: .jpg
Members: S1.sj.example.com
S2.sj.example.com
Group 2: URL: ‘english’
Members: S3.sj.example.com
S4.sj.example.com
We do not have to redefine the real servers and virtual service so we will leave them as they were originally defined in the basic SLB configuration example above.
- Step 1 Define the two groups and their members, much as before
FortiBalancer(config)#slb group method group1 rr
FortiBalancer(config)#slb group method group2 rr
- Step 2 Add the real services into the groups (the real services are defined in the last example)
FortiBalancer(config)#slb group member group1 service1http
FortiBalancer(config)#slb group member group1 service2http
FortiBalancer(config)#slb group member group2 service3http
FortiBalancer(config)#slb group member group2 service4http
- Step 3 Set the policies and the URL associated with each group (the virtual service is defined in the last example)
FortiBalancer(config)#slb policy qos url url_pol_1 virtual1http group1 “.jpg ”1
FortiBalancer(config)#slb policy qos url url_pol_2 virtual1http group2 english 2
- Step 4 Define a default policy
If we receive a request that has neither .jpg or ‘english’ in the URL, then the FortiBalancer appliance will returne a 503 Service Unavailable since it does not know how to handle the request. This is fine if it is guaranteed every URL will always contain one of the strings. If not, it is best to define the default policy. In our case we are just going to direct any request that does not contain one of the strings to go to the “english” servers belonging to group 2.
FortiBalancer(config)#slb policy default virtual1http group2
QoS Cookie
QoS cookie allows you to add policies to the Layer 7 rules to load balance requests to a group based on a cookie name and value pair. The following figure shows the QoS cookie in action. We are going to define our two groups, define our cookies, and then setup the policies to make cookie-based load balancing work within our model network.
Figure 6-8 QoS Cookie Policy
Since we are using QoS cookie, which works on top of the existing groups, we define the groups as would with Layer 4 rules. Group1: Round Robin
Members: S1.sj.example.com
S2.sj.example.com
Group2: Round Robin
Members: S3.sj.example.com S4.sj.example.com
Group3: Round Robin
Members: S5.sj.example.com
The path that a packet goes through in this policy is as follows:
- If there is a Cookie sent with the request that has the name “Service” and value “Gold”, then go to Group 1.
- If there is a Cookie sent with the request that has a name “Service” and value “Silver”, then go to Group 2.
- If there are no cookies in the request, go to Group 3.
Group3 will be our cookie setters. If a client has never been to a site then the request will not contain a cookie since it is the server that sets the cookie for the first time. These types of requests will not match Group1 or Group2 and will be served through Group3, the default. After the client has been to the Web site through Group3 and the cookie has been set by the server, the next time the client accesses the Web site the browser will send the cookies in the HTTP request headers.
These cookies will ensure we pick the appropriate service from Group1 or Group2.
Note: If we do not have the default policy, the rule will “drop through” and the FortiBalancer appliance will return a 503 service unavailable.
Now that we have defined what needs to happen, let’s configure the appliance. We do not have to redefine the real services so we will leave them as they have been originally defined in the basic SLB configuration example.
- Step1 Define three groups
FortiBalancer(config)#slb group method gold_group rr
FortiBalancer(config)#slb group method silver_group rr
FortiBalancer(config)#slb group method cookie_set_group rr
- Step2 Add the real services into the groups
FortiBalancer(config)#slb group member gold_group service1http
FortiBalancer(config)#slb group member gold_group service2http
FortiBalancer(config)#slb group member silver_group service3http
FortiBalancer(config)#slb group member silver_group service4http
FortiBalancer(config)#slb group member cookie_set_group service5http
- Step 3 Set the default policy for group “cookie_set_group”, where cookies will be set
FortiBalancer(config)#slb policy default virtual1http cookie_set_group
- Step 4 Set the QoS Cookie policy for group “gold_group” and “silver_group”
FortiBalancer(config)#slb policy qos cookie gold_policy virtual1http gold_group “service=gold” 1
FortiBalancer(config)#slb policy qos cookie silver_policy virtual1http silver_group “service=silver” 2
Persistent Cookie
Using persistent cookies, you can set cookie names and values and tie them to specific real servers. This is different from QoS cookie in which the requests go directly to a server. And it so happens that the configuration of persistent cookie is completely different.
Group 1
Server1: Cookie Name: Service Cookie Value: GOLD
Server2: Cookie Name: Service
Cookie Value: SILVER
Group 2
Server3: Default cookie setter
Definition of the real services has been already completed. Now let’s proceed to setting up the cookies, groups and then the policies.
- Step 1 Define two groups
FortiBalancer(config)#slb group method group1 pc
FortiBalancer(config)#slb group method group2 rr
Note: Persistent Cookie must be used with either Hash Cookie or Persistent Cookie group balancing methods.
- Step 2 Add the real services into the groups
FortiBalancer(config)#slb group member group1 service1http gold
FortiBalancer(config)#slb group member group1 service2http silver FortiBalancer(config)#slb group member group2 service3http
- Step 3 Set the default policy for “group2”, where cookies will be set
FortiBalancer(config)#slb policy default virtual1http group2
- Step 4 Set the persistent cookie policy for “group1”
FortiBalancer(config)#slb policy persistent cookie perst_pol virtual1http group1 Service 1
Note: All members of a PC group must have a cookie name association.
QoS Hostname
QoS hostname based load balancing makes decisions on the host name within the URL. This is also known as Virtual Hosting. This setup is similar to QoS cookie, but we are going to use hostname policies instead of qos cookie policies.
In the following figure we have three groups. In our example, c-one.example.com refers to “customer one” while c-two.example.com refers to “customer two”. Any other host name that is used to access the VIP will go to the default policy.
Figure 6-9 QoS Hostname Policy
Group 1: host name: c-one.example.com (Round Robin)
Members: S1.sj.example.com S2.sj.example.com
Group 2: host name: c-two.example.com (Round Robin)
Members: S3.sj.example.com S4.sj.example.com
Group 3: any other host name (Default Policy)
Members: S5.sj.example.com
- Step 1 Define the groups
FortiBalancer(config)#slb group method c_one_group rr
FortiBalancer(config)#slb group method c_two_group rr
FortiBalancer(config)#slb group method www_group rr
Note: QoS hostname policy can be used with any balancing method except Persistent Cookie and Persistent URL.
- Step 2 Add the real services into the groups
FortiBalancer(config)#slb group member c_one_group service1http FortiBalancer(config)#slb group member c_one_group service2http
FortiBalancer(config)#slb group member c_two_group service3http
FortiBalancer(config)#slb group member c_two_group service4http
FortiBalancer(config)#slb group member www_group service5http
- Step 3 Define the policy for “www_group”
By default, we want “www_group” to service any requests that do not have “c-one.example.com” or “c-two.example.com” as their host names.
FortiBalancer(config)#slb policy default virtual1http www_group
- Step 4 Define the QoS Hostname policy for “c_one_group” and “c_two_group”
FortiBalancer(config)#slb policy QoS hostname c_one_pol virtual1http c_one_group c_one.example.com 1
FortiBalancer(config)#slb policy QoS hostname c_two_pol virtual1http c_two_group c_two.example.com 2
Persistent URL
Persistent URL works by looking for a string which has the format: tag=value. This is typically used within a URL when the browser is submitting a form to the server. This way you can set persistence to the backend server by the value of a parameter being passed to the CGI script. For example a URL of the form:
http://www.example.com/find_user.pl?username=bob
This will match our Layer 7 policy and direct the request to server1. The following configuration example shows you how to set up a persistent URL policy.
- Step 1 Create the group for Persistent URL policy
FortiBalancer(config)#slb group method pu_group pu
FortiBalancer(config)#slb group method regular_group rr
Note: Persistent URL policy must be used with a persistent URL (pu) and hash query (hq) group.
- Step 2 Add the real services into the group
FortiBalancer(config)#slb group member pu_group service1http bob
FortiBalancer(config)#slb group member pu_group service2http janet
FortiBalancer(config)#slb group member pu_group service3http steve
FortiBalancer(config)#slb group member regular_group service4http
FortiBalancer(config)#slb group member regular_group service5http
- Step 3 Setup the policies
FortiBalancer(config)#slb policy default virtual1http regular_group
FortiBalancer(config)#slb policy persistent url pol1 virtual1http pu_group username 1
Insert Cookie
Insert Cookie (ic) is a method that allows users to insert a cookie into the server response in order to maintain the persistency between the clients and servers.
- Step 1 Create an SLB group and configure Insert Cookie algorithm for it
FortiBalancer(config)#slb group method ic_group ic
Note: Insert Cookie policy must be used with an Insert Cookie (ic) group.
- Step 2 Define the Insert Cookie properties for the group
FortiBalancer(config)#slb group option ic ic_group “expires=300 secure=yes”
- Step 3 Add real services into the Insert Cookie group
FortiBalancer(config)#slb group member ic_group service1http
FortiBalancer(config)#slb group member ic_group service2http
FortiBalancer(config)#slb group member ic_group service3http
FortiBalancer(config)#slb group member ic_group service4http
FortiBalancer(config)#slb group member ic_group service5http
- Step 4 Set up the SLB policies to associate the group with virtual services
FortiBalancer(config)#slb policy icookie pol1 virtual1http ic_group 1
FortiBalancer(config)#slb policy default virtual1http ic_group
By default you do not need to define a cookie name. The system will generate a random cookie name and save it in the configuration file. You can view the cookie name by running the “show slb group method” command, as follows:
FortiBalancer(config)#show slb group method slb group method ic_group “yqv” 1 rr
If you want to set the name of the cookie, just add the name by using the command “slb group method <group_name> ic [cookie_name] [add_path] [rr|sr|lc] [threshold]”. For example:
FortiBalancer(config)#slb group method ic_group ic CookieExampleName
Now the cookie “CookieExampleName” will be inserted into the responses from the real services. The value will be used by the FortiBalancer appliance to determine which real service to keep persistent to. For example:
CookieExampleName=server1http
Rewrite Cookie
Rewrite cookie allows us to rewrite a section of a cookie value to make sure that the cookie gets sent back to the same server. We will not strip out the modifications that the OS has made. So the backend server will see the modified cookie.
Note: For insert cookie, we will not strip out the modifications that the OS has made too. So the backend server will see the inserted cookie now. Ø Step 1 Create the group for Rewrite Cookie policy
FortiBalancer(config)#slb group method rc_group rc CookieExampleName 4
Note: Rewrite Cookie policy must be used with Rewrite Cookie group method and Embed Cookie group method.
- Step 2 Add the real services into the group
FortiBalancer(config)#slb group member rc_group service1http
FortiBalancer(config)#slb group member rc_group service2http FortiBalancer(config)#slb group member rc_group service3http FortiBalancer(config)#slb group member rc_group service4http FortiBalancer(config)#slb group member rc_group service5http
- Step 3 Setup the policies
Then we use the rcookie policy to bind the virtual service to the group:
FortiBalancer(config)#slb policy rcookie pol1 virtual1http rc_group 1
FortiBalancer(config)#slb policy default virtual1http rc_group
Now the cookie, CookieExampleName, will be rewritten with the service name. For example the name will look like the following if the response comes from service1http: CookieExaampleName=valueabcdefghijk New cookie will be:
CookieExampleName= service1http!?ijk
Note: The length of cookie value has to be not less than the length of real service name +2. Otherwise the rewrite operation will not be performed.
Redirect
A Redirect policy is applied to the URL host in incoming HTTP requests. Redirect policy allows users to redirect the client’s HTTP request from one host to another host. By doing this, all the HTTP requests are balanced to different real services and the persistency is kept by the new host name at the same time.
In our example, the requests for the homepage “http://www.abc.com/index.htm” from the client will be redirected to be “http://www1.abc.com/index.htm”, “http://www2.abc.com/index.htm” or “http://www3.abc.com/index.htm” depending on the configured group method (rr).
- Step 1 Define the real services that HTTP requests will be redirected to
FortiBalancer(config)#slb real http www1.abc.com 192.168.10.10 FortiBalancer(config)#slb real http www2.abc.com 192.168.10.11
FortiBalancer(config)#slb real http www3.abc.com 192.168.10.12
- Step 2 Create a group
FortiBalancer(config)#slb group method group1 rr
- Step 3 Add the real services into the group
FortiBalancer(config)#slb group member group1 www1.abc.com
FortiBalancer(config)#slb group member group1 www2.abc.com
FortiBalancer(config)#slb group member group1 www3.abc.com
- Step 4 Use the “slb policy redirect” command to associate an existing virtual service with the group
FortiBalancer(config)#slb policy redirect pol1 virtual1http group1 www.abc.com
Currently, the Redirect policy supports rr (Round Robin), lc (Least Connection), sr (Shortest Response Time) and prox (Proximity) load balancing methods.