• Aucun résultat trouvé

CHAPITRE 2 OUTIL DE GESTION DU SYSTÈME IMS

2.1 Motivations

Les outils les plus fonctionnels de gestion dynamique du système IMS actuellement proposés sont des systèmes réactifs. Ils attendent pour allouer ou libérer des ressources de franchir un certain seuil d’utilisation. Bellavista et al. (Bellavista et al. 2012) proposent, par exemple, un outil pour gérer de manière dynamique un système IMS en fonction de la valeur de la charge du CPU. Ils utilisent cette ressource comme référence, car ils ont remarqué qu’elle était la ressource la plus critique des systèmes IMS. Mais dans ce cas, comme dans celui de Nemati et al. (Nemati 2014), nous constatons que la mise à niveau du système, c’est-à-dire le déploiement de nouvelles ressources physiques utilisables, s’effectue quand le système est déjà en manque de ressources. L’objectif ici est donc de construire un outil proactif qui permettrait d’anticiper ce manque, ou l’abondance de ressources, avant que ce ne soit le cas. Nous proposons de développer cet outil pour les systèmes IMS virtualisés.

De nombreux travaux de recherche ont proposé différentes solutions pour la gestion dynamique des systèmes de nuage informatique. En effet, certains chercheurs ont déjà construit des systèmes proactifs. Jiang et al. (Jiang, Perng, et al. 2013), par exemple, veulent pouvoir créer ou supprimer des VM sur leurs machines physiques, afin de réagir à la variation de la charge de trafic de manière automatique. Étant donné qu’il est impossible de demander à un utilisateur d’annoncer son utilisation future des ressources d’un système, ils

ont alors défini un moyen de la prédire. Ils ont construit leur système de prédiction en se basant sur une mesure qu’ils ont appelée le coût de prédiction du nuage (CPC, Cloud Prediction Cost). Leur but est de minimiser ce coût. Pour mesurer cette valeur, ils proposent de calculer la différence entre les ressources que dispose le système à un instant t et les ressources dont il aurait besoin. Si le système dispose de plus de ressources que nécessaire il y a des coûts de gaspillage des ressources, si le système manque de ressources les coûts viennent de la pénalité financière à reverser pour avoir violé le SLA. En fonction de l’évolution de cette mesure, ils prédisent ce qu’il faut faire pour les secondes à venir. C’est-à- dire le nombre de VM qu’il faut éteindre ou allumer pour réduire au maximum leur fonction de coût. Leur solution fonctionne relativement bien, car leurs VMs sont créées en quelques secondes. Nous pouvons cependant voir dans la présentation de leurs résultats que le nombre de VM en activité est très variable. Leur système semble passer beaucoup de temps à construire et détruire des VM et nous pouvons nous demander si cela ne consomme pas aussi des ressources du système. Malgré cela, leur travail a été fructueux, car leurs résultats expérimentaux démontrent que leur approche permet d’améliorer la qualité de service de leur système tout en conservant un faible coût dû au manque ou à l’abondance de ressources.

Jiang et al. (Jiang, Lu, et al. 2013) ont, quant à eux, construit un système de prédiction du trafic sur Internet en se basant sur des techniques d’apprentissage automatique (machine learning) pour analyser des enregistrements de trafic et ainsi prédire celui à venir. Grâce aux modèles déterminés lors de leur analyse du trafic et en cherchant à minimiser une relation qui lie le coût de fonctionnement de leur système et son temps de latence, ils prédisent les ressources physiques nécessaires à leur système pour supporter le trafic à venir. Leur solution permet également de réduire le nombre de violations du SLA tout en optimisant le coût de fonctionnement du système.

Pour finir, Gong et al. (Gong, Gu, and Wilkes 2010) proposent une solution pour gérer dynamiquement les ressources du nuage informatique en prédisant le trafic. Pour cela, ils ont relevé un ensemble de modèles d’évolution du trafic sur le nuage informatique en s’appuyant sur des traces du trafic réel de Google. Ils ont ensuite développé un outil, PRESS (PRedictive

Elastic reSource Scaling), pour télémétrer la charge du CPU, la mémoire, la bande passante et les entrées/sorties d’un réseau afin d’identifier le modèle qui s’adapte le mieux au cas présent. Si un des modèles précédemment relevés correspond à l’état actuel du réseau, ils alloueront à ce dernier autant de ressources qu’il en était nécessaire au bon fonctionnement du réseau lors de l’enregistrement de leur modèle. Si aucun modèle ne s’adapte, ils utilisent des techniques de statistique, dont les chaînes de Markov, pour prédire l’évolution du trafic. Selon leur analyse, leur solution consomme peu de ressources et permet une bonne prédiction des ressources nécessaires à leur réseau. En effet, leur prédiction sous-estime le nombre de ressources nécessaires d’au maximum 5%. Une sous-estimation peut engendrer une violation du SLA. Pour éviter ce problème, ils ajoutent une marge pour avoir toujours un peu plus de ressources disponibles que ce qui est vraiment nécessaire. Cette marge est utile, car même si le trafic sur leur réseau suit régulièrement les mêmes modèles, il reste spontané et une fluctuation peut survenir à tout moment. Leur solution, d’après leurs résultats, ne surestime quasiment pas le nombre de ressources nécessaires au réseau qu’ils gèrent. Le nombre de ressources gaspillées est donc nul.

La différence majeure entre ces solutions et celle que nous cherchons à construire est que leur système gère dynamiquement les ressources d’un nuage informatique en général et que nous nous souhaitons nous concentrer sur la gestion dynamique d’un système IMS virtualisé. À terme, nous souhaitons que les ressources d’un système IMS virtualisé soient adaptées sans intervention humaine et de manière proactive pour garantir une bonne qualité de service aux utilisateurs. Pour cela, nous nous inspirerons des techniques présentées ici afin de construire notre outil de gestion d’un système IMS virtualisé.