Revision cc424a1d
b/man/ganeti.rst | ||
---|---|---|
1 |
ganeti(7) Ganeti | Version @GANETI_VERSION@ |
|
2 |
=========================================== |
|
3 |
|
|
4 |
Name |
|
5 |
---- |
|
6 |
|
|
7 |
ganeti - cluster-based virtualization management |
|
8 |
|
|
9 |
Synopsis |
|
10 |
-------- |
|
11 |
|
|
12 |
:: |
|
13 |
|
|
14 |
# gnt-cluster init cluster1.example.com |
|
15 |
# gnt-node add node2.example.com |
|
16 |
# gnt-instance add -n node2.example.com \ |
|
17 |
> -o debootstrap --disk 0:size=30g \ |
|
18 |
> -t plain instance1.example.com |
|
19 |
|
|
20 |
|
|
21 |
DESCRIPTION |
|
22 |
----------- |
|
23 |
|
|
24 |
The Ganeti software manages physical nodes and virtual instances of a |
|
25 |
cluster based on a virtualization software. The current version (2.3) |
|
26 |
supports Xen 3.x and KVM (72 or above) as hypervisors, and LXC as an |
|
27 |
experimental hypervisor. |
|
28 |
|
|
29 |
Quick start |
|
30 |
----------- |
|
31 |
|
|
32 |
First you must install the software on all the cluster nodes, either |
|
33 |
from sources or (if available) from a package. The next step is to |
|
34 |
create the initial cluster configuration, using **gnt-cluster init**. |
|
35 |
|
|
36 |
Then you can add other nodes, or start creating instances. |
|
37 |
|
|
38 |
Cluster architecture |
|
39 |
-------------------- |
|
40 |
|
|
41 |
In Ganeti 2.0, the architecture of the cluster is a little more |
|
42 |
complicated than in 1.2. The cluster is coordinated by a master daemon |
|
43 |
(**ganeti-masterd**(8)), running on the master node. Each node runs |
|
44 |
(as before) a node daemon, and the master has the RAPI daemon running |
|
45 |
too. |
|
46 |
|
|
47 |
Node roles |
|
48 |
~~~~~~~~~~ |
|
49 |
|
|
50 |
Each node can be in one of the following states: |
|
51 |
|
|
52 |
master |
|
53 |
Only one node per cluster can be in this role, and this node is the |
|
54 |
one holding the authoritative copy of the cluster configuration and |
|
55 |
the one that can actually execute commands on the cluster and |
|
56 |
modify the cluster state. See more details under |
|
57 |
*Cluster configuration*. |
|
58 |
|
|
59 |
master_candidate |
|
60 |
The node receives the full cluster configuration (configuration |
|
61 |
file and jobs) and can become a master via the |
|
62 |
**gnt-cluster master-failover** command. Nodes that are not in this |
|
63 |
state cannot transition into the master role due to missing state. |
|
64 |
|
|
65 |
regular |
|
66 |
This the normal state of a node. |
|
67 |
|
|
68 |
drained |
|
69 |
Nodes in this state are functioning normally but cannot receive |
|
70 |
new instances, because the intention is to set them to *offline* |
|
71 |
or remove them from the cluster. |
|
72 |
|
|
73 |
offline |
|
74 |
These nodes are still recorded in the Ganeti configuration, but |
|
75 |
except for the master daemon startup voting procedure, they are not |
|
76 |
actually contacted by the master. This state was added in order to |
|
77 |
allow broken machines (that are being repaired) to remain in the |
|
78 |
cluster but without creating problems. |
|
79 |
|
|
80 |
|
|
81 |
Node flags |
|
82 |
~~~~~~~~~~ |
|
83 |
|
|
84 |
Nodes have two flags which govern which roles they can take: |
|
85 |
|
|
86 |
master_capable |
|
87 |
The node can become a master candidate, and furthermore the master |
|
88 |
node. When this flag is disabled, the node cannot become a |
|
89 |
candidate; this can be useful for special networking cases, or less |
|
90 |
reliable hardware. |
|
91 |
|
|
92 |
vm_capable |
|
93 |
The node can host instances. When enabled (the default state), the |
|
94 |
node will participate in instance allocation, capacity calculation, |
|
95 |
etc. When disabled, the node will be skipped in many cluster checks |
|
96 |
and operations. |
|
97 |
|
|
98 |
|
|
99 |
Cluster configuration |
|
100 |
~~~~~~~~~~~~~~~~~~~~~ |
|
101 |
|
|
102 |
The master node keeps and is responsible for the cluster |
|
103 |
configuration. On the filesystem, this is stored under the |
|
104 |
``@LOCALSTATEDIR@/ganeti/lib`` directory, and if the master daemon is |
|
105 |
stopped it can be backed up normally. |
|
106 |
|
|
107 |
The master daemon will replicate the configuration database called |
|
108 |
``config.data`` and the job files to all the nodes in the master |
|
109 |
candidate role. It will also distribute a copy of some configuration |
|
110 |
values via the *ssconf* files, which are stored in the same directory |
|
111 |
and start with a ``ssconf_`` prefix, to all nodes. |
|
112 |
|
|
113 |
Jobs |
|
114 |
~~~~ |
|
115 |
|
|
116 |
All cluster modification are done via jobs. A job consists of one |
|
117 |
or more opcodes, and the list of opcodes is processed serially. If |
|
118 |
an opcode fails, the entire job is failed and later opcodes are no |
|
119 |
longer processed. A job can be in one of the following states: |
|
120 |
|
|
121 |
queued |
|
122 |
The job has been submitted but not yet processed by the master |
|
123 |
daemon. |
|
124 |
|
|
125 |
waiting |
|
126 |
The job is waiting for for locks before the first of its opcodes. |
|
127 |
|
|
128 |
canceling |
|
129 |
The job is waiting for locks, but is has been marked for |
|
130 |
cancellation. It will not transition to *running*, but to |
|
131 |
*canceled*. |
|
132 |
|
|
133 |
running |
|
134 |
The job is currently being executed. |
|
135 |
|
|
136 |
canceled |
|
137 |
The job has been canceled before starting execution. |
|
138 |
|
|
139 |
success |
|
140 |
The job has finished successfully. |
|
141 |
|
|
142 |
error |
|
143 |
The job has failed during runtime, or the master daemon has been |
|
144 |
stopped during the job execution. |
|
145 |
|
|
146 |
|
|
147 |
Common options |
|
148 |
-------------- |
|
149 |
|
|
150 |
Many Ganeti commands provide the following options. The |
|
151 |
availability for a certain command can be checked by calling the |
|
152 |
command using the ``--help`` option. |
|
153 |
|
|
154 |
**gnt-...** *command* [--dry-run] [--priority {low | normal | high}] |
|
155 |
|
|
156 |
The ``--dry-run`` option can be used to check whether an operation |
|
157 |
would succeed. |
|
158 |
|
|
159 |
The option ``--priority`` sets the priority for opcodes submitted |
|
160 |
by the command. |
Also available in: Unified diff