Quel est le système ?

Dans le cadre de nos travaux, nous nous sommes placés dans un contexte de clouds. C'est-à- dire un contexte, où nous possédons une infrastructure virtualisée, et les tâches sont contenues à l'intérieur de machines virtuelles. Chaque tâche étant hébergée par une machine virtuelle, nous avons donc la capacité au niveau de l'utilisateur, de demander un pourcentage pour chaque ressource de la machine hôte. De plus, une infrastructure virtualisée implique aussi une possible migration des machines virtuelles d'une machine physique vers une autre. Au niveau de l'infras- tructure elle même, nous prendrons un cloud, constitué de plusieurs clusters géographiquement distribués, un cas qui arrive quand le fournisseur de services, pour orir une meilleure qualité d'expérience à ses utilisateurs, va construire des data centers au plus près de ses clients. Par exemple, on peut avoir un cloud possédant en Europe plusieurs centre de données dans diérents pays. C'est le cas de Google, qui possède en Europe trois data centers : un à Hamina en Fin- lande, un à St. Ghislain en Belgique et un dernier à Dublin en Irlande [51]. C'est aussi le cas des emplacements périphériques des centres d'Amazon pour le service de distribution de contenu CloudFront, qui possède des data centers à Amsterdam, Dublin, Francfort, Londres, Madrid, Milan, Paris, Stockholm[11].

Ces data centers étant distribués, potentiellement construits à des moments diérents, n'au- ront pas tous été dotés des mêmes machines, ni de la même infrastucture de refroidissement. A l'intérieur d'un data center même, nous pourrons avoir des machines diérentes, dans le sens où par exemple une augmentation de capacité aura été eectuée, et ainsi le cluster possèdera des serveurs moins récents que d'autres.

Par conséquent, nous avons une infrastructure de clusters possédant des hôtes homogènes à l'intérieur du cluster, mais des clusters hétérogènes entre eux. Ce qui veut dire que nous aurons des capacités de serveurs diérentes sur chaque cluster, mais ce ne sera pas le cas à l'intérieur du cluster.

Au niveau de la consommation d'énergie inter clusters, nous aurons une consommation dif- férente des hôtes, dû aux spécications matérielles diérentes, mais aussi à l'intérieur d'un même cluster, au sein d'un même rack, nous aurons des consommations diérentes. Cet eet à été observé sur grid5000 dans [35], et peut être tout simplement attribué à la chaleur montante

des serveurs situés en bas du rack, induisant une plus grosse chaleur (et donc consommation) des serveurs situés en hauteur. En eet, une chaleur plus importante, qu'elle soit induite par la charge du processeur, ou par l'environnement, induira potentiellement une augmentation de la vitesse du ventilateur, ce qui amènera une consommation plus importante. De plus, il existe une variation de consommation de puissance entre les diérents processeurs d'un même modèle comme montré dans [14], où les auteurs étudient la variabilité de consommation de puissance entre diérents processeurs Intel Core i5-540M. Leur données montrent une variabilité allant de 7% à 17% en fonction des diérentes applications et des diérentes congurations de DVFS des processeurs.

L'infrastructure de refroidissement des diérents data centers est aussi à prendre en compte, celle-ci consommant une grosse partie de la consommation totale du data center. Ici, l'infras- tructure de refroidissement sur laquelle nous allons agir est celle qui conditionne et gère les ux d'air dans les data centers. Nous supposerons donc par la suite que le refroidissement du cluster se fait par acheminement d'air froid, ce qui n'est pas le cas dans tous les centre de données. Ainsi, dans un cluster, nous aurons une consommation d'énergie totale dépendant à la fois de la consommation des serveurs, et de l'infrastructure de refroidissement. Cette infrastructure de refroidissement, est appelée CRAH/CRAC pour Computer Room Air Handler/Conditionner, le CRAH étant ce qui amène l'air froid sur les serveurs, et le CRAC étant ce qui refroidit eective- ment ce qui doit être acheminé. Celle-ci sera dépendante de l'utilisation du cluster. En eet, de la même manière que pour les serveurs eux-mêmes, une grande utilisation des serveurs amènera une hausse de température, ce qui aura pour eet d'augmenter la vitesse des ventilateurs pour le refroidissement an de maintenir une température basse constante, ce qui amènera à son tour une plus grande consommation d'énergie.

Nous supposerons que nous pourrons agir sur ces CRAC/CRAH, an de pouvoir les allumer ou les éteindre en fonction des besoins. Si le groupe de serveurs directement refroidis par un CRAC/CRAH n'est pas utilisé, donc éteint, nous éteindrons aussi l'infrastructure de refroidisse- ment, an d'avoir une économie d'énergie substantielle. Nous ne prendrons pas en compte la perturbation des ux d'airs, ce qui est cohérent dans un cadre de certains data centers modu- laires par exemple. Ceux-ci peuvent être de type conteneurs, où chaque unité, chaque conteneur, contient à la fois les serveurs, le refroidissement et l'alimentation de manière autosusante. Cette supposition peut être aussi cohérente si l'on suppose que l'on est en mesure d'accepter une hausse dans la température globale de la salle, dûe à la perturbation des ux d'air. Ainsi, lorsque l'on décidera d'éteindre les CRAC/CRAH, nous pourrions voir une augmentation de la tempéra- ture moyenne de la salle, mais restant toujours en dessous des températures recommandées par l'ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) [5]. Les data centers ont plus souvent tendance à être trop refroidis, et les degrés en trop sont les plus chers. La relation entre la puissance et la température n'étant pas linéaire [45], une augmen- tation faible de température induira une faible augmentation de consommation de puissance. Par contre, une augmentation forte de température induira une augmentation proportionnelle- ment plus forte de consommation. À l'inverse, réduire la température de peu de degrés réduira grandement la consommation d'énergie, et les degrés suivants réduiront en proportion moins cette consommation.

Pour plus de clarté, et pour résumer toutes ces suppositions, prenons un exemple montrant dans quel cadre nous nous trouvons, représenté en gure 3.1.

Nous avons un fournisseur de services clouds distribuant des services à des utilisateurs en Europe. Ainsi, ce fournisseur a décidé d'implanter ses serveurs à diérents endroits, an de pouvoir mieux servir les diérentes zones géographiques. Cette infrastructure comprend 3 clusters géographiquement distribués, situés en France, Royaume Uni et Norvège. Pour chaque cluster, nous avons des spécications diérentes pour tous les hôtes. Ici, le cluster du Royaume-Uni

3.2. QUEL EST LE PROBLÈME ? 35