How many times – in retrospect – does it seem that the answer to a head scratcher was clearly there, but we just didn’t see it at the time? In doing a major multinational GSLB project, such a situation arose.
Today’s enterprises use Global Server Load Balancing (GSLB) to send user traffic to two or more datacenters. Typically, this is used for one of two purposes. The first is to automatically send user traffic to a disaster recovery (DR) site in the event of a catastrophic failure in the primary datacenter. The second typical use of GSLB is by companies that have multinational presence and localized datacenters with application and data equivalence. These organizations often use GSLB to distribute user traffic between those sites on a load balancing basis. In either usage scenario, the users always hit the same URL for their application, XenDesktop, or SSLVPN, and “the system” sends their request appropriately.
GSLB is a DNS redirection process. Sure, we all understand that. And the NetScaler GSLB algorithms respond with appropriate addresses based upon many parameters that might include the health and possibly proximity of the datacenters, their applications, or the XenDesktop infrastructures.
But there’s the rub. IP proximity – which seems like the universal cure-all – is based upon the assigning the closest eligible GSLB site based upon the location affinity of the IP address of the DNS server making the request, not based upon that of the actual user.
In my recent project, this became an interesting issue. In configuring east-coast and west-coast GSLB sites, I used an IP proximity database. I even overrode the NetScaler GSLB configuration stating that the requests with a location affinity west of the Mississippi would be sent to the San Francisco site, while defaulting all other states to the Miami site. Pretty clever, I thought.
But no. Users seemed to be going to the Miami site, predominantly. Even from my house, in the San Francisco Bay area, off I went to the Miami site.
What was going on? Further investigation (Don’t you just love network traces?) revealed that my ISP hosted their DNS servers in New York. So the location affinity of the requesting DNS server was east coast. That caused the GSLB site assignment to be Miami, even though I lived just across the bay from the San Francisco datacenter.
Then, on a business trip to Los Angeles, I stayed in a hotel that used a British ISP. Hello London site!
So what did I do? To address the US site assignment problem, I simply changed the GSLB algorithm to use Round Robin for the US based GSLB Sites – treating the two datacenters as one logical location – while using IP proximity for the other datacenters on their own continents.
And the Los Angeles hotel? London is nice this time of year, and it was not worth creating specific override…
In blogs to come, I’ll discuss some of the other “interesting” considerations of implementing GSLB, based upon my experiences, of course. Additionally, I’m working on a more formal document that will include some detailed recommendations and some trouble shooting tips.
Watch this space!