F5 GTM DNS persistence

We ran for about 8 years with a dual site load balancing architecture for our Internet accessible web sites. Started with 3DNS engines and BigIP at version 3.x, thru 4.5, now at version 9.48 GTM and LTM. We used persistence at the DNS level and simple source ip persistence at the LTM, or BIgiIP level. That worked fine for the first few years until the load balancing of local DNS servers started happenign and it started to become more common for a users ldns to change during the middle of their web session. That could be alleviated by increasing the TTL, but the tradeoff is more downtime to a user if you have a problem at one datacenter and they keep coming to it until the TTL expires and they ask you again which datacenter to go to.

 

 

As a stopgap we applied topology records that basically split the Internet in half, and went with a quasi active/standby for each half, making each datacenter primary for one of the halfs. That seemed to work fairly well. It was still technically possible for someone to be using an ldns from the lower half if the IP range and then come from one in the upper range, but it was much less likely.

 

 

We then (about 2 years ago) closed our second in region datacenter and moved a lot of the equipment either to our one remaining datacenter in the region, and opened an out of region datacenter about 1500 miles away. The latency involved with that connection made a lot of the apps unusable when the app servers were in the out of region datacenter and the database was in the primary, so we are in a true active standby mode now.

 

 

I have read some of the stuff F5 is coming out with on global topology to try and address the issue of ldns persistence, but haven't had the time to pursue it yet, although we are starting to get more pressure to make use of the valuable resources in our out of region datacenter for more than just insurance against a disaster, so I'm going to need to make the time....

 

 

Regards,

 

 

Mark

Hey guys, I ran into this very problem a couple years back... Persistence worked just great at the WideIP level for a while... Then it seemed we were getting more and more complaints about bouncing from one dc to the next.. After some investigation, yep you guessed it, load balancing of LDNSs.... And the problem with Persistence at the WIP level is it's based on the 32 bit address of the LDNS..

 

 

I actually put a feature request in a while back so you could specify the CIDR block... ie perist on first 8 bits, 16, etc etc This was back in ver 9.3.x I believe... I don't believe it has been resolved.. has it? If you see this as useful, could you please +1 the feature request?? I'll try to dig up the ID... or maybe someone internal will see this post and dig it up for us ;)

 

 

Soo your solution is to use Static Persist at the Pool level, where you CAN specify the CIDR.. You specify the CIDR in--> System--->Configuration---->Global Traffic--->General--->Static Persist CIDR (IPv4) & (IPV6).. I do wish this was not a global setting, and specified at the pool level..

 

 

Now that will absolutely work for you, but you need to understand how it works and the trade-offs...

 

 

Static Persist will do an MD5 hash on the pool member makeup and the LDNS then return the SAME value every time to a user, unless the pool makeup changes, or that member is unavailable.. There is no persistence table with this logic..

 

 

With all of that in mind you may not see the most even split of traffic... In my experience it was never to bad... 60/40ish and the business was very happy to have a fix.. but it has the potential to be worse.. So you need to take that into account and share the info.. but if persistence is what you need it seems to be the best option without using topology record logic..

 

 

 

Hello,

 

We are running into the same issue. Let us know if F5 has a recommended solution for ldns persistence.

 

 

Regards,

 

Karthik