| ganeti-masterd(8) Ganeti | Version @GANETI_VERSION@ |
| =================================================== |
| |
| 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 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. |
| |
| 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. |
| |
| SHUTDOWN |
| ~~~~~~~~ |
| |
| 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. |
| |
| JOB QUEUE |
| ~~~~~~~~~ |
| |
| The master daemon maintains a job queue (located under the directory |
| ``@LOCALSTATEDIR@/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. |
| |
| .. vim: set textwidth=72 : |
| .. Local Variables: |
| .. mode: rst |
| .. fill-column: 72 |
| .. End: |
