Notre approche d’ordonnancement

5.3 Notre approche d’ordonnancement

5.3.1 Strat´egie d’ordonnancement

Le tableau 5.1pr´esente toutes les possibilit´es de strat´egie. Les lignes du centre de calcul et des panneaux solaires n’ont aucune valeur, car certaines situations ne peuvent pas se produire.

Par exemple, le panneau solaire ne peut pas recevoir d’´energie, donc il ne peut pas stocker d’´energie et ˆetre de type Sauvegarde,Trop-plein etDestination. Le centre de calcul ne peut pas g´en´erer d’´energie (Source) et stocker de l’´energie (SauvegardeetTrop-plein), il ne peut consommer d’´energie (Destination).

Tableau 5.1 – Repr´esentation des ´el´ements et l’ensemble des valeurs possibles pour chaque ´el´ement du r´eseau intelligent, via le mod`ele de flux d’´energie pr´esent´e dans le chapitre3

´el´ements

Notre strat´egie d’ordonnancement utilise le tableau 5.2 comme mod`ele de donn´ees. Ce ta-bleau 5.2 met en ´evidence l’ordre d’utilisation des diff´erentes sources d’´energie. Les panneaux solaires fournissent le centre de calcul en tant que sources. En cas de sous-production, la batterie (Sauvegarde = 1) alimente le centre de calcul. Si la batterie est vide, le fournisseur ´electrique alimente le centre de calcul (Sauvegarde = 2). En cas de sur-production, le surplus d’´energie est stock´e dans la batterie (Trop-plein = 1). Si la batterie est pleine, l’´energie est vendue au fournis-seur d’´electricit´e (trop-plein = 2). Ce mod`ele vise `a acheter le moins d’´energie possible aupr`es du fournisseur. Notre strat´egie peut ˆetre repr´esent´ee par la figure5.2.

5.3. Notre approche d’ordonnancement 88

Tableau 5.2 –Mod`ele ´energ´etique pour la strat´egie d’ordonnancement

Source Destination Sauvegarde Trop-plein Panneaux

solaires

1 × 0 ×

Centre de calcul

× 1 × ×

Batterie 0 0 1 1

Fournisseur 0 0 2 2

Figure 5.2 – L’utilisation des diff´erentes sources d’´energies pendant 48 heures

La figure5.3est un exemple dans une situation presque parfaite. Les VMs sont programm´ees en fonction de l’heure, de l’´energie disponible dans la production solaire et de l’espace disponible dans les serveurs. Le stockage (batterie) n’est pas une contrainte d’ordonnancement des algo-rithmes mais elle fait partie de la strat´egie d’ordonnancement de la gestion des flux d’´energie. Il s’agit d’une solution de sauvegarde, seulement si la production des panneaux solaires n’est pas suffisante pour alimenter le centre de calcul.

5.3. Notre approche d’ordonnancement 89

Les contraintes d’ordonnancement des VMs sont :

- l’utilisation de serveurs h´et´erog`enes en termes de VCPU ;

- le placement de VMs h´et´erog`enes en termes de temps d’ex´ecution ; - le nombre de VCPU utilis´es par VM ;

- l’´energie disponible issue de la production des panneaux solaires.

