Persistence or Affinity is a function of load balancing where connections will be routed to the same service based upon the criteria selected. Sometimes this is referred to session stickiness as well. This is set up alongside the algorithms for the load balancing virtual servers. Each persistence type has a time-out value which will keep the persistence session in effect until it has been inactive for the specified amount of time.
In the event a server being utilized for a persistence session goes down, the load balancing virtual server will employ the specified load balancing method to select another service and establish an active persistence session with it.
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 on your load balancing virtual servers.
When this persistence type is configured the load balancing virtual server 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 balancing virtual server 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 balancing virtual server is configured with rule based persistence, any requests matching the rules you specify will direct the initial request and all subsequest 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 balancing virtual server 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 persistent 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 balancing virtual server 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.