Vers une méthode de distribution adaptative à la charge
2.3. MÉTHODE LAD 55 5. Considération du serveur libre suivant, si le serveur A reste surchargé après
avoir transféré une partie de sa charge à srv. Le nouveau serveur libre pourra recevoir un autre ensemble d’entrées du serveur A.
6. Tri de l’ensemble S à chaque changement de serveur surchargé A. Ainsi, il est possible d’avoir un minimum de transferts : le plus gros ensemble possible de A est déplacé dans le plus grand espace libre possible.
Algorithme 3 Algorithme glouton pour choisir un sous-ensemble d’entrées Entrée:
1: loadcurrent - la charge de départ (zero),
2: list - la liste de toutes les charges des entrées (celles du serveur surchargé),
3: goal - la charge à atteindre (min (|ysrv|, yA)) Sortie: subset - l’ensemble d’entrées à transférer
4: fonction: Choix_entree(loadcurrent, list, goal)
5: .Initialisation
6: subset = ∅
7: Sum = loadcurrent .charge évoluant au cours de l’algorithme
8: last = −1 .last est le dernier élément que l’on n’a pas pu ajouter
9: .Étapes du choix d’entrées
10: Tri de list par ordre décroissant
11: pour tout element ∈ list faire
12: si Sum + element ≥ goal alors
13: si element == 0 alors .on ne transfere pas de charge nulle
14: Break
15: Sum = Sum + element
16: subset = subset ∪ {element}
17: sinon
18: last = index[element]
19: .Si le dernier élément vu n’augmente pas l’écart de charge, on le rajoute
20: si (last 6= −1) et (absolue(Sum + list[last]) < absolue(Sum)) alors
21: subset = subset ∪ list[last]
En appliquant cet algorithme de redistribution, nous répartissons les surcharges sur un ensemble de serveurs libres. Cette vision prend en compte tous les cas de déséquilibres de charges possibles : une surcharge importante pourra, par exemple, être divisée et répartie sur plusieurs petits espaces libres ou être placée entièrement sur un seul espace libre de taille adéquate. De la même manière, plusieurs petites surcharges pourront être déplacées sur un seul large espace libre ou sur plusieurs petits espaces libres. La répartition commence par considérer les serveurs les plus
chargés, ce qui minimise le déséquilibre. Cet algorithme ne permet pas qu’un ser-veur de L reste significativement surchargé car il n’y a plus d’espace libre dû aux répartitions sur les serveurs précédents. Cela garantit aussi le plus petit nombre de transferts possibles, puisque nous remplissons d’abord les espaces libres les plus grands avec les charges les plus grandes. Cependant, cet algorithme ne garantit pas que l’ensemble de destinataires le plus réduit puisse être atteint pour un serveur chargé.
Exemple :
On applique cet algorithme de redistribution sur l’exemple de la section précé-dente avec 6 serveurs qui ont reçu respectivement 24, 19, 29, 22, 10 et 16 requêtes lors de l’époque précédente. Nous supposons, ici aussi, que l’espace de nom est divisé en 10, ce qui nous donne une MLT de 10 entrées avec une répartition des entrées sur les différents serveurs comme le montre la table 2.1. Nous calculons d’abord les SAI relatifs à chaque entrée. Par simplicité, nous choisissons la valeur de α = 1, afin de prendre en compte uniquement les requêtes reçues pour cette époque. La structure EACL et la MLT associées sont sur la table 2.1.
Entrée Serveur responsable SAI = acces_count Serveur responsable après redistribution 1 0 20 0 2 0 4 5 3 1 19 1 4 2 20 2 5 2 9 4 6 3 1 1 7 3 1 4 8 3 20 3 9 4 10 4 10 5 16 5
Table 2.1: Exemple : EACL et MLT pour la méthode LAD.
La première étape de l’algorithme de redistribution consiste à calculer la moyenne idéale que chaque serveur devrait recevoir : celle-ci est de 20 requêtes. Nous
calcu-2.3. MÉTHODE LAD 57 lons ensuite les charges relatives à chaque serveur : respectivement [+4 ; -1 ; +9 ; +2 ; -10 ; -4] comme illustré par la figure 2.5a. Nous plaçons chaque serveur dans les ensembles L et S : L = {0, 2, 3} et S = {1, 4, 5}.
L’étape suivante consiste à répartir les surcharges. Nous cherchons pour le serveur 2, qui est le plus chargé, un ensemble d’entrées dont la somme des SAI vaut 9 (le surplus du serveur 2) ou 10 (l’espace libre du serveur le moins chargé, le serveur 4).
→ l’entrée 5 possède un SAI de 9, elle est donc transférée au serveur 4.
Nous recalculons les charges relatives des serveurs : [+4 ; -1 ; 0 ; +2 ; -1 ; -4] et passons au serveur suivant le plus chargé, c’est-à-dire le serveur 0.
→ L’entrée 2 possède un SAI de 4, elle est transférée au serveur 5.
Nous mettons à jour les charges relatives : [0 ; -1 ; 0 ; +2 ; -1 ; 0]. Puis, nous cherchons pour le serveur 3 un ensemble d’entrées dont la somme des SAI vaut 2 (surplus du serveur 3) ou à 1 (espace libre du serveur 1).
→ L’entrée 6 possède un SAI de 1, elle est transférée au serveur 1.
Nous continuons avec le serveur 3 car sa charge relative est toujours positive. → L’entrée 7 possède aussi un SAI de 1, elle est alors transférée au serveur 4. Nous mettons à jour les charges relatives : [0 ; 0 ; 0 ; 0 ; 0 ; 0]. Tous les serveurs de L ont été traités. Nous obtenons des charges relatives valant toutes 0 ce qui signifie que la charge de travail est équilibrée comme nous pouvons le voir sur la figure 2.5b. La table d’index est mise à jour avec les entrées transférées au cours de la redistribution et nous obtenons la répartition présentée dans la dernière colonne de la table 2.1.
(a) Avant redistribution. (b) Après redistribution.
Figure 2.5: Exemple d’application de la méthode LAD.
Afin de donner une idée des valeurs des charges relatives lors d’une exécution dans un système réel, nous avons extrait un état possible d’une exécution de flux réel sur 4 serveurs avant et après l’algorithme de redistribution. Le calcul des charges relatives avant redistribution fournit les valeurs suivantes, montrant une surcharge du serveur 1 : respectivement −16626, +39296, −10360 et −10309. Après
application de l’algorithme de redistribution, nous pouvons observer la diminution des écarts de charges avec les valeurs suivantes : respectivement −87, +5181, −1572 et −3521. Ces charges sont illustrées par la figure 2.6 récapitulant l’impact de la redistribution.
(a) Avant redistribution. (b) Après redistribution.
Figure 2.6: Exemple d’application de la méthode LAD sur flux réel.
2.3.4 Étude des limites
La méthode LAD diminue le nombre de redistributions inutiles en effectuant une redistribution quand un serveur en exprime le besoin. Cela permet aussi de gérer des flux variants fréquemment comme présenté sur la figure 2.2.
Toutefois, cette méthode possède des coûts notamment en espace mémoire qu’implique la table d’index du côté client et du côté serveur. Cependant, le coût en puissance de calcul est diminué par rapport à la méthode du Dynamic Hashing, puisque les redistributions ne sont pas effectuées à chaque époque. Il reste pour chaque serveur le coût de calcul de la charge. Le nombre de communications in-duites par l’algorithme de redistribution peut être supérieur à celui de la méthode précédente puisque la méthode LAD permet à un serveur de transférer sa charge vers plusieurs serveurs libres. Un surplus de communication pourrait être néces-saire afin de gérer les demandes de redistribution.
L’ajout d’un seuil pour chaque serveur peut aussi aboutir à des redistributions inappropriées. Tel est le cas lorsque le nombre de requêtes reçues par tous les serveurs augmente ou diminue significativement tout en gardant l’équilibre des charges, une redistribution sera demandée.
De plus, le système d’évaluation prend en compte tous les accès passés avec un facteur d’oubli. Cela signifie qu’une valeur de charge aura potentiellement un impact dans l’évaluation de toutes les charges futures, ce qui peut affecter le com-portement de la méthode. En considérant le flux schématisé par la figure 2.7a, la méthode LAD exécutera 6 redistributions avant de se stabiliser (pour obtenir ce résultat nous avons arbitrairement défini les paramètres aux valeurs suivantes : α = 0.5, marge = 10%). Certains flux de requêtes très changeants, comme celui