Clustering F5 Big-IP Devices; Is it Possible?

Solution 1:

Most of F5 come in HA pairs, so these would be clustered. As soon as one F5 goes down, the IPs are assumed by the other F5 in the pair, so there is no downtime. For your question, each IP is assigned to only one F5 at a time and is not truly active/active on both.

That is your solution, now next question you should ask is what happens if the whole site goes down where both F5 are hosted?(and then look into global load balancing).

Solution 2:

I don't believe that you can truly 'cluster' two F5 content switches, though I believe they're working on the feature but I could be wrong. Clustering load-balancers is a huge engineering challenge - how do they share information at layer4 or layer 7, how do they communicate over layer 2 or layer 3 and how is clustering and information-sharing enabled without affecting performance as load-balancers have to operate at wire-speed essentially.

Think of firewalls in the old days, proxy-based firewalls were always standalone-nodes because they did so much at layer 7 and it was essentially impossible to share this information across nodes without killing performance, whereas stateful packet filters only had to transfer layer 4 information and even that was an overhead. Load-balancers will typically be deployed with much of their configuration, as in your case with VIPs, acting as an endpoint and so the whole TCP session is rewritten and the load-balancer becomes the client to the server (i.e. there's essentially two flows and this is one reason why the actual client can't perform http pipelining direct to the back-end server).

With HA, you don't achieve the scale out that you want so you'll have to scale-up your load-balancer to handle the load etc. Vendors like that as with scale-up, it generally (not always as sometimes you can enable extra CPU with a license upgrade) means a new, bigger box HA does provide resiliency and reliability though obviously. With HA, you generally have command propagation, configuration synchronisation and some element of session exchange (which can be configured to a degree as this can cause load).

You could look scaling by load-balancing your load-balancers (i.e. LB -> LB -> Web Farm) but that's not great, can introduce latency, is (very) costly and your infrastructure has another point of failure though I have seen it successfully implemented.

You can use something like VRRP, which is like a quasi-cluster almost In this implementation you could have two sets of HA pairs of load-balancers in front of your web farm, call them HA1 and HA2. With VRRP, you could create two VIPs, one being live on HA1 (vip1) and the other being live on HA2 (vip2) due to the higher VRRP priority configuration. Both vip1 and vip2 can failover to the other HA pair through VRRP, either automatically (based on monitors etc) or manually by lowering the VRRP priority.

Most vendors have KB articles on the above configurations. I believe that there is one vendor who has true clustering in their product but I'll let you google for that.

All load-balancers have various forms of persistence, which you apply to the back-end server association. Popular forms today are cookie and hash (based on the 4-tuple and one or two other things). When the load-balancer acts as an endpoint like in your scenario, once the TCP connection is fully established, it will create a protocol control buffer essentially, which will contain information on the connection (essentially the 4-tuple and a couple of other things again). There's two such buffers, one representing each side of the connection and this buffer lives in memory on the load-balancer until the session is ended, when they're cleared to free up the memory for use again.

Solution 3:

Citrix NetScaler seems to be the most advanced load balancing solution especially in the area of clustering. You don't need to install an HA pair, just use a two box cluster. Then as you want to grow, just add more boxes to cluster. They also can cluster load balancers running in VM's.