The Create Pool popup and the Edit Pool popup share the same interface that consists of the following tabs:

  • Settings

  • Servers

  • Advanced

  • Review

Step 1: Settings

The Create/Edit Pool > Settings tab contains the basic settings for the pool. The exact options shown may vary depending on the types of clouds configured in NSX Advanced Load Balancer. For instance, servers in VMware may show an option to “Select Servers by Network”.



To add or edit Pool settings:

Field

Description

Name

Provide a unique name for the pool.

Default Server Port

New connections to servers will use this destination service port. The default port is 80, unless it is either inherited from the virtual service (if the pool was created during the same workflow), or the port was manually assigned. The default server port setting may be changed on a per-server basis by editing the Service Port field for individual servers in the Step2: Servers tab.

Graceful Disable Timeout

A time value ranging from 1 to 7,200 minutes used to gracefully disable a back-end server. The virtual service will wait for the specific time before terminating existing connections to disabled servers. To values are special: 0 causes immediate termination and -1 (negative one, standing for “infinite”) never terminates.

Load Balancing

Select a load-balancing algorithm from the pull-down menu. This choice determines the method and prioritization for distributing connections or HTTP requests across available servers. The available algorithms are:

  • Least Connections — New connections are sent to the server that currently has the least number of outstanding concurrent connections. This is the default algorithm when creating a new pool and is best for general-purpose servers and protocols. New servers with zero connections are introduced gracefully over a short period of time via the Connection Ramp setting in the Step 3: Advanced tab, which slowly brings the new server up to the connection levels of other servers within the pool.

    Note:

    A server that is having issues, such as rejecting all new connections, will have a concurrent connection count of zero and be the most eligible to receive all new connections that will fail. Use the Least Connections algorithm in conjunction with the Passive Health Monitor which recognizes and adjusts for scenarios like this.

  • Round Robin — New connections are sent to the next eligible server in the pool in sequential order. This static algorithm is best for basic load testing, but is not ideal for production traffic because it does not take the varying speeds or periodic hiccups of individual servers into account.

  • Least Load — New connections are sent to the server with the lightest load, regardless of the number of connections that server has. For instance, if an HTTP request that will require a 200kB response is sent to a server and a second request that will generate a 1kB response is sent to a server, this algorithm will estimate that —based on previous requests— the server sending the 1kB response is more available than the one still streaming the 200kB of data. The idea is to ensure that a small and fast request does not get queued behind a very long request. This algorithm is HTTP specific. For non-HTTP traffic, the algorithm will default to the Least Connections algorithm.

  • Fewest Servers — Instead of attempting to distribute all connections or requests across all servers, NSX Advanced Load Balancer will determine the fewest number of servers required to satisfy the current client load. Excess servers will no longer receive traffic and may be either de-provisioned or temporarily powered down. This algorithm monitors server capacity by adjusting the load and monitoring the server’s corresponding changes in response latency. Connections are sent to the first server in the pool until it is deemed at capacity, with the next new connections sent to the next available server down the line. This algorithm is best for hosted environments where virtual machines incur a cost.

  • Consistent Hash — New connections are distributed across the servers using a hash that is based on a key specified in the field that appears below the Load Balance field or (as of release 17.2.4) in a custom string. This algorithm inherently combines load balancing and persistence, which minimizes the need to add a persistence method. This algorithm is best for load balancing large numbers of cache servers with dynamic content. It is ‘consistent’ because adding or removing a server does not cause a complete recalculation of the hash table. For the example of cache servers, it will not force all caches to have to re-cache all content. If a pool has nine servers, adding a tenth server will cause the pre-existing servers to send approximately 1/9 of their hits to the newly-added server based on the outcome of the hash. Hence persistence may still be valuable. The rest of the server’s connections will not be disrupted. The available hash keys in the pull-down menu are:

    • Source IP Address of the client

    • Source IP Address and Port of the client

    • URI, which includes the host header and the path, e.g., www.acme.com/index.htm.

    • Callid — Supporting starting in release 17.2.10, this field specifies the call ID field within the SIP header. With this option, SIP transactions with new call IDs are load balanced using consistent hash, while existing call IDs are retained on the previously chosen servers. The state of existing call IDs are maintained for an idle timeout period defined by the ‘transaction timeout’ parameter in the application profile. The state of existing call IDs are relevant for as long as the underlying TCP/UDP transport state for the SIP transaction remains the same. For more information about SIP, refer to NSX Advanced Load Balancer for SIP Applications.

    • Custom String, which is provided by the user via the avi.pool.chash DataScript function.

    • Custom Header — Specify the HTTP header to use in the Custom Header field, such as referer. This field is case sensitive. If the field is blank or if the header does not exist, the connection or request is considered a miss, and will hash to a server.

  • Fastest Response — New connections are sent to the server that is currently providing the fastest response to new connections or requests. This is measured as time to first byte. In the End-to-End Timing chart, this is reflected as Server RTT plus App Response time. This option is best when the pool’s servers contain varying capabilities or they are processing short-lived connections. A server that is having issues, such as a lost connection to the data store containing images, will generally respond very quickly with HTTP 404 errors. It is best practice when using the fastest response algorithm to also enable a passive health monitor, which recognizes and adjusts for scenarios like this by taking into account the quality of server response, not just speed of response.

    Note:

    A server that is having issues, such as a lost connection to the data store containing images, will generally respond very quickly with HTTP 404 errors. You should therefore use the fastest response algorithm in conjunction with the passive health monitor, which recognizes and adjusts for scenarios such as this.There are several other factors beyond the load balancing algorithm that can affect connection distribution, such as connection multiplexing, server ratio, connection ramp, and server persistence.

  • Fewest Tasks — Load is adaptively balanced, based on server feedback. This algorithm is facilitated by an external health monitor. It is configurable via the NSX Advanced Load Balancer CLI and REST API, but is not visible in the NSX Advanced Load Balancer UI. For details, refer to the Fewest Tasks Load-Balancing Algorithm article.

  • Core Affinity — To Be Supplied.

Persistence

By default, NSX Advanced Load Balancer will load balance clients to a new server each time the client opens a new connection to a virtual service. There is no guarantee that the client will reconnect to the same server to which it was previously connected. A persistence profile ensures that subsequent connections from the same client will connect to the same server. Persistence can be thought of as the opposite of load balancing: a client’s first connection to NSX Advanced Load Balancer is load balanced; thereafter, that client and any connections made by it will be persisted to the same server for the desired duration of time. Persistent connections are critical for most servers that maintain client session information locally. For instance, many HTTP applications will keep a user’s information in memory for 20 minutes, which enables the user to continue their session by reconnecting to the same server. As a best practice, HTTP virtual services requiring persistence should use HTTP cookies, while general TCP or UDP applications requiring persistence will use the client’s source IP. For more information on persistence types, refer to the [Persistence Profile] article.

AutoScale Policy

  • Name — Name chosen for the policy.

  • Instances — The minimum and maximum number of instances that can be running at any given time. The default minimum is zero. The maximum permitted is 400.

  • Scale Out

    • Alerts — The pool will be scaled out when alerts are raised due to any of the selected alert configurations. Multiple selections can be made, as shown below.



    • Cooldown Period — The time period (in seconds) during which no new scale-out operations will be triggered, to give time for previous scale-out operations to complete.

    • Adjustment Step — The maximum number of server instances to simultaneously launch when the system determines it is necessary to scale out. The actual number of instances launched is chosen such that the final total number of server instances will be less than or equal to the specified maximum for the pool.

  • Scale In

    • Alerts — The pool will be scaled in when alerts are raised due to any of the selected alert configurations. Multiple selections can be made, as shown above.

    • Cooldown Period — The time period (in seconds) during which no new scale-in operations will be triggered, to give time for previous scale-in operations to complete.

    • Adjustment Step — The maximum number of server instances to simultaneously terminate when the system determines it is necessary to scale in. The actual number of instances terminated is chosen such that the final total number of server instances remaining will be greater than or equal to the specified minimum for the pool.

