root / man / ganeti.rst @ ad0e078e
History | View | Annotate | Download (11.5 kB)
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 |
Node Parameters |
100 |
~~~~~~~~~~~~~~~ |
101 |
|
102 |
These parameters are node specific and can be preseeded on node-group |
103 |
and cluster level. |
104 |
|
105 |
Currently we support the following node parameters: |
106 |
|
107 |
oob_program |
108 |
Path to an executable used as the out-of-band helper as described in |
109 |
the `Ganeti Node OOB Management Framework <design-oob.rst>`_ design |
110 |
document. |
111 |
|
112 |
|
113 |
Hypervisor State Parameters |
114 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
115 |
|
116 |
Using ``--hypervisor-state`` you can set hypervisor specific states as |
117 |
pointed out in ``Ganeti Resource Model <design-resource-model.rst>``. |
118 |
|
119 |
The format is: ``hypervisor:option=value``. |
120 |
|
121 |
Currently we support the following hypervisor state values: |
122 |
|
123 |
mem_total |
124 |
Total node memory, as discovered by this hypervisor |
125 |
mem_node |
126 |
Memory used by, or reserved for, the node itself; note that some |
127 |
hypervisors can report this in an authoritative way, other not |
128 |
mem_hv |
129 |
Memory used either by the hypervisor itself or lost due to instance |
130 |
allocation rounding; usually this cannot be precisely computed, but |
131 |
only roughly estimated |
132 |
cpu_total |
133 |
Total node cpu (core) count; usually this can be discovered |
134 |
automatically |
135 |
cpu_node |
136 |
Number of cores reserved for the node itself; this can either be |
137 |
discovered or set manually. Only used for estimating how many VCPUs |
138 |
are left for instances |
139 |
|
140 |
|
141 |
Disk State Parameters |
142 |
~~~~~~~~~~~~~~~~~~~~~ |
143 |
|
144 |
Using ``--disk-state`` you can set disk specific states as pointed out |
145 |
in ``Ganeti Resource Model <design-resource-model.rst>``. |
146 |
|
147 |
The format is: ``storage_type/identifier:option=value``. Where we |
148 |
currently just support ``lvm`` as storage type. The identifier in this |
149 |
case is the LVM volume group. By default this is ``xenvg``. |
150 |
|
151 |
Currently we support the following hypervisor state values: |
152 |
|
153 |
disk_total |
154 |
Total disk size (usually discovered automatically) |
155 |
disk_reserved |
156 |
Reserved disk size; this is a lower limit on the free space, if such a |
157 |
limit is desired |
158 |
disk_overhead |
159 |
Disk that is expected to be used by other volumes (set via |
160 |
``reserved_lvs``); usually should be zero |
161 |
|
162 |
|
163 |
Cluster configuration |
164 |
~~~~~~~~~~~~~~~~~~~~~ |
165 |
|
166 |
The master node keeps and is responsible for the cluster |
167 |
configuration. On the filesystem, this is stored under the |
168 |
``@LOCALSTATEDIR@/ganeti/lib`` directory, and if the master daemon is |
169 |
stopped it can be backed up normally. |
170 |
|
171 |
The master daemon will replicate the configuration database called |
172 |
``config.data`` and the job files to all the nodes in the master |
173 |
candidate role. It will also distribute a copy of some configuration |
174 |
values via the *ssconf* files, which are stored in the same directory |
175 |
and start with a ``ssconf_`` prefix, to all nodes. |
176 |
|
177 |
Jobs |
178 |
~~~~ |
179 |
|
180 |
All cluster modification are done via jobs. A job consists of one |
181 |
or more opcodes, and the list of opcodes is processed serially. If |
182 |
an opcode fails, the entire job is failed and later opcodes are no |
183 |
longer processed. A job can be in one of the following states: |
184 |
|
185 |
queued |
186 |
The job has been submitted but not yet processed by the master |
187 |
daemon. |
188 |
|
189 |
waiting |
190 |
The job is waiting for for locks before the first of its opcodes. |
191 |
|
192 |
canceling |
193 |
The job is waiting for locks, but is has been marked for |
194 |
cancellation. It will not transition to *running*, but to |
195 |
*canceled*. |
196 |
|
197 |
running |
198 |
The job is currently being executed. |
199 |
|
200 |
canceled |
201 |
The job has been canceled before starting execution. |
202 |
|
203 |
success |
204 |
The job has finished successfully. |
205 |
|
206 |
error |
207 |
The job has failed during runtime, or the master daemon has been |
208 |
stopped during the job execution. |
209 |
|
210 |
|
211 |
Common command line features |
212 |
---------------------------- |
213 |
|
214 |
Options |
215 |
~~~~~~~ |
216 |
|
217 |
Many Ganeti commands provide the following options. The |
218 |
availability for a certain command can be checked by calling the |
219 |
command using the ``--help`` option. |
220 |
|
221 |
**gnt-...** *command* [--dry-run] [--priority {low | normal | high}] |
222 |
|
223 |
The ``--dry-run`` option can be used to check whether an operation |
224 |
would succeed. |
225 |
|
226 |
The option ``--priority`` sets the priority for opcodes submitted |
227 |
by the command. |
228 |
|
229 |
Defaults |
230 |
~~~~~~~~ |
231 |
|
232 |
For certain commands you can use environment variables to provide |
233 |
default command line arguments. Just assign the arguments as a string to |
234 |
the corresponding environment variable. The format of that variable |
235 |
name is **binary**_*command*. **binary** is the name of the ``gnt-*`` |
236 |
script all upper case and dashes replaced by underscores, and *command* |
237 |
is the command invoked on that script. |
238 |
|
239 |
Currently supported commands are ``gnt-node list``, ``gnt-group list`` |
240 |
and ``gnt-instance list``. So you can configure default command line |
241 |
flags by setting ``GNT_NODE_LIST``, ``GNT_GROUP_LIST`` and |
242 |
``GNT_INSTANCE_LIST``. |
243 |
|
244 |
Field formatting |
245 |
---------------- |
246 |
|
247 |
Multiple ganeti commands use the same framework for tabular listing of |
248 |
resources (e.g. **gnt-instance list**, **gnt-node list**, **gnt-group |
249 |
list**, **gnt-debug locks**, etc.). For these commands, special states |
250 |
are denoted via a special symbol (in terse mode) or a string (in |
251 |
verbose mode): |
252 |
|
253 |
\*, (offline) |
254 |
The node in question is marked offline, and thus it cannot be |
255 |
queried for data. This result is persistent until the node is |
256 |
de-offlined. |
257 |
|
258 |
?, (nodata) |
259 |
Ganeti expected to receive an answer from this entity, but the |
260 |
cluster RPC call failed and/or we didn't receive a valid answer; |
261 |
usually more information is available in the node daemon log (if |
262 |
the node is alive) or the master daemon log. This result is |
263 |
transient, and re-running command might return a different result. |
264 |
|
265 |
-, (unavail) |
266 |
The respective field doesn't make sense for this entity; |
267 |
e.g. querying a down instance for its current memory 'live' usage, |
268 |
or querying a non-vm_capable node for disk/memory data. This |
269 |
result is persistent, and until the entity state is changed via |
270 |
ganeti commands, the result won't change. |
271 |
|
272 |
??, (unknown) |
273 |
This field is not known (note that this is different from entity |
274 |
being unknown). Either you have mis-typed the field name, or you |
275 |
are using a field that the running Ganeti master daemon doesn't |
276 |
know. This result is persistent, re-running the command won't |
277 |
change it. |
278 |
|
279 |
Key-value parameters |
280 |
~~~~~~~~~~~~~~~~~~~~ |
281 |
|
282 |
Multiple options take parameters that are of the form |
283 |
``key=value,key=value,...`` or ``category:key=value,...``. Examples |
284 |
are the hypervisor parameters, backend parameters, etc. For these, |
285 |
it's possible to use values that contain commas by escaping with via a |
286 |
backslash (which needs two if not single-quoted, due to shell |
287 |
behaviour):: |
288 |
|
289 |
# gnt-instance modify -H kernel_path=an\\,example instance1 |
290 |
# gnt-instance modify -H kernel_path='an\,example' instance1 |
291 |
|
292 |
Query filters |
293 |
~~~~~~~~~~~~~ |
294 |
|
295 |
Most commands listing resources (e.g. instances or nodes) support filtering. |
296 |
The filter language is similar to Python expressions with some elements from |
297 |
Perl. The language is not generic. Each condition must consist of a field name |
298 |
and a value (except for boolean checks), a field can not be compared to another |
299 |
field. Keywords are case-sensitive. |
300 |
|
301 |
Syntax in pseudo-BNF:: |
302 |
|
303 |
<quoted-string> ::= /* String quoted with single or double quotes, |
304 |
backslash for escaping */ |
305 |
|
306 |
<integer> ::= /* Number in base-10 positional notation */ |
307 |
|
308 |
<re> ::= /* Regular expression */ |
309 |
|
310 |
/* |
311 |
Modifier "i": Case-insensitive matching, see |
312 |
http://docs.python.org/library/re#re.IGNORECASE |
313 |
|
314 |
Modifier "s": Make the "." special character match any character, |
315 |
including newline, see http://docs.python.org/library/re#re.DOTALL |
316 |
*/ |
317 |
<re-modifiers> ::= /* empty */ | i | s |
318 |
|
319 |
<value> ::= <quoted-string> | <integer> |
320 |
|
321 |
<condition> ::= |
322 |
{ /* Value comparison */ |
323 |
<field> { == | != } <value> |
324 |
|
325 |
/* Collection membership */ |
326 |
| <value> [ not ] in <field> |
327 |
|
328 |
/* Regular expressions (recognized delimiters |
329 |
are "/", "#", "^", and "|"; backslash for escaping) |
330 |
*/ |
331 |
| <field> { =~ | !~ } m/<re>/<re-modifiers> |
332 |
|
333 |
/* Globbing */ |
334 |
| <field> { =* | !* } <quoted-string> |
335 |
|
336 |
/* Boolean */ |
337 |
| <field> |
338 |
} |
339 |
|
340 |
<filter> ::= |
341 |
{ [ not ] <condition> | ( <filter> ) } |
342 |
[ { and | or } <filter> ] |
343 |
|
344 |
Operators: |
345 |
|
346 |
*==* |
347 |
Equality |
348 |
*!=* |
349 |
Inequality |
350 |
*=~* |
351 |
Pattern match using regular expression |
352 |
*!~* |
353 |
Logically negated from *=~* |
354 |
*=\** |
355 |
Globbing, see **glob**(7), though only * and ? are supported |
356 |
*!\** |
357 |
Logically negated from *=\** |
358 |
*in*, *not in* |
359 |
Collection membership and negation |
360 |
|
361 |
As a shortcut globbing patterns can be specified as names, e.g. |
362 |
``gnt-instance list '*.site1' '*.site2'``. |
363 |
|
364 |
|
365 |
Common daemon functionality |
366 |
--------------------------- |
367 |
|
368 |
All Ganeti daemons re-open the log file(s) when sent a SIGHUP signal. |
369 |
**logrotate**(8) can be used to rotate Ganeti's log files. |
370 |
|
371 |
.. vim: set textwidth=72 : |
372 |
.. Local Variables: |
373 |
.. mode: rst |
374 |
.. fill-column: 72 |
375 |
.. End: |