L’avantage de cette m´ethode est l’utilisation maximale de la production des panneaux solaires et la r´eduction de l’achat d’´energie chez le fournisseur d’´electricit´e. La VM n’est ordonnanc´ee que s’il y a suffisamment d’´energie produite par les panneaux solaires. Cependant, les VMs continuent de fonctionner mˆeme si l’´energie solaire est nulle. Par exemple, dans la figure 5.3, la Vm 10 commence `a s’ex´ecuter lorsqu’il y a assez d’´energie solaire sur le serveur S3. Cependant, cette VM continue de s’ex´ecuter lorsque la production solaire diminue.

Id Serverur

Figure 5.3 – Un exemple d’ordonnancement de VMs en fonction de la production solaire

5.3.2 Proposition d’adaptation d’algorithmes existants

Dans cette partie sont pr´esent´ees et analys´ees plusieurs solutions d’ordonnancement. Pour chacun des algorithmes suivants, les contraintes de ressources de diff´erents serveurs et l’´energie solaire disponibles au fil du temps sont toujours prises en compte. Pour chacun des algorithmes suivants est ordonnanc´e un ensemble de VMs ind´ependantes, stock´ees dans une liste d’attente.

La figure5.4pr´esente les diff´erentes entr´ees et sorties des algorithmes d´ecrits dans cette partie.

5.3. Notre approche d’ordonnancement 90

Figure 5.4 –Entr´ees et sorties des diff´erents algorithmes d’ordonnancement

Round Robin [41] (RR)

L’algorithmeRRpermet de placer une VM sur un serveur puis une fois la VM plac´ee, la VM suivante sera plac´ee sur le serveur suivant et ainsi de suite. Dans ce cas, si une VM ne peut ˆetre plac´ee sur un serveur, le suivant est s´electionn´e. Si elle ne peut ˆetre plac´ee sur l’un des serveurs du centre de calcul, elle est ´eject´ee et la VM suivante est s´electionn´ee. La charge des serveurs est plus ou moins ´equilibr´ee dans le temps. L’inconv´enient est qu’il n’y a pas d’optimisation du parc informatique en termes de serveurs allum´es, il y a une sous-utilisation des ressources. Cet algorithme a pour but de servir de r´ef´erence.

Algorithme 3 RR

whileVM <nbVmsOrdonnancees do

for tps=0;tps<fenetreOrdonnancement;tps++ do

if energieSolaire[tps] ==vraiand serveurs[s][tps] ==vrai then V M ⇒serveur[s][tps]

serveurs[s+ 1]

end if end for end while

First Fit (FF)

L’algorithmeFFconsiste `a placer les diff´erentes VMs sur un serveur. Une fois ce dernier plein, l’op´eration se r´ep`ete sur le serveur suivant. L’inconv´enient est la charge des diff´erents serveurs.

Les premiers serveurs auront une charge plus importante que les derniers serveurs car l’´energie solaire disponible aura fortement diminu´ee par les placements d´ej`a effectu´es.

5.3. Notre approche d’ordonnancement 91

Algorithme 4 FF

whileVM <nbVmsOrdonnancees do

for tps=0;tps<fenetreOrdonnancement;tps++ do

if energieSolaire[tps] ==vraiand serveurs[s][tps] ==vrai then V M ⇒serveur[s][tps]

Round Robin [41] avec des classes de serveurs (RR CLASSES)

L’algorithme RR CLASSESreprend l’algorithme (RR) sauf qu’il contient des classes de ser-veurs. Un ensemble de serveurs est d´edi´e `a l’ordonnancement de VMs courtes, moyennes ou longues. Par exemple, 10% des serveurs ordonnancent les VMs longues, 40% les VMs moyennes et 50% les VMs courtes. Cette division en classes, permet de r´epartir un ensemble de VMs, et d’ordonnancer plus de VMs dans le temps. Cela permet aux VMs longues d’obtenir plus faci-lement des ressources VCPU qui peuvent ˆetre utilis´ees par des VMs de dur´ee moins longues et donc empˆecher l’ordonnancement de certaines VMs plus gourmandes. L’inconv´enient de cet algo-rithme est l’optimisation des diff´erentes ressources du parc informatique. Par exemple, une VM longue, qui ne peut plus ˆetre plac´ee sur un des serveurs appartenant `a la classe VMs longues, sera

´

eject´ee, mˆeme s’il reste de la place sur un serveur permettant d’ordonnancer des VMs courtes ou moyennes. Les classes serveurs doivent ˆetre impl´ement´ees en fonction du nombre de diff´erentes VMs `a ex´ecuter, pour trouver la meilleure r´epartition de classes serveurs.

Algorithme 5 RR CLASSES

whileVM <nbVmsOrdonnancees do

for tps=0;tps<fenetreOrdonnancement;tps++ do

if energieSolaire[tps] ==vraiand serveurs[s][classe][tps] ==vrai then V M ⇒serveur[s][tps]

serveurs[classe][s+ 1]

end if end for end while

Round Robin et Longest Processing Time (RR LPT)

Cet algorithmeRR LPT consiste `a ordonnancer une VM sur un serveur, puis une fois que la VM est plac´ee, la prochaine VM sera plac´ee sur le serveur suivant et ainsi de suite. Cet algorithme