AutoScale Launch Config

If configured, then NSX Advanced Load Balancer will trigger orchestration of pool-server creation and deletion. This option is only supported for public cloud autoscale groups and OpenStack.

Health Monitoring

Incorporate a Health Monitor to verify the health of server instances within the pool. There are two kinds of health monitors:

  • Passive Health Monitor — A passive health monitor listens only to client-to-server communication. If servers are replying with errors (such 500 busy or TCP connection errors), then the passive health monitor will reduce the amount of connections or requests sent to that server. The reduction percentage depends on the number of servers available within the pool. When the server responds satisfactorily to the throttled requests directed to it, the passive health monitor will restore the server to full traffic volume. You may use this monitor in conjunction with any other health monitors. Errors are defined in the analytics profile assigned to the virtual service. Best practice is to ensure that a passive health monitor is enabled in addition to any synthetic check that may also be configured.

  • Active Health Monitor — In addition to normal client-to-server traffic, NSX Advanced Load Balancer can generate synthetic connections or requests to servers to ensure the integrity of the server’s health. Add one or more health monitors to the pool by clicking on the green + Add Active Monitor button and either selecting a health monitor or clicking to create a new one. You may disassociate a health monitor from the pool by clicking the trash can icon to the right of the monitor name.

Lookup Server by Name

Enable server lookup by name.

Rewrite Host Header to Server Name

Rewrite the incoming host header to the name of the server to which the request is proxied. Enabling this feature rewrites the host header of requests sent to all servers in the pool.

SSL to Backend Servers

Enables SSL encryption between the NSX Advanced Load Balancer Service Engine and the back-end servers. This is independent from the SSL option in the virtual service, which enables SSL encryption from the client to the NSX Advanced Load Balancer Service Engine.

  • SSL Profile: Determines which SSL versions and ciphers NSX Advanced Load Balancer will support when negotiating SSL with the server.

  • Server SSL Certificate Validation PKI Profile: This option validates the certificate presented by the server. When not enabled, the Service Engine automatically accepts the certificate presented by the server when sending health checks. Refer to the PKI Profile section for additional help on certificate validation.

  • Service Engine Client Certificate: When establishing an SSL connection with a server, either for normal client-to-server communications or when executing a health monitor, the Service Engine will present this certificate to the server.

Enable real time metrics

Checking this option enables real time metrics for server and pool metrics. Default is OFF.

Step 2: Servers

The Servers tab supports the addition/removal/disablement/enablement of servers and displays the results of those actions.



Add Servers

The servers added to a pool may be specified one of three ways:

  1. IP address, IP range, or DNS name

  2. IP group

  3. Auto-scaling groups defined by public cloud ecosystems such as Amazon Web Services (AWS) and Microsoft Azure.

Field

Description

IP Address, Range, or DNS Name

