A persistence profile governs the settings that will force a client to stay connected to the same server for a specified duration of time. This is sometimes referred to as ‘sticky connections’.

By default, load balancing may send a client to a different server every time the client connects with a virtual service or even distribute every HTTP request to a different server when connection multiplex is enabled. Server persistence guarantees the client will reconnect to the same server every time when they connect to a virtual service, so long as the persistence is still in effect. Enabling a persistence profile ensures the client will reconnect to the same server every time, or at least for a desired duration of time. Persistent connections are critical for most servers that maintain client session information locally.

All persistence methods are based on the same principle, which is to find a unique identifier of a client and remember it for the desired length of time. The persistence information may be stored locally on NSX Advanced Load Balancer Service Engines or may be sent to a client, such as through a cookie or TLS ticket. The client will then present that identifier to the SE, which directs the SE to send the client to the correct server.

Persistence is an optional profile, configured within Templates > Profiles > Persistence Profile. Once the profile is created, it may be attached to one or more pools.

Types of Persistence

NSX Advanced Load Balancer can be configured with a number of persistence templates:

  • HTTP Cookie: NSX Advanced Load Balancer inserts a cookie into HTTP responses

  • App Cookie: NSX Advanced Load Balancer reads existing server cookies or URI embedded data such as JSessionID

  • Custom HTTP Header: Administrators may create custom, static mappings of header values to specific servers

  • Client IP Address: The client’s IP is used as the identifier and mapped to the server

  • TLS: Persist information is embedded in the client’s SSL/TLS ticket ID

  • GSLB Site: GSLB application can be configured to persist to the sites in which the transactions are initiated

Outside of the persistence profiles, two other types of persistence are available:

  • DataScript: Custom persistence may be built using DataScripts for unique persistence identifiers

  • Consistent Hash: This is a combined load balancing algorithm and persistence method, which can be based on a number of different identifiers as the key

Persistence Mirroring

Persistence data is either stored locally on NSX Advanced Load Balancer Service Engines or is sent to and stored by clients.

Client stored persistence, which includes HTTP cookie, HTTP header mapping, and consistent hash, are not kept locally on Service Engines. When the data, such as a cookie presented by the client, is received, it contains the IP address and port of the persisted server for the client. No local storage or memory is consumed to mirror the persistence. Persist tables may be infinite in size, as no table is locally maintained.

Locally stored persistence methods, which includes HTTP app cookies, TLS, client IP addresses, and DataScripts, NSX Advanced Load Balancer SEs maintain the persist mappings in a local table. This table is automatically mirrored to all other Service Engines supporting the virtual service as well as the Controllers. An SE failover will not result in a loss of persistence mappings. To support larger persistence tables, allocate more memory to Service Engines and the SE Group > Connection table setting.

Persistence Profile Settings

Select Templates > Profiles > Persistence to open the Persistence Profiles tab.

  • Search: Search across the list of objects.

  • Create: Opens the New Persistence Profile popup.

  • Edit: Opens the Edit Persistence Profile popup.

  • Delete: A profile may only be deleted if it is not currently assigned to a virtual service. An error message will indicate the virtual service referencing the profile. The default system profiles can be edited, but not deleted.

The table on this tab provides the following information for each persistence profile:



Field

Description

Persistence Name

Name of the profile.

Type

Full descriptions of each type of persistence are described in the next section. The types of persistence can be one of the following:

  • App Cookie

  • Client IP Address

  • Custom HTTP Header

  • GSLB Site

  • HTTP Cookie

  • TLS

Create Persistence Profile

The New Persistence Profile and Edit Persistence Profile popups share the same interface.



To create or edit a Persistence Profile:

Field

Description

Name

Enter a unique name for the Persistence Profile in the Name field.

Type

Select the persistence type using the Type pull-down menu. The available options are:

  • App Cookie: Rather than have Avi insert a new cookie for persistence, Avi will use an existing cookie that has been inserted by the server. If the cookie does not exist, Avi will look for a URI query of the same name and will persist on that value. Typically this persistence will be performed on a ASP or Java session ID.

  • Client IP Address: NSX Advanced Load Balancer will record the client’s source IP address in a table for the duration of the Persistence Timeout for this profile. While the IP address remains in the table, any new connection by the user will be sent to the same server. The Client IP Address persistence table is stored in memory on the Service Engine, and is automatically mirrored to the Controller and all other Service Engines that support this virtual service.

    Note:

    Starting with release 18.1.2, this feature is supported for IPv6 in NSX Advanced Load Balancer. IPv4 and IPv6, both the type of IP addresses can be used for the persistence type – Client IP Address.

  • Custom HTTP Header: This method allows an HTTP header to be specified for persistence. The Service Engine will inspect the value of the defined header, and will match the value against a statically assigned header field for each server in the pool. If there is a match, the client will be persisted. The server’s header field is configured in the Pool’s edit server page, where new servers are added.

    • Header Name: Specify the HTTP header whose value will be used for the persistence lookup.

  • GSLB Site: This permits a given client of a global application to persist to the first site to which it is directed. Refer to GSLB Site Cookie Persistance for more information.

  • HTTP Cookie: Applicable to virtual services with an attached HTTP application profile. NSX Advanced Load Balancer inserts a cookie into outgoing HTTP responses and reads the cookie on incoming requests. The cookie is session based, meaning that the cookie persistence remains valid as long as the client keeps their browser open. Closing the browser removes the cookie stored by the client browser, thereby tearing down both the connections and the persistence. Cookies uniquely identify each client, which is useful if multiple users are accessing the virtual service from the same IP address. Clients store the persistence information, so it does not consume memory on the Service Engine.

    • HTTP Cookie Name: Specify the HTTP cookie name. If this field is left blank, then the system generates a random 8-character cookie name.

  • TLS: Applicable to virtual services that are terminating SSL or TLS. This method embeds user persistence information within the ticket field of a TLS session. Clients negotiating with older SSL v3 will use a variation that inserts the persistence information into the SSL Session ID. NSX Advanced Load Balancer does not allow clients to renegotiate the session, which is more secure and also ensures that Avi NSX Advanced Load Balancer can maintain the persistence as it controls if and when the Session ID is renegotiated and recreated.

Select New Server When Persistent Server Down

Determine how this profile will handle a condition when the Health Monitor marks a server as down while NSX Advanced Load Balancer is persisting clients to it.

  • Immediate: NSX Advanced Load Balancer will immediately select a new server to replace the one that has gone down and switch the persistence entry to the new server.

  • Never: No replacement server will be selected. Persistent entries will be required to expire normally based upon the persistence type.

Persistence Timeout

Enter the number of minutes to preserve the client’s IP address in the Persistence Timeout field. Entering 0 disables persistence and allows new connections to be load balanced to a new server immediately. The timeout begins counting down when all connections from the same source IP address to the virtual service are closed. This field applies to Client IP persistence only.