hbal - En ligne dans le Cloud

PROGRAMME:

Nom

hbal - Équilibreur de cluster pour Ganeti

SYNOPSIS

hbal {options backend...} [options d'algorithme...] [options de rapport...]

hbal --version

Options d'arrière-plan :

{ -m grappe | -L[ chemin ] [-X] | -t fichier de données | -I chemin }

Options d'algorithme :

[ --max-processeur rapport cpu ] [ --min-disque rapport de disque ] [ -l limite ] [ -e But ] [ -g delta ] [
--min-gain-limite порог ] [ -O prénom... ] [ --aucun-déplacement-de-disque ] [ --aucun-déplacement-d'instance ] [
-U fichier-util ] [ --ignorer-dynu ] [ --ignore-soft-erreurs ] [ --monde oui|non ] [ --mond-xen ]
[ --exit-on-missing-mond-data ] [ --mode-évacuation ] [ --migration-restreinte ] [
--select-instances inst ... ] [ --exclure-instances inst ... ]

Options de rapport :

[ -C[ filet ] ] [ -p[ des champs ] ] [ --print-instances ] [ -S filet ] [ -v... | -q ]

DESCRIPTION

hbal est un équilibreur de cluster qui examine l'état actuel du cluster (nœuds avec
leur disque total et libre, mémoire, etc.) et le placement de l'instance et calcule une série de
étapes conçues pour amener le cluster dans un meilleur état.

L'algorithme utilisé est conçu pour être stable (c'est-à-dire qu'il vous donnera les mêmes résultats lorsque
en le redémarrant à partir du milieu de la solution) et raisonnablement rapide. Ce n'est pourtant pas
conçu pour être un algorithme parfait : il est possible de le faire entrer dans un coin d'où
il ne peut trouver aucune amélioration, car il n'a qu'un "pas" d'avance.

Le programme accède à l'état du cluster via Rapi ou Luxi. Il demande également des données sur le
réseau de tous les MonD avec l'option --mond. Actuellement, il utilise uniquement les données produites par
Collecteur de charge CPU.

Par défaut, le programme affichera la solution au fur et à mesure qu'elle est calculée, dans un
format quelque peu cryptique; pour obtenir la liste de commandes Ganeti réelle, utilisez le -C option.

ALGORITHME
Le programme fonctionne par étapes indépendantes ; à chaque étape, nous calculons le meilleur mouvement d'instance
qui abaisse le score du cluster.

Les types de déplacement possibles pour une instance sont des combinaisons de basculement/migration et
replace-disks de telle sorte que nous modifions l'un des nœuds d'instance et que l'autre reste
(mais éventuellement avec un changement de rôle, par exemple de primaire il devient secondaire). La liste est :

· basculement (f)

· remplacer secondaire (r)

· remplacer primaire, un mouvement composite (f, r, f)

· basculement et remplacement du secondaire, également composite (f, r)

· remplacer le secondaire et le basculement, également composite (r, f)

Nous ne faisons pas la seule possibilité restante de remplacer les deux nœuds (r,f,r,f ou le
équivalent f,r,f,r) car ces mouvements nécessitent une recherche exhaustive sur les deux candidats
nœuds primaires et secondaires, et est O(n*n) dans le nombre de nœuds. De plus, il
ne semble pas donner de meilleurs scores mais entraînera plus de remplacements de disques.

PLACEMENT RESTRICTIONS
À chaque étape, nous empêchons un déplacement d'instance si cela provoque :

· un nœud pour passer en état de défaillance N+1

· une instance pour passer sur un nœud hors ligne (les nœuds hors ligne sont soit lus depuis le cluster
ou déclaré avec -O; les nœuds drainés sont considérés comme hors ligne)

· un conflit basé sur les balises d'exclusion (les balises d'exclusion sont lues à partir du cluster et/ou définies
via le --étiquettes-d'exclusion option)

