What is Session Affinity Manager (SAM); how is it different from classic cookie persistence?

Short answer

Session Affinity Manager (SAM) is a cookie-based and stateful persistence method on the HTTP vService: the cookie carries only the session ID; the session → Backend Service mapping and the per-session request, connection and traffic counters are kept in a table on TR7. In this way, sessions are monitored and deleted on the SAM tab of the vService and rebalanced with Rebalance. Classic New Cookie and Current Cookie, on the other hand, carry the Backend Service information directly in the cookie; they do not keep state on TR7, so sessions cannot be listed or redistributed.

How Does It Work?

1. Cookie Source (default TR7 Generates):
   • TR7 Generates: If there is no SAM cookie in the request, TR7 generates a session ID according to the selected Session ID Format and adds it to the response as a cookie. The cookie name is required in the Cookie Name field; the field opens empty and its placeholder is TR7SID.
   • Current Cookie: The application's own session cookie is read; TR7 does not add a new cookie.
2. When the client sends the cookie, the session ID is looked up in the table; if there is a record, the request goes to the mapped Backend Service; if not, the algorithm selects a Backend Service and the mapping is written to the table. Requests that do not carry the cookie are not recorded in the table and are distributed with the algorithm.
3. A record that receives no request during Max Idle (default 30 min) drops from the table; Max Life (default 24 hours) is the total lifetime of the cookie.

Comparison

	New Cookie / Current Cookie	SAM
Where the server information is	In the cookie	In the session table on TR7
State on TR7	Not kept	Kept (with per-session counters)
Viewing / deleting sessions	None	Sessions on the SAM tab
Rebalancing	None	Rebalance, Clear All
Cookie security flags	No option	Security Flags: HttpOnly, Secure (HTTPS only), SameSite=Strict, SameSite=Lax (default HttpOnly and Secure)
Session ID format	–	Session ID Format: UUID (default), IP-Timestamp-Random, IP-Random, Custom Format
On restart	Not affected (the information is on the client)	The table is emptied; it is preserved on a regular save (Does saving a configuration change reset the persistence tables?)
Cluster	Since the information is in the cookie, the same result on both devices	The table is separate on each device; it is not shared between devices

Constraints

• It can be used only on an HTTP vService and with algorithms that are not self-persistent.
• If there are at least two servers in the Default Backend Services list of the vService or in a conditional set, SAM is applied to that list; it is not applied to a list with a single server (Why does SAM require at least two Backend Services?).
• The table capacity is fixed (1,000,000 sessions) and cannot be changed.
• Details: Compatibility and Limitations.

In TR7

• Selection: Load Balancer → Load Balancer vService List → HTTP vService → Edit → Details → LB Algorithm box → Persistence → Session Affinity Manager (SAM); it is saved with Save. Fields: Cookie Source, Cookie Name, Session ID Format (only with TR7 Generates), Custom format format keys (only with Custom Format), Max Life, Max Idle, Security Flags.
• Cluster: The settings are transferred to the peer device automatically while Clustering is on and Manual Sync Mode is off (default); the session table is separate on each device.
• Monitoring: When Persistence is SAM, the Session Affinity Manager (SAM) tab appears on the vService screen (tabs); for each list (Default Backend Services or a conditional set), the Sessions, Backends, Max Idle and Max Life cards and the session counts per Backend Service are shown. The Refresh and Clear All buttons are in the top toolbar, and the Sessions and Rebalance buttons are in the header of each list (What do Rebalance and Clear All do on the Session Affinity Manager (SAM) tab?).

Common Misconceptions

• "The SAM table is synchronized between cluster devices." Each device keeps its own table; if the VIP moves to the peer device, the sessions are mapped again there with the algorithm.
• "The SAM cookie is encrypted." The value generated by TR7 is only encoded (base64); in ID formats that contain an IP, the client IP can be read from the cookie. If privacy is important, the UUID format is selected.
• "SAM pins from the first request on." With TR7 Generates, the first request arrives without a cookie and is distributed with the algorithm; the mapping is established on the request in which the cookie comes back.
• "SAM also works with clients without cookies." Requests that do not carry the cookie are not recorded in the table.

How it is done in the documentation

• HTTP (L7) vService · What Is SAM?
• HTTP (L7) vService · How Does It Work?
• HTTP (L7) vService · Compatibility and Limitations

Related questions

• What do Rebalance and Clear All do on the Session Affinity Manager (SAM) tab?
• Why does SAM require at least two Backend Services?
• What is the difference between New Cookie and Current Cookie?