Add one or more servers to the pool using one or more of the listed methods. The example below shows servers created using multiple methods.

  • Add by IP Address - Into the Server IP Address field enter the IP address of a server you want to add. The Add Server button will change from light grey to green. You may also enter a range of IP addresses via a dash, such as 10.0.0.1-10.0.0.20.

  • Add by DNS Resolvable Name - Into the Server IP Address field enter the FQDN of the server you want to add. If the server successfully resolves, the IP address will appear and the Add Server button will change to green. Click the Add Server button to add it to the pool server list. Refer to Add Servers by DNS for more information.

  • Select Servers by Network - This option is only available if NSX Advanced Load Balancer has read or write access to the cloud orchestrator. Adding servers using this method enables NSX Advanced Load Balancer to provide significantly richer information regarding the server. NSX Advanced Load Balancer can query the virtualization orchestrator for the virtual machine’s CPU, memory, and disk utilization. This is useful for better load balancing and visibility and is the best-practice method. Adding servers by IP address or name will not provide this information. After a server has been added via the method, the server’s Network column in the server list table will be populated with the network or port group. Refer to Select Servers by Network for more details.

    • Clicking the Select Servers by Network opens a list of reachable networks. What appears will resemble the below example:



    • In this example, we drift the cursor over the network named 2a-private - 10.0.1.0/24, and it becomes highlighted.

    • Clicking on its row causes the servers on that network to appear as below. You can filter the search for servers, such as searching for “Demo” then select all matching servers.



    • Checking the boxes beside both servers results in the below.



    • Clicking the Add Servers button in the above window completes the selection process. Successful addition is reflected in the table, as shown below.

IP Group

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 whitelists, DataScripts, or similar automation purposes. However, be advised that many common pool features are unavailable when using this method, such as manually disabling 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.

Auto Scaling groups

External environments such as AWS and Azure define and manage autoscaling groups of their own.

  • Clicking this option reveals one’s choices.



  • One or more may be selected, as shown below. Once chosen, notice how the list of candidates shrinks down to just one, ScaleoutASG.
Servers

Field

Description

Changing Server Status

Adding servers to the pool populates the table within the Servers tab. Use it to remove, enable, disable, or gracefully disable servers. Changes to server status take effect immediately when changes are saved. The table below shows two servers have been enabled.



  • Remove — Select one or more servers to remove from the pool. This will immediately reset any existing client connections for these servers and purge the server from the pool’s list.

  • Enable — Select one or more disabled 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.

  • Disable — Select one or more enabled servers to disable. NSX Advanced 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.

Editing Servers

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 Disabled.

  • Server — 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 — his optional field creates an unequal distribution of traffic to a server relative to its peers. The ratio is used in conjunction 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 and 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).

  • Network — Shows networks of the servers in the pool if the Select Servers by Network option was used.

  • Header Value — This special field is used by the custom HTTP header persistence. Each server may be statically allocated an identifier, such as s1, s2, etc. If the selected client header exists, and the header value is s1, this server will receive the connection or request.

  • Rewrite Host Header — This is analogous to the pool-level feature described earlier in this article but on a more granular, server-level basis.

Step 3: Advanced

The Advanced tab of the Pool Create/Edit popup specifies optional settings for the pool.



Field

Description

Placement Settings

In some scenarios, a server may exist in multiple networks. Similarly, a network may have multiple IP subnets or a single subnet may exist in multiple networks. For instance, VMware servers may have multiple port groups assigned to a single subnet, or a single port group is assigned to multiple subnets. Normally, NSX Advanced Load Balancer will try to determine the network for the servers. However, in scenarios where it cannot determine which network to use, an administrator may be required to manually select it as follows.

  • Server Network — Click the pull-down menu icon to reveal potential networks for server placement. The list might look as shown below. Click on the desired network.



  • Subnet — Once the network has been chosen, a subnet(s) will be displayed. Choose one or enter one using the syntax 10.1.1.0/24.

Pool Full Settings

This section configures HTTP request queuing, which causes NSX Advanced Load Balancer to queue requests that are received after a back-end server has reached its maximum allowed number of concurrent connections. Queuing HTTP requests provides time for new connections to become available on the server, thus avoiding the configured pool-down action. For complete details, refer to the HTTP Request Queueing article.

Pool Failure Settings