· un ratio max vcpu/pcpu à dépasser (configuré via --max-processeur)

· pourcentage de disque libre minimum pour passer en dessous de la limite configurée (configuré via --min-disque)

CLUSTER NOTATION
Comme indiqué précédemment, l'algorithme essaie de minimiser le score du cluster à chaque étape. Actuellement
ce score est calculé comme une somme pondérée des composants suivants :

· écart type du pourcentage de mémoire libre

· écart type du pourcentage de mémoire réservée

· la somme des pourcentages de mémoire réservée

· écart type du pourcentage de disque libre

· nombre de nœuds échouant au contrôle N+1

· nombre d'instances vivant (en tant que primaire ou secondaire) sur des nœuds hors ligne ; dans le
sens des nœuds drainés hbal (et les autres htools) sont considérés comme hors ligne

· nombre d'instances vivant (en tant que principal) sur des nœuds hors ligne ; cela diffère de ce qui précède
métrique en facilitant le basculement de telles instances dans des clusters à 2 nœuds

· écart type du rapport processeurs virtuels/processeurs physiques (pour les instances primaires de
le nœud)

· écart type de la fraction des broches disponibles (en mode dédié,
les broches représentent les broches physiques ; sinon cette mesure sursouscrite pour IO
charge, et le facteur de sursouscription est pris en compte dans le calcul du nombre de
broches disponibles)

· écart type de la charge dynamique sur les nœuds, pour le processeur, la mémoire, le disque et le réseau

· écart type de la charge CPU fournie par MonD

· le nombre d'instances avec primaire et secondaire dans le même domaine de défaillance

Les valeurs de mémoire libre et de disque libre permettent de s'assurer que tous les nœuds sont quelque peu équilibrés dans
leur utilisation des ressources. La mémoire réservée permet de s'assurer que les nœuds sont quelque peu
équilibré dans la détention d'instances secondaires et qu'aucun nœud ne garde trop de mémoire réservée
pour N+1. Et enfin, le pourcentage N+1 permet de guider l'algorithme vers l'élimination
N+1 échecs, si possible.

À l'exception des échecs N+1, du nombre d'instances hors ligne et de la violation de domaine d'échec
compte, nous utilisons l'écart type car lorsqu'il est utilisé avec des valeurs dans une plage fixe (nous
utiliser des pourcentages exprimés sous forme de valeurs comprises entre zéro et un), il donne des résultats cohérents à travers
toutes les métriques (il y a quelques petits problèmes liés à différents moyens, mais ça marche
généralement bien). Les valeurs de type 'count' auront un score plus élevé et auront donc plus d'importance
pour l'équilibrage; donc ceux-ci sont meilleurs pour les contraintes dures (comme l'évacuation des nœuds et
correction des défaillances N+1). Par exemple, le nombre d'instances hors ligne (c'est-à-dire le nombre de
instances vivant sur des nœuds hors ligne) entraînera le déplacement actif des instances par l'algorithme
loin des nœuds hors ligne. Ceci, associé à la restriction de placement donnée par hors ligne
nœuds, entraînera l'évacuation de ces nœuds.

Les valeurs de charge dynamique doivent être lues à partir d'un fichier externe (Ganeti ne fournit pas
eux), et sont calculés pour chaque nœud comme : somme de la charge du processeur de l'instance principale, somme de
charge mémoire de l'instance, somme de la charge disque de l'instance principale et secondaire (comme DRBD génère
écrire la charge sur les nœuds secondaires aussi dans le cas normal et dans les scénarios dégradés également lire
load) et la somme de la charge réseau de l'instance principale. Un exemple de la façon de générer ces
les valeurs à saisir dans hbal seraient de suivre la liste xm pour les instances sur une journée et par
calculer le delta des valeurs du processeur, et le nourrir via le -U option pour toutes les instances
(et gardez les autres métriques comme une seule). Pour que l'algorithme fonctionne, il suffit de
que les valeurs sont cohérentes pour une métrique dans toutes les instances (par exemple, toutes les instances utilisent
cpu% pour signaler l'utilisation du processeur, et non quelque chose lié au nombre de secondes de processeur utilisées si le
les processeurs sont différents) et qu'ils sont normalisés entre zéro et un. Notez que c'est
recommandé de ne pas avoir zéro comme valeur de charge pour toute métrique d'instance depuis lors
les instances secondaires ne sont pas bien équilibrées.

