Can the Source algorithm be used instead of persistence?

Short answer

Yes, but it provides limited persistence. Source selects a server with the hash of the client's IP address and always sends the same IP to the same server; for this reason, it is self-persistent and the Persistence field is hidden when it is selected. However, all users behind NAT go to a single server, a client whose IP changes (e.g. mobile) changes servers, and when the number of running servers changes, most clients shift to another server (only a small portion if Hash Consistency is on). In applications where session loss is a problem, Persistence (New cookie, Current cookie, Hash, Session Affinity Manager (SAM)) is preferred. Source exists only on an HTTP vService.

How Does It Work?

• For each request, the client IP is hashed and a server is selected by dividing the result by the total Weight of the running servers; the Weight values are reflected in the distribution.
• The mapping is not kept in a table; the same IP goes to the same server with the same calculation on every request.
• If the number of running servers changes (a server is added, fails the health check or is taken into maintenance), the calculation changes and most clients go to a different server. If Hash Consistency is on, only the clients of that server change place when a server leaves, and a small portion of the clients change place when a server is added (What does the Hash Consistency option do in hash-based algorithms?).

Comparison of Source and Persistence

	Source algorithm	Persistence (e.g. New cookie, Hash keyed on client IP)
Source of persistence	Hash recalculated on every request	Cookie or the mapping table in TR7
Initial distribution	Determined by the hash	Determined by the selected algorithm (e.g. Least Connection)
When a server is added	Most clients change place (a small portion if Hash consistency is on)	With New cookie, Current cookie and SAM, existing users stay on their servers; the new server receives new clients
Behind NAT	All to a single server	With New cookie, Current cookie and SAM, each user can go to a separate server
vService type	HTTP only	HTTP; only Hash on L7 TCP

When Is It Sufficient?

• If persistence is at a "nice to have" level (e.g. to benefit from the server cache).
• If clients come from different, fixed IPs (e.g. internal network clients).
• If session information is kept in a shared store and a server change does not affect the user.

Alternatives

• HTTP: Persistence → New Cookie (TR7 adds its own cookie), Current Cookie (the application's cookie), Hash or Session Affinity Manager (SAM).
• L7 TCP: The Source algorithm does not exist; Persistence → Hash is selected and the client IP address is added as the Hash Key (L7 TCP · Persistence).
• Network: The Source Hash algorithm or L4 Persistence.

In TR7

• Selection: vService → Details → LB Algorithm → Algorithm → Source (Self-persistent); the Hash Consistency switch appears in the same box (off by default).
• Monitoring: The Load Balancer Management screen of the vService states that the algorithm pins the client to a server by itself.

Common Misconceptions

• "Source is as reliable as cookie persistence." When the number of running servers changes, persistence can break; with cookie-based Persistence, existing users stay on their servers.
• "I turn on cookie persistence together with Source." When Source is selected, the Persistence field is hidden.
• "I can select Source on L7 TCP." It exists only on HTTP.
• "Corporate users are distributed evenly." Those coming from behind NAT are gathered on a single IP, so they go to a single server.

How it is done in the documentation

• HTTP (L7) vService · Algorithms
• HTTP (L7) vService · Session Persistence
• HTTP (L7) vService · Algorithm-specific additional fields
• Network vService · L4 Persistence

Related questions

• All users coming from behind a corporate NAT go to a single server; why?
• Which persistence methods are available?
• What does the Hash Consistency option do in hash-based algorithms?