Manual Chapter :
Session Persistence Profiles
Applies To:
Show Versions
BIG-IP APM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP Analytics
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP LTM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP PEM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP AFM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP DNS
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
BIG-IP ASM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
Session Persistence Profiles
Introduction to session persistence profiles
Using the BIG-IP system, you can configure session persistence. When you
configure
session persistence
, the BIG-IP system tracks and stores session data,
such as the specific pool member that serviced a client request. The primary reason for tracking
and storing session data is to ensure that client requests are directed to the same pool member
throughout the life of a session or during subsequent sessions.In addition, session persistence can track and store other types of information, such as user preferences or a user name and password.
The BIG-IP system offers several types of session persistence, each one designed to accommodate
a specific type of storage requirement for session data. The type of persistence that you
implement depends on where and how you want to store client-specific information, such as items
in a shopping cart or airline ticket reservations.
For example, you might store airline ticket reservation information in a back-end database that all servers can access, or on the specific server to which the client originally connected, or in a cookie on the client’s machine. When you enable persistence, returning clients can bypass load balancing and instead connect to the server to which they last connected in order to access their saved information. Note that when using Cookie persistence, you can configure an option in a Cookie persistence profile to tell the BIG-IP system to encrypt the pool name embedded in the BigIPServer default cookie.
The BIG-IP system keeps session data for a period of time that you specify.
The primary tool for configuring session persistence is to configure a persistence profile and assign it to a virtual server. If you want to enable persistence for specific types of traffic only, as opposed to all traffic passing through the virtual server, you can write an iRule.
A
persistence profile
is a pre-configured object that automatically enables
persistence when you assign the profile to a virtual server. By using a persistence profile, you
avoid having to write a program to implement a type of persistence.Each type of persistence that the BIG-IP system offers includes a corresponding default persistence profile. These persistence profiles each contain settings and setting values that define the behavior of the BIG-IP system for that type of persistence. You can either use the default profile or create a custom profile based on the default.
Persistence profile types
You can configure persistence profile settings to set up session persistence on the BIG-IP system. You can configure these settings when you create a profile, or after profile creation, by modifying the profile’s settings. After configuring a persistence
profile, you deploy the profile by assigning it to a virtual server.
The persistence types that you can enable using a persistence profile are:
- Cookie persistence
- Cookie persistence uses the HTTP cookie header to persist connections across a session. Most application servers insert a session ID into responses that is used by developers to access data stored in the server session (shopping carts and so on). Load balancing services use this value to enable persistence. This technique prevents the issues associated with simple persistence because the session ID is unique.
- Destination address affinity persistence
- Also known as sticky persistence, destination address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the destination IP address of a packet.
- Hash persistence
- Hash persistence allows you to create a persistence hash based on an existing hash persistence profile. Using hash persistence is the same as using universal persistence, except that with hash persistence, the resulting persistence key is a hash of the data, rather than the data itself. If you use hash persistence, and Local Traffic Manager cannot find an entry in the persistence table for a connection, and the system has not yet chosen a pool member due to fallback persistence, then the system uses the hash value, rather than the specified load balancing method, to select the pool member. For example, if the persistence table contains no entry for the hash value2356372769, and the number of active nodes in the pool remains the same, then a session with that hash value for persistence is always persisted to node10.10.10.190(assuming that the node is active). Hash persistence allows the use of multiple values within a request to enable persistence. To avoid problems with simple persistence, for example, a hash value may be created based on source IP, destination IP, and destination port. While not necessarily unique to every session, this technique results in a more even distribution of load across servers. You generally use hash persistence with stateless applications or streaming content (video and audio).You cannot associate hash persistence with a virtual server that is managing Fast L4 traffic; use of hash persistence for Fast L4 traffic is disallowed.
- Host persistence
- Host persistence allows the BIG-IP system to use theHTTP Hostheader passed in an HTTP request to determine which pool member to choose. You can also activate host persistence from within an iRule.
- Microsoft Remote Desktop Protocol persistence
- Microsoft Remote Desktop Protocol (MSRDP) persistence tracks sessions between clients and servers running the Microsoft Remote Desktop Protocol (RDP) service.
- SIP persistence
- SIP persistence is an application-specific type of persistence used for servers that receive Session Initiation Protocol (SIP) messages sent through UDP, SCTP, or TCP. You generally use this persistence technique with stateful applications that depend on the client being connected to the same application instance throughout the life of the session.
- Source address affinity persistence
- Also known as simple persistence, source address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the source IP address of a packet. You generally use this type of persistence technique with stateless applications or streaming content (video and audio) as a means to more evenly distribute load.
- SSL persistence
- Because SSL sessions need to be established and are very much tied to a session between client and server, failing to persist SSL-secured sessions results in renegotiation of the session,. Regnegotiation requires a noticeable amount of time and can result in user dissatisfaction. To avoid unnecessary renegotiation, the BIG-IP system uses the SSL session ID to ensure that a session is properly routed to the application instance to which the session first connected. Even when the client's IP address changes, the BIG-IP system still recognizes the connection as being persistent based on the session ID. You generally use this persistence technique with stateful applications that depend on the client being connected to the same application instance throughout the life of the session.
- Universal persistence
- Universal persistence uses any piece of data (network, application protocol, payload) to persist a session. This technique requires the BIG-IP system to be able to inspect and ultimately extract any piece of data from a request or response. This technique is the basis for application-specific persistence solutions addressing popular applications like SIP, WTS, and more recently, VMware View. With universal persistence, you can write an expression that defines the data that the BIG-IP system will persist on in a packet. The expression, written using the same expression syntax that you use in iRules, defines some sequence of bytes to use as a session ID. You generally use this persistence technique with stateful applications that depend on the client being connected to the same application instance throughout the life of the session.
Session persistence and iRules
Instead of configuring a persistence profile, which enables a persistence type for all sessions passing through the virtual server, you can write an iRule, which enables a persistence type for particular requests (for example, for HTTP traffic that includes a certain cookie version only).
You can also use an iRule to enable persistence for SSL-terminated requests, that is, requests
that the BIG-IP system terminates by performing decryption and
re-encryption and by handling SSL certificate authentication. In iRules of
this type, you can use an HTTP header insertion iRule command to insert an SSL session ID as a
header into an HTTP request.
HTTP requests and sesssion persistence
When you configure a persistence profile on a virtual server, the BIG-IP
system tracks a pointer to the pool member that serviced a client request. Configuring a
persistence profile for a virtual server ensures that client requests are directed to the same
pool member throughout the lifetime of a session.
By default, the BIG-IP system performs load balancing for each TCP connection, rather than for
each HTTP request. After the initial TCP connection is load balanced, the system sends all HTTP
requests seen on the same connection to the same pool member. You can change this behavior if you
want the system can make a new load balancing decision according to changing persistence
information in HTTP requests. You do this by configuring a OneConnect
profile and assigning the profile to a virtual server. A OneConnect profile causes the system to
detach server-side connections so that the system can perform load balancing for each request
within the TCP connection and send the HTTP requests to different destination servers if
necessary.
Criteria for session persistence
For most persistence types, you can specify the criteria that the BIG-IP
system uses to send all requests from a given client to the same pool member. These criteria are
based on the virtual server or servers that are hosting the client connection. To specify these
criteria, you configure the
Match Across Services
, Match Across
Virtual Servers
, and Match Across Pools
settings contained
within persistence profiles. Before configuring a persistence profile, it is helpful to
understand these settings.For the Cookie persistence type, these global settings are only available the
Cookie Hash method specifically.
The Match Across Services setting
When you enable the
Match Across Services
setting within a persistence
profile, the BIG-IP system attempts to send all persistent connection
requests received from the same client, within the persistence time limit, to the same node only
when the virtual server hosting the connection has the same virtual address as the virtual server
hosting the initial persistent connection. Connection requests from the client that go to other
virtual servers with different virtual addresses, or those connection requests that do not use
persistence, are load balanced according to the load balancing method defined for the pool.For example, suppose you configure virtual server mappings where the virtual server
v1:http
has persistence enabled and references the
http_pool
(containing the nodes n1:http
and
n2:http
), and the virtual server v1:ssl
has
persistence enabled and references the pool ssl_pool
(containing the nodes
n1:ssl
and n2:ssl
).Suppose the client makes an initial connection to
v1:http
, and the load
balancing algorithm assigned to the pool http_pool
chooses
n1:http
as the node. If the client subsequently connects to
v1:ssl
, the BIG-IP system uses the persistence
session established with the first connection to determine the pool member that should receive
the connection request, rather than the load balancing method. the BIG-IP system should then
send the third connection request to n1:ssl
, which uses the same node as
the n1:http
node that currently hosts the client's first connection with
which it shares a persistent session. If the same client then connects to a virtual server with a different virtual address (for
example,
v2:ssl
), the BIG-IP system starts tracking a new persistence
session, using the load balancing method to determine which node should receive the connection
request. The system starts a new persistence session because the requested virtual server uses a
different virtual address (v2) than the virtual server hosting the first persistent
connection request (v1). For the
Match Across Services
setting to be
effective, virtual servers that use the same virtual address, as well as those that use SSL
persistence, should include the same node addresses in the virtual server mappings.With respect to Cookie profiles, this setting applies to the Cookie Hash method only.
The Match Across Virtual Servers setting
You can set the BIG-IP system to maintain persistence for all sessions
requested by the same client, regardless of which virtual server hosts each individual connection
initiated by the client. When you enable the
Match Across Virtual Servers
setting within a persistence profile, the system attempts to send all persistent connection
requests received from the same client, within the persistence time limit, to the same node.
Connection requests from the client that do not use persistence are load balanced according to
the currently selected load balancing method.With respect to Cookie profiles, this setting applies to the Cookie Hash method
only.
For this setting to be effective, virtual servers that use pools with TCP or
SSL persistence should include the same member addresses in the virtual server mappings.
The Match Across Pools setting
When you enable the
Match Across Pools
setting within a persistence
profile, the BIG-IP system can use any pool that contains a given
persistence record. The default is disabled (cleared).Enabling this setting can cause the BIG-IP system to direct client traffic to a pool other than that specified by the virtual server.
With respect to Cookie profiles, this setting applies to the Cookie Hash method only.
