ganeti-masterd - Ganeti master daemon
ganeti-masterd [-f] [-d] [–no-voting]
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.
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 master-failover command.
If the master daemon is stopped, the instances are not affected, but they won’t be restarted automatically in case of failure.
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.
When the master daemon receives a SIGINT (Ctrl-C) or SIGTERM signal, it stops accepting new jobs and prepares to shut down shortly after jobs running at the time finish. Meanwhile it still responds to LUXI requests. Pending jobs are re-queued after the daemon is started again. When a second signal is received, the master daemon terminates without waiting (it might still need to wait for some threads to finish). Note that the latter, as well as sending SIGKILL, may leave the cluster in an inconsistent state.
The master daemon maintains a job queue (located under the directory /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).
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.