Session is a virtual channel created between client and server via which these two communicates. One session can be made of many connections. And some application servers maintain a client state in its memory and thus are session sensitive. For example e-shops app. servers can stores shopping card info in its memory and if we are directed all the time to different servers, our shopping card will change its state every time. Thats why we need to ensure persistent client sessions. You configure persistence via profiles. Profiles are covered in previous article.

Local Traffic Manager 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.

Local Traffic Manager 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 clients 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.

What are persistence profiles?

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 Local Traffic Manager 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

• Cookie persistence – Cookie persistence uses an HTTP cookie stored on a clients computer to allow the client to reconnect to the same server previously visited at a web site.
• 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 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 a type of persistence used for servers that receive Session Initiation Protocol (SIP) messages sent through UDP, SCTP, or TCP.
• 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.
• SSL persistence – SSL persistence is a type of persistence that tracks non-terminated SSL sessions, using the SSL session ID. Even when the clients IP address changes, Local Traffic Manager still recognizes the connection as being persistent based on the session ID. Note that the term non-terminated SSL sessions refers to sessions in which Local Traffic Manager does not perform the tasks of SSL certificate authentication and encryption/re-encryption.
• Universal persistence – Universal persistence allows you to write an expression that defines what to 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 identifier.

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

The OneConnect profile and session persistence

When you configure session persistence, Local Traffic Manager tracks and stores session data, such as 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 life of a session or during subsequent sessions.
Occasionally, however, for Cookie and Universal persistence types specifically, Local Traffic Manager ignores the session data in this header, and sends requests to an unexpected node. This occurs when many nodes accesses same resources via proxy device, because proxy then handles and creates all tcp connections.

HTTP parsing without a OneConnect profile

If the virtual server does not reference a OneConnect profile, Local Traffic Manager performs load balancing for each TCP connection. Once the TCP connection is load balanced, the system sends all requests that are part of the connection to the same pool member.
For example, if the virtual server does not reference a OneConnect profile, and Local Traffic Manager initially sends a client request to node A in pool A, the system inserts a cookie for node A. Then, within the same TCP connection, if Local Traffic Manager receives a subsequent request that contains a cookie for node B in pool B, the system ignores the cookie information and incorrectly sends the request to node A instead.

HTTP parsing using a OneConnect profile

Using a OneConnect type of profile solves the problem. If the virtual server references a OneConnect profile, Local Traffic Manager can perform load balancing for each request within the TCP connection. That is, when an HTTP client sends multiple requests within a single connection, Local Traffic Manager is able to process each HTTP request individually. Local Traffic Manager sends the HTTP requests to different destination servers if necessary.
For example, if the virtual server references a OneConnect profile and the client request is initially sent to node A in pool A, Local Traffic Manager inserts a cookie for node A. Then, within the same TCP connection, if Local Traffic Manager receives a subsequent request that contains a cookie for node B in pool B, the system uses that cookie information and correctly sends the request to node B.

Criteria for Session Persistence

You can specify additional criteria for session persistence regardless of type of persistence you are using. This criteria specify conditions to send the client persistent sessions to same pool member. There are 3 types of criteria. Match Across Services, Match Across Virtual Servers, and Match Across Pools profile settings.

The Match Across Services setting

When you enable the Match Across Services profile setting, Local Traffic Manager 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, Local Traffic Manager 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. Local Traffic Manager 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), Local Traffic Manager 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).
In order 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.
Note with respect to cookie profiles, this method applies to the cookie hash method only

The Match Across Virtual Servers setting

You can set Local Traffic Manager 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, Local Traffic Manager 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.
In order 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.
Note with respect to cookie profiles, this method applies to the cookie hash method only

The Match Across Pools setting

When you enable the Match Across Pools setting, Local Traffic Manager can use any pool that contains a given persistence record. The default is disabled (cleared).
Warning: Enabling this setting can cause Local Traffic Manager to direct client traffic to a pool other than that specified by the virtual server.