Persistence or Affinity is a function of load balancing where connections will be routed to the same device (service) based upon the criteria selected. Sometimes this is referred to session stickiness as well. This is configured in the load balancing dialog for your config/pack. Each persistence type has a time-out value which will keep the persistence session in effect until it has been inactive/idle for the specified amount of time.
In the event a server being utilized for a persistence session goes down, the load balancer will use the specified load balancing method to select another device and establish an active persistence session with it instead. Additionally, if you take a device out of service, persistence will be nullified after the wait period.
The following describes the available persistence types and what each does. This information will help you make an educated decision about which type would be best utilized for your load balancer.
When this persistence type is configured the load balancer will select a service to which a new connection will be routed, and thereafter will direct all traffic with the same source IP address to that service.
Use the IPv4 and IPv6 netmask drop-down menus to determine the persistence width using CIDR notation: /8 through /24 for IPv4 and /8 through /23, /32, /48, and /64 for IPv6. For example, if IPv4 /24 is selected and a user with the IP 192.168.10.23 connects, any subsequent connections from any IP address between 192.168.10.0 and 192.168.10.255 will be routed to the same service.
This persistence type would not be the best choice if you expect much of your traffic to originate from multiple users behind a single subnet.
Upon the initial client request this persistence type will set a cookie containing the IP address and port of the selected service in the HTTP header which the client will include with any subsequent requests. Persistence is maintained as the load balancing virtual server detects the cookie and forwards the requests to the selected service.
A session ID is created during the SSL handshake process, and if the load balancer is configured to use it for persistence, all subsequent requests using the same SSL session ID will be directed to the service to which the initial request was sent.
A caveat to this persistence type is that persistence will be lost if the client and load balanced server renegotiate the ID during a session.
When the load balancer is configured with rule based persistence, any requests matching the rules you specify will direct the initial request and all subsequent requests to the same service. The rules can be set up to match incoming requests or responses from the load balanced servers.
There are a multitude of expression types and qualifiers which may be employed in your rules, the details of which are out of the scope of this article. Suffice it to say, there is a rich supply of expression type/qualifier combinations at your disposal.
When the load balancer is configured to use URL Passive, all connections to the same URL are treated as part of the same persistence session. A rule is require for this to work properly. It also works on more than just the URL. You can configure the expression to persist based on the Host Header, Method (GET, POST, PUT etc.), HTTP version, URL, URL length, URL Query etc. as shown in the drop down in the user interface.
With this persistence type, connections with the same HTTP Host header are treated as part of the same persistence session. A server ID must be set on the services which users must know when submitting requests for specific services.
NOTE: At the time of this writing this persistence type is not fully supported. The persistence can be configured, but the setting of the server ID is a feature to be fully realized in the future.
When this persistence type is configured the load balancer will look at the destination IP address and create a persistence session based upon the service to which the IP address is assigned.
Use the IPv4 and IPv6 netmask drop-down menus to determine the persistence width using CIDR notation: /8 through /24 for IPv4 and /8 through /23, /32, /48, and /64 for IPv6.