NAME
ganeti-masterd - ganeti master daemon
SYNOPSIS
ganeti-masterd [ -f ] [ -d ] [ --no-voting ]
DESCRIPTION
The ganeti-masterd is the daemon which is responsible for the overall
cluster coordination. Without it, no change can be performed on the
cluster.
For testing purposes, you can give the -f option and the program won’t
detach from the running terminal.
Debug-level message can be activated by giving the -d option.
ROLE
The role of the master daemon is to coordinate all the actions that
change the state of the cluster. Things like accepting new jobs,
coordinating the changes on nodes (via RPC calls to the respective node
daemons), maintaining the configuration and so on are done via this
daemon.
The only action that can be done without the master daemon is the
failover of the master role to another node in the cluster, via the
gnt-cluster masterfailover command.
If the master daemon is stopped, the instances are not affected, but
they won’t be restarted automatically in case of failure.
STARTUP
At startup, the master daemon will confirm with the node daemons that
the node it is running is indeed the master node of the cluster. It
will abort if it doesn’t get half plus one positive answers (offline
nodes are queried too, just in case our configuration is stale).
For small clusters with a number of nodes down, and especially for two-
node clusters where the other has gone done, this creates a problem. In
this case the --no-voting option can be used to skip this process. The
option requires interactive confirmation, as having two masters on the
same cluster is a very dangerous situation and will most likely lead to
data loss.
JOB QUEUE
The master daemon maintains a job queue (located under
/var/lib/ganeti/queue) in which all current jobs are stored, one job
per file serialized in JSON format; in this directory a subdirectory
called archive holds archived job files.
The moving of jobs from the current to the queue directory is done via
a request to the master; this can be accomplished from the command line
with the gnt-job archive or gnt-job autoarchive commands. In case of
problems with the master, a job file can simply be moved away or
deleted (but this might leave the cluster inconsistent).
COMMUNICATION PROTOCOL
The master accepts commands over a Unix socket, using JSON serialized
messages separated by a specific byte sequence. For more details, see
the design documentation supplied with Ganeti.
REPORTING BUGS
Report bugs to <URL:http://code.google.com/p/ganeti/> or contact the
developers using the ganeti mailing list <ganeti@googlegroups.com>.
SEE ALSO
Ganeti overview and specifications: ganeti(7) (general overview),
ganeti-os-interface(7) (guest OS definitions).
Ganeti commands: gnt-cluster(8) (cluster-wide commands), gnt-job(8)
(job-related commands), gnt-node(8) (node-related commands), gnt-
instance(8) (instance commands), gnt-os(8) (guest OS commands), gnt-
backup(8) (instance import/export commands), gnt-debug(8) (debug
commands).
Ganeti daemons: ganeti-watcher(8) (automatic instance restarter),
ganeti-cleaner(8) (job queue cleaner), ganeti-noded(8) (node daemon),
ganeti-masterd(8) (master daemon), ganeti-rapi(8) (remote API daemon).
COPYRIGHT
Copyright (C) 2006, 2007, 2008, 2009 Google Inc. Permission is granted
to copy, distribute and/or modify under the terms of the GNU General
Public License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
On Debian systems, the complete text of the GNU General Public License
can be found in /usr/share/common-licenses/GPL.