Synnefo » snf-ganeti » ganeti-local

between machines connected to the same switch might be bigger than the

bandwidth for inter-switch connections.

together for inter-node consistency, and won't scale if we increase the

number of nodes to a few hundreds.

~~~~~~~~~~~~~~~~

With this change we'll divide Ganeti nodes into groups. Nothing will

Node group management

+++++++++++++++++++++

To manage node groups and the nodes belonging to them, the following new

  gnt-node group-add <group> # add a new node group

  gnt-node group-del <group> # delete an empty group

  - Moving an instance between groups can only happen via an explicit

    operation, which for example in the case of DRBD will work by

    performing internally a replace-disks, a migration, and a second

    group-move operation.

  - Cluster verify will signal an error if an instance has been left

    mid-transition between groups.

    group will be able to accept the instance network/storage wise, and

    fail otherwise. In the future we may be able to make some parameter

    changed during the move, but in the first version we expect an

We expect the following changes for cluster management:

  - Frequent multinode operations, such as os-diagnose or cluster-verify

    is passed. Command line tools will have a way to easily target all

    groups, by generating one job per group.

  - Groups will have a human-readable name, but will internally always

should we see it's useful.

We envision groups as a good place to enhance cluster scalability. In

to allow a better master scalability. For example it could be possible

to change some all-nodes RPCs to contact each group once, from the

master, and make one node in the group perform internal diffusion. We

- the total node memory, CPU count are very seldom changing; the total

  node disk space is also slow changing, but can change at runtime; the

  free memory and free disk will change significantly for some jobs, but

  during the lifetime of a job

- we already have a periodic set of jobs that query the node and

  instance state, driven the by :command:`ganeti-watcher` command, and

  we're just discarding the results after acting on them

The cache will not be serialised to disk, and will be for the most part

transparent to the outside of the master daemon.

consistent). Partial results will not update the cache (see next

paragraph).

would like to have a consistent cache view when driven by the watcher,

we'll introduce a new OpCode/LU for the watcher to run, instead of the

current separate opcodes (see below in the watcher section).

allocation on one group from exclusive blocking jobs on other node

groups.

the respective sections.

Watcher operation

This method will feed the cluster state (for the complete set of node

group, or alternative just a subset) to the iallocator plugin (either

new capacity in the format currently exported by the htools suite and

known as the “tiered specs” (see :manpage:`hspace(1)`).