Server Load Balance
The Server Load Balance menu contain features and configurations that allow you to server load balance.
This section is organized into the following sub-menu topics:
- Virtual Server
- Application Resources
- Application Optimization
- Real Server Pool
- Scripting
- SSL-FP Resources
Server load balancing basics
An application delivery controller (ADC) is like an advanced server load balancer. An ADC routes traffic to available destination servers based on health checks and load-balancing algorithms. ADCs improve application availability and performance, which directly improves user experience.
The physical distance between clients and the servers in your backend server farm has a significant impact on server response times. Besides physical distance, the most important factors contributing to server performance are:
- Number of simultaneous connections and requests that the servers can handle
- Load distribution among the servers
The purpose of an ADC is to give you multiple methods for optimizing server response times and server capacity.
After you have deployed an ADC, traffic is routed to the ADC virtual server instead of the destination real servers.
Basic network topology shows an example of a basic load balancing deployment. The FortiADC appliance is deployed in front of a server farm, and the network interfaces are connected to three subnets: a subnet for management traffic; a subnet that hosts real servers A, B, and C; and a different subnet that hosts real servers D, E, and F. The FortiADC system performs health checks on the real servers and distributes traffic to them based on system logic and user-defined settings.
Optionally, you can further improve application security and performance by offloading system processes from the server and having them handled transparently by the ADC. Server tasks that can be handled by the FortiADC appliance include SSL encryption/decryption, WAF protection, Gzip compression, and routing processes, such as NAT.
FortiADC processing shows the order in which the FortiADC features process client-to-server and server-to-client traffic.
In the client-to-server direction:
- If SNI or SSL decryption is applicable, the system acts on those exchanges.
- Then, security module rules filter traffic, and traffic not dropped continues to the virtual server module.
- Virtual server security features are applied. Traffic not dropped continues for further processing.
- If a caching rule applies, the FortiADC cache serves the content and the request is not forwarded to a backend server.
- If the system selects a destination server based on a persistence rule, content route, or script, the load balancing rules are not applied.
- After selecting a server, the system performs any rewriting and re-encryption actions that are applicable, and then forwards the packets to the server.
In the server-to-client direction:
- WAF HTTP response, NAT, rewriting, persistence, and caching rules are applied.
- If applicable, the FortiADC compresses and encrypts the server response traffic.
Server load balancing configuration overview
The configuration object framework supports the granularity of FortiADC application delivery control rules. You can configure specific options and rules for one particular type of traffic, and different options and rules for another type.
Server load balancing configuration steps shows the configuration objects used in the server load balancing configuration and the order in which you create them.
Basic steps
- Configure health check rules and real server SSL profiles.
- Configure server pools.
- Configure persistence rules, optional features and policies, profile components, and load balancing methods.
- Configure the virtual server.
This step is optional. In many cases, you can use predefined health check rules and predefined real server SSL profiles. If you want to use custom rules, configure them before you configure the pools of real servers.
This step is required. Server pools are the backend servers you want to load balance and specify the health checks used to determine server availability.
You can skip this step if you want to select from predefined persistence rules, profiles, and methods.
When you configure a virtual server, you select from predefined and custom configuration objects.
Example workflow
For a members-only HTTPS web server farm, you might have a workflow similar to the following:
- Configure security module firewall rules that allow only HTTPS traffic from untrusted subnets to the virtual server.
- Import server SSL certificates, configure a local certificate group, and a certificate verification policy.
- Configure HTTPS health checks to test the availability of the web servers.
- Configure the server pools, referencing the health check configuration object.
- Configure authentication:
- Create a RADIUS or LDAP server configuration.
- Create user groups.
- Create an authentication policy.
- Predefined: WAF policy, Persistence, Method
- User-defined: Authentication Policy, Profile
