root / man / hail.rst @ f30d0610
History | View | Annotate | Download (5.3 kB)
1 |
HAIL(1) Ganeti | Version @GANETI_VERSION@ |
---|---|
2 |
========================================= |
3 |
|
4 |
NAME |
5 |
---- |
6 |
|
7 |
hail - Ganeti IAllocator plugin |
8 |
|
9 |
SYNOPSIS |
10 |
-------- |
11 |
|
12 |
**hail** [ **-t** *file* | **\--simulate** *spec* ] [options...] *input-file* |
13 |
|
14 |
**hail** \--version |
15 |
|
16 |
DESCRIPTION |
17 |
----------- |
18 |
|
19 |
hail is a Ganeti IAllocator plugin that implements the instance |
20 |
placement and movement using the same algorithm as **hbal**\(1). |
21 |
|
22 |
The program takes input via a JSON-file containing current cluster |
23 |
state and the request details, and output (on stdout) a JSON-formatted |
24 |
response. In case of critical failures, the error message is printed |
25 |
on stderr and the exit code is changed to show failure. |
26 |
|
27 |
If the input file name is ``-`` (a single minus sign), then the request |
28 |
data will be read from *stdin*. |
29 |
|
30 |
Apart from input data, hail collects data over the network from all |
31 |
MonDs with the --mond option. Currently it uses only data produced by |
32 |
the CPUload collector. |
33 |
|
34 |
ALGORITHM |
35 |
~~~~~~~~~ |
36 |
|
37 |
The program uses a simplified version of the hbal algorithm. |
38 |
|
39 |
For single-node allocations (non-mirrored instances), again we |
40 |
select the node which, when chosen as the primary node, gives the best |
41 |
score. |
42 |
|
43 |
For dual-node allocations (mirrored instances), we chose the best |
44 |
pair; this is the only choice where the algorithm is non-trivial |
45 |
with regard to cluster size. |
46 |
|
47 |
For relocations, we try to change the secondary node of the instance to |
48 |
all the valid other nodes; the node which results in the best cluster |
49 |
score is chosen. |
50 |
|
51 |
For node changes (*change-node* mode), we currently support DRBD |
52 |
instances only, and all three modes (primary changes, secondary changes |
53 |
and all node changes). |
54 |
|
55 |
For group moves (*change-group* mode), again only DRBD is supported, and |
56 |
we compute the correct sequence that will result in a group change; job |
57 |
failure mid-way will result in a split instance. The choice of node(s) |
58 |
on the target group is based on the group score, and the choice of group |
59 |
is based on the same algorithm as allocations (group with lowest score |
60 |
after placement). |
61 |
|
62 |
The deprecated *multi-evacuate* modes is no longer supported. |
63 |
|
64 |
In all cases, the cluster (or group) scoring is identical to the hbal |
65 |
algorithm. |
66 |
|
67 |
OPTIONS |
68 |
------- |
69 |
|
70 |
The options that can be passed to the program are as follows: |
71 |
|
72 |
-p, \--print-nodes |
73 |
Prints the before and after node status, in a format designed to allow |
74 |
the user to understand the node's most important parameters. See the |
75 |
man page **htools**\(1) for more details about this option. |
76 |
|
77 |
-t *datafile*, \--text-data=*datafile* |
78 |
The name of the file holding cluster information, to override the data |
79 |
in the JSON request itself. This is mostly used for debugging. The |
80 |
format of the file is described in the man page **htools**\(1). |
81 |
|
82 |
\--mond |
83 |
If given the program will query all MonDs to fetch data from the |
84 |
supported data collectors over the network. |
85 |
|
86 |
\--mond-data *datafile* |
87 |
The name of the file holding the data provided by MonD, to override |
88 |
quering MonDs over the network. This is mostly used for debugging. The |
89 |
file must be in JSON format and present an array of JSON objects , |
90 |
one for every node, with two members. The first member named ``node`` |
91 |
is the name of the node and the second member named ``reports`` is an |
92 |
array of report objects. The report objects must be in the same format |
93 |
as produced by the monitoring agent. |
94 |
|
95 |
\--ignore-dynu |
96 |
If given, all dynamic utilisation information will be ignored by |
97 |
assuming it to be 0. This option will take precedence over any data |
98 |
passed by the MonDs with the ``--mond`` and the ``--mond-data`` |
99 |
option. |
100 |
|
101 |
\--simulate *description* |
102 |
Backend specification: similar to the **-t** option, this allows |
103 |
overriding the cluster data with a simulated cluster. For details |
104 |
about the description, see the man page **htools**\(1). |
105 |
|
106 |
-S *filename*, \--save-cluster=*filename* |
107 |
If given, the state of the cluster before and the iallocator run is |
108 |
saved to a file named *filename.pre-ialloc*, respectively |
109 |
*filename.post-ialloc*. This allows re-feeding the cluster state to |
110 |
any of the htools utilities via the ``-t`` option. |
111 |
|
112 |
-v |
113 |
This option increases verbosity and can be used for debugging in order |
114 |
to understand how the IAllocator request is parsed; it can be passed |
115 |
multiple times for successively more information. |
116 |
|
117 |
|
118 |
CONFIGURATION |
119 |
------------- |
120 |
|
121 |
For the tag-exclusion configuration (see the manpage of hbal for more |
122 |
details), the list of which instance tags to consider as exclusion |
123 |
tags will be read from the cluster tags, configured as follows: |
124 |
|
125 |
- get all cluster tags starting with **htools:iextags:** |
126 |
- use their suffix as the prefix for exclusion tags |
127 |
|
128 |
For example, given a cluster tag like **htools:iextags:service**, |
129 |
all instance tags of the form **service:X** will be considered as |
130 |
exclusion tags, meaning that (e.g.) two instances which both have a |
131 |
tag **service:foo** will not be placed on the same primary node. |
132 |
|
133 |
OPTIONS |
134 |
------- |
135 |
|
136 |
The options that can be passed to the program are as follows: |
137 |
|
138 |
EXIT STATUS |
139 |
----------- |
140 |
|
141 |
The exist status of the command will be zero, unless for some reason |
142 |
the algorithm fatally failed (e.g. wrong node or instance data). |
143 |
|
144 |
BUGS |
145 |
---- |
146 |
|
147 |
Networks (as configured by **gnt-network**\(8)) are not taken into |
148 |
account in Ganeti 2.7. The only way to guarantee that they work |
149 |
correctly is having your networks connected to all nodegroups. This will |
150 |
be fixed in a future version. |
151 |
|
152 |
.. vim: set textwidth=72 : |
153 |
.. Local Variables: |
154 |
.. mode: rst |
155 |
.. fill-column: 72 |
156 |
.. End: |