DNS SRV Client Bootstrap as part of the official supported SDKs.
Michael Nitschinger <email@example.com>
26 March 2014
Developers using Couchbase, SDK Development Team.
Provide a simple way of externalising bootstrap nodes. System admins and devops should have an easy way to change bootstrap nodes without having to touch the actual application configurations.
Utilizing the DNS Service Resource Records (http://en.wikipedia.org/wiki/SRV_record), it is possible to fetch a list of bootstrap nodes through a single “service record” identifier.
This list can then be used to bootstrap the client library instead of a hardcoded host/URI list.
The project assumes that in the used environment, DNS is configured properly and the client can read the required DNS information from there.
A potential risk is that since this feature depends on a external service, if this one is unavailable the feature can't be used. Fallback mechanisms are discussed later.
The main problem is that in larger and diverse setups, managing bootstrap nodes can be a pain. There are many ways to centralize this, most of them dependent on the language and frameworks used. The method described here is diverse, because DNS support can be found in almost all languages.
Every user out there, but more likely larger (enterprise) users who have their own DNS infrastructure and want to centralize couchbase cluster node bootstrap information. Also, users will benefit that run different languages since once implemented they can all use the same sources.
If libcouchbase, .net and java all implement the DNS bootstrap facilities as described in this proposal. Users will be able to bootstrap off of them.
1) Before bootstrapping the application, the network administrator configures SRV record entries like this:
_cbmcd._tcp.example.com. 0 IN SRV 20 0 11210 node2.example.com.
_cbmcd._tcp.example.com. 0 IN SRV 10 0 11210 node1.example.com.
_cbmcd._tcp.example.com. 0 IN SRV 30 0 11210 node3.example.com.
_cbhttp._tcp.example.com. 0 IN SRV 20 0 8091 node2.example.com.
_cbhttp._tcp.example.com. 0 IN SRV 10 0 8091 node1.example.com.
_cbhttp._tcp.example.com. 0 IN SRV 30 0 8091 node3.example.com.
2) A utility class (or directly baked into the bootstrap process) takes the service ID "example.com” as an argument and looks for both _cbmcd.tcp and/or _cbhttp._tcp. Depending on what we find, we can bootstrap through
CCCP (11210) or fallback to HTTP (8091). Of course if the user specifies different ports, use those.
From the given list, the regular bootstrap process can be run.
- Note that as part of DNS SRV, both weighting and priorities are supported. While weighting is somewhat more complicated (because the value would tell you the percent chance that it gets used), implementing priority is straightforward and makes sense. What should happen is that lower priority gets put first in the list, so its sorted ascending by the priority value.
In our example case above, we would get it sorted 10, 20, 30… so node1, node2, node3.
- Also, since IO errors could happen all the time (dns not reachable,…) docs and the process should always think about the case what happens then. Most of the time there would need to be a fallback to a static list, or fail appropriately.
The implementation with the given process in each of the underlying SDKs (that is, C, Java and .NET)
Anything that has to do with DNS management, especially in the user environment.
Exacts yet to be defined, but most probably either a helper class or baked in into the bootstrap process.
Every SDK needs to document on how to use it.
None Couchbase-wise, DNS needs to be configured by the user.
With the next planned minor releases, ideally in line with the next line of CCCP changes.
Java prototype: http://review.couchbase.org/#/c/32994/
- 26 March 2014: Initial port over to the wiki from email communication