Fail Action — Three fail actions are defined.

  • Close Connection — If all servers in a pool are down, the default behavior of the virtual service is to close new client connection attempts by issuing TCP resets or dropping UDP packets. Existing connections are not terminated, even though their server is marked down. The assumption is the server may be slow but may still be able to continue processing the existing client connection.

  • HTTP Local Response — Returns a simple web page. Specify a status code of 200 or 503. If a custom HTML file has not been uploaded to NSX Advanced Load Balancer, it will return a basic page with the error code.



    • Status Code — Select 200 or 503 from the pull-down.

    • Upload File — Click the button to navigate to and select an HTML page to be returned as the SE-local response.

  • HTTP Redirect — Returns a redirect HTTP response code, including a specified URL.



    • Status Code — Choose 301, 302, or 307 from the pull-down.

    • HTTP/HTTPS — By default NSX Advanced Load Balancer will redirect via HTTPS unless HTTP is clicked instead.

    • URL — Enter a URL of the format domain.com/path/file?query=bbb.

Note:

A virtual service is marked up when at least one of the pools associated with the virtual service is up, or if there are redirect policies that do not need pools. The mere presence of pool-down action by itself does not mark the virtual service up.

Starting with NSX Advanced Load Balancer release 18.2.1, you can specify the minimum threshold parameters for a pool to make it serviceable. For more information, view Parameters to Mark a Virtual Service or Pool up.

If a virtual service is marked down, and any of the following situations apply, then the pool-down action is not triggered:

  1. “Remove Listening Port when VS Down” setting on the VS - When this is set, and the VS is down, the dispatcher drops the packets, and the pool-down action is not triggered.

  2. BGP cases - When the virtual service is marked down, BGP withdraws this VS from the peer. Consequently, the peer does not send any traffic to this SE.

  3. ECMP case (without route summarization) - When the virtual service is marked down, the Controller withdraws the VS from the router. As a result, the router does not send any traffic to this SE.

Other Settings

Disable Port Translation — This feature is for virtual services that are listening on multiple service ports, such as Microsoft Lync, which has multiple listener ports. Instead of having all connections directed to a single port on the server (defined by the pool’s default server port or the server’s optional port field), they will be sent to the same port that they were received on the virtual service.

  • Ignore Server Port — The Ignore Server Port option is only relevant when the pool is configured to use the consistent hash load balancing algorithm or when Disable 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.



  • Description — Enter an optional description of up to 256 characters in this field. This field is for user convenience only.

  • Connection Ramp — Enabling this option by entering a number larger than 0 results in a graceful increase in the number of new connections sent to a server over the specified time period. For instance, assume that the load balancing algorithm is set to least connections and a pool has two servers with 100 connections each. Adding a third server would immediately overwhelm that third server by immediately sending the next 100 consecutive connections to it. Setting a connection ramp adds traffic to a new server in a manner similar to using a ratio. Over the specified period of time, the new server will receive an ever-increasing ratio of traffic in relation to its peers. For instance, setting the ramp to 4 seconds means that the new server will receive 1/4 of the traffic it would normally be given for the 1st second. By the 2nd second, the server will be receiving 1/2 the traffic it might otherwise have been given. After the 4-second ramp time has elapsed, the server will receive the normal amount of traffic as determined by the load balancing algorithm.

Max Connections per Server

Specify the maximum number of concurrent connections allowed for a server. If all servers in the pool reach this maximum the virtual service will send a reset for TCP connections or silently discard new UDP streams unless otherwise specified in the Pool Down Action, described above. As soon as an existing connection to the server is closed, that server is eligible to receive the next client connection. A value of 0 disables the connection limit.

HTTP Server Reselect

This option retries an HTTP request that fails or returns one of a set of user-specified error codes from the backend server. Normally, NSX Advanced Load Balancer forwards these error messages back to the client. For more information, refer to the HTTP Server Reselect.

Step 4: Review

The Review tab displays a summary of the information entered in the previous pool creation tabs.



Review this information and then click Save to finish creating the pool. If needed, you may return to any previous step by clicking the appropriate tab at the top of the window.

Note:

The Review tab only displays when creating a new pool; it does not display when editing an existing pool.