Fortinet white logo
Fortinet white logo

Handbook

Using real server pools

Using real server pools

This section includes the following topics:

Configuring real server pools

Server pools are groups of real servers that host the applications that you load balance.

To configure a server pool:

  1. Create a server pool object.
  2. Add members.

Before you begin:

  • You must have a good understanding and knowledge of the backend server boot behavior, for example, how many seconds it takes to “warm up” after a restart before it can process traffic.
  • You must know the IP address and port of the applications.
  • If you want to select user-defined health checks, you must create them before creating the pool configuration. See Configuring health checks.
  • If you want to select user-defined real server SSL profiles, you must create them before creating the pool configuration. See Configuring real server SSL profiles.
  • You must have Read-Write permission for Load Balance settings.

After you have configured a real server pool, you can select it in the virtual server configuration.

To configure a pool:
  1. Go to Server Load Balance > Real Server Pool.
  2. The configuration page displays the Real Server tab.

  3. Click Create New to display the configuration editor.
  4. Complete the configuration and add members as described in Real Server Pool configuration guidelines.
  5. Save the configuration.

Real Server Pool configuration guidelines

Settings Guidelines
Real Server Pool
Name

Configuration name. Valid characters are A-Z, a-z, 0-9, _, and -. No spaces. You reference this name in the virtual server configuration.

Note: After you initially save the configuration, you cannot edit the name.

Address Type
  • IPv4
  • IPv6

Type

Static

Dynamic

  • Select "SDN Connector" which is created on "Global external connectors"
  • Select "Service"

IP Address Type

Select whether the SDN connector should get the private address or public address of the instances.

Available only when Type is Dynamic and FortiADC is deployed on public cloud platforms.

Health Check

Enable health checking for the pool. You can override this for individual servers in the pool.

Health Check Relationship
  • AND—All of the selected health checks must pass for the server to the considered available.
  • OR—One of the selected health checks must pass for the server to be considered available.
Health Check List

Select one or more health check configuration objects.

Real Server SSL Profile

Select a real server SSL profile. Real server profiles determine settings for communication between FortiADC and the backend real servers. The default is NONE, which is applicable for non-SSL traffic.

Member
Status
  • Enable—The server can receive new sessions.
  • Disable—The server does not receive new sessions and closes any current sessions as soon as possible.
  • Maintain—The server does not receive new sessions but maintains any current connections.
Real Server

Click the down arrow and select a real server configuration object from the list menu.

Note: The name of the selected real server pool member will appear in logs and reports.

Port

Enter the backend server's listening port (number), as described below:

  • HTTP—80,
  • HTTPS —443
  • FTP—21
  • SMTP—25
  • DNS—53
  • POP3—110
  • IMAP4—143
  • RADIUS—1812
  • SNMP—161

Tip: The system uses Port 0 as a “wildcard” port. When configured to use Port 0, the system uses the destination port from the client request. For example, if you specify 0, and the destination port in the client request is 50000, the traffic will be forwarded to Port 50000.

Weight

Assigns relative preference among members—higher values are more preferred and are assigned connections more frequently. The default is 1. The valid range is 1 to 256.

All load balancing methods consider weight. Servers are dispatched requests proportional to their weight, relative to the sum of all weights.

The following example shows the effect of weight on Round Robin:

  • Sever A, Weight 2; Server B, Weight 1: Requests are sent AABAAB.
  • Sever A, Weight 3; Server B, Weight 2: Requests are sent AABAB.

For other methods, weight functions as a tie-breaker. For example, with the Least Connection algorithm, requests are sent to the server with the least connections. If the number of connections is equal, the request is sent to the server with the greater weight. For example:

  • Server A, Weight 1, 1 connection
  • Server B, Weight 2, 1 connection
  • The next request is sent to Server B.
Recover

Seconds to postpone forwarding traffic after downtime, when a health check indicates that this server has become available again. The default is 0 (disabled). The valid range is 1 to 86,400 seconds. After the recovery period elapses, the FortiADC assigns connections at the warm rate.

Examples of when the server experiences a recovery and warm-up period:

  • A server is coming back online after the health check monitor detected it was down.
  • A network service is brought up before other daemons have finished initializing and therefore the server is using more CPU and memory resources than when startup is complete.

To avoid connection problems, specify the separate warm-up rate, recovery rate, or both.

Tip: During scheduled maintenance, you can also manually apply these limits by setting Status to Maintenance instead of Enable.

Note: Not applicable for SIP servers.

Warm Up

If the server cannot initially handle full connection load when it begins to respond to health checks (for example, if it begins to respond when startup is not fully complete), indicate how long to forward traffic at a lesser rate. The default is 0 (disabled). The valid range is 1 to 86,400 seconds.

Note: Not applicable for SIP servers.

