The tab explains the server settings for the pool. You can select the servers either by IP address, range, DNS name or by IP group.
In Create Pool window, click Servers tab.
You can set the following details in Servers tab while creating a pool.
Select Servers By: Select the servers either by IP address, range, DNS name or by IP group.
If you select IP Address, Range or DNS Name option, then you can
Specify the IP address of a server. You may also enter a range of IP addresses using a dash, such as 10.0.0.1-10.0.0.20.
Specify the FQDN of the server you want to add. If the server successfully resolves, the IP address will appear and the ADD button will change to blue. Click the ADD button to add it to the pool server list.
Rather than add individual servers to a pool one at a time, multiple servers may be added in one step by storing their IP addresses in a comma-separated IP Group. This may be useful if the same list is used elsewhere for IP allowlists, DataScripts, or similar automation purposes. However, be advised that many common pool features are unavailable when using this method, such as manually deactivating a server, setting a specific service port, or setting a ratio. The IP Group method for adding servers may not be used with other methods. If you select IP Group option, then you can select the required option from the drop-down menu. The following are the options available in the drop-down menu:
ANZ
APJ
dos-attacker-countries
embargo-countries
EMEA
Internal
Internal Only
LATAM
UAG Servers
US
You can also add servers by network, by clicking BY NETWORK button. You can select network to open a list of servers (virtual machines) available on that network. Provide an optional search filter, such as apache, and select servers matching the search criteria. Select the servers and click ADD button to include the new servers in the pool. The results returned are filtered by the network selected. If a server has multiple IP addresses in the network, the server shows up in the list multiple times. Similarly, if the server has an NIC in the network, but no valid IP address, it is not shown in the returned list of servers.
Adding servers using the above method allows the Avi Load Balancer to provide significantly richer information regarding the server. The Avi Load Balancer is able to query vCenter for the server or virtual machine’s CPU, memory, and disk utilization. This is useful for better load balancing and visibility, and is the best-practice method for adding servers. When adding servers by IP address, the Controller might not be able to associate the IP against a virtual machine in VMware, and therefore might not be able to gather this data. After a server has been added through the Select by Network method, the server’s Network column in the server list table is populated with the network or port group.
Server Deactivation Type: You can set server graceful deactivate timeout behaviour by selecting one of the following options. This is applicable only when Graceful Deactivate Timeout is enabled.
Allow New Connections: Select one or more deactivated servers, and then reactivate them by clicking the Enable button. Enabling a server makes that server immediately available for load balancing, provided it passes its first health check.
Note:Allow new connections during Graceful deactivate timeout is allowed only if persistence entry is present.
Disallow New Connections: Select one or more enabled servers to deactivate. Avi Load Balancer immediately marks a disabled server as unavailable for new connections and resets any existing client connections. A server will not receive health checks while it is in a disabled state. The reset will happen only after timeout is configured in Graceful Deactivate Timeout.
Servers added to the pool can be modified by editing theirIP Address, Port, or Ratio fields.
Status: The status of a server may be Enabled or Deactivated.
Server Name: Name of the server (or the IP address, if the server was added manually).
IP Address: Changing the IP address for an existing server will reset any existing connections for the server.
Port: This optional field overrides the default service port number for the pool by giving server a specific port number that might differ from the other servers in the pool.
Ratio: This optional field creates an unequal distribution of traffic to a server relative to its peers. The ratio is used with the load balancing algorithm. For instance, If Server A has a Ratio of two and Server B has a Ratio of one, then Server A will receive two connections for every one connection that is sent to Server B. The Ratio may be any number between 1-20.
Note:The Ratio is statically assigned to servers. Dynamic load balancing algorithms work with Ratio but may produce inexact results with Ratio, and are not recommended for normal environments. The ratio is most commonly used to send a small sampling of traffic to a test server (such as one running a newer, untested version of code).
Graceful Deactivate Timeout: Specify timeout value ranging from 1 through 7,200 minutes used to gracefully deactivate a back-end server. The virtual Service will wait for the specified time before terminating the existing connections to deactivated servers.
0 causes immediate termination
-1 (negative one, standing for “infinite”) never terminates.
The Graceful Deactivate Timeout parameter set for a pool governs how servers within the pool are deactivated as follows:
Deactivate with immediate effect: All client sessions are immediately terminated. The pool’s Graceful Deactivate Timeout parameter must be set to 0.
Gracefully deactivate with a finite timeout: No new sessions are sent to the server. Existing sessions are allowed to terminate on their own, up to the specified timeout. Once the timeout is reached, any remaining sessions are immediately terminated. The pool’s Graceful Deactivate Timeout parameter must range from 1-7200 minutes.
Gracefully deactivate with infinite timeout: No new sessions are sent to the server. All existing sessions are allowed to terminate on their own. The pool’s Graceful Deactivate Timeout parameter must be set to
-1.When servers are gracefully deactivated with a timeout value, the idle connections are closed immediately, while any busy or bound connection will be closed at the end of the timeout. Any existing request will be processed until the end of the timeout. Any new requests, whether from an existing connection or a new connection, will be sent to a new server.
You can configure how the pool server must behave when it is deactivated through the CLI as follows:
Use disallow_new_connection to specify that a node or pool member allows existing connections to time out but to not allow new connections, as shown below:
configure pool <pool name> server_disable_type disallow_new_connection save
Use allow_new_connection_if_persistence_present to disallow the allocation of new connections with persistence deactivated, as shown below:
configure pool <pool name> server_disable_type allow_new_connection_if_persistence_present save
When allow_new_connection_if_persistence_present is configured, the timer is refreshed if a disabled server is picked from the persist table.
When deactivated, the node or pool member continues to process persistent and active connections. New connections can be accepted only if the connections belong to an existing persistent connection. These persistence matches for new connections continue until persistence times out.
Health Monitor Graceful Deactivate Timeout: Specify the time interval for gracefully closing the connections on server, when the health monitoring marks the server down. The data connections present on that server will be closed after a configured graceful_hm_down_disable_timeout time interval value. By default configured value is -1(infinite), which is no close. Configured value, 0 will close connections immediately. The unit of timeout for this field is second.
When the server is marked down by maintenance reason, Graceful Deactivate Timeout configured value will be used to close connections, instead of Health Monitor Graceful Deactivate Timeout. By default graceful deactivate timeout value is 1 minute. So server down by maintenance reasons will close connections on this server by default after 1 minute.
The CLI configuration for Health Monitor Graceful Deactivate Timeout is as follows:
[admin:ctrl1]: > configure pool pool1 [admin:ctrl1]: pool> graceful_hm_down_disable_timeout INTEGER 1-432000 Time interval for gracefully closing the connections on server, When health monitoring marks the server down.
Enable HTTP2: Check this box to enable HTTP/2 for traffic from virtual service to all backend servers in this pool.
Lookup Server by Name: Check this box to allow server lookup by name.
Rewrite Host Header to Server Name: Check this box to rewrite incoming host header to server name to which the request is proxied. Enabling this feature rewrites Host Header for requests to all servers in the pool.
When proxying a request to a back-end server through Avi Load Balancer, an SE can rewrite the host header to the server name of the back end server to which the request is forwarded. This functionality can be turned on for selected or all servers in the pool.
Using rewrite_host_header_to_server_name with rewrite_host_header_to_sni: Below are the few observations which clarifies how rewrite_host_header_to_server_name interacts with rewrite_host_header_to_sni.
For Non-SSL back-end servers:
rewrite_host_header_to_snihas no effect on the non-SSL back-end servers. Host Header is set according to therewrite_host_header_to_server_nameflag.For SSL back-end servers with the
TLS SNI Enabledflag set asOFF: Therewrite_host_header_to_snihas no effect. The Host header is set according to therewrite_host_header_to_server_nameflag.For SSL back-end servers with the
TLS SNI Enabledflag set asON: Incoming Host Header = Abc.com.
The following combination of the configuration options is not supported because the SNI name used in the SSL handshake, and the host header used in the request do not match.
The
TLS SNI Enabledflag is set asON.SNI name is configured in the pool, while the
rewrite_host_header_to_server_nameoption isenabled.
Append Port To Host Name: You can allow the option to append port to hostname in the host header while sending a request to the server. By default, port is appended for non default ports. This setting will apply for pool's 'Rewrite Host Header to SNI' features and server's 'Rewrite Host Header' setting as well as HTTP health monitors attached to pools. Select one of the following options:
Never
Always
Non Default (80,443). By default, this option is selected.
Deactivate Port Translation: Check this box to not translate the client's destination port when sending the connection to the server. You need to specify monitor port for health monitors.
Use Service SSL Mode: This is applicable only when use_service_port/ Deactivate Port Transalation is set to True. If you check this box, the SSL mode of the connection to the server is decided by the SSL mode on the virtual service port on which the request was received.
Ignore Server Port: Check this box to ignore the server port in building the load balancing state. This is applicable only for consistent hash load balancing algorithm or 'Deactivate Port Translation' (use_service_port) use cases.
The Ignore Server Port option is only relevant when the pool is configured to use the consistent hash load balancing algorithm or when Deactivate Port Translation is set. When Ignore Server Port is enabled, the consistent hash algorithm considers only the server IP address and ignores the server port, resulting in the same server being selected across pools with the same pool members but different server ports.
HTTP Server Reselect: Check this box to enable HTTP request reselect when server responds with specific response codes. This field is deactivated by default. The feature can be configured within individual pools. You optionally select the error codes that trigger the feature. Once enabled, the feature works in all connection or SSH failure scenarios.
HTTP server reselect applies only to idempotent request methods, since a given request of this type always has the same result, even if an identical request is received multiple times by a server. Multiple identical requests of non-idempotent request methods (POST, LOCK, PATCH, and CONNECT) are by definition, not guaranteed to have the same effect as that of single such requests. So, HTTP server reselect is not performed for these request methods.
HTTP Response Codes: Specify server response codes which will trigger an HTTP request retry. The pool configuration specifies the HTTP error response codes that must result in server reselection. The error codes can be specified in any of the following ways.
Explicit code number(s): Specify one or more individual error codes (for instance, 404).
Range of codes: Specify a range between 400-499 or 500 and 599 (for instance, 501-503).
Entire block of codes: 4xx or 5xx (for instance, 4xx).
Number of Retries: Specify the count to retry an HTTP request when the server responds with configured status codes. By default, it is set to four. Following the first error response, the Avi Load Balancer resends the request to the pool up to four more times, for a total of five attempts. Each retry is sent to a different server, and each server can receive only one attempt.
If the setting for maximum retries is higher than the number of enabled and running servers within the pool, each of those servers still receives only one attempt. For instance, if maximum retries is set to four, but the pool has only three servers, the maximum number of retries is only two. The initial attempt that fails goes to one of the servers, leaving two more servers to try. If the second server also sends a 4xx or 5xx error code in response to the request, the request is sent to the last server in the pool. If the last server also sends a 4xx or 5xx, the response from the server is sent back to the client.
Server Retry Timeout: Specify timeout per retry attempt for a given request. By default, it is set to zero. The srv_retry_timeout variable can be set through the Avi Load Balancer REST API or CLI. Ensure that server_reselect.enabled is set to
Truefor the srv_retry_timeout variable setting to take effect. The timeout range is 0-3600000 ms (60 minutes). A value of zero causes the timeout to default to the connection timeout value.
Based on this configuration, if a server in this pool responds to a client request with a 4xx error code, the Avi Load Balancer retries the request by sending it to another server in the pool. The retry process can happen up to four times (to four different servers).
CLI Example
Only significant lines of interest from the CLI output are included in the following example.
[admin:10-10-27-18]: > configure pool vs-test-pool Updating an existing object. Currently, the object is: +---------------------------------------+------------------------------------------------+ | Field | Value | +---------------------------------------+------------------------------------------------+ | uuid | pool-8e91b1a6-17bf-490e-b59a-05efd942a3f6 | | name | vs-test-pool | . . . . . . | server_reselect | | | enabled | False | | num_retries | 4 | | retry_nonidempotent | False | | srv_retry_timeout | 0 milliseconds | . . . . . . +---------------------------------------+------------------------------------------------+ [admin:10-10-27-18]: pool> server_reselect enabled [admin:10-10-27-18]: pool:server_reselect> srv_retry_timeout 5000 Overwriting the previously entered value for srv_retry_timeout [admin:10-10-27-18]: pool:server_reselect> save [admin:10-10-27-18]: pool> exit +---------------------------------------+------------------------------------------------+ | Field | Value | +---------------------------------------+------------------------------------------------+ | uuid | pool-8e91b1a6-17bf-490e-b59a-05efd942a3f6 | | name | vs-test-pool | . . . . . . | server_reselect | | | enabled | True | | num_retries | 4 | | retry_nonidempotent | False | | srv_retry_timeout | 5000 milliseconds | . . . . . . +---------------------------------------+------------------------------------------------+ [admin:10-10-27-18]: > configure pool vs-test-pool server_reselect [admin:10-10-27-18]: pool:server_reselect> no enabled +---------------------+-------------------+ | Field | Value | +---------------------+-------------------+ | enabled | False | | num_retries | 4 | | retry_nonidempotent | False | | srv_retry_timeout | 5000 milliseconds | +---------------------+-------------------+ [admin:10-10-27-18]: pool:server_reselect> srv_retry_timeout 0 Overwriting the previously entered value for srv_retry_timeout [admin:10-10-27-18]: pool:server_reselect> save [admin:10-10-27-18]: pool> save +---------------------------------------+------------------------------------------------+ | Field | Value | +---------------------------------------+------------------------------------------------+ | uuid | pool-8e91b1a6-17bf-490e-b59a-05efd942a3f6 | | name | vs-test-pool | . . . . . . | server_reselect | | | enabled | False | | num_retries | 4 | | retry_nonidempotent | False | | srv_retry_timeout | 0 milliseconds | . . . . . . +---------------------------------------+------------------------------------------------+ [admin:10-10-27-18]: >
