Synnefo » snf-ganeti » ganeti-local

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