Warm Rate

Maximum connection rate while the server is starting up. The default is 10 connections per second. The valid range is 1 to 86,400 connections per second.

The warm up calibration is useful with servers that have the network service brought up before other daemons have finished initializing. As the servers are brought online, CPU and memory are more utilized than they are during normal operation. For these servers, you define separate rates based on warm-up and recovery behavior. For example, if Warm Up is 5 and Warm Rate is 2, the number of allowed new connections increases at the following rate:

  • 1st second—Total of 2 new connections allowed (0+2).
  • 2nd second—2 new connections added for a total of 4 new connections allowed (2+2).
  • 3rd second—2 new connections added for a total of 6 new connections allowed (4+2).
  • 4th second—2 new connections added for a total of 8 new connections allowed (6+2).
  • 5th second—2 new connections added for a total of 10 new connections allowed (8+2).

Note: Not applicable for SIP servers.

Connection Limit

Maximum number of concurrent connections to the backend server. The default is 0 (disabled). The valid range is 1 to 1,048,576 concurrent connections.

Note: Connection Limit is not supported for FTP or SIP servers.

Connection Rate Limit

Limit the number of new connections per second to this server. The default is 0 (disabled). The valid range is 1 to 86,400 connections per second.

In Layer 4 deployments, you can apply a connection rate limit per real server and per virtual server. Both limits are enforced.

Note: The connection rate limit applies only when the real servers belong to a Layer 4 virtual server. If you add a real server pool with this setting configured to a Layer 7 virtual server, for example, the setting is ignored.

Note: Connection Rate Limit is not supported for FTP or SIP servers.

Cookie

Specify the cookie name to be used when cookie-based Layer 7 session persistence is enabled. The cookie is used to create a FortiADC session ID, which enables the system to forward subsequent related requests to the same backend server.

If you do not specify a cookie name, it is set to the pool member server name string.

Note: This option is NOT applicable for SIP servers.

MySQL Group ID

Specify the MySQL group ID.

MySQL Read Only

Disabled by default. Select the button to enable it.

Backup

Designate this as a backup server to which FortiADC will direct traffic when the other servers in the pool are down. The backup server receives connections when all the other pool members fail the health check or you have manually disabled them.

Note: Not applicable for SIP servers.

Health Check Inherit When enabled, FortiADC will use the pool's health check settings. If disabled, you must select a health check to use with this individual backend server. See below.
Health Check

Select this option to specify a health check configuration object for this server.

Note: This option becomes available only when

Health Check Relationship
  • AND—All of the selected health checks must pass for the server to the considered available.
  • OR—One of the selected health checks must pass for the server to be considered available.
Health Check List Select one or more health check configuration objects. Shift-click to select multiple objects at the same time.
RS Profile Inherit Enable to inherit the real server SSL profile from the pool configuration. Disable to specify the real server profile in this member configuration. See below.
RS Profile

If RS Profile Inherit (above) is disabled, you must specify a real server SSL profile. A real server SSL profile determines the settings for communication between FortiADC and backend real server.

Note: This option becomes available only when RS Profile Inherit is disabled.

Proxy Protocol

This is a protocol of application layer, which is located upper layer of HTTP and SSL, and it contains a head to description the real IP address of client. There two major version of this protocol v1 and v2.

Support none, v1, v2. None will disable this function and it’s the default value, v1 and v2 is different version of this protocol, the v1 version is human readable.

You need co-deployment with ForitWeb, and because X-Forword-For option isn’t valid for them they demand use proxy protocol to deliver the real client’s IP address to them.

Only support : HTTP/HTTPS/TCPS/RDP, Either L7 and L2 VS of these type can support it.

Example: Using port ranges and the port 0 configuration

In some deployments, it is advantageous to support listening port ranges for client requests. For example, data centers or web hosting companies sometimes use port numbers to identify their customers. Client A sends requests to port 50000, client B to port 50001, client C to port 50002, and so on.

To support this scenario:
  1. On the real servers, configure the listening ports and port ranges according to your requirements.
  2. On the FortiADC, when you configure the real server pool member, specify port 0 for the port. The system handles port 0 as a “wildcard” port. When configured to use port 0, the system uses the destination port from the client request. For example, if you specify 0, and the destination port in the client request is 50000, the traffic is forwarded to port 50000.
  3. When you configure the virtual server, specify a listening port and port range. The port range is like an offset. If the specified port is 50000 and the port range is 10, the virtual server listens on ports 50000-50009.

Key FortiADC configuration elements

Note: Ports shown on the Dashboard > Virtual Server > Real Server page are for the configured port, so in this case, port 0. The ports shown in traffic logs are the actual destination port, so in this case, port 50000.

Note: The real-server port must be 0 or the same as the virtual server port for Layer-4 virtual servers in tunnel mode.

