Server Load Balance
As an advanced application delivery controller (ADC), FortiADC supports load balancing for your application servers to enhance application availability and performance. After you have deployed the FortiADC, the traffic can be routed to the FortiADC virtual server and distributed among the destination real servers. To optimize server response times and server capacity, FortiADC can assign traffic based on various load-balancing algorithms and health checks to ensure application availability.
FortiADC's Server Load Balance functionality is supported by the following core modules that work in tandem to load-balance your application servers:
- Virtual Server — The Virtual Server module contains configurations to define the application delivery control, wherein three classes are supported: Layer 7, Layer 4, and Layer 2.
- Application Resources — The Application Resources module contains configurations to define the protocols and load-balancing methods that will be used to distribute traffic.
- Application Optimization — The Application Optimization module contains tools to further optimize application response times and server capacity, such as defining compression and caching rules.
- Real Server Pool — The Real Server Pool module contains configurations to define the destination real servers to direct the traffic.
Additional functionality such as HTTP scripting and SSL Forward Proxy is offered for advanced customization of your load-balancing needs.
- Scripting — Lua scripting is supported for HTTP/HTTPS applications to perform actions that are not supported by the current built-in feature set.
- SSL-FP Resources — FortiADC offers resources to support SSL Forward Proxy functionality, such as SSL decryption exceptions using L2 Exception Lists and Web Filtering, and Certificate Caching to enhance performance.
Basic network topology illustrates an example of a basic load balancing deployment. The FortiADC appliance is deployed in front of a server farm, where the network interfaces are connected to three subnets: 1) a subnet for management traffic; 2) a subnet that hosts the real servers A, B, and C; and 3) a different subnet that hosts the real servers D, e, and F. In this topology, the FortiADC system performs health checks on the real servers and distributes traffic to them according to the 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.
The FortiADC processing for application using HTTP illustrates the order in which the FortiADC features process Client-to-Server and Server-to-Client traffic in an HTTP application server.
FortiADC processing for application using HTTP
In the Client-to-Server direction:
-
If the SNI or SSL decryption is applicable, the system acts on those exchanges.
-
The security module rules filter the traffic. If the traffic is not dropped, it will continue to the virtual server module.
-
The virtual server security features are applied. If the traffic is not dropped, it will continue for further processing until it is forwarded to the server.
-
If a caching rule applies, the FortiADC cache serves the content and the request will not be forwarded to a backend server.
-
If the system selects a destination server based on a persistence rule, content route, or script, then the load-balancing rules will not be 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:
-
The server traffic reaches the virtual server where the WAF HTTP response, rewriting, persistence, and caching rules are applied.
-
If applicable, the FortiADC compresses and encrypts the server response traffic and forwards the packets to the client.
Server load balancing configuration overview
The FortiADC server load-balancing configuration framework is designed to be modular to support the granularity of the FortiADC application delivery control rules. This allows you to tailor configurations based on traffic type by specifying different options and rules for each type.
FortiADC provides a wide range of configuration options that allow you to customize your server load-balancing to your desired use-case. Many predefined options and configurations are also available to help you get started on load-balancing your application server. Be aware that some configurations and options are minimally required to run server load-balancing.
The steps below describes the basic configuration workflow for server load-balancing:
-
Configure health check rules and real server SSL profiles. For details, see Configuring health checks and Configuring real server SSL profiles.
This step is optional if you intend to use predefined health check rules and predefined real server SSL profiles. However, if you do intend to use custom health check rules and real server SSL profiles, ensure to configure them before you configure the pools of real servers. -
Configure real server pools. For details, see Using real server pools.
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. -
Configure persistence rules, optional features and policies, profile components, and load balancing methods. These configurations are all contained under the Application Resources module. For details, see Application Resources.
This step is optional if you intend to use predefined persistence rules, profiles, and methods. -
Configure the virtual server. For details, see Configuring virtual servers.
This step is required. In your virtual server configuration, you define the load-balancing rules by specifying the class of application delivery control (Layer 7, Layer 4, or Layer 2), and the persistence rules, profiles, and load-balancing methods to use to assign traffic. You can reference predefined or custom defined objects configured in previous steps.
Example workflow
For a members-only HTTPS web server farm, you may 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