La charge CPU du collecteur de données de MonD ne sera utilisée que si tous les MonD sont en cours d'exécution,
sinon, cela n'affectera pas le score du cluster. Comme nous ne pouvons pas trouver la charge CPU de chaque
instance, on peut supposer que la charge CPU d'une instance est proportionnelle au nombre de
son vcpus. Avec cette heuristique, les instances des nœuds avec une charge CPU élevée auront tendance à se déplacer
aux nœuds avec moins de charge CPU.

Sur un cluster parfaitement équilibré (tous les nœuds de la même taille, toutes les instances de la même taille et
répartis de manière égale sur les nœuds), les valeurs de toutes les métriques seraient de zéro, avec le
exception du pourcentage total de mémoire réservée. Cela n'arrive pas trop souvent dans
s'entraîner :)

HORS LIGNE LES INSTANCES
Étant donné que les versions actuelles de Ganeti ne signalent pas la mémoire utilisée par les instances hors ligne (hors service),
ignorer l'état d'exécution des instances entraînera des calculs erronés. Pour cette raison, le
l'algorithme soustrait la taille de la mémoire des instances vers le bas de la mémoire de nœud libre de leur
nœud primaire, simulant en fait le démarrage de telles instances.

EXCLUSION MOTS CLÉS
Le mécanisme des balises d'exclusion est conçu pour empêcher les instances qui exécutent la même charge de travail
(par exemple deux serveurs DNS) pour atterrir sur le même nœud, ce qui ferait du nœud respectif un
SPOF pour le service donné.

