Defining your pool of back-end servers
Before FortiADC can distribute connection requests from clients, it must first know the IP addresses of your servers. To define you server farm, first define the methods that FortiADC will use to monitor each server for availability (see
“Monitoring your servers’ responsiveness”), then go to
Server Load Balance > Resources > Pool.
When adding each back-end server in the pool definition, you can define separate connection limits that FortiADC will use while a server is not yet ready to handle full capacity (a “warm-up rate”), such as while returning online again after the health check monitor detected downtime.
For example, if this network service is brought up before other daemons have finished initializing, and therefore the server’s CPU and memory are more utilized than they will be after startup is complete, you would define a separate warm-up rate and/or recovery rate. During scheduled maintenance, you can also manually apply these limits by setting Status to Maintenance instead of Enable.
You can also specify whether FortiADC will use SSL or TLS in its connection with the back-end server. (Sometimes this is called “re-encryption” because FortiADC terminated and decrypted the connection on the client side.) For details, see
“How to re-encrypt SSL/TLS to back-end servers”.
If you use Layer 7 session persistence with a back-end server, FortiADC will inject an HTTP cookie whose name you can configure in
Cookie. This contains the FortiADC session ID and will enable the appliance to forward subsequent related reqests to the same back-end server.
| To prevent session tampering, use a web application firewall such as FortiWeb. Failure to do so could compromise the continuity of sessions and allow attackers to hijack other clients’ sessions. While the FortiADC session cookie is only used for routing, many web applications also use session cookies which are more sensitive, such as for authentication. |