A server is attached to a cluster via a server pool. A server pool is a collection of server definitions, each of which has additional parameters assigned to it in the server pool -- these additional parameters are organized by the server’s name and are referred to as server instances within the server pool context. This allows you to associated a distinct set of server instance options (weight, flags, maximum number of connections), to multiple instances of the same real server in different server pools.
Server Instance Flags
A flag may be turned off by prefixing with "!".
| hot_spare | Enable the hot spare check box if you plan to use this server as a backup server, in case the other server instances in a server pool on the cluster fail. Enabling hot spare forces FortiADC to direct incoming connections to this server only if all the other servers in the cluster are down. You should only configure one server in a cluster as a hot spare.persist_override - Disables persistence for the server when the persist flag (Layer 7 cluster) or a non-zero sticky time (Layer 4 cluster) is set on a cluster. For a Layer 7 cluster, this means that a cookie will not be inserted into the response header when returned to the client. No sticky record is set for a Layer 4 cluster. This flag is usually used to disable persistence for a hot spare. |
| quiesce | When enabled, FortiADC avoids sending new requests to the server. This is usually used in preparation for shutting down an HTTP or HTTPS server, and is sometimes also called “server draining”. |
| probe_l4 | This flag enables or disables Layer 4 TCP and ACV probes for this server. By default this flag is enabled. |
| strict_maxconn | This flag allows you to customize the behavior of the max connections parameter |
Health Check Instance Flags
A flag may be turned off by prefixing with "!".
|
require_response |
When the require_response flag is disabled (the default) and no response is received from the server application, then load balancing decisions are made without considering the health check’s returned load value. When the require_response flag is enabled and no response is received from the server application, then the server is marked down and no cluster traffic is sent to it. |
Server instance specific commands can be applied to multiple server instances by entering a comma-separated list of server instance names on the command line. For example, to set the weight to 125 on three server instances (sv01, sv02, sv03) in server pool sp01, you could enter a command like this:
|
eqcli > srvpool sp01 si sv01,sv02,sv03 weight 125 |
You can also change to an aggregate context that applies to multiple server instances, that allows you to display and modify the parameters for all the server instances. For example, you could change to an aggregate context for the three server instances in the previous example above using a command like the following:
|
eqcli > srvpool sp01 si sv01,sv02,sv03 eqcli sp-sp01-si-sv0*> |
The CLI is now in the aggregate server instance context “sv01,sv02,sv03” -- only the first three characters of which are displayed in the command line. To see the entire context name, use the context command:
|
eqcli sp-sp01-si-sv0*> context The context is “sv01,sv02,sv03”. eqcli sp-sp01-si-sv0*> |
In an aggregate server instance context, the show command will display the configuration of all the server instances in the context.
Load Balancing Policies
FortiADC supports the following load balancing policies, each of which is associated with a particular algorithm that FortiADC uses to determine how to distribute requests on a server pool in the cluster:
|
Load Balancing Policy |
Description |
|---|---|
|
round robin |
round robin load balancing distributes requests on the server pool in the cluster. FortiADC dispatches the first incoming request to the first server, the second to the second server, and so on. When FortiADC reaches the last server, it repeats the cycle. If a server in the cluster is down, FortiADC does not send requests to that server. This is the default method.
The round robin method does not support FortiADC’s adaptive load balancing feature; so, FortiADC ignores the servers’ initial weights and does not attempt to dynamically adjust server weights based on server performance. |
|
static weight |
static weight load balancing distributes requests among the servers depending on their assigned initial weights. A server with a higher initial weight gets a higher percentage of the incoming requests. Think of this method as aweighted round robin implementation. Static weight load balancing does not support FortiADC’s adaptive load balancing feature; FortiADC does not dynamically adjust server weights based on server performance. |
|
adaptive |
adaptive load balancing distributes the load according to the following performance indicators for each server.
|
|
fastest response load balancing |
fastest response load balancingdispatches the highest percentage of requests to the server with the shortest response time. FortiADC does this carefully: if FortiADC sends too many requests to a server, the result can be an overloaded server with slower response time. The fastest response policy optimizes the cluster-wide response time. The fastest response policy also checks the number of active connections and server agent values (if configured); but both of these have less of an influence than they do under the adaptive load balancing policy. For example, if a server’s active connection count and server agent values are high, FortiADC might not dispatch new requests to that server even if that server’s response time is the fastest in the cluster. |
|
least connections load balancing dispatches |
least connections load balancing dispatchesthe highest percentage of requests to the server with the least number of active connections. In the same way as Fastest Response, FortiADC tries to avoid overloading the server so it checks the server’s response time and server agent value. Least Connections optimizes the balance of connections to server pool in the cluster. |
|
server agent load balancing dispatches |
server agent load balancing dispatchesthe highest percentage of requests to the server with the lowest server agent value. In a similar way to Fastest Response, FortiADC tries to avoid overloading the server by checking the number of connections and response time. This method only works if server agents are running on the server pool in the cluster. |
FortiADC’s Load Balancing Response Settings
The responsiveness setting controls how aggressively FortiADC adjusts the servers’ dynamic weights. FortiADC provides five response settings: Slowest, Slow, Medium, Fast, and Fastest. The response setting affects the dynamic weight spread, weight spread coefficient, and optimization threshold that FortiADC uses when it performs adaptive load balancing:
Aggressive Load Balancing
After you fine-tune the initial weights of each server in the cluster, you might discover that FortiADC is not adjusting the dynamic weights of the servers at all: the dynamic weights are very stable, even under a heavy load. In this case, you might want to set the cluster’s load balancing response parameter to fast so that FortiADC tries to optimize the performance of your servers more aggressively. This should improve the overall cluster performance.
Dynamic Weight Oscillations
If you notice a particular server’s dynamic weight oscillates (for example, the dynamic weight varies from far below 100 to far above 100 and back again), you might benefit by choosing slow response for the cluster. You should also investigate the reason for this behavior; it is possible that the server application is behaving erratically.
Using Server Pool commands in the global context:
Related Topics