Cela fonctionne en marquant les instances avec certaines balises, puis en créant des cartes d'exclusion basées sur
ces. Les balises réellement utilisées sont configurées soit via la ligne de commande (option
--étiquettes-d'exclusion) ou en les ajoutant aux balises du cluster :

--exclusion-tags=a,b
Cela rendra toutes les balises d'instance du formulaire une:*, b :* être pris en considération pour le
carte d'exclusion

grappe étiquettes htools:iextags:a, htools:iextags:b
Cela fera des balises d'instance une:*, b :* être pris en compte pour la carte d'exclusion. Suite
précisément, le suffixe des balises de cluster commençant par htools:iextags : deviendra le
préfixe des balises d'exclusion.

Les deux formes ci-dessus signifient que deux instances ayant toutes les deux (par exemple) la balise un:foo or b: barre
ne se terminera pas sur le même nœud.

MIGRATION MOTS CLÉS
Si Ganeti est déployé sur un cluster hétérogène, la migration peut ne pas être possible entre
tous les nœuds d'un groupe de nœuds. Un exemple d'une telle situation est la mise à niveau de l'hyperviseur
nœud par nœud. Pour informer hbal de ces restrictions, les balises de cluster suivantes sont
utilisé.

grappe étiquettes htools:migration:a, htools:migration:b, etc
Cela fait des balises de nœud de la forme une:*, b :*, etc être considéré comme une migration
restriction. Plus précisément, le suffixe des balises de cluster commençant par
htools:migration : deviendra le préfixe des balises de migration. Seuls ceux
les migrations seront prises en considération lorsque toutes les balises de migration de la source
node sont également présents sur le nœud cible.

grappe étiquettes htools:allowmigration:x::y en migration étiquettes x ainsi que y
Cela affirme qu'un nœud étiqueté y est capable de recevoir des instances de la même manière que si
ils avaient un x Étiquette.

Ainsi, dans le cas simple d'une mise à niveau d'hyperviseur, le marquage de tous les nœuds qui ont été
mis à niveau avec une balise de migration suffit. Dans des situations plus compliquées, il est toujours
possible d'utiliser une balise de migration différente pour chaque hyperviseur utilisé et d'indiquer explicitement le
directions de migration autorisées au moyen de htools:autoriser la migration : Mots clés.

EMPLACEMENT MOTS CLÉS
Au sein d'un groupe de nœuds, certains nœuds peuvent être plus susceptibles de tomber en panne simultanément en raison d'un
cause commune d'erreur (par exemple, s'ils partagent le même bloc d'alimentation). Ganeti peut être
sensibilisé aux causes courantes de défaillance au moyen de balises.

grappe étiquettes htools:nemplacement:a, htools:nemplacement:b, etc
Cela fait des balises de nœud de la forme une:*, b :*, etc. être considéré comme ayant un
cause d'échec.

Les instances avec des nœuds primaire et secondaire ayant une cause commune de défaillance sont prises en compte
mal positionné. Bien que de tels placements soient toujours autorisés, ils comptent beaucoup pour le
score de cluster.

OPTIONS

Les options qui peuvent être passées au programme sont les suivantes :

-Ç, --print-commandes
Imprimer la liste des commandes à la fin de l'exécution. Sans cela, le programme ne
afficher une sortie plus courte, mais cryptique.

Notez que la liste des déplacements sera divisée en étapes indépendantes, appelées "jobsets",
mais uniquement pour une inspection visuelle, pas pour une parallélisation réelle. Ce n'est pas
possible de les paralléliser directement lorsqu'elles sont exécutées via des commandes "gnt-instance",
car une commande composée (par exemple, basculement et remplacement de disques) doit être exécutée
en série. L'exécution parallèle n'est possible qu'en utilisant le backend Luxi et le
-L option.

L'algorithme pour diviser les mouvements en ensembles de tâches consiste à accumuler les mouvements jusqu'à ce que
le prochain coup touche des nœuds déjà touchés par les coups en cours ; cela signifie que nous
ne peut pas exécuter en parallèle (en raison de l'allocation des ressources dans Ganeti) et nous commençons donc
un nouvel ensemble d'emplois.

-p, --print-noeuds
Imprime l'état du nœud avant et après, dans un format conçu pour permettre à l'utilisateur de
comprendre les paramètres les plus importants du nœud. Voir la page de manuel outils(1) pour
plus de détails sur cette option.

--print-instances
Imprime la carte d'instance avant et après. Ceci est moins utile que le statut du nœud,
mais cela peut aider à comprendre les mouvements d'instance.

-O prénom
Cette option (qui peut être donnée plusieurs fois) marquera les nœuds comme étant direct.
Cela signifie plusieurs choses :

· les instances ne seront pas placées sur ces nœuds, même temporairement ; par exemple le remplacer
primaire le déplacement n'est pas disponible si le nœud secondaire est hors ligne, car ce déplacement
nécessite un basculement.

· ces nœuds ne seront pas inclus dans le calcul du score (sauf pour le
pourcentage d'instances sur des nœuds hors ligne)

Notez que l'algorithme marquera également comme hors ligne tous les nœuds signalés par RAPI
en tant que tel, ou qui ont "?" dans l'entrée basée sur un fichier dans n'importe quel champ numérique.

-e But, --min-score=*score*
Ce paramètre indique à quel point au-dessus de la borne N+1, le score du cluster peut nous permettre de
satisfait et modifie le calcul de deux manières :

· si le cluster a le score initial inférieur à cette valeur, alors nous n'entrons pas
l'algorithme du tout, et sortir avec succès

· au cours du processus itératif, si on atteint un score inférieur à cette valeur, on sort
l'algorithme

La valeur par défaut du paramètre est actuellement 1e-9 (choisi empiriquement).

-g delta, --min-gain=*delta*
Étant donné que l'algorithme d'équilibrage peut parfois entraîner de très petites améliorations,
qui apportent moins de gain qu'ils ne coûtent en temps de relocalisation, ce paramètre (par défaut
à 0.01) représente le gain minimum dont nous avons besoin pendant une étape, pour continuer
équilibrage.

--min-gain-limit=*seuil*
L'option de gain minimum ci-dessus ne prendra effet que si le score du cluster est déjà
ci-dessous порог (par défaut à 0.1). La raison d'être de ce paramètre est qu'à
scores de cluster élevés (clusters mal équilibrés), nous ne voulons pas annuler le rééquilibrage
trop rapidement, car les gains ultérieurs pourraient encore être importants. Cependant, sous le
seuil, le gain total n'est que la valeur seuil, nous pouvons donc sortir plus tôt.

--aucun-déplacement-de-disque
Ce paramètre empêche hbal d'utiliser le déplacement de disque (c'est-à-dire "gnt-instance
replace-disks"). Cela se traduira par un équilibrage beaucoup plus rapide, mais de
bien sûr les améliorations sont limitées. C'est à l'utilisateur de décider quand utiliser
l'un ou l'autre.

--aucun-déplacement-d'instance
Ce paramètre empêche hbal d'utiliser les mouvements d'instance (c'est-à-dire "gnt-instance
migrate/failover"). Cela n'utilisera que le remplacement lent du disque
opérations, et fournira également un moins bon équilibre, mais peut être utile si vous déplacez
instances autour est considérée comme dangereuse ou non préférée.

--mode-évacuation
Ce paramètre restreint la liste des instances envisagées pour le déplacement vers celles
vivant sur des nœuds hors ligne/vidangés. Il peut être utilisé comme un remplacement (en vrac) pour
Le propre de Ganeti nœud-gnt évacuer, avec la note qu'il ne garantit pas la pleine
évacuation.

--migration-restreinte
Ce paramètre interdit tous les mouvements primaires de remplacement (frf), ainsi que ceux
les déplacements de remplacement et de basculement (rf) où le nœud principal de l'instance n'est pas
drainé. Si elle est utilisée avec l'option --evac-mode, les seules migrations qui
hbal fera des migrations d'instances à partir d'un nœud drainé. Cela peut être utile si
lors d'une réinstallation du système d'exploitation de base, la migration n'est possible qu'à partir du
ancien système d'exploitation vers le nouveau système d'exploitation. Notez, cependant, que généralement l'utilisation de balises de migration est la
meilleur choix.

--select-instances=*instances*
Ce paramètre marque les instances données (sous forme de liste séparée par des virgules) comme les seules
ceux étant déplacés pendant le rééquilibrage.

--exclude-instances=*instances*
Ce paramètre marque les instances données (sous forme de liste séparée par des virgules) d'être
déplacé lors du rééquilibrage.

-U fichier-util
Ce paramètre spécifie un fichier contenant les informations d'utilisation dynamique de l'instance
qui sera utilisé pour peaufiner l'algorithme d'équilibrage pour égaliser la charge sur les nœuds
(par opposition à l'utilisation statique des ressources). Le fichier est au format "instance_name
cpu_util mem_util disk_util net_util" où les paramètres "_util" sont interprétés
sous forme de nombres et le nom de l'instance doit correspondre exactement à l'instance telle que lue à partir de
Ganeti. En cas de noms d'instance inconnus, le programme s'arrêtera.

Si elles ne sont pas fournies, les valeurs par défaut sont une pour toutes les métriques et donc dynamiques
l'utilisation n'a qu'un effet sur l'algorithme : l'égalisation du secondaire
instances à travers les nœuds (c'est la seule métrique qui n'est pas suivie par une autre,
valeur dédiée, et donc la charge de disque des instances entraînera une instance secondaire
égalisation). Notez que la valeur de un influencera également légèrement le primaire
nombre d'instances, mais qui est déjà suivi via d'autres métriques et donc le
l'influence de l'utilisation dynamique sera pratiquement insignifiante.

--ignorer-dynu
Si elles sont fournies, toutes les informations d'utilisation dynamique seront ignorées en supposant qu'elles sont
0. Cette option prévaudra sur toutes les données transmises par l'option -U ou par
les MonDs avec les options --mond et --mond-data.

--ignore-soft-erreurs
Si elle est donnée, toutes les vérifications des erreurs logicielles seront omises lors de l'examen de l'équilibrage
se déplace. De cette façon, des progrès peuvent être réalisés dans un cluster où tous les nœuds sont dans un
mauvais état du point de vue des politiques, comme le dépassement des taux de surabonnement sur le processeur ou les broches.

-S nom de fichier, --save-cluster=*nom de fichier*
Si donné, l'état du cluster avant l'équilibrage est enregistré dans le fichier donné
plus l'extension "original" (c'est-à-dire nom de fichier.original), et l'état à la fin
de l'équilibrage est enregistré dans le fichier donné plus l'extension "balanced" (c'est-à-dire
nom de fichier.équilibré). Cela permet de réalimenter l'état du cluster à hbal lui-même
ou par exemple hspace via l'option -t.

-t fichier de données, --text-data=*fichier de données*
Spécification du backend : le nom du fichier contenant les informations sur le nœud et l'instance
(si non collecte via RAPI ou LUXI). Celui-ci ou l'un des autres backends doit être
choisi. L'option est décrite dans la page de manuel outils (1).

--mond=*oui|non*
Si cela est donné, le programme interrogera tous les MonD pour récupérer les données des données prises en charge
collecteurs sur le réseau.

--mond-xen
Le cas échéant, interrogez également les collecteurs spécifiques à Xen de MonD, à condition que la surveillance
les démons sont interrogés du tout.

--exit-on-missing-mond-data
S'il est fourni, abandonne si les données pouvant être obtenues à partir de l'interrogation de MonDs sont incomplètes. Les
le comportement par défaut est de continuer avec une meilleure estimation basée sur les informations statiques.

--mond-data fichier de données
Le nom du fichier contenant les données fournies par MonD, pour remplacer les requêtes MonD
sur le réseau. Ceci est principalement utilisé pour le débogage. Le fichier doit être en JSON
formater et présenter un tableau d'objets JSON, un pour chaque nœud, avec deux membres.
Le premier membre nommé node est le nom du nœud et le second membre nommé
reports est un tableau d'objets de rapport. Les objets du rapport doivent être dans le même
format tel que produit par l'agent de surveillance.

-m grappe
Spécification backend : collectez les données directement à partir du grappe donné comme argument
via RAPI. L'option est décrite dans la page de manuel outils (1).

-L [chemin]
Spécification backend : collecter les données directement depuis le démon maître, qui doit être
contacté via LUXI (protocole Ganeti interne). L'option est décrite dans le
Page de manuel outils (1).

-X Lors de l'utilisation du backend Luxi, hbal peut également exécuter les commandes données. Les
méthode d'exécution consiste à exécuter les jobs individuels (voir le -C possibilité pour
détails) dans des étapes distinctes, abandon si à tout moment un ensemble de travaux n'a pas tous les travaux
à succès. Chaque étape de la solution d'équilibrage sera traduite exactement en
un travail Ganeti (ayant entre un et trois OpCodes), et toutes les étapes d'un
jobset seront exécutés en parallèle. Les jobsets eux-mêmes sont exécutés en série.

L'exécution de la série de tâches peut être interrompue, voir ci-dessous pour le traitement des signaux.

-l N, --max-longueur=*N*
Restreindre la solution à cette longueur. Cela peut être utilisé par exemple pour automatiser le
exécution de l'équilibrage.

--max-cpu=*ratio-cpu*
Le rapport processeur virtuel/processeur physique maximal, sous forme de nombre à virgule flottante supérieur à
ou égal à un. Par exemple, en spécifiant rapport cpu as 2.5 signifie que, pour un 4-cpu
machine, un maximum de 10 processeurs virtuels doit être autorisé à être utilisé pour le
instances. Une valeur d'exactement un signifie qu'il n'y aura pas de sur-abonnement de CPU
(à l'exception du temps CPU utilisé par le nœud lui-même), et les valeurs inférieures à un ne font pas
sens, car cela signifie que d'autres ressources (par exemple le disque) ne seront pas pleinement utilisées en raison de
Restrictions du processeur.

--min-disk=*rapport-disque*
Quantité minimale d'espace disque libre restant, sous forme de nombre à virgule flottante. Pour
exemple, en spécifiant rapport de disque as 0.25 signifie qu'au moins un quart du disque
l'espace doit être laissé libre sur les nœuds.

-G uuid, --group=*uuid*
Sur un cluster multi-groupes, sélectionnez ce groupe pour le traitement. Sinon hbal
annuler, car il ne peut pas équilibrer plusieurs groupes en même temps.

-dans, --verbeux
Augmentez la verbosité de la sortie. Chaque utilisation de cette option augmentera la
la verbosité (actuellement plus de 2 n'a pas de sens) à partir de la valeur par défaut.

-q, --silencieux
Diminuez la verbosité de la sortie. Chaque utilisation de cette option réduira la
la verbosité (inférieure à zéro n'a pas de sens) à partir de la valeur par défaut de un.

-V, --version
Affichez simplement la version du programme et quittez.

SIGNAL MANIPULATION

Lors de l'exécution de tâches via LUXI (à l'aide de l'option -X), hbal exécutera normalement toutes les tâches
jusqu'à ce qu'une erreur se produise ou que tous les travaux se terminent avec succès.

Étant donné que l'équilibrage peut prendre beaucoup de temps, il est possible d'arrêter hbal tôt de deux manières :

· en envoyant un SIGINT (^C), hbal enregistrera la demande de résiliation, et attendra
jusqu'à ce que les travaux actuellement soumis se terminent, moment auquel il se terminera (avec le code de sortie 0
si tous les travaux se sont terminés correctement, sinon avec le code de sortie 1 comme d'habitude)

· en envoyant un SIGTERM, hbal sortira immédiatement (avec le code de sortie 2); c'est le
responsabilité de l'utilisateur de suivre avec Ganeti et de vérifier le résultat de la
tâches en cours d'exécution

Notez que dans n'importe quelle situation, il est parfaitement sûr de tuer hbal, soit via les signaux ci-dessus
ou via tout autre signal (par exemple SIGQUIT, SIGKILL), puisque les jobs eux-mêmes sont traités
par Ganeti alors que hbal (après soumission) ne surveille que leur progression. Dans ce cas,
l'utilisateur devra interroger Ganeti pour les résultats du travail.

EXIT STATUT

L'état de sortie de la commande sera zéro, sauf si pour une raison quelconque l'algorithme a échoué
(par exemple, mauvais nœud ou données d'instance), options de ligne de commande invalides ou (en cas de tâche
exécution) l'un des travaux a échoué.

Une fois l'exécution du job via Luxi démarrée (-X), si l'équilibrage a été interrompu prématurément (via
SIGINT, ou via --max-length) mais tous les travaux ont été exécutés avec succès, alors le statut de sortie est
zéro; un code de sortie différent de zéro signifie que l'état du cluster doit être examiné, car un
le travail a échoué ou nous n'avons pas pu calculer son statut et cela peut également indiquer un problème sur le
Côté Ganeti.

Utiliser hbal en ligne en utilisant les services onworks.net