Skip to end of metadata
Go to start of metadata

Introduction

Project/Component Working Name:

DNS SRV Client Bootstrap as part of the official supported SDKs.

Name of Document Author/Supplier:

Michael Nitschinger <michael.nitschinger@couchbase.com>

Date of this Document:

26 March 2014

Proposal Status:

DRAFT

Name of Major Document Customer(s)/Consumer(s):

Developers using Couchbase, SDK Development Team.

Communications:

couchbase@googlegroups.com

Project Summary:

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.

Project Description:

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.

Risks and Assumptions:

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.

Business Summary

Problem Area

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.

Market/Requester

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.

How will you know when you are done?

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.

Technical Description

Details

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.

Issues/Issues to be Opened:

tbd

Other Solutions Previously Considered:

-

In Scope:

The implementation with the given process in each of the underlying SDKs (that is, C, Java and .NET)

Out of Scope:

Anything that has to do with DNS management, especially in the user environment.

Interfaces:

Exacts yet to be defined, but most probably either a helper class or baked in into the bootstrap process.

Doc Impact:

Every SDK needs to document on how to use it.

Admin/Config Impact:

None Couchbase-wise, DNS needs to be configured by the user.

Packaging and Delivery Impact:

-

Security Impact:

-

Dependencies:

-

Reference Documents:

http://en.wikipedia.org/wiki/SRV_record

Resources and Schedule

Projected Availability:

With the next planned minor releases, ideally in line with the next line of CCCP changes.

Cost of Effort:

-

Prototype Availability

Prototype Availability:

Java prototype: http://review.couchbase.org/#/c/32994/

Prototype Cost:

-

Open Questions

-

Changelog

  • 26 March 2014: Initial port over to the wiki from email communication
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 26, 2014

    Matt Ingenthron says:

    Doc impact should include that we need to detail the record format somewhere, an...

    Doc impact should include that we need to detail the record format somewhere, and that's probably more related to cluster installation and configuration with a crossreference from SDK docs.