Assurance de trouver une solution si elle existe

Une autre amélioration de la procédure de traitement d’un événement est de garantir qu’une solution sera toujours trouvée si elle existe [QLS12].

98 des machines virtuelles i m m i (a) i m m i (b) i m m i (c) i m

Partition liée au traitement d’un premier événement Partition liée au traitement d’un deuxième événement Nœud de calcul

Initiateur du traitement d’un événement Meneur d’une partition Raccourci

(d) Légende

FIGURE6.3 – Utilisation de raccourcis pour agrandir plus rapidement une partition Prérequis

Un premier pas en ce sens consiste à cesser de détruire une partition lorsqu’un événement donné revient à son initiateur sans avoir été résolu ; il est en effet possible que des nœuds, préalablement impliqués dans d’autres partitions, se soient libérés entre-temps et puissent être utilisés pour résoudre l’événement qui nous intéresse.

Cette étape n’est cependant pas suffisante, car elle peut créer des situations de pénurie de nœuds libres.

Définition 6.5 (Pénurie)

Une pénurie se produit lorsqu’au moins deux partitions ont besoin de s’agrandir alors qu’il ne reste plus de nœuds libres dans l’infrastructure.

Vue d’ensemble de la gestion des pénuries

Afin d’échapper aux pénuries, notre approche consiste à fusionner les partitions deux à deux. Fusionner deux partitions ne garantit pas que les événements associés pourront être résolus ; cependant, cela offre plus de possibilités de migrations à l’or-donnanceur. Cela est d’autant plus vrai lorsque deux événements complémentaires sont impliqués, par exemple deux événements liés respectivement à la surutilisation et à la sous-utilisation des ressources d’un nœud.

Afin d’identifier les partitions qu’il pourrait être intéressant de fusionner, nous leur associons des états : créée, en croissance, bloquée ou détruite (cf. figure6.4).

Créée En croissance Détruite Bloquée

(1) (4)

(2) (3)

(5)

(1) Un événement se produit, son traitement débute (2) L'événement fait le tour de l'anneau sans être résolu (3) Un ou plusieurs nœud(s) intègre(nt) la partition (4) L'événement est résolu

(5) Aucune solution n'existe, l'événement est ignoré FIGURE6.4 – États associés à une partition

Lorsqu’une partition est créée, son état initial est spécifié comme étant en crois-sance. Elle conserve cet état tant que l’événement qui lui est associé n’est pas revenu à son initiateur ; lorsque cela se produit, la partition est alors identifiée comme étant bloquée. Cela ne signifie pas nécessairement qu’il n’y a plus de nœuds libres dans l’infrastructure, mais c’est une possibilité.

L’événement continue de parcourir l’anneau tant qu’il n’a pas été résolu et qu’il reste au moins un nœud en dehors de la partition P1 qui lui est associée ; afin d’ac-célérer ce parcours, nous utilisons les raccourcis présentés précédemment. L’arrivée de l’événement sur un nœud externe à P1soulève trois possibilités :

1. le nœud est membre d’une partition P2 en croissance ; l’événement est alors transféré au premier nœud externe à P2; il ne serait en effet pas judicieux de fusionner P1 avec P2, cette dernière étant susceptible de résoudre son évé-nement toute seule, elle pourrait être pénalisée en devant absorber plus de nœuds que nécessaire ;

2. le nœud est membre d’une partition P2 qui est elle aussi bloquée ; les deux partitions tentent alors de fusionner ; si cette tentative échoue, l’événement est transféré au premier nœud externe à P2; si elle réussit, la partition résultante repasse en croissance ; nous reviendrons plus en détails par la suite sur le fonctionnement de la fusion des partitions ;

3. le nœud est libre ; il est alors intégré dans la partition P1, qui repasse en crois-sance.

Si une solution est trouvée, la procédure de traitement se termine avec succès ; si au contraire tous les nœuds de l’infrastructure ont été absorbés par la partition sans qu’une solution ait été trouvée, le problème est garanti comme étant insoluble. Les différentes étapes de l’algorithme de gestion des situations de pénurie de nœuds sont synthétisées sur la figure6.5.

Détail du processus de fusion de deux partitions

Comme promis, nous revenons maintenant sur le processus de fusion de deux partitions.

Tout d’abord, nous faisons une différence entre la partition demandeuse et la partition exécutrice.

100 des machines virtuelles

Un traitement débute État ← En croissance

L'événement peut-il être résolu avant de revenir à l'initiateur ?

État ← Bloquée

Y a-t-il au moins un nœud hors de la partition ?

État du prochain nœud hors de la partition ? Ignorer les nœuds de cette partition Tenter de fusionner les deux partitions Intégrer le nœud dans la partition

Pas de solution

Traitement terminé avec succès

Oui Non

Non Oui

Impliqué dans une partition (en croissance) Impliqué dans une partition (bloquée) Libre

Échec Succès

FIGURE6.5 – Algorithme de gestion des pénuries de nœuds

Définition 6.6 (Partition demandeuse)

La partition demandeuse est la partition qui effectue la demande de fusion. Définition 6.7 (Partition exécutrice)

La partition exécutrice est la partition qui réalise la fusion.

Afin d’éviter que les deux partitions ne cherchent à endosser simultanément le rôle de demandeuse, nous définissons un ordre total en associant un identifiant unique à chaque nœud, en fonction de sa place sur l’anneau ; nous avons choisi arbitrairement que la partition avec le meneur d’identifiant le plus faible serait la partition demandeuse.

Il faut tout d’abord vérifier qu’aucune des deux partitions n’est déjà impliquée dans un processus de fusion ; le meneur de la partition exécutrice se charge alors de la fusion des partitions et des événements associés :

– le type et l’initiateur de l’événement fusionné sont les mêmes que ceux de l’événement de la partition demandeuse ;

– le meneur de la partition fusionnée est le même que celui de la partition exé-cutrice ;

– la partition fusionnée est constituée des nœuds des deux partitions ;

– les raccourcis sont mis à jour pour éviter qu’ils pointent sur des nœuds de la partition fusionnée (ce qui peut arriver si des raccourcis de la partition deman-deuse pointaient sur des nœuds de la partition exécutrice, et inversement). Une fois les partitions fusionnées, un calcul d’ordonnancement est lancé afin de résoudre l’événement fusionné.

Prenons l’exemple de trois partitions (cf. figure 6.6) pour résumer les notions évoquées jusqu’à présent en matière de gestion des situations de pénurie de nœuds. Les deux partitions bleu clair sont initialement bloquées (cf. figure 6.6(a)) ; l’iden-tifiant du meneur de la partition du bas (6) est inférieur à celui du meneur de la

partition du haut (8) ; la partition du bas endosse donc le rôle de demandeuse, et celle du haut celui d’exécutrice ; la partition fusionnée a la même couleur que celle de l’ex-partition du bas, pour rappeler le type de l’événement (cf. figure 6.6(b)). Si les deux partitions restantes sont également bloquées, le processus de fusion re-commence ; cette fois, la partition de droite est la demandeuse et celle de gauche l’exécutrice ; la partition résultante a la même couleur que l’ex-partition de droite, là encore pour rappeler le type de l’événement (cf. figure 6.6(c)). Si un ordonnan-cement sur la partition fusionnée ne permet pas de résoudre l’événement associé, nous avons alors la garantie qu’aucune solution n’existait, puisque tous les nœuds de l’infrastructure ont été pris en compte.

i i m m m i 1 2 3 4 5