Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NOT_A_BUG] Shuffling data centers based on GeoIP and availability #127

Open
birdie-github opened this issue Jun 20, 2016 · 3 comments
Open

Comments

@birdie-github
Copy link

birdie-github commented Jun 20, 2016

Hi,

I'm terribly sorry if this is already covered in Wiki but I couldn't understand how to implement this, so I'm asking here.

We have six data centers, let's say two in the US, two in the UK, and two in Germany. Based on the client IP and DC response time we need to give the client up to three DCs' IP addresses: two, which are the closest to the client, and one random IP from the remaining pool of DCs. If one of the closest DCs is too slow, then we omit its IP address from the output altogether.

The config below resolves only the closest DC:

plugins => {
  geoip => {
    maps => {
      prod_servers_map => {
        geoip2_db => GeoLite2-Country.mmdb
        datacenters => [ us, uk, de ] ; the fallback default result ordering in various default cases
        map => {
          NA => [ us, uk, de ] ; North America
          SA => [ us, de, uk ] ; South America
          EU => [ de, uk, us ] ; European Union
          AF => [ uk, us, de ] ; Africa
          AS => [ de, us, uk ] ; Asia
          OC => [ de, us, uk ] ; Oceania
          AN => [ uk, us, de ] ; Antarctica
          -- => [ uk, us, de ] ; All others, unidentified, satellites, etc.
        }
      }
    }
    resources => {
      prod_cdn => {
        map => prod_servers_map
        service_types => [ http_status ]
        up_thresh = 0.5
        dcmap => {
          us  = { lb1 = 127.0.10.1, lb2 = 127.0.10.2 }
          uk  = { lb1 = 127.0.20.1, lb2 = 127.0.20.2 }
          de  = { lb1 = 127.0.30.1, lb2 = 127.0.30.2 }
        }
      }
    }
  }
}

Zone:

                DYNA  geoip!prod_cdn

So if you're from the EU, you should get two Germany IP addresses and one random IP address from the remaining pool. If one of Germany's IP addresses is too slow to respond, then we provide the client with just one Germany address and two random IP from US/UK. If both Germany addresses are too slow, we randomly give random three remaining IP address (if they're not too slow of course).

So, based on your address, you should get either:

  • 2 close good, 1 good random
  • 1 close good, 2 good random
  • 0 close good, 3 good random

if all the conditions above fail, e.g. all DCs are slow, we randomly give any three IP addresses.

@blblack
Copy link
Member

blblack commented Jun 20, 2016

There's probably a way to get close to what you're describing by layering various plugins. The meta-plugins ("geoip" and "meta") can both make layered use of resources defined by other plugins, including each other. I'm really not sure if it's possible to do exactly what you're describing, though.

At least on the surface, I also don't see why you'd want to do what you're doing though. It seems very complicated, and end-result doesn't sound great for users/caches, who don't care about ordering so much and will choose randomly from the set you serve. Knowing the actual use-case would be helpful.

@birdie-github
Copy link
Author

Hi,

Like I said earlier we have two data centers for each of our three geographical locations.

We are basically a CDN, so we want to supply our end users with the best geographical location (because obviously it means lower latency and higher satisfaction) and also we want to take into consideration a particular data center load - i.e. if it's already near or above its capacity we want to serve the user a random remaining data center.

So, my question is what's the best way to implement our needs in terms of returning DNS records.

@blblack blblack added this to the The Future milestone Jun 6, 2018
@blblack
Copy link
Member

blblack commented Jun 6, 2018

This is old (sorry for lack of response back then!), but some of the questions it raises are interesting to think about as the DYNx stuff's design is re-visited. I don't know if the entirety of the original desire here is feasible (or useful in the real world?), but it's worth contemplation...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants