Commit c0446a46 authored by Guido Trotter's avatar Guido Trotter

ganeti-confd design doc

Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
Reviewed-by: default avatarIustin Pop <iustin@google.com>
parent 4a34c5cf
......@@ -40,6 +40,61 @@ Core changes
Feature changes
---------------
Ganeti Confd
~~~~~~~~~~~~
Current State and shortcomings
++++++++++++++++++++++++++++++
In Ganeti 2.0 all nodes are equal, but some are more equal than others. In
particular they are divided between "master", "master candidates" and "normal".
(Moreover they can be offline or drained, but this is not important for the
current discussion). In general the whole configuration is only replicated to
master candidates, and some partial information is spread to all nodes via
ssconf.
This change was done so that the most frequent Ganeti operations didn't need to
contact all nodes, and so clusters could become bigger. If we want more
information to be available on all nodes, we need to add more ssconf values,
which is counter-balancing the change, or to talk with the master node, which
is not designed to happen now, and requires its availability.
Information such as the instance->primary_node mapping will be needed on all
nodes, and we also want to make sure services external to the cluster can query
this information as well. This information must be available at all times, so
we can't query it through RAPI, which would be a single point of failure, as
it's only available on the master.
Proposed changes
++++++++++++++++
In order to allow fast and highly available access read-only to some
configuration values, we'll create a new ganeti-confd daemon, which will run on
master candidates. This daemon will talk via UDP, and authenticate messages
using HMAC with a cluster-wide shared key.
An interested client can query a value by making a request to a subset of the
cluster master candidates. It will then wait to get a few responses, and use
the one with the highest configuration serial number (which will be always
included in the answer). If some candidates are stale, or we are in the middle
of a configuration update, various master candidates may return different
values, and this should make sure the most recent information is used.
In order to prevent replay attacks queries will contain the current unix
timestamp according to the client, and the server will verify that its
timestamp is in the same 5 minutes range (this requires synchronized clocks,
which is a good idea anyway). Queries will also contain a "salt" which they
expect the answers to be sent with, and clients are supposed to accept only
answers which contain salt generated by them.
The configuration daemon will be able to answer simple queries such as:
- master candidates list
- master node
- offline nodes
- instance list
- instance primary nodes
Redistribute Config
~~~~~~~~~~~~~~~~~~~
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment