Virtual server load balance
This topic shows a special virtual IP type: virtual server. Use this type of VIP to implement server load balancing.
The FortiProxy server load balancing contains all the features of a server load balancing solution. You can balance traffic across multiple backend servers based on multiple load balancing schedules including:
-
Static (failover)
-
Round robin
-
Weighted (to account for different sized servers or based on the health and performance of the server including round trip time and number of connections)
The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, and SSL/TLS protocols. Session persistence is supported based on the SSL session ID based on an injected HTTP cookie, or based on the HTTP or HTTPS host. SSL/TLS load balancing includes protection from protocol downgrade attacks. Server load balancing is supported on most FortiProxy devices and includes up to 10,000 virtual servers on high-end systems.
FortiProxy HTTP and HTTPS server load balancing does not support load balancing based on URL routing. You can use FortiWeb server pools or FortiADC server load balancing to load balance sessions to two or more URL based routes. |
Sample topology
SSL/TLS offloading
FortiProxy SSL/TLS offloading is designed for the proliferation of SSL/TLS applications. The key exchange and encryption/decryption tasks are offloaded to the FortiProxy unit where they are accelerated using FortiASIC technology which provides significantly more performance than a standard server or load balancer. This frees up valuable resources on the server farm to give better response to business operations. Server load balancing offloads most SSL/TLS versions including SSL 3.0, TLS 1.0, and TLS 1.2, and supports full mode or half mode SSL offloading with DH key sizes up to 4096 bits.
FortiProxy SSL offloading allows the application payload to be inspected before it reaches your servers. This prevents intrusion attempts, blocks viruses, stops unwanted applications, and prevents data loss. SSL/TLS content inspection supports TLS versions 1.0, 1.1, and 1.2 and SSL versions 1.0, 1.1, 1.2, and 3.0.
Virtual server requirements
When creating a new virtual server, you must configure the following options:
-
Virtual Server Type.
-
Load Balancing Methods.
-
Session persistence (optional).
-
Virtual Server IP (External IP Address).
-
Virtual Server Port (External Port).
-
Real Servers (Mapped IP Address & Port).
Virtual server types
Select the protocol to be load balanced by the virtual server. You can apply additional server load balancing features such as Persistence and HTTP Multiplexing.
HTTP |
Select HTTP to load balance only HTTP sessions with the destination port number that matches the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 80 for HTTP sessions). You can enable HTTP Multiplexing. You can also set Persistence to HTTP Cookie to enable cookie-based persistence. |
HTTPS |
Select HTTPS to load balance only HTTPS sessions with the destination port number that matches the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 443 for HTTPS sessions). You can enable HTTP Multiplexing. You can also set Persistence to HTTP Cookie to enable cookie-based persistence, or you can set Persistence to SSL Session ID. |
IMAPS |
Select IMAPS to load balance only IMAPS sessions with the destination port number that matches the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 993 for IMAPS sessions). You can also set Persistence to SSL Session ID. |
POP3S |
Select POP3S to load balance only POP3S sessions with the destination port number that matches the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 995 for POP3S sessions). You can also set Persistence to SSL Session ID. |
SMTPS |
Select SMTPS to load balance only SMTPS sessions with the destination port number that matches the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 465 for SMTPS sessions). You can also set Persistence to SSL Session ID. |
SSL |
Select SSL to load balance only SSL sessions with the destination port number that matches the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions to be load balanced. You can also set Persistence to SSL Session ID. |
Load balancing methods
The load balancing method defines how sessions are load balanced to real servers. When a real server is down or not responding, no traffic will be sent to it.
Static |
The traffic load is statically spread evenly across all real servers. Sessions are not assigned according to how busy individual real servers are. This load balancing method provides some persistence because all sessions from the same source address always go to the same real server. Because the distribution is stateless, so if a real server is added, removed, or goes up or down, the distribution is changed and persistence might be lost. |
Round Robin |
Directs new requests to the next real server. This method treats all real servers as equals regardless of response time or the number of connections. This method does not direct requests to real servers that down or non responsive. |
Weighted |
Real servers with a higher weight value receive a larger percentage of connections. Set the real server weight when adding a real server. |
Least Session |
Directs requests to the real server that has the least number of current connections. This method works best in environments where the real servers or other equipment you are load balancing all have similar capabilities. This load balancing method uses the FortiProxy session table to track the number of sessions being processed by each real server. The FortiProxy unit cannot detect the number of sessions actually being processed by a real server. |
First Alive |
Directs sessions to the first live real server. This load balancing schedule provides real server failover protection by sending all sessions to the first live real server. If a real server fails, all sessions are sent to the next live real server. Sessions are not distributed to all real servers so all sessions are processed by the first real server only. |
Session persistence
Use persistence to ensure a user is connected to the same real server every time the user makes an HTTP, HTTPS, or SSL request that is part of the same user session. For example, if you are load balancing HTTP and HTTPS sessions to a collection of eCommerce web servers, when users make a purchase, they will be starting multiple sessions as they navigate the eCommerce site. In most cases, all the sessions started by this user during one eCommerce session should be processed by the same real server. Typically, the HTTP protocol keeps track of these related sessions using cookies. HTTP cookie persistence ensure all sessions that are part of the same user session are processed by the same real server.
When you configure persistence, the FortiProxy unit load balances a new session to a real server according to the load balance method. If the session has an HTTP cookie or an SSL session ID, the FortiProxy unit sends all subsequent sessions with the same HTTP cookie or SSL session ID to the same real server.
Real servers
Add real servers to a load balancing virtual server to provide information the virtual server requires to send sessions to the server. A real server configuration includes the IP address of the real server and port number the real server receives sessions on. The FortiProxy unit sends sessions to the real server’s IP address using the destination port number in the real server configuration.
When configuring a real server, you can also specify the weight (if the load balance method is set to Weighted) and you can limit the maximum number of open connections between the FortiProxy unit and the real server. If the maximum number of connections is reached for the real server, the FortiProxy unit automatically switches all further connection requests to other real servers until the connection number drops below the limit. Setting Maximum Connections to 0 means that the FortiProxy unit does not limit the number of connections to the real server.
Sample of HTTP load balancing to three real web servers
This example describes the steps to configure the load balancing configuration below. In this configuration, a FortiProxy unit is load balancing HTTP traffic from the Internet to three HTTP servers on the internal network. HTTP sessions are accepted at the wan1 interface with destination IP address 172.20.120.121 on TCP port 8080, and forwarded from the internal interface to the web servers. When forwarded, the destination address of the session is translated to the IP address of one of the web servers.
This load balancing configuration also includes session persistence using HTTP cookies and round-robin load balancing for the real servers.
General steps:
-
Create a load balance virtual server with three real servers. This can only done in the CLI
-
Add the load balancing virtual server to a policy as the destination address.
Configure a load balancing virtual server
To configure HTTP load balancing to three real web servers:
config firewall vip edit "Vserver-HTTP-1" set type server-load-balance set extip 172.20.120.121 set extintf "any" set server-type http set ldb-method round-robin set persistence http-cookie set extport 8080 config realservers edit 1 set type ip set ip 10.31.101.30 set port 80 next edit 2 set type ip set ip 10.31.101.40 set port 80 next edit 3 set type ip set ip 10.31.101.50 set port 80 next end next end
To create a policy that includes the load balance virtual server as the destination address:
GUI:
-
Go to Policy & Objects > Policy.
-
Click Create New.
-
Set the following:
-
Name to LB-policy
-
Incoming Interface to wan1
-
Outgoing Interface to internal
-
Source to all
-
Destination to Vserver-HTTP-1
-
Schedule to always
-
Service to ALL
-
Action to ACCEPT
-
-
Enable AntiVirus and select an antivirus profile.
-
Click OK.
CLI:
config firewall policy edit 2 set name "LB-policy" set srcintf "wan1" set dstintf "internal" set srcaddr "all" set dstaddr "Vserver-HTTP-1" set action accept set schedule "always" set service "ALL" set utm-status enable set ssl-ssh-profile "certificate-inspection" set av-profile "default" next end
Results
Traffic accessing 172.20.120.121:8080 is forwarded in turn to the three real servers.
If the access request has an http-cookie, FortiProxy forwards the access to the corresponding real server according to the cookie.