Configuring load balancing
How to use the FortiOS server load balancing to load balance traffic to multiple backend servers.
- You can configure FortiOS load balancing to intercept incoming traffic with a virtual server and distribute it among one or more backend real servers. By doing so, FortiOS enables multiple real servers to respond as if they were a single device or virtual server. This in turn means that more simultaneous requests can be handled by the servers.
- Traffic can be balanced across multiple backend real servers based on a selection of load balancing methods 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, number of connections. The load balancer can balance layer 7 HTTP, HTTPS, SSL, generic layer 4 TCP, UDP and generic layer 3 IP protocols. Session persistence is supported based on injected HTTP/HTTPS cookies or the SSL session ID.
- You can bind up to 8 real servers can to one virtual server. The real server topology is transparent to end users, and the users interact with the system as if it were only a single server with the IP address and port number of the virtual server. The real servers may be interconnected by high-speed LAN or by geographically dispersed WAN. The FortiGate unit schedules requests to the real servers and makes parallel services of the virtual server to appear to involve a single IP address.
- There are additional benefits to load balancing. First, because the load is distributed across multiple servers, the service being provided can be highly available. If one of the servers breaks down, the load can still be handled by the other servers. Secondly, this increases scalability. If the load increases substantially, more servers can be added behind the FortiGate unit to cope with the increased load.
Configuring load balancing from the GUI
A virtual server is a specialized firewall virtual IP that performs server load balancing. From the web-based manager you add load balancing virtual server by going to Policy & Objects > Virtual Servers.
Name
Enter the name for the virtual server.
Type
Select the protocol to be load balanced by the virtual server. If you select a general protocol such as IP, TCP, or UDP the virtual server load balances all IP, TCP, or UDP sessions. If you select specific protocols such as HTTP, HTTPS, or SSL you can apply additional server load balancing features such as Persistence and HTTP Multiplexing.
- Select HTTP to load balance only HTTP sessions with destination port number that matches the Virtual Server Port Change Virtual Server Port to match the destination port of the sessions to be load balanced (usually port 80 for HTTP sessions). You can also select HTTP Multiplex. You can also set Persistenceto HTTP Cookie to select cookie-based persistence.
- Select HTTPS to load balance only HTTPS sessions with destination port number that matches the Virtual Server Port Change Virtual Server Portto match the destination port of the sessions to be load balanced (usually port 443 for HTTPS sessions). You can also select Multiplex HTTP requests/responses. You can also set Persistence to HTTP Cookie to select cookie-based persistence. You can also set Persistence to SSL Session ID.
- Select IMAPS to load balance only IMAPS sessions with destination port number that matches the Virtual Server Port Change Virtual Server Portto 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.
- Select POP3S to load balance only POP3S sessions with destination port number that matches the Virtual Server Port Change Virtual Server Portto 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.
- Select SMTPS to load balance only SMTPS sessions with destination port number that matches the Virtual Server Port Change Virtual Server Portto 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.
- Select SSL to load balance only SSL sessions with destination port number that matches the Virtual Server Port Change Virtual Server Portto match the destination port of the sessions to be load balanced.
- Select TCP to load balance only TCP sessions with destination port number that matches the Virtual Server Port Change Virtual Server Portto match the destination port of the sessions to be load balanced.
- Select UDP to load balance only UDP sessions with destination port number that matches the Virtual Server Port Change Virtual Server Portto match the destination port of the sessions to be load balanced.
- Select IP to load balance all sessions accepted by the security policy that contains this virtual server.
Interface
Select the virtual server external interface from the list. The external interface is connected to the source network and receives the packets to be forwarded to the destination network.
Virtual Server IP
The IP address of the virtual server. This is an IP address on the external interface that you want to map to an address on the destination network.
Virtual Server Port
Enter the external port number that you want to map to a port number on the destination network. Sessions with this destination port are load balanced by this virtual server.
Load Balance Method
Select the load balancing method used by the virtual server.
Persistence
Configure persistence to make sure that a user is connected to the same server every time they make a request that is part of the same session. Session persistence is supported for HTTP and SSL sessions.
HTTP Multiplexing
Select to use the FortiGate unit to multiplex multiple client connections into a few connections between the FortiGate unit and the real server.
Preserve Client IP
Select to preserve the IP address of the client in the X-Forwarded-For HTTP header. This can be useful if you want log messages on the real servers to the client’s original IP address. If this option is not selected, the header will contain the IP address of the FortiGate unit.
This option appears only if HTTP or HTTS are selected for Type, and is available only if HTTP Multiplexing is selected.
SSL Offloading
Select to accelerate clients’ SSL connections to the server by using the Fortinet FortiGate unit to perform SSL operations, then select which segments of the connection will receive SSL offloading.
Certificate
Select the certificate to use with SSL Offloading. The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.
This option appears only if HTTPS or SSL are selected for Type, and is available only if SSL Offloading is selected.
Health Check
Select which health check monitor configuration will be used to determine a server’s connectivity status.
Configuring load balancing from the CLI
From the CLI you configure load balancing by adding a firewall virtual IP and setting the virtual IP type to server load balance:
config firewall vip
edit Vserver-HTTP-1
set type server-load-balance
...
A virtual server includes a virtual server IP address bound to an interface. The virtual server IP address is the destination address incoming packets to be load balanced and the virtual server is bound to the interface that receives the packets to be load balanced.
For example, if you want to load balance incoming HTTP traffic from the Internet to a group of web servers on a DMZ network, the virtual server IP address is the known Internet IP address of the web servers and the virtual server binds this IP address to the FortiGate interface connected to the Internet.
When you bind the virtual server’s external IP address to a FortiGate unit interface, by default, the network interface responds to ARP requests for the bound IP address. Virtual servers use proxy ARP, as defined in RFC 1027, so that the FortiGate unit can respond to ARP requests on a network for a real server that is actually installed on another network. In some cases, you may not want the network interface sending ARP replies. You can use the arp-reply option disable sending ARP replies:
config firewall vip
edit Vserver-HTTP-1
set type server-load-balance
set arp-reply disable
...
The load balancing virtual server configuration also includes the virtual server port. This is the TCP port on the bound interface that the virtual server listens for traffic to be load balanced on. The virtual server can listen on any port.
Load balancing limitations
The following limitations apply when adding virtual IPs, load balancing virtual servers, and load balancing real servers. Load balancing virtual servers are actually server load balancing virtual IPs. You can add server load balance virtual IPs from the CLI.
- Virtual IP External IP Address/Range entries or ranges cannot overlap with each other or with load balancing virtual server Virtual Server IP entries.
- A virtual IP Mapped IP Address/Range cannot be 0.0.0.0 or 255.255.255.255.
- A real server IP cannot be 0.0.0.0 or 255.255.255.255.
- If a static NAT virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP Address/Range must be a single IP address.
- If a load balance virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP Address/Range can be an address range.
- When port forwarding, the count of mapped port numbers and external port numbers must be the same. The web-based manager does this automatically but the CLI does not.
- Virtual IP and virtual server names must be different from firewall address or address group names.
Monitoring load balancing
From the GUI you can go to Monitor > Load Balance Monitor to monitor the status of configured virtual servers and real server and start or stop the real servers. You can also use the get test ipldb command from the CLI to display similar information.
For each real server the monitor displays health status (up or down), active sessions, round trip time and the amount of bytes of data processed. From the monitor page you can also stop sending new sessions to any real server. When you select to stop sending sessions the FortiGate unit performs of graceful stop by continuing to send data for sessions that were established or persistent before you selected stop. However, no new sessions are started.
Virtual Server
The IP addresses of the existing virtual servers.
Real Server
The IP addresses of the existing real servers.
Health Status
Displays the health status according to the health check results for each real server. A green arrow means the server is up. A red arrow means the server is down.
Mode
The mode of the health check monitor. Can be active, standby, or disabled.
Monitor Events
Display each real server’s up and down times.
Active Sessions
Display each real server’s active sessions.
RTT (ms)
Displays the Round-Trip Time (RTT) of each real server. By default, the RTT is “<1”. This value will change only when ping monitoring is enabled on a real server.
Bytes Processed
Displays the traffic processed by each real server.
Graceful Stop/Start
Select to start or stop real servers. When stopping a server, the FortiGate unit will not accept new sessions but will wait for the active sessions to finish.
Load balancing diagnose commands
You can also use the following diagnose commands to view status information for load balancing virtual servers and real servers:
diagnose firewall vip realserver {down | flush | healthcheck | list | up}
diagnose firewall vip virtual-server {filter | log | real-server | session | stats}
For example, the following command lists and displays status information for all real servers:
diagnose firewall vip virtual-server real-server
vd root/0 vs vs/2 addr 10.31.101.30:80 status 1/1
conn: max 0 active 0 attempts 0 success 0 drop 0 fail 0
vd root/0 vs vs/2 addr 10.31.101.20:80 status 1/1
conn: max 0 active 0 attempts 0 success 0 drop 0 fail 0
Many of the diagnostic commands involve retrieving information about one or more virtual servers. To control which servers are queried you can define a filter:
diagnose firewall vip virtual-server filter <filter_str>
Where <filter_str> can be:
- clear erase the current filter
- dst the destination address range to filter by
- dst-port the destination port range to filter by
- list display the current filter
- name the vip name to filter by
- negate negate the specified filter parameter
- src the source address range to filter by
- src-port the source port range to filter by
- vd index of virtual domain. -1 matches all
The default filter is empty, so no filtering is done.
Logging Diagnostics
The logging diagnostics provide information about two separate features:
diagnose firewall vip virtual-server log {console | filter}
Where
- console {disable | enable} enables or disables displaying the event log messages generated by virtual server traffic on the console to simplify debugging.
- filter sets a filter for the virtual server debug log
- The filter option controls what entries the virtual server daemon will log to the console if diagnose debug application vs level is non-zero. The filtering can be done on source, destination, virtual-server name, virtual domain, and so on:
diagnose firewall vip virtual-server log filter <filter_str>
Where <filter_str> can be
- clear erase the current filter
- dst the destination address range to filter by
- dst-port the destination port range to filter by
- list display the current filter
- name the virtual-server name to filter by
- negate negate the specified filter parameter
- src the source address range to filter by
- src-port the source port range to filter by
- vd index of virtual domain. -1 matches all
The default filter is empty, so no filtering is done.
Real server diagnostics
Enter the following command to list all the real servers:
diag firewall vip virtual-server real-server list
In the following example there is only one virtual server called slb and it has two real-servers:
diag firewall vip virtual-server server
vd root/0 vs slb/2 addr 172.16.67.191:80 status 1/1
conn: max 10 active 0 attempts 0 success 0 drop 0 fail 0
http: available 0 total 0
vd root/0 vs slb/2 addr 172.16.67.192:80 status 1/1
conn: max 10 active 1 attempts 4 success 4 drop 0 fail 0
http: available 1 total 1
The status indicates the administrative and operational status of the real-server.
- max indicates that the real-server will only allow 10 concurrent connections.
- active is the number of current connections to the server attempts is the total number of connections attempted success is the total number of connections that were successful.
- drop is the total number of connections that were dropped because the active count hit max.
- fail is the total number of connections that failed to complete due to some internal problem (for example, lack of memory).
If the virtual server has HTTP multiplexing enabled, then the HTTP section indicates how many established connections to the real-sever are available to service a HTTP request and also the total number of connections.
Comments
0 comments
Article is closed for comments.