root / man / hbal.rst @ e715a6d6
History | View | Annotate | Download (28 kB)
1 |
HBAL(1) Ganeti | Version @GANETI_VERSION@ |
---|---|
2 |
========================================= |
3 |
|
4 |
NAME |
5 |
---- |
6 |
|
7 |
hbal \- Cluster balancer for Ganeti |
8 |
|
9 |
SYNOPSIS |
10 |
-------- |
11 |
|
12 |
**hbal** {backend options...} [algorithm options...] [reporting options...] |
13 |
|
14 |
**hbal** \--version |
15 |
|
16 |
|
17 |
Backend options: |
18 |
|
19 |
{ **-m** *cluster* | **-L[** *path* **] [-X]** | **-t** *data-file* | |
20 |
**-I** *path* } |
21 |
|
22 |
Algorithm options: |
23 |
|
24 |
**[ \--max-cpu *cpu-ratio* ]** |
25 |
**[ \--min-disk *disk-ratio* ]** |
26 |
**[ -l *limit* ]** |
27 |
**[ -e *score* ]** |
28 |
**[ -g *delta* ]** **[ \--min-gain-limit *threshold* ]** |
29 |
**[ -O *name...* ]** |
30 |
**[ \--no-disk-moves ]** |
31 |
**[ \--no-instance-moves ]** |
32 |
**[ -U *util-file* ]** |
33 |
**[ \--ignore-dynu ]** |
34 |
**[ \--mond *yes|no* ]** |
35 |
**[ \--evac-mode ]** |
36 |
**[ \--select-instances *inst...* ]** |
37 |
**[ \--exclude-instances *inst...* ]** |
38 |
|
39 |
Reporting options: |
40 |
|
41 |
**[ -C[ *file* ] ]** |
42 |
**[ -p[ *fields* ] ]** |
43 |
**[ \--print-instances ]** |
44 |
**[ -S *file* ]** |
45 |
**[ -v... | -q ]** |
46 |
|
47 |
|
48 |
DESCRIPTION |
49 |
----------- |
50 |
|
51 |
hbal is a cluster balancer that looks at the current state of the |
52 |
cluster (nodes with their total and free disk, memory, etc.) and |
53 |
instance placement and computes a series of steps designed to bring |
54 |
the cluster into a better state. |
55 |
|
56 |
The algorithm used is designed to be stable (i.e. it will give you the |
57 |
same results when restarting it from the middle of the solution) and |
58 |
reasonably fast. It is not, however, designed to be a perfect algorithm: |
59 |
it is possible to make it go into a corner from which it can find no |
60 |
improvement, because it looks only one "step" ahead. |
61 |
|
62 |
The program accesses the cluster state via Rapi or Luxi. It also |
63 |
requests data over the network from all MonDs with the --mond option. |
64 |
Currently it uses only data produced by CPUload collector. |
65 |
|
66 |
By default, the program will show the solution incrementally as it is |
67 |
computed, in a somewhat cryptic format; for getting the actual Ganeti |
68 |
command list, use the **-C** option. |
69 |
|
70 |
ALGORITHM |
71 |
~~~~~~~~~ |
72 |
|
73 |
The program works in independent steps; at each step, we compute the |
74 |
best instance move that lowers the cluster score. |
75 |
|
76 |
The possible move type for an instance are combinations of |
77 |
failover/migrate and replace-disks such that we change one of the |
78 |
instance nodes, and the other one remains (but possibly with changed |
79 |
role, e.g. from primary it becomes secondary). The list is: |
80 |
|
81 |
- failover (f) |
82 |
- replace secondary (r) |
83 |
- replace primary, a composite move (f, r, f) |
84 |
- failover and replace secondary, also composite (f, r) |
85 |
- replace secondary and failover, also composite (r, f) |
86 |
|
87 |
We don't do the only remaining possibility of replacing both nodes |
88 |
(r,f,r,f or the equivalent f,r,f,r) since these move needs an |
89 |
exhaustive search over both candidate primary and secondary nodes, and |
90 |
is O(n*n) in the number of nodes. Furthermore, it doesn't seems to |
91 |
give better scores but will result in more disk replacements. |
92 |
|
93 |
PLACEMENT RESTRICTIONS |
94 |
~~~~~~~~~~~~~~~~~~~~~~ |
95 |
|
96 |
At each step, we prevent an instance move if it would cause: |
97 |
|
98 |
- a node to go into N+1 failure state |
99 |
- an instance to move onto an offline node (offline nodes are either |
100 |
read from the cluster or declared with *-O*; drained nodes are |
101 |
considered offline) |
102 |
- an exclusion-tag based conflict (exclusion tags are read from the |
103 |
cluster and/or defined via the *\--exclusion-tags* option) |
104 |
- a max vcpu/pcpu ratio to be exceeded (configured via *\--max-cpu*) |
105 |
- min disk free percentage to go below the configured limit |
106 |
(configured via *\--min-disk*) |
107 |
|
108 |
CLUSTER SCORING |
109 |
~~~~~~~~~~~~~~~ |
110 |
|
111 |
As said before, the algorithm tries to minimise the cluster score at |
112 |
each step. Currently this score is computed as a weighted sum of the |
113 |
following components: |
114 |
|
115 |
- standard deviation of the percent of free memory |
116 |
- standard deviation of the percent of reserved memory |
117 |
- standard deviation of the percent of free disk |
118 |
- count of nodes failing N+1 check |
119 |
- count of instances living (either as primary or secondary) on |
120 |
offline nodes; in the sense of hbal (and the other htools) drained |
121 |
nodes are considered offline |
122 |
- count of instances living (as primary) on offline nodes; this |
123 |
differs from the above metric by helping failover of such instances |
124 |
in 2-node clusters |
125 |
- standard deviation of the ratio of virtual-to-physical cpus (for |
126 |
primary instances of the node) |
127 |
- standard deviation of the dynamic load on the nodes, for cpus, |
128 |
memory, disk and network |
129 |
- standard deviation of the CPU load provided by MonD |
130 |
|
131 |
The free memory and free disk values help ensure that all nodes are |
132 |
somewhat balanced in their resource usage. The reserved memory helps |
133 |
to ensure that nodes are somewhat balanced in holding secondary |
134 |
instances, and that no node keeps too much memory reserved for |
135 |
N+1. And finally, the N+1 percentage helps guide the algorithm towards |
136 |
eliminating N+1 failures, if possible. |
137 |
|
138 |
Except for the N+1 failures and offline instances counts, we use the |
139 |
standard deviation since when used with values within a fixed range |
140 |
(we use percents expressed as values between zero and one) it gives |
141 |
consistent results across all metrics (there are some small issues |
142 |
related to different means, but it works generally well). The 'count' |
143 |
type values will have higher score and thus will matter more for |
144 |
balancing; thus these are better for hard constraints (like evacuating |
145 |
nodes and fixing N+1 failures). For example, the offline instances |
146 |
count (i.e. the number of instances living on offline nodes) will |
147 |
cause the algorithm to actively move instances away from offline |
148 |
nodes. This, coupled with the restriction on placement given by |
149 |
offline nodes, will cause evacuation of such nodes. |
150 |
|
151 |
The dynamic load values need to be read from an external file (Ganeti |
152 |
doesn't supply them), and are computed for each node as: sum of |
153 |
primary instance cpu load, sum of primary instance memory load, sum of |
154 |
primary and secondary instance disk load (as DRBD generates write load |
155 |
on secondary nodes too in normal case and in degraded scenarios also |
156 |
read load), and sum of primary instance network load. An example of |
157 |
how to generate these values for input to hbal would be to track ``xm |
158 |
list`` for instances over a day and by computing the delta of the cpu |
159 |
values, and feed that via the *-U* option for all instances (and keep |
160 |
the other metrics as one). For the algorithm to work, all that is |
161 |
needed is that the values are consistent for a metric across all |
162 |
instances (e.g. all instances use cpu% to report cpu usage, and not |
163 |
something related to number of CPU seconds used if the CPUs are |
164 |
different), and that they are normalised to between zero and one. Note |
165 |
that it's recommended to not have zero as the load value for any |
166 |
instance metric since then secondary instances are not well balanced. |
167 |
|
168 |
The CPUload from MonD's data collector will be used only if all MonDs |
169 |
are running, otherwise it won't affect the cluster score. Since we can't |
170 |
find the CPU load of each instance, we can assume that the CPU load of |
171 |
an instance is proportional to the number of its vcpus. With this |
172 |
heuristic, instances from nodes with high CPU load will tend to move to |
173 |
nodes with less CPU load. |
174 |
|
175 |
On a perfectly balanced cluster (all nodes the same size, all |
176 |
instances the same size and spread across the nodes equally), the |
177 |
values for all metrics would be zero. This doesn't happen too often in |
178 |
practice :) |
179 |
|
180 |
OFFLINE INSTANCES |
181 |
~~~~~~~~~~~~~~~~~ |
182 |
|
183 |
Since current Ganeti versions do not report the memory used by offline |
184 |
(down) instances, ignoring the run status of instances will cause |
185 |
wrong calculations. For this reason, the algorithm subtracts the |
186 |
memory size of down instances from the free node memory of their |
187 |
primary node, in effect simulating the startup of such instances. |
188 |
|
189 |
EXCLUSION TAGS |
190 |
~~~~~~~~~~~~~~ |
191 |
|
192 |
The exclusion tags mechanism is designed to prevent instances which |
193 |
run the same workload (e.g. two DNS servers) to land on the same node, |
194 |
which would make the respective node a SPOF for the given service. |
195 |
|
196 |
It works by tagging instances with certain tags and then building |
197 |
exclusion maps based on these. Which tags are actually used is |
198 |
configured either via the command line (option *\--exclusion-tags*) |
199 |
or via adding them to the cluster tags: |
200 |
|
201 |
\--exclusion-tags=a,b |
202 |
This will make all instance tags of the form *a:\**, *b:\** be |
203 |
considered for the exclusion map |
204 |
|
205 |
cluster tags *htools:iextags:a*, *htools:iextags:b* |
206 |
This will make instance tags *a:\**, *b:\** be considered for the |
207 |
exclusion map. More precisely, the suffix of cluster tags starting |
208 |
with *htools:iextags:* will become the prefix of the exclusion tags. |
209 |
|
210 |
Both the above forms mean that two instances both having (e.g.) the |
211 |
tag *a:foo* or *b:bar* won't end on the same node. |
212 |
|
213 |
OPTIONS |
214 |
------- |
215 |
|
216 |
The options that can be passed to the program are as follows: |
217 |
|
218 |
-C, \--print-commands |
219 |
Print the command list at the end of the run. Without this, the |
220 |
program will only show a shorter, but cryptic output. |
221 |
|
222 |
Note that the moves list will be split into independent steps, |
223 |
called "jobsets", but only for visual inspection, not for actually |
224 |
parallelisation. It is not possible to parallelise these directly |
225 |
when executed via "gnt-instance" commands, since a compound command |
226 |
(e.g. failover and replace-disks) must be executed |
227 |
serially. Parallel execution is only possible when using the Luxi |
228 |
backend and the *-L* option. |
229 |
|
230 |
The algorithm for splitting the moves into jobsets is by |
231 |
accumulating moves until the next move is touching nodes already |
232 |
touched by the current moves; this means we can't execute in |
233 |
parallel (due to resource allocation in Ganeti) and thus we start a |
234 |
new jobset. |
235 |
|
236 |
-p, \--print-nodes |
237 |
Prints the before and after node status, in a format designed to allow |
238 |
the user to understand the node's most important parameters. See the |
239 |
man page **htools**\(1) for more details about this option. |
240 |
|
241 |
\--print-instances |
242 |
Prints the before and after instance map. This is less useful as the |
243 |
node status, but it can help in understanding instance moves. |
244 |
|
245 |
-O *name* |
246 |
This option (which can be given multiple times) will mark nodes as |
247 |
being *offline*. This means a couple of things: |
248 |
|
249 |
- instances won't be placed on these nodes, not even temporarily; |
250 |
e.g. the *replace primary* move is not available if the secondary |
251 |
node is offline, since this move requires a failover. |
252 |
- these nodes will not be included in the score calculation (except |
253 |
for the percentage of instances on offline nodes) |
254 |
|
255 |
Note that algorithm will also mark as offline any nodes which are |
256 |
reported by RAPI as such, or that have "?" in file-based input in |
257 |
any numeric fields. |
258 |
|
259 |
-e *score*, \--min-score=*score* |
260 |
This parameter denotes the minimum score we are happy with and alters |
261 |
the computation in two ways: |
262 |
|
263 |
- if the cluster has the initial score lower than this value, then we |
264 |
don't enter the algorithm at all, and exit with success |
265 |
- during the iterative process, if we reach a score lower than this |
266 |
value, we exit the algorithm |
267 |
|
268 |
The default value of the parameter is currently ``1e-9`` (chosen |
269 |
empirically). |
270 |
|
271 |
-g *delta*, \--min-gain=*delta* |
272 |
Since the balancing algorithm can sometimes result in just very tiny |
273 |
improvements, that bring less gain that they cost in relocation |
274 |
time, this parameter (defaulting to 0.01) represents the minimum |
275 |
gain we require during a step, to continue balancing. |
276 |
|
277 |
\--min-gain-limit=*threshold* |
278 |
The above min-gain option will only take effect if the cluster score |
279 |
is already below *threshold* (defaults to 0.1). The rationale behind |
280 |
this setting is that at high cluster scores (badly balanced |
281 |
clusters), we don't want to abort the rebalance too quickly, as |
282 |
later gains might still be significant. However, under the |
283 |
threshold, the total gain is only the threshold value, so we can |
284 |
exit early. |
285 |
|
286 |
\--no-disk-moves |
287 |
This parameter prevents hbal from using disk move |
288 |
(i.e. "gnt-instance replace-disks") operations. This will result in |
289 |
a much quicker balancing, but of course the improvements are |
290 |
limited. It is up to the user to decide when to use one or another. |
291 |
|
292 |
\--no-instance-moves |
293 |
This parameter prevents hbal from using instance moves |
294 |
(i.e. "gnt-instance migrate/failover") operations. This will only use |
295 |
the slow disk-replacement operations, and will also provide a worse |
296 |
balance, but can be useful if moving instances around is deemed unsafe |
297 |
or not preferred. |
298 |
|
299 |
\--evac-mode |
300 |
This parameter restricts the list of instances considered for moving |
301 |
to the ones living on offline/drained nodes. It can be used as a |
302 |
(bulk) replacement for Ganeti's own *gnt-node evacuate*, with the |
303 |
note that it doesn't guarantee full evacuation. |
304 |
|
305 |
\--select-instances=*instances* |
306 |
This parameter marks the given instances (as a comma-separated list) |
307 |
as the only ones being moved during the rebalance. |
308 |
|
309 |
\--exclude-instances=*instances* |
310 |
This parameter marks the given instances (as a comma-separated list) |
311 |
from being moved during the rebalance. |
312 |
|
313 |
-U *util-file* |
314 |
This parameter specifies a file holding instance dynamic utilisation |
315 |
information that will be used to tweak the balancing algorithm to |
316 |
equalise load on the nodes (as opposed to static resource |
317 |
usage). The file is in the format "instance_name cpu_util mem_util |
318 |
disk_util net_util" where the "_util" parameters are interpreted as |
319 |
numbers and the instance name must match exactly the instance as |
320 |
read from Ganeti. In case of unknown instance names, the program |
321 |
will abort. |
322 |
|
323 |
If not given, the default values are one for all metrics and thus |
324 |
dynamic utilisation has only one effect on the algorithm: the |
325 |
equalisation of the secondary instances across nodes (this is the |
326 |
only metric that is not tracked by another, dedicated value, and |
327 |
thus the disk load of instances will cause secondary instance |
328 |
equalisation). Note that value of one will also influence slightly |
329 |
the primary instance count, but that is already tracked via other |
330 |
metrics and thus the influence of the dynamic utilisation will be |
331 |
practically insignificant. |
332 |
|
333 |
\--ignore-dynu |
334 |
If given, all dynamic utilisation information will be ignored by |
335 |
assuming it to be 0. This option will take precedence over any data |
336 |
passed by the ``-U`` option or by the MonDs with the ``--mond`` and |
337 |
the ``--mond-data`` option. |
338 |
|
339 |
-S *filename*, \--save-cluster=*filename* |
340 |
If given, the state of the cluster before the balancing is saved to |
341 |
the given file plus the extension "original" |
342 |
(i.e. *filename*.original), and the state at the end of the |
343 |
balancing is saved to the given file plus the extension "balanced" |
344 |
(i.e. *filename*.balanced). This allows re-feeding the cluster state |
345 |
to either hbal itself or for example hspace via the ``-t`` option. |
346 |
|
347 |
-t *datafile*, \--text-data=*datafile* |
348 |
Backend specification: the name of the file holding node and instance |
349 |
information (if not collecting via RAPI or LUXI). This or one of the |
350 |
other backends must be selected. The option is described in the man |
351 |
page **htools**\(1). |
352 |
|
353 |
\--mond=*yes|no* |
354 |
If given the program will query all MonDs to fetch data from the |
355 |
supported data collectors over the network. |
356 |
|
357 |
\--mond-data *datafile* |
358 |
The name of the file holding the data provided by MonD, to override |
359 |
quering MonDs over the network. This is mostly used for debugging. The |
360 |
file must be in JSON format and present an array of JSON objects , |
361 |
one for every node, with two members. The first member named ``node`` |
362 |
is the name of the node and the second member named ``reports`` is an |
363 |
array of report objects. The report objects must be in the same format |
364 |
as produced by the monitoring agent. |
365 |
|
366 |
-m *cluster* |
367 |
Backend specification: collect data directly from the *cluster* given |
368 |
as an argument via RAPI. The option is described in the man page |
369 |
**htools**\(1). |
370 |
|
371 |
-L [*path*] |
372 |
Backend specification: collect data directly from the master daemon, |
373 |
which is to be contacted via LUXI (an internal Ganeti protocol). The |
374 |
option is described in the man page **htools**\(1). |
375 |
|
376 |
-X |
377 |
When using the Luxi backend, hbal can also execute the given |
378 |
commands. The execution method is to execute the individual jobsets |
379 |
(see the *-C* option for details) in separate stages, aborting if at |
380 |
any time a jobset doesn't have all jobs successful. Each step in the |
381 |
balancing solution will be translated into exactly one Ganeti job |
382 |
(having between one and three OpCodes), and all the steps in a |
383 |
jobset will be executed in parallel. The jobsets themselves are |
384 |
executed serially. |
385 |
|
386 |
The execution of the job series can be interrupted, see below for |
387 |
signal handling. |
388 |
|
389 |
-l *N*, \--max-length=*N* |
390 |
Restrict the solution to this length. This can be used for example |
391 |
to automate the execution of the balancing. |
392 |
|
393 |
\--max-cpu=*cpu-ratio* |
394 |
The maximum virtual to physical cpu ratio, as a floating point number |
395 |
greater than or equal to one. For example, specifying *cpu-ratio* as |
396 |
**2.5** means that, for a 4-cpu machine, a maximum of 10 virtual cpus |
397 |
should be allowed to be in use for primary instances. A value of |
398 |
exactly one means there will be no over-subscription of CPU (except |
399 |
for the CPU time used by the node itself), and values below one do not |
400 |
make sense, as that means other resources (e.g. disk) won't be fully |
401 |
utilised due to CPU restrictions. |
402 |
|
403 |
\--min-disk=*disk-ratio* |
404 |
The minimum amount of free disk space remaining, as a floating point |
405 |
number. For example, specifying *disk-ratio* as **0.25** means that |
406 |
at least one quarter of disk space should be left free on nodes. |
407 |
|
408 |
-G *uuid*, \--group=*uuid* |
409 |
On an multi-group cluster, select this group for |
410 |
processing. Otherwise hbal will abort, since it cannot balance |
411 |
multiple groups at the same time. |
412 |
|
413 |
-v, \--verbose |
414 |
Increase the output verbosity. Each usage of this option will |
415 |
increase the verbosity (currently more than 2 doesn't make sense) |
416 |
from the default of one. |
417 |
|
418 |
-q, \--quiet |
419 |
Decrease the output verbosity. Each usage of this option will |
420 |
decrease the verbosity (less than zero doesn't make sense) from the |
421 |
default of one. |
422 |
|
423 |
-V, \--version |
424 |
Just show the program version and exit. |
425 |
|
426 |
SIGNAL HANDLING |
427 |
--------------- |
428 |
|
429 |
When executing jobs via LUXI (using the ``-X`` option), normally hbal |
430 |
will execute all jobs until either one errors out or all the jobs finish |
431 |
successfully. |
432 |
|
433 |
Since balancing can take a long time, it is possible to stop hbal early |
434 |
in two ways: |
435 |
|
436 |
- by sending a ``SIGINT`` (``^C``), hbal will register the termination |
437 |
request, and will wait until the currently submitted jobs finish, at |
438 |
which point it will exit (with exit code 0 if all jobs finished |
439 |
correctly, otherwise with exit code 1 as usual) |
440 |
|
441 |
- by sending a ``SIGTERM``, hbal will immediately exit (with exit code |
442 |
2\); it is the responsibility of the user to follow up with Ganeti |
443 |
and check the result of the currently-executing jobs |
444 |
|
445 |
Note that in any situation, it's perfectly safe to kill hbal, either via |
446 |
the above signals or via any other signal (e.g. ``SIGQUIT``, |
447 |
``SIGKILL``), since the jobs themselves are processed by Ganeti whereas |
448 |
hbal (after submission) only watches their progression. In this case, |
449 |
the user will have to query Ganeti for job results. |
450 |
|
451 |
EXIT STATUS |
452 |
----------- |
453 |
|
454 |
The exit status of the command will be zero, unless for some reason the |
455 |
algorithm failed (e.g. wrong node or instance data), invalid command |
456 |
line options, or (in case of job execution) one of the jobs has failed. |
457 |
|
458 |
Once job execution via Luxi has started (``-X``), if the balancing was |
459 |
interrupted early (via *SIGINT*, or via ``--max-length``) but all jobs |
460 |
executed successfully, then the exit status is zero; a non-zero exit |
461 |
code means that the cluster state should be investigated, since a job |
462 |
failed or we couldn't compute its status and this can also point to a |
463 |
problem on the Ganeti side. |
464 |
|
465 |
BUGS |
466 |
---- |
467 |
|
468 |
The program does not check all its input data for consistency, and |
469 |
sometime aborts with cryptic errors messages with invalid data. |
470 |
|
471 |
The algorithm is not perfect. |
472 |
|
473 |
EXAMPLE |
474 |
------- |
475 |
|
476 |
Note that these examples are not for the latest version (they don't |
477 |
have full node data). |
478 |
|
479 |
Default output |
480 |
~~~~~~~~~~~~~~ |
481 |
|
482 |
With the default options, the program shows each individual step and |
483 |
the improvements it brings in cluster score:: |
484 |
|
485 |
$ hbal |
486 |
Loaded 20 nodes, 80 instances |
487 |
Cluster is not N+1 happy, continuing but no guarantee that the cluster will end N+1 happy. |
488 |
Initial score: 0.52329131 |
489 |
Trying to minimize the CV... |
490 |
1. instance14 node1:node10 => node16:node10 0.42109120 a=f r:node16 f |
491 |
2. instance54 node4:node15 => node16:node15 0.31904594 a=f r:node16 f |
492 |
3. instance4 node5:node2 => node2:node16 0.26611015 a=f r:node16 |
493 |
4. instance48 node18:node20 => node2:node18 0.21361717 a=r:node2 f |
494 |
5. instance93 node19:node18 => node16:node19 0.16166425 a=r:node16 f |
495 |
6. instance89 node3:node20 => node2:node3 0.11005629 a=r:node2 f |
496 |
7. instance5 node6:node2 => node16:node6 0.05841589 a=r:node16 f |
497 |
8. instance94 node7:node20 => node20:node16 0.00658759 a=f r:node16 |
498 |
9. instance44 node20:node2 => node2:node15 0.00438740 a=f r:node15 |
499 |
10. instance62 node14:node18 => node14:node16 0.00390087 a=r:node16 |
500 |
11. instance13 node11:node14 => node11:node16 0.00361787 a=r:node16 |
501 |
12. instance19 node10:node11 => node10:node7 0.00336636 a=r:node7 |
502 |
13. instance43 node12:node13 => node12:node1 0.00305681 a=r:node1 |
503 |
14. instance1 node1:node2 => node1:node4 0.00263124 a=r:node4 |
504 |
15. instance58 node19:node20 => node19:node17 0.00252594 a=r:node17 |
505 |
Cluster score improved from 0.52329131 to 0.00252594 |
506 |
|
507 |
In the above output, we can see: |
508 |
|
509 |
- the input data (here from files) shows a cluster with 20 nodes and |
510 |
80 instances |
511 |
- the cluster is not initially N+1 compliant |
512 |
- the initial score is 0.52329131 |
513 |
|
514 |
The step list follows, showing the instance, its initial |
515 |
primary/secondary nodes, the new primary secondary, the cluster list, |
516 |
and the actions taken in this step (with 'f' denoting failover/migrate |
517 |
and 'r' denoting replace secondary). |
518 |
|
519 |
Finally, the program shows the improvement in cluster score. |
520 |
|
521 |
A more detailed output is obtained via the *-C* and *-p* options:: |
522 |
|
523 |
$ hbal |
524 |
Loaded 20 nodes, 80 instances |
525 |
Cluster is not N+1 happy, continuing but no guarantee that the cluster will end N+1 happy. |
526 |
Initial cluster status: |
527 |
N1 Name t_mem f_mem r_mem t_dsk f_dsk pri sec p_fmem p_fdsk |
528 |
* node1 32762 1280 6000 1861 1026 5 3 0.03907 0.55179 |
529 |
node2 32762 31280 12000 1861 1026 0 8 0.95476 0.55179 |
530 |
* node3 32762 1280 6000 1861 1026 5 3 0.03907 0.55179 |
531 |
* node4 32762 1280 6000 1861 1026 5 3 0.03907 0.55179 |
532 |
* node5 32762 1280 6000 1861 978 5 5 0.03907 0.52573 |
533 |
* node6 32762 1280 6000 1861 1026 5 3 0.03907 0.55179 |
534 |
* node7 32762 1280 6000 1861 1026 5 3 0.03907 0.55179 |
535 |
node8 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
536 |
node9 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
537 |
* node10 32762 7280 12000 1861 1026 4 4 0.22221 0.55179 |
538 |
node11 32762 7280 6000 1861 922 4 5 0.22221 0.49577 |
539 |
node12 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
540 |
node13 32762 7280 6000 1861 922 4 5 0.22221 0.49577 |
541 |
node14 32762 7280 6000 1861 922 4 5 0.22221 0.49577 |
542 |
* node15 32762 7280 12000 1861 1131 4 3 0.22221 0.60782 |
543 |
node16 32762 31280 0 1861 1860 0 0 0.95476 1.00000 |
544 |
node17 32762 7280 6000 1861 1106 5 3 0.22221 0.59479 |
545 |
* node18 32762 1280 6000 1396 561 5 3 0.03907 0.40239 |
546 |
* node19 32762 1280 6000 1861 1026 5 3 0.03907 0.55179 |
547 |
node20 32762 13280 12000 1861 689 3 9 0.40535 0.37068 |
548 |
|
549 |
Initial score: 0.52329131 |
550 |
Trying to minimize the CV... |
551 |
1. instance14 node1:node10 => node16:node10 0.42109120 a=f r:node16 f |
552 |
2. instance54 node4:node15 => node16:node15 0.31904594 a=f r:node16 f |
553 |
3. instance4 node5:node2 => node2:node16 0.26611015 a=f r:node16 |
554 |
4. instance48 node18:node20 => node2:node18 0.21361717 a=r:node2 f |
555 |
5. instance93 node19:node18 => node16:node19 0.16166425 a=r:node16 f |
556 |
6. instance89 node3:node20 => node2:node3 0.11005629 a=r:node2 f |
557 |
7. instance5 node6:node2 => node16:node6 0.05841589 a=r:node16 f |
558 |
8. instance94 node7:node20 => node20:node16 0.00658759 a=f r:node16 |
559 |
9. instance44 node20:node2 => node2:node15 0.00438740 a=f r:node15 |
560 |
10. instance62 node14:node18 => node14:node16 0.00390087 a=r:node16 |
561 |
11. instance13 node11:node14 => node11:node16 0.00361787 a=r:node16 |
562 |
12. instance19 node10:node11 => node10:node7 0.00336636 a=r:node7 |
563 |
13. instance43 node12:node13 => node12:node1 0.00305681 a=r:node1 |
564 |
14. instance1 node1:node2 => node1:node4 0.00263124 a=r:node4 |
565 |
15. instance58 node19:node20 => node19:node17 0.00252594 a=r:node17 |
566 |
Cluster score improved from 0.52329131 to 0.00252594 |
567 |
|
568 |
Commands to run to reach the above solution: |
569 |
echo step 1 |
570 |
echo gnt-instance migrate instance14 |
571 |
echo gnt-instance replace-disks -n node16 instance14 |
572 |
echo gnt-instance migrate instance14 |
573 |
echo step 2 |
574 |
echo gnt-instance migrate instance54 |
575 |
echo gnt-instance replace-disks -n node16 instance54 |
576 |
echo gnt-instance migrate instance54 |
577 |
echo step 3 |
578 |
echo gnt-instance migrate instance4 |
579 |
echo gnt-instance replace-disks -n node16 instance4 |
580 |
echo step 4 |
581 |
echo gnt-instance replace-disks -n node2 instance48 |
582 |
echo gnt-instance migrate instance48 |
583 |
echo step 5 |
584 |
echo gnt-instance replace-disks -n node16 instance93 |
585 |
echo gnt-instance migrate instance93 |
586 |
echo step 6 |
587 |
echo gnt-instance replace-disks -n node2 instance89 |
588 |
echo gnt-instance migrate instance89 |
589 |
echo step 7 |
590 |
echo gnt-instance replace-disks -n node16 instance5 |
591 |
echo gnt-instance migrate instance5 |
592 |
echo step 8 |
593 |
echo gnt-instance migrate instance94 |
594 |
echo gnt-instance replace-disks -n node16 instance94 |
595 |
echo step 9 |
596 |
echo gnt-instance migrate instance44 |
597 |
echo gnt-instance replace-disks -n node15 instance44 |
598 |
echo step 10 |
599 |
echo gnt-instance replace-disks -n node16 instance62 |
600 |
echo step 11 |
601 |
echo gnt-instance replace-disks -n node16 instance13 |
602 |
echo step 12 |
603 |
echo gnt-instance replace-disks -n node7 instance19 |
604 |
echo step 13 |
605 |
echo gnt-instance replace-disks -n node1 instance43 |
606 |
echo step 14 |
607 |
echo gnt-instance replace-disks -n node4 instance1 |
608 |
echo step 15 |
609 |
echo gnt-instance replace-disks -n node17 instance58 |
610 |
|
611 |
Final cluster status: |
612 |
N1 Name t_mem f_mem r_mem t_dsk f_dsk pri sec p_fmem p_fdsk |
613 |
node1 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
614 |
node2 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
615 |
node3 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
616 |
node4 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
617 |
node5 32762 7280 6000 1861 1078 4 5 0.22221 0.57947 |
618 |
node6 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
619 |
node7 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
620 |
node8 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
621 |
node9 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
622 |
node10 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
623 |
node11 32762 7280 6000 1861 1022 4 4 0.22221 0.54951 |
624 |
node12 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
625 |
node13 32762 7280 6000 1861 1022 4 4 0.22221 0.54951 |
626 |
node14 32762 7280 6000 1861 1022 4 4 0.22221 0.54951 |
627 |
node15 32762 7280 6000 1861 1031 4 4 0.22221 0.55408 |
628 |
node16 32762 7280 6000 1861 1060 4 4 0.22221 0.57007 |
629 |
node17 32762 7280 6000 1861 1006 5 4 0.22221 0.54105 |
630 |
node18 32762 7280 6000 1396 761 4 2 0.22221 0.54570 |
631 |
node19 32762 7280 6000 1861 1026 4 4 0.22221 0.55179 |
632 |
node20 32762 13280 6000 1861 1089 3 5 0.40535 0.58565 |
633 |
|
634 |
Here we see, beside the step list, the initial and final cluster |
635 |
status, with the final one showing all nodes being N+1 compliant, and |
636 |
the command list to reach the final solution. In the initial listing, |
637 |
we see which nodes are not N+1 compliant. |
638 |
|
639 |
The algorithm is stable as long as each step above is fully completed, |
640 |
e.g. in step 8, both the migrate and the replace-disks are |
641 |
done. Otherwise, if only the migrate is done, the input data is |
642 |
changed in a way that the program will output a different solution |
643 |
list (but hopefully will end in the same state). |
644 |
|
645 |
.. vim: set textwidth=72 : |
646 |
.. Local Variables: |
647 |
.. mode: rst |
648 |
.. fill-column: 72 |
649 |
.. End: |