root / man / ganeti-masterd.rst @ 295ed29b
History | View | Annotate | Download (3.3 kB)
1 |
ganeti-masterd(8) Ganeti | Version @GANETI_VERSION@ |
---|---|
2 |
=================================================== |
3 |
|
4 |
Name |
5 |
---- |
6 |
|
7 |
ganeti-masterd - Ganeti master daemon |
8 |
|
9 |
Synopsis |
10 |
-------- |
11 |
|
12 |
**ganeti-masterd** [-f] [-d] [\--no-voting] |
13 |
|
14 |
DESCRIPTION |
15 |
----------- |
16 |
|
17 |
The **ganeti-masterd** is the daemon which is responsible for the |
18 |
overall cluster coordination. Without it, no change can be |
19 |
performed on the cluster. |
20 |
|
21 |
For testing purposes, you can give the ``-f`` option and the |
22 |
program won't detach from the running terminal. |
23 |
|
24 |
Debug-level message can be activated by giving the ``-d`` option. |
25 |
|
26 |
ROLE |
27 |
~~~~ |
28 |
|
29 |
The role of the master daemon is to coordinate all the actions that |
30 |
change the state of the cluster. Things like accepting new jobs, |
31 |
coordinating the changes on nodes (via RPC calls to the respective |
32 |
node daemons), maintaining the configuration and so on are done via |
33 |
this daemon. |
34 |
|
35 |
The only action that can be done without the master daemon is the |
36 |
failover of the master role to another node in the cluster, via the |
37 |
**gnt-cluster master-failover** command. |
38 |
|
39 |
If the master daemon is stopped, the instances are not affected, |
40 |
but they won't be restarted automatically in case of failure. |
41 |
|
42 |
STARTUP |
43 |
~~~~~~~ |
44 |
|
45 |
At startup, the master daemon will confirm with the node daemons |
46 |
that the node it is running is indeed the master node of the |
47 |
cluster. It will abort if it doesn't get half plus one positive |
48 |
answers (offline nodes are queried too, just in case our |
49 |
configuration is stale). |
50 |
|
51 |
For small clusters with a number of nodes down, and especially for |
52 |
two-node clusters where the other has gone done, this creates a |
53 |
problem. In this case the ``--no-voting`` option can be used to |
54 |
skip this process. The option requires interactive confirmation, as |
55 |
having two masters on the same cluster is a very dangerous |
56 |
situation and will most likely lead to data loss. |
57 |
|
58 |
SHUTDOWN |
59 |
~~~~~~~~ |
60 |
|
61 |
When the master daemon receives a ``SIGINT`` (Ctrl-C) or ``SIGTERM`` |
62 |
signal, it stops accepting new jobs and prepares to shut down shortly |
63 |
after jobs running at the time finish. Meanwhile it still responds to |
64 |
LUXI requests. Pending jobs are re-queued after the daemon is started |
65 |
again. When a second signal is received, the master daemon terminates |
66 |
without waiting (it might still need to wait for some threads to |
67 |
finish). Note that the latter, as well as sending ``SIGKILL``, may leave |
68 |
the cluster in an inconsistent state. |
69 |
|
70 |
JOB QUEUE |
71 |
~~~~~~~~~ |
72 |
|
73 |
The master daemon maintains a job queue (located under the directory |
74 |
``@LOCALSTATEDIR@/lib/ganeti/queue``) in which all current jobs are |
75 |
stored, one job per file serialized in JSON format; in this directory |
76 |
a subdirectory called ``archive`` holds archived job files. |
77 |
|
78 |
The moving of jobs from the current to the queue directory is done |
79 |
via a request to the master; this can be accomplished from the |
80 |
command line with the **gnt-job archive** or |
81 |
**gnt-job autoarchive** commands. In case of problems with the |
82 |
master, a job file can simply be moved away or deleted (but this |
83 |
might leave the cluster inconsistent). |
84 |
|
85 |
COMMUNICATION PROTOCOL |
86 |
~~~~~~~~~~~~~~~~~~~~~~ |
87 |
|
88 |
The master accepts commands over a Unix socket, using JSON |
89 |
serialized messages separated by a specific byte sequence. For more |
90 |
details, see the design documentation supplied with Ganeti. |
91 |
|
92 |
.. vim: set textwidth=72 : |
93 |
.. Local Variables: |
94 |
.. mode: rst |
95 |
.. fill-column: 72 |
96 |
.. End: |