In the initial blog, I mentioned that in a recent GSLB project, I had used an IP Proximity database to determine the location of the “most suitable” GSLB site. After addressing the issues of actually reading the massive database, I felt that I was progressing nicely.

But my stumbling on some rather unexpected considerations continued.

Orphan Geographies

The next step, I recognized, was to associate any worldwide geography to the most appropriate GSLB site.

So what, really, is the problem?

Remember that we had four sites in the GSLB configuration. These were Miami, San Francisco, London, and Sydney. According to the IP location database, these sites had the following location affinity. (I’ve substituted some Citrix IP addresses to protect the anonymity of the project.)

But there are more countries than there are GSLB Sites. Where should requests from “orphan continents” be directed? I had to find a way to “bind” the other countries to the appropriate site. The following diagram explains the issue.

So, I made an arbitrary routing decision, since the data was replicated to all four GSLB sites. All South American DNS requests should be pointed to the Miami Site; all African requests should resolve to the London; all Asian requests to Sydney.

Remember that in a non-match condition, the GSLB would revert to the backup distribution – which I set to Round Robin. So to avoid wide spread round robin distribution, I had to manually configure the NetScaler so that it correctly associated regions with those that hosted a GSLB site.

Assigning Homes

To set the correct associations, I created NetScaler DNS policies. In each of these, I specified the geographic region in which a GSLB site was located. Then, in each of these, I specified the appropriate locations of the client source IP address (actually – the IP addresses of the DNS servers) to these GSLB site locations. I did this for all continents. That way, I felt I was sending all requests to their most logical GSLB site.

It is interesting to note that the IP Proximity database contains no references to the “Continent” location parameter. Upon loading the data into the NetScaler, the GSLB location algorithms automatically pre-pend the appropriate continent information to the country. This simplifies location overrides.

In this example GSLB request coming from a DNS server in Asia will be treated as if the request came from a DNS server in Sydney. This causes the GSLB routing to assign the Sydney GSLB site to this request.

Of course there was some trial and error, and I had to define additional DNS policies, and bind them. But after this process was complete, I had regained control over the GSLB IP Proximity routing process.

I’ll be writing this up in greater detail in my formal paper. This will include binding the policies and other details. But to summarize, the chart below contains all the overrides I ultimately needed. Blatantly missing is Antarctica. I thought that I would let users using DNS servers based there could go round robin. From there, probably all the sites are equidistant anyway.

You may be wondering what happened to the San Francisco site. I had originally supplied overrides for the “western” American states and Canadian provinces, binding them to the San Francisco site. But, as we discussed in the earlier blog, the DNS servers of the major ISPs appeared to be east coast resident and sent every request to Miami. So I dropped the country splitting approach, and applied a NetScaler responder in the US GSLB locations. That simply sent the domestic requests to secondary round-robin GSLB between the Miami and San Francisco GSLB sites.

There are, of course other options, but I chose these.

In the next BLOG of this series, I’ll be looking at some of the trouble shooting tips and tricks I used during this GSLB implementation. Some were obvious, while others were obvious only in hindsight. Don’t we all just love the latter type?

I’d love to hear your comments!

Twitter: @StefanDrege