Forum Discussion
Kevin_Nail
Nimbostratus
NimbostratusGTM Topology configuration
Hi,
I have a configuration dilema that I am not sure how to resolve.
Here is the scenario. I have 3 GTM's all in one location, so all queries will go the same geographic location. I need to load-balance (for lack of a better term) DNS queries between 4 different servers based on client-IP. The servers are located in:
Oklahoma
Colorado
Singapore
Korat
I have created 4 different data centers and placed the Singapore, Colorado, and Korat servers by themselves in their own datacenter. The Oklahoma servers already has a datacenter with several other IPs.
I need clients from Singapore to get handed back the server in Sinagapore, etc...
My question is this. Which would be better suited, topology or an iRule. There is 1 wideip and 1 pool that contains the 4 other servers (actually pools of servers. I created 1 pool for each location).
I could configure topology but I am not sure how to set it up so that I don't run into issues with any other future topology plans. IE: Should the destination be based on datacenter location of specific pool or regions?
Or should I just use an iRule. Any help or suggestions?
Thanks,
Kevin
- JRahm
Admin
You could do topology at the pool level, separating singapore and korat into a pool and oklahoma/colorado into a pool. Then you could further do topology within the singapore/korat pool, and use another method for the US (least conn / rr / vs capacity, etc). It really boils down to what your business rules are. If you can narrow down the business rules it would help. For example, should all users outside singapore go to US, or should all asia requests hit korat or singapore. Except for singapore, does it matter which DC the requests go to? For all other world users, should they go to colorado, oklahoma, or both? 
Kevin_NailHi,
Thanks for the assisstance.
Topology at the pool level is where I was leaning towards. With all 4 of them being in different pool.
The site in question is a file upload/download site and the topology would only apply to this one site. This is why I have to be careful with the topology rules, so that it doesn't affect or won't hinder any future topology setups. All other wideips would function within their own pools outside of this one particular setup.
In this case the business rules are as follows:
All Colo users that access this one particular site will get sent to the Colo pool
All Korat users (with IPs in a certain range) to the site would get sent to the Korat pool
All other users in Asia would get sent to the Singapore pool.
All other users to the site (world-wide and US) would go to the Okla. site.- JRahmSo if you have multiple matches, the highest weight wins. Also, if you have multiple records match, but the destination is not referenced in the wideIP, then the record is ineligible. This should mitigate your concern for future expansion of topology. So for this instance, you'll need IP source for Korat & Colorado. You'd place a slightly higher weight on the records for Korat & Colorado, then you could build a Continent is Asia record to send all Asia requests to Singapore, then a Continent is not Asia to send all other requests to Oklahoma.
- Kevin_Nailok the picture is becoming a little clearer... thanks for being patient.
One other question; Where do I point the topology record?
For example:
wideip -----> contains to all 4 pools (Korat, Colorado, Singapore, US)
Topology record (for Korat)
IP based with a weight of 200
where is the destination? How does it know to get to the Korat pool? Do I assign its destination as the Korat pool?
Also what did you mean that if the destination is not referenced in the wideip the topology record is invalid?
Thanks,
Kevin - JRahmFor the topology record, IP subnets would be the source, the destination would be the korat pool. In the wideIP, you would add the korat pool at that level and assign topology.
For the invalid record, consider:
IP source: 10.10.20.0/24, destination: korat pool, weight 10
IP source: 10.10.20.0/24, destination: other, weight 10
Both records would match your ldns server, but only the first would be valid as it is the only of the two records that have a known reference in the wideIP. - JRahmwhoops, didn't see Denny's response before posting...thanks Denny!
- Kevin_NailThanks Guys!
I have implemented your suggestions. Will let you know how the testing goes.
Regards,
Kevin - Kevin_NailThe testing is going well but has brought up another question.
I have setup Topology on the wideip but there is not a second option to set on the wideip, I can set the fallback pool but not a secondary option. Am I missing something? I know the pool have 3 options, what about the wide-ip? Also what happens when a client makes a request and the topology records match a pool that is marked down (3 of the pools currently on have 1 member)? would it resolve to the next best match, or use the fallback pool?
Thanks,
Kevin - dennypayne
Employee
Sorry, I misspoke a little. You're right that the Preferred, Alternate, and Fallback methods are set on the pool. The wideip can then have a lb method to lb between multiple pools (which most people don't have a need for). So if you are using only 1 pool, the wideip lb method doesn't really do anything.
If the Preferred fails, the Alternate should be used. If that fails, then Fallback. So if you set both P and A to Topology, then if the topology records match a down pool, the fallback will be used. You could switch the Alternate to something else if that works better for your environment.
Denny - Kevin_NailThanks Denny! That explains alot.
Kevin
