Support DNS lookups to "meta" DCs

[armon]

We can support special meta-dc's that have special meanings. Examples:

• 'global' - Do a lookup across all DCs
• 'any' - Returns results from first DC to respond

[progrium]

• 'local' - do a lookup for only services on that agent (special meta DC)

[wuub]

@armon this is very interesting. are there any active work/design going on, or is it only an idea?

[armon]

@wuub No active work on this yet, but its in the design phase you could say. Definitely something I'm keen to support!

[armon]

@andrewwatson mentioned the possibility of named groups of data centers. e.g. "EU" -> ["UK", "GE", "FR"]

[andrewwatson]

In addition to establishing maps like "EU" -> ["UK", "DE"] it would be very useful to be able to specify for each dc a backup or a list of backups

I'm thinking this could be in the K/V, even.

/_meta/dc/backups => 'dc1, dc2, dc3'

That way you could change it without restarting anything.

[jefferai]

Yes, yes, a thousand times yes.

We want to have the ability, when desired, to have services resolve locally when possible but remotely if necessary. We don't necessarily want every query to behave this way so it'd be nice to be able to specify behavior per-query.

I'm assuming the "global" behavior mentioned in the first comment would be what I described above.

[keyneston]

If and when you do implement this can you make sure these meta-datacenters also work in the http api.

It would be useful in our puppet code for example to be able to say dc=global.

[mfischer-zd]

+1 for this request. We would like a datacenter-neutral, globally replicated K/V store, where the HTTP clients (not necessarily through their own Consul agent) preferentially look up from the local datacenter but can fall back over the WAN if necessary.

[armon]

@mfischer-zd As a note, this ticket will only affect DNS and not the KV store

[mfischer-zd]

@armon understood - this would affect how the Consul HTTP server (which would be accessible remotely) would be resolved.

[andrewwatson]

No, I don't think so. It would affect the answers you got back from the
consul server you send DNS queries to.

On Mon, Oct 27, 2014, 1:19 PM Michael S. Fischer [email protected]
wrote:

@armon https://github.com/armon understood - this would affect how the
Consul HTTP server (which would be accessible remotely) would be resolved.

—
Reply to this email directly or view it on GitHub
#208 (comment).

[mfischer-zd]

@andrewwatson in my scenario I have two separate Consul clusters, one configured in the usual way (cluster A), and another that provides a replicated K/V store (cluster B, running on a dedicated set of hosts which does not include the clients). Cluster A would be used by clients to perform DNS queries to resolve members of Cluster B.

So really we're saying the same thing.

[hco]

+1 For this feature! :-)

A nice to have would be to allow your own priorities for a response of the DC "any".

[adrienbrault]

👍

[hopperd]

+1
This functionality would be very useful, we have multiple data centers and a client might not actually know which datacenter that service resides in and thus would want to have local return if available, but then the others if not.

[mfischer-zd]

An easy workaround would be to use a regular DNS server to serve a CNAME record outside the .service.consul domain. For example, a query for "frobinator.service.local" against the local DNS resolver could result in a CNAME answer for "frobinator.dc1.service.consul".

What do you think of this? Doing so would keep Consul out of the complex business of managing foreign service endpoints.

[jefferai]

@mfischer-zd then you have to implement and configure some other piece of software to do this, when Consul already knows where things live.

[DanyC97]

Has been done any progress on this ?

thanks!

[StephenTallamy]

Any updates on this? Is a solution likely to hit a release version soon? I have this same requirement - I want my DNS names to resolve to nodes in my local data center unless Consul detects an outage for all nodes in my local data center and then it will resolve to nodes in a remote data center. At this point I don't need rules around which data center it fails over to, although later this could be beneficial.

[armon]

We are getting closer, but still looking like a Consul 0.6 or 0.7 feature.

[StephenTallamy]

Thanks @armon - what's the release timescale on those?

[armon]

@StephenTallamy No hard deadlines. Consul 0.6 likely next month, and 0.7 in Q4.

[hopperd]

Will this functionality help with DNS forwarding? Currently it seems as though it isn't possible to use DNS forwarding with multiple data centers as you'll only get back the services from the DC that is queried. We have currently 2 data centers (these are real data centers in different parts of the country) and multiple environments in each data center (dev, qa, perf, prod, etc).

So it seems that setting up DNS forward to work in this situation is essentially not possible without this feature.

[armon]

@Split3 Correct! You will be able to query multiple DCs at the same time.

[slackpad]

The "local" use case is covered here #1229 and in its linked issues. The multi-DC aspect of this is now supported with prepared queries, released in 0.6.0:

https://www.consul.io/docs/agent/http/query.html