Load Balancing Multiple Tier Applications
In this scenario an F5 virtual servers sits in front of the PS server and is using source IP persistence. This means that based on the clients source IP they will be assigned to the same back-end PS server.
The proxy servers in front of the Web APP virtual server will be using HTTP Insertion cookie to maintain persistence. What this means is the F5 will present a cookie to the clients browser even though it is going through the PS server. So when that client connects to the web application through the PS server it will present that cookie in its header and the F5 will decrypt the cookie and send it to the correct Web APP server in the back-end.
Source IP benefits and short comings
Benefit:
There is no dependency on the client’s device or software such as browser or OS.
It is very easy to troubleshoot, and view current state on the clients’ persistence on the F5 using CLI command.
It is proven persistence method and is very dependable.
Many apps i have configured to use source IP have seen fairly balanced load balancing.
Short comings:
It will not give you as evenly distributed load balancing as a session based persistence. (Sites that have users behind a NAT)
It is not the correct load balancing persistence to set on the web application since the only IP addresses it would see are the PS servers.
HTTP cookie benefits and short comings:
Benefits:
This is a session based load balancing which means it doesn’t load balance each machine or IP, but the actual web session the client has open. When the users closes their browser the cookie is destroyed.
Create a very balanced load between back-end servers.
Cons:
Depended on user machines, browsers, security policies, or OS. If there systems or software does not support encrypted cookies, or their policy is not to accept or store cookies, this would break persistence.
More difficult to troubleshoot and map users back to a machine without actually having the clients cookie.
Solution:
The perfect solution would be to find a session based persistence that does not rely on the client’s machine to provide a cookie. At the very least we will need a session based persistence between the PS servers and the Web APP virtual server since we know source IP address is not a viable solution between the PS servers and the Web APP virtual server.
Recommendation:
Load balance the PS virtual server using source IP persistence provides good load balancing as long as there is a diverse client pool, and allows for more visibility into troubleshooting specific end point connections. Then use a session based persistence between the PS servers and the Web APP virtual servers that does not involve the client.
F5 recommended using SSL persistence for the Web APP virtual server and sticking with source IP on the PS Virtual server. What this would do is set persistence based on the SSL session ID between the PS servers and the Web APP virtual server. SSL persistence also makes a persistence table entry so we would have similar troubleshooting visibility we would have with source ip persistence.
In addition we will need to make sure least connection is set as the load balancing algorithm for both the PS and Web APP pools. This will insure we are not blindly load balancing but leveraging the F5 visibility into connections to the pool members.
FYI:
Theoretically you can still use the HTTP cookie persistence on your WebAPP server, but as I found out the hard way many PS servers will combine multiple client HTTP sessions into one back end connection to the WebApp virtual server. The default way F5 handles http cookie persistence is during the creation of an HTTP session it looks at the first HTTP request for the http cookie header, then based on the first cookie will load balance the entire HTTP session to the designated back end HTTP server. Where this breaks is if you are combining multiple HTTP client sessions and the web application servers are not expecting that clients traffic, (web application does not share user session information.) To fix this issue you can enable a OneConnect profile on the WebAPP virtual server. One of the actions that is taken by the OneConnect profile is to look at every HTTP request and load balance based on each request not just the first HTTP request.
If SSL Persistence and Cookie is not an option:
Universal persistence profile allows you to use an irule that will look for the x-forwarded-for header and use a hash value to maintain persistence. F5 warned us there would be some coding on our part to create a custom irule and it that this type of persistence is a very CPU expensive process on the F5. This one is definitely last on the list.
Share On
