F5 UAG SharePoint 2010 (NO DIRECT ACCESS)

Lazar, I believe cookie insert persistence, being based off a simple hash, has a couple advantages.

 

1. Gets around the clumping that happens with the 'branch office' or proxy scenario that Joe might encounter.

 

2. No persistence table needs to be maintained on the BIG-IP, as in the case of source IP persistence.

 

3. No persistence table needs to mirrored to the failover BIG-IP. Since it is a hash, the failover BIG-IP can read and understand it immediately.

 

 

If you do go with source IP persistence (which is often the only option when you are persisting non-http traffic), the BIG-IP builds and maintains a persistence table that includes the source IP / VIP:Port / and selected pool member. You can also configure the BIG-IP to mirror this table to the peer BIG-IP in the case of a BIG-IP failover. In my experience, sometimes I recommend mirroring the persistence table, sometimes I don't. If the application you are load balancing uses a very large number of short lived TCP connections, constantly mirroring this table can start to eat resources on the BIG-IP (fortunately HTTP keep-alives has mitigated this behaviour for http to a large extent), and some protocols/apps are actually more resilient to failure than others. For instance, a lot of times, if an HTTP session is disrupted (as may be the case with a BIG-IP failover) the client will often just resend the request after a short timeout, which will hopefully result in a completed transaction.