Using real server pools

Using real server pools

This section includes the following topics:

Configuring real server pools

Server pools are groups of real servers that host the applications that you load balance.

To configure a server pool:

  1. Create a server pool object.
  2. Add members.

Before you begin:

  • You must have a good understanding and knowledge of the backend server boot behavior, for example, how many seconds it takes to “warm up” after a restart before it can process traffic.
  • You must know the IP address and port of the applications.
  • If you want to select user-defined health checks, you must create them before creating the pool configuration. See Configuring health checks.
  • If you want to select user-defined real server SSL profiles, you must create them before creating the pool configuration. See Configuring real server SSL profiles.
  • You must have Read-Write permission for Load Balance settings.

After you have configured a real server pool, you can select it in the virtual server configuration.

To configure a pool:
  1. Go to Server Load Balance > Real Server Pool.
  2. The configuration page displays the Real Server tab.

  3. Click Create New to display the configuration editor.
  4. Complete the configuration and add members as described in Real Server Pool configuration guidelines.
  5. Save the configuration.

Real Server Pool configuration guidelines

Settings Guidelines
Real Server Pool
Name

Configuration name. Valid characters are A-Z, a-z, 0-9, _, and -. No spaces. You reference this name in the virtual server configuration.

Note: After you initially save the configuration, you cannot edit the name.

Address Type
  • IPv4
  • IPv6

Type

Static

Dynamic

  • Select "SDN Connector" which is created on "Global external connectors"
  • Select "Service"

IP Address Type

Select whether the SDN connector should get the private address or public address of the instances.

Available only when Type is Dynamic and FortiADC is deployed on public cloud platforms.

Health Check

Enable health checking for the pool. You can override this for individual servers in the pool.

Health Check Relationship
  • AND—All of the selected health checks must pass for the server to the considered available.
  • OR—One of the selected health checks must pass for the server to be considered available.
Health Check List

Select one or more health check configuration objects.

Real Server SSL Profile

Select a real server SSL profile. Real server profiles determine settings for communication between FortiADC and the backend real servers. The default is NONE, which is applicable for non-SSL traffic.

Member
Status
  • Enable—The server can receive new sessions.
  • Disable—The server does not receive new sessions and closes any current sessions as soon as possible.
  • Maintain—The server does not receive new sessions but maintains any current connections.
Real Server

Click the down arrow and select a real server configuration object from the list menu.

Note: The name of the selected real server pool member will appear in logs and reports.

Port

Enter the backend server's listening port (number), as described below:

  • HTTP—80,
  • HTTPS —443
  • FTP—21
  • SMTP—25
  • DNS—53
  • POP3—110
  • IMAP4—143
  • RADIUS—1812
  • SNMP—161

Tip: The system uses Port 0 as a “wildcard” port. When configured to use Port 0, the system uses the destination port from the client request. For example, if you specify 0, and the destination port in the client request is 50000, the traffic will be forwarded to Port 50000.

Weight

Assigns relative preference among members—higher values are more preferred and are assigned connections more frequently. The default is 1. The valid range is 1 to 256.

All load balancing methods consider weight. Servers are dispatched requests proportional to their weight, relative to the sum of all weights.

The following example shows the effect of weight on Round Robin:

  • Sever A, Weight 2; Server B, Weight 1: Requests are sent AABAAB.
  • Sever A, Weight 3; Server B, Weight 2: Requests are sent AABAB.

For other methods, weight functions as a tie-breaker. For example, with the Least Connection algorithm, requests are sent to the server with the least connections. If the number of connections is equal, the request is sent to the server with the greater weight. For example:

  • Server A, Weight 1, 1 connection
  • Server B, Weight 2, 1 connection
  • The next request is sent to Server B.
Recover

Seconds to postpone forwarding traffic after downtime, when a health check indicates that this server has become available again. The default is 0 (disabled). The valid range is 1 to 86,400 seconds. After the recovery period elapses, the FortiADC assigns connections at the warm rate.

Examples of when the server experiences a recovery and warm-up period:

  • A server is coming back online after the health check monitor detected it was down.
  • A network service is brought up before other daemons have finished initializing and therefore the server is using more CPU and memory resources than when startup is complete.

To avoid connection problems, specify the separate warm-up rate, recovery rate, or both.

Tip: During scheduled maintenance, you can also manually apply these limits by setting Status to Maintenance instead of Enable.

Note: Not applicable for SIP servers.

Warm Up

If the server cannot initially handle full connection load when it begins to respond to health checks (for example, if it begins to respond when startup is not fully complete), indicate how long to forward traffic at a lesser rate. The default is 0 (disabled). The valid range is 1 to 86,400 seconds.

Note: Not applicable for SIP servers.

Warm Rate

