Hypothèses

Dans notre étude, nous faisons l’hypothèse qu’il existe une corrélation entre les valeurs relevées au niveau des ressources et au niveau service. Afin de trouver cette corrélation, nous faisons également l’hypothèse que les valeurs relevées en temps réel traduisent bien l’état du réseau et des ressources. Nous restons cependant conscients que les ordinateurs exécutent souvent en tâches de fond et sans prévenir des processus, mais ces derniers consomment une quantité de ressources négligeable face à celles consommées par notre système IMS comme nous pouvons le voir sur la figure 3.1. Par ailleurs, dans le cas où notre système ne relèverait pas de valeur à une seconde donnée pour une métrique précise, nous faisons l’hypothèse que nous pouvons utiliser le résultat de la seconde précédente. Cette hypothèse se justifie par le fait que le nombre d’appels par seconde ne varie pas brutalement et donc que le système ne doit pas non plus évoluer soudainement (à chaque seconde). Une valeur prise à la seconde précédente doit donc être proche de celle que l’on aurait obtenue.

Figure 3.1 Vue des ressources consommées quand notre système IMS est éteint

Grâce à l’outil de visualisation des ressources de Linux, nous pouvons observer sur la figure 3.1 que le système au repos n’utilise que le cœur 1 (CPU1) de la machine pour fonctionner comme nous l’avons contraint à le faire.

Nous faisons également l’hypothèse que les entrées/sorties ne sont pas à prendre en compte, car elles ne sont pas sollicitées par notre système IMS. Les données sur la mémoire de la machine hôte ne seront pas non plus analysées, car cette ressource est abondante dans notre système. En effet, lors d’analyses préliminaires, nous observons que, dans le pire cas simulé, les conteneurs ne consomment que 10% de la mémoire disponible. Nous avons donc donné aux conteneurs un accès illimité à la mémoire de l’ordinateur.

Nous ferons aussi l’hypothèse que nos outils de télémétrie n’empêchent pas le système de bien fonctionner et que les ressources qu’ils consomment eux même pour réaliser les tâches qui leur sont demandées n’ont pas d’impact sur les simulations. Pour satisfaire à cette hypothèse, nous ne pouvons pas utiliser le premier outil de télémétrie pour les ressources du système que nous avons développé. En effet, comme expliqué dans la section 2.3.1, celui-ci utilise l’outil TShark qui est trop lent. Lorsque nous simulons beaucoup d’appels, nous sommes donc confrontés à deux problèmes : avoir des données en temps réel et avoir des

données exhaustives. Pour avoir les données en temps réel, cela nécessite de suivre en temps réel l’échange de messages sur le réseau, mais l’outil n’a pas le temps de tout analyser et dans le cas où le nombre d’appels est important il nous en manque et les résultats sont erronés. Pour avoir des données exhaustives, il faut récupérer tous les messages échangés, mais dans ce cas, le relevé ne se fait plus en temps réel, il peut nous falloir plusieurs minutes pour relever une seule seconde de la simulation. De plus, pour s’exécuter et récupérer tous les messages, cet outil consomme énormément de ressources CPU créant une famine pour les conteneurs.

Figure 3.2 Comparaison des relevés du nombre de messages RINGING reçus dans le cas temps réel ou non

La comparaison entre les relevés des messages RINGING reçus en temps réel ou non est illustrée à la figure 3.2. Le relevé dit fiable, qui permet de collecter toutes les valeurs, a été réalisé en presque 8 heures alors que la simulation ne dure que quelques minutes. L’outil de télémétrie haut niveau avec TShark ne sera donc utilisé que dans notre phase d’analyse préliminaire du système IMS virtualisé pour apprendre à mieux l’appréhender. Nous

0 200 400 600 800 1000 1200 1400 11:41:29 cps et nombre de messages seconde cps expected

Nombre de messages ringing recu - relevé fiable Nombre de messages ringing recu - relevé en temps réel 0 234

utiliserons ensuite, comme mentionné à la section 2.3.1, les valeurs du CPS fournies par le simulateur. L’outil de monitorage des ressources bas niveau a été, quant à lui, exploité, car il ne consomme qu’une quantité raisonnable de ressources comme nous pouvons le lire sur la figure 3.3.

Figure 3.3 Vue des ressources consommées par l'outil de télémétrie bas niveau

Grâce à l’outil de télémétrie de Linux, nous pouvons visualiser les ressources CPU consommées par l’outil de monitorage développé. Cette consommation est, en partie, due au fait qu’une requête est envoyée chaque seconde à chaque conteneur pour leur demander les ressources qu’ils utilisent au niveau du CPU, de la mémoire et de la bande passante. Pour remplacer l’outil de monitorage système, nous avons inclus à celui-ci une fonction qui va lire le fichier log du simulateur de trafic, car ce dernier enregistre aussi le nombre d’appels simulés qui n’a pas abouti.

Pour finir, à la fin de chaque simulation, nous calculons le coefficient de Spearman qui lie les différentes métriques deux à deux. La corrélation de Spearman est utilisée pour étudier la relation entre deux variables qui ne suivent pas une loi normale. Cette méthode ne se base pas sur les valeurs exactes des variables analysées mais sur le rang de ces valeurs. La corrélation de Spearman permet donc de mesurer l’intensité de la liaison entre les deux

Système au repos Outil de télémétrie bas niveau lancé

variables analysées. Nous faisons l’hypothèse que ce résultat peut être exploité et n’est pas biaisé par l’influence des autres métriques sur celles que nous avons choisies d’étudier.