A persistence profile governs the settings that 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 can send a client to a different server, every time the client connects with a virtual service. Server persistence guarantees the client will reconnect to the same server every time they connect to a virtual service, until the persistence is still in effect. Enabling a persistence profile ensures that 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 Vantage 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. 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 several persistence templates:

HTTP Cookie Persistence:

NSX Advanced Load Balancer inserts a cookie into HTTP responses.

App Cookie Persistence:

NSX Advanced Load Balancer reads existing server cookies or URI embedded data such as Java Session ID.

HTTP Custom Header Persistence:

Administrators may create custom, static mappings of header values to specific servers.

Client IP Persistence:

The client’s IP is used as the identifier and mapped to the server.

TLS Persistence:

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

GSLB Site Cookie Persistence:

GSLB application can be configured to persist to the sites in which the transactions are initiated. (See GSLB Site Cookie Persistence section in the VMware NSX Advanced Load BalancerGSLB guide)

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 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 and 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 Connection table settings in SE group.

Persistence Profile Settings

Navigate to Templates > Profiles > Persistence to open the Persistence Profile window. Click CREATE button to create a new persistence profile, or click edit icon to edit the existing persistence profile types.

Name: Specify the name of the persistence profile.

Type: Select the method used to persist clients to the same server for a duration of time or a session from the drop-down menu. The following are the options available in the drop-down menu:

  • App Cookie: Rather than have NSX Advanced Load Balancer insert a new cookie for persistence, NSX Advanced Load Balancer will use an existing cookie that has been inserted by the server. If the cookie does not exist, NSX Advanced Load Balancer will look for a URI query of the same name and will persist on that value. Typically this persistence will be performed on an 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 time defined in 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:

    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.

  • 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 until 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 NSX Advanced Load Balancer can maintain the persistence as it controls if and when the Session ID is renegotiated and recreated.

Create Persistence Profile

The New Persistence Profile and Edit Persistence Profile screens 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 drop-down menu. The available options are:

  • App Cookie: Rather than have NSX Advanced Load Balancer insert a new cookie for persistence, NSX Advanced Load Balancer will use an existing cookie that has been inserted by the server. If the cookie does not exist, NSX Advanced Load Balancer will look for a URI query of the same name and will persist on that value. Typically this persistence will be performed on an 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 time defined in 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:

    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.

  • 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 until 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 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 is 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 on 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.