Maximum connection rate while the server is starting up. The default is 10 connections per second. The valid range is 1 to 86,400 connections per second.

The warm up calibration is useful with servers that have the network service brought up before other daemons have finished initializing. As the servers are brought online, CPU and memory are more utilized than they are during normal operation. For these servers, you define separate rates based on warm-up and recovery behavior. For example, if Warm Up is 5 and Warm Rate is 2, the number of allowed new connections increases at the following rate:

  • 1st second—Total of 2 new connections allowed (0+2).
  • 2nd second—2 new connections added for a total of 4 new connections allowed (2+2).
  • 3rd second—2 new connections added for a total of 6 new connections allowed (4+2).
  • 4th second—2 new connections added for a total of 8 new connections allowed (6+2).
  • 5th second—2 new connections added for a total of 10 new connections allowed (8+2).

Note: Not applicable for SIP servers.

Connection Limit

Maximum number of concurrent connections to the backend server. The default is 0 (disabled). The valid range is 1 to 1,048,576 concurrent connections.

Note: Connection Limit is not supported for FTP or SIP servers.

Connection Rate Limit

Limit the number of new connections per second to this server. The default is 0 (disabled). The valid range is 1 to 86,400 connections per second.

In Layer 4 deployments, you can apply a connection rate limit per real server and per virtual server. Both limits are enforced.

Note: The connection rate limit applies only when the real servers belong to a Layer 4 virtual server. If you add a real server pool with this setting configured to a Layer 7 virtual server, for example, the setting is ignored.

Note: Connection Rate Limit is not supported for FTP or SIP servers.

Cookie

Specify the cookie name to be used when cookie-based Layer 7 session persistence is enabled. The cookie is used to create a FortiADC session ID, which enables the system to forward subsequent related requests to the same backend server.

If you do not specify a cookie name, it is set to the pool member server name string.

Note: This option is NOT applicable for SIP servers.

MySQL Group ID

Specify the MySQL group ID.

MySQL Read Only

Disabled by default. Select the button to enable it.

Backup

Designate this as a backup server to which FortiADC will direct traffic when the other servers in the pool are down. The backup server receives connections when all the other pool members fail the health check or you have manually disabled them.

Note: Not applicable for SIP servers.

Health Check Inherit When enabled, FortiADC will use the pool's health check settings. If disabled, you must select a health check to use with this individual backend server. See below.
Health Check

Select this option to specify a health check configuration object for this server.

Note: This option becomes available only when

Health Check Relationship
  • AND—All of the selected health checks must pass for the server to the considered available.
  • OR—One of the selected health checks must pass for the server to be considered available.
Health Check List Select one or more health check configuration objects. Shift-click to select multiple objects at the same time.
RS Profile Inherit Enable to inherit the real server SSL profile from the pool configuration. Disable to specify the real server profile in this member configuration. See below.
RS Profile

If RS Profile Inherit (above) is disabled, you must specify a real server SSL profile. A real server SSL profile determines the settings for communication between FortiADC and backend real server.

Note: This option becomes available only when RS Profile Inherit is disabled.

Proxy Protocol

This is a protocol of application layer, which is located upper layer of HTTP and SSL, and it contains a head to description the real IP address of client. There two major version of this protocol v1 and v2.

Support none, v1, v2. None will disable this function and it’s the default value, v1 and v2 is different version of this protocol, the v1 version is human readable.

You need co-deployment with ForitWeb, and because X-Forword-For option isn’t valid for them they demand use proxy protocol to deliver the real client’s IP address to them.

Only support : HTTP/HTTPS/TCPS/RDP, Either L7 and L2 VS of these type can support it.

Example: Using port ranges and the port 0 configuration

In some deployments, it is advantageous to support listening port ranges for client requests. For example, data centers or web hosting companies sometimes use port numbers to identify their customers. Client A sends requests to port 50000, client B to port 50001, client C to port 50002, and so on.

To support this scenario:
  1. On the real servers, configure the listening ports and port ranges according to your requirements.
  2. On the FortiADC, when you configure the real server pool member, specify port 0 for the port. The system handles port 0 as a “wildcard” port. When configured to use port 0, the system uses the destination port from the client request. For example, if you specify 0, and the destination port in the client request is 50000, the traffic is forwarded to port 50000.
  3. When you configure the virtual server, specify a listening port and port range. The port range is like an offset. If the specified port is 50000 and the port range is 10, the virtual server listens on ports 50000-50009.

Key FortiADC configuration elements

Note: Ports shown on the Dashboard > Virtual Server > Real Server page are for the configured port, so in this case, port 0. The ports shown in traffic logs are the actual destination port, so in this case, port 50000.

Note: The real-server port must be 0 or the same as the virtual server port for Layer-4 virtual servers in tunnel mode.