Hyperviseur vs Docker. le choc des virtualisations

Transcription

1 Projet n 10 : Hyperviseur vs Docker le choc des virtualisations Master 1 Informatique Étudiants : Belfouz Annas Vandamme Yohan Responsables : Nabitz Sophie Jabaian Bassam Tuteurs : Janod Killian Jean-Valère Cossu Vandamme/Belfouz 1/17

2 Table des matières I Présentation du projet 1 Rappel du sujet 2 Contexte 3 Problématique 4 Second semestre 5 - Planning II - Mise en œuvre III - Bilan 1 Protocole de test 2 Premier algorithme a) Machine native b) Docker c) VirtualBox 3 Deuxième Algorithme a) Machine native b) Docker c) VirtualBox 1 Problèmes rencontrés 2 Capitalisation Conclusion Bibliographie Annexes Vandamme/Belfouz 2/17

3 I Présentation du sujet 1 - Rappel du sujet Hyperviseur vs Docker, le choc des virtualisations Dans le cadre de notre projet de Master nous avons pour objectif d'étudier le comportement des nouveaux outils de virtualisation comme Docker ou Xen dans un contexte extrêmes de calcul scientifique. Ainsi, nous avons comparer les performances entre notre machine physique de référence et nos solutions de virtualisation afin de déterminer la faisabilité d'une application effectuant des calculs scientifiques dans un environnement virtualisé. Pour répondre à cette problématique nous avons découpé le projet en deux parties : La première, réalisé au cours du premier semestre, portait sur l'analyse du sujet et l'élaboration de notre cahier des charges. La seconde, effectué pendant le deuxième semestre, a été consacré à la réalisation de nos protocoles de test afin d'obtenir un benchmarking des différentes solutions. Pour cela, nous avons testé les éléments clés de la machine notamment la consommation de RAM, la charge CPU ou encore la vitesse d'écriture/lecture du disque. Dans ce rapport, nous verrons tout d'abord la planification du projet. Puis nous présenterons les différents tests effectués. Enfin, nous analyserons les résultats obtenu et répondrons à notre problématique. Vandamme/Belfouz 3/17

4 2 - Contexte Dans la conjecture actuelle les entreprises recherchent les économies. De nouvelles technologies émergente permettent de réduire les coûts et le temps d'administration : La virtualisation et le cloud-computing. Ces solutions permettent de faire fonctionner plusieurs systèmes d'exploitation/applications sur une même machine physique ce qui permet d'avoir une mutualisation des ressources mais aussi une meilleure exploitation de celles-ci. De plus elles permettent d'avoir moins de machines physiques et ainsi réduire les coûts matériels. Comme nous avons pu le dire dans la première partie il existe différents types de techniques de virtualisation. Nous avons dans un premier temps l'hyperviseur de type 1 qui est le plus connu dans le milieu professionnel et le plus utilisé. Il s'agit d'un hyperviseur qui s intègre directement sur la couche matérielle ce qui lui permet d'avoir de bonnes performances contrairement à son homologue l'hyperviseur de type 2 qui est installé sur le système d'exploitation de la machine hôte. Par conséquent elle est moins performante à cause de cet empilement, les appels systèmes de la machine virtuelle sont interceptés dans un premier temps par l'hyperviseur puis dans un second temps par le système d'exploitation de la machine hôte. Nous pouvons aussi citer la virtualisation par isolateur qui consiste à isoler les espaces de travail des utilisateurs dans le même niveau que les logiciels de contrôle pour que le tout interagisse avec le système d'exploitation qui nous lit à tout ce qui est hardware. Il existe aussi la virtualisation du noyau en espace utilisateur qui n'est presque pas utilisée, uniquement dans des applications spécifiques notamment pour le temps réel. Vandamme/Belfouz 4/17

5 3 - Problématique Hyperviseur vs Docker, le choc des virtualisations En effet la virtualisation subit un essor de popularité et est de plus en plus utilisée dans les sociétés. Mais dans certains domaines de recherches comme notamment le traitement de la paroles ils travaillent avec des algorithmes qui utilisent des matrices de milliers de lignes et colonnes. Ce qui en conséquence demande beaucoup de puissance de calcul et de mémoire. C'est pourquoi on peut se demander si certaines solutions de virtualisation sont capables de supporter ces algorithmes et donc par la suite d'être éventuellement mis en place pour ce genre de contexte et ainsi avoir les mêmes apports en terme de mutualisations des ressources et d'une meilleure utilisation de celle ci? 4 - Second semestre Le premier semestre a était consacré à l'analyse du problème, c'est à dire comprendre le sujet, réfléchir sur les différentes solutions à tester et l élaboration du cahier des charges. Le deuxième semestre est consacré à la partie réalisation proprement dit, il nous à fallu dans un premier temps réfléchir sur le protocole de test, créer un script qui va permettre de récupérer certaines données que nous exploiterons à la fin. De plus il nous à fallu comprendre le fonctionnement des différents outils de virtualisation et créer des machines virtuelles. Cela va permettre de répondre à la problématique du premier semestre et donc de voir les différences de ces solutions. 5 - Planning Dans un premier temps nous avons décidé de travailler sur la machine native pour voir comment se comportent les différents algorithmes en termes de consommation CPU et d'utilisation de RAM. Permettant ainsi d'avoir un point de comparaison. Vandamme/Belfouz 5/17

6 II Mise en œuvre du projet 1 - Protocole de Test Hyperviseur vs Docker, le choc des virtualisations Pour répondre à notre problématique de départ qui je le rappelle et de voir comment ce comporte les différentes solutions de virtualisation dans un contexte de calcul scientifique. Pour cela nous avons un protocole de test sur différents points comme par exemple le CPU, la mémoire. Comme nous avons pu le voir dans la première partie du projet, nous avons utilisé une solution basé sur Linux «phoronix-test-suite» qui propose de multiple tests. Parmi les divers tests que propose phoronix nous en avons choisi quelques uns qui nous paraissez intéressants à exploiter. Nous avons donc choisi Compress-7zip, qui est un test simple qui permet de tester le CPU. Comme son nom l'indique il va utiliser 7zip pour décompresser un fichier. En effet une compression et une décompression de fichier utilise énormément le CPU donc cela nous parait être un bon test pour avoir des informations sur le CPU. De plus, pour avoir les meilleurs résultats possibles et appuyer les premiers nous avons choisi un second test, qui lui aussi utilise le CPU, il s'agit de n-queens du Français n-dames. l'algorithme des huit dames : «Le but du problème des huit dames est de placer huit dames d'un jeu d échecs sur un échiquier de 8 8 cases sans que les dames ne puissent se menacer mutuellement, conformément aux règles du jeu d'échecs (la couleur des pièces étant ignorée). Par conséquent, deux dames ne devraient jamais partager la même rangée, colonne, ou diagonale.» source : Wikipédia Concernant la consommation de la ram nous avons choisi ramspeed. Ce test va nous permettre de calculer la mémoire vive utilisé. Nous avons aussi tester le disque dur, pour cela nous avons utilisé unpack-linux qui permet de décompresser un fichier se trouvant sur le disque dur de la machine. Permettant ainsi de calculer la vitesse d'écriture/lecture du disque. Pour avoir les meilleurs résultats possibles nous avons effectué des moyennes, c'est à dire que nous avons exécuté tous les tests plusieurs fois pendant le fonctionnement de l'algorithme. Cela permet de moyenner les résultats. Cela est utlile pour ce genre de test, en effet il est vraie que le disque, cpu ou la ram peuvent au moment x être utilisé par un autre processus qui tourne en fond de tâche est qui pourrait fausser les résultats. Comme par exemple une mise à jour. Nous avons aussi voulu avoir l'évolution de la RAM et du CPU sur toute la durée de l'algorithme pour cela nous avons utilisé des commandes Linux existantes comme notamment free qui nous permet d'avoir la consommation de la mémoire vive ainsi que la commande top qui affiche la charge CPU du processeur. Vandamme/Belfouz 6/17

7 Grâce à ces deux commandes nous avons pu créer un petit script (voir annexe p XX) qui nous permet de récupérer grâce à un filtre, uniquement la mémoire utilisé et la charge global du processeur. Tout cela toute les 5 ou 10 secondes, se qui nous a permis de faire un graphe de l'évolution de la mémoire et du CPU pendant toute la durée du script. Cela nous permettre d'appuyer nos résultats précédents, c'est à dire d'analyser le comportement de chaque solution de virtualisation. 2 - Résultats avec le premier algorithme les algorithmes que nous allons utiliser pour exécuter les différents tests nous ont été fournis par nos tuteurs. Il s'agit de programme concernant la reconnaissance vocal qu'ils utilisent dans le cadre de leurs recherches. Le premier algorithme fonctionne sur un seul cœur comparativement au second qui lui fonctionne sur les 4 cœurs disponible du processeur. Nous avons tout d abord regardé l'impact de l'algorithme par rapport à la machine native pour avoir un témoin. Évolution de mémoire sur la machine native Ce graphe nous permet de voir une évolution constante de la mémoire de jusqu'à un peu plus de bits. De plus, nous pouvons apercevoir une chute à la fin du graphique, ce qui constitue bien entendu la fin de l'algorithme. Donc à la libération de la mémoire utilisé par celui-ci. Nous allons maintenant regarder l'impact sur la consommation de cpu. Vandamme/Belfouz 7/17

8 Nous pouvons constater que l'algorithme utilise presque toute les ressources CPU. Évolution du CPU pour la machine native Nous allons à présent regarder l'impact de la solution de virtualisation Docker sur la mémoire et le CPU. Évolution de la mémoire avec Docker Nous pouvons constater une évolution quasi identique de la mémoire mais avec des capacités différents. Contrairement à la machine native nous partons de jusqu'à bits à la fin de l'algorithme. Cela est du au surplus d'utilisation de la mémoire pour Docker, ce qui est l'un des buts du projet de regarder laquelle des solutions de virtualisation sera la moins «gourmande» en mémoire, CPU. Vandamme/Belfouz 8/17

9 ainsi afin d'analyser quelle solution serait «meilleure» dans un contexte de calcul scientifique. Pour la solution VirtualBox nous retrouvons les mêmes évolutions avec la aussi des augmentations au niveau de la charge cpu et de la consommation de ram. Grâce à notre protocole de test nous allons pouvoir mettre à présent appuyer nos graphique par des pourcentages. Résultats du benchmarking : Compress- 7Zip RamSpeed CacheBench Unpack-Linux N-queens Native 100,00% 100,00% 100,00% 100,00% 100,00% Native avec Algorithme 83,50% 88,60% 97,00% 128,00% 133,00% Docker 84,50% 89,30% 95,55% 131,00% 133,84% VirtualBox 52,67% 82,22% 84,81% 251,00% 174,20% XEN EN ATTENTE EN ATTENTE EN ATTENTE EN ATTENTE EN ATTENTE Nous pouvons voir un tableau récapitulatif des résultats obtenus. Dans un premier temps nous pouvons dire que effectivement la solution VirtualBox qui est un hyperviseur de type 2 obtient de fortes baisses comparativement à Docker. Donc nous pouvons déduire à présent, d'après les résultats, que la solution de virtualisation Docker offre des taux de performances relativement proche de la machine physique. Contrairement à la solutions VirtualBox qui admet une perte de performance relativement forte. Vandamme/Belfouz 9/17

10 3 - Deuxième algorithme Hyperviseur vs Docker, le choc des virtualisations Le deuxième algorithme est différent du premier puisqu'il fonctionne sur les 4 cœurs simultanément, ceci va permettre de comparer comment se comporte ce genre d applications dans les différentes solutions de virtualisation par rapport à l'algorithme mono-coeur. Nous pouvons constater l évolution de la ram ainsi que le cpu dans le conteneur Docker. Nous pouvons constater que la ram et le cpu sont régulièrement au maximum de la puissance disponible sur la machine physique. Vandamme/Belfouz 10/17

11 VirtualBox Nous n'avons pas réussi à avoir de résultats avec la solution VirtualBox. En effet après quelques minutes de fonctionnement de l'algorithme nous avons pu constater un arrêt de la machine virtuelle. Nous avons pu émettre deux hypothèses pouvant expliquer ce résultat. Tout d'abord nous avons vu que cette algorithme faisait tourner les 4 cœurs simultanément et à des niveau très élevé ainsi que la RAM. Donc nous avons pu en déduire qu'une fois la mémoire de la machine virtuelle remplie la machine physique devait libérer sa mémoire et donc couper la VM. Il est possible de tester cette hypothèse en diminuant le nombre de fork de 4 à 3, 2 ou 1 pour voir si la machine continue de se couper. Il y a une seconde hypothèse possible qui proviendrait du processeur qui coupe directement la machine virtuelle si elle reçoit un appel système incorrect. De plus il est intéressant de constater que Docker malgré une consommation de ram régulièrement à 100% ne swap pas le container. Ce qui nous permet de dire que Docker à une meilleure gestion de ressources. Résultats des tests pour le deuxième algorithme Native avec Algorithme Compress-7Zip RamSpeed CacheBench Unpack-Linux N-queens 7023MIPS 10485,46MB/s 2760,78MB/s 109,17s Docker 8932MIPS 9678,19MB/s 2420,25MB/s 15,90s 102,53s VirtualBox x x x x x XEN EN ATTENTE EN ATTENTE EN ATTENTE EN ATTENTE EN ATTENTE 1 - Points forts et critiques sur les différentes solutions de virtualisation D'après les résultats obtenus nous pouvons constater les différents points forts et faibles de ces diverses solutions de virtualisation. Nous pouvons dire tout d'abord que la solutions virtualbox n'est pas fait pour des applications avec de fortes demande d'accès disque mais permet toutefois d'avoir des applications avec des accès ram régulier. Quant à Docker elle parait être la solution parfaite que ce soit sur les accès disque, ram ou cpu. Cette solution peut donc être utilisé dans la plupart des applications. Vandamme/Belfouz 11/17

12 III - Bilan 1 - Problèmes rencontrés Au cours de ce projet, nous n'avons pas pu remplir l'intégralité de nos objectifs définis dans le cahier des charges du premier semestre et pour cause nous avons rencontrés divers problèmes. Tout d'abord un problème technique qui faisait que la machine se coupait de manière permanente. Ce qui ne nous permettez plus de faire nos travaux sur la machine, malgré la réactivité de nos tuteurs les week-end elles ne pouvait être rallumé, la machine étant distante. Ce qui nous à été pénalisant pour l'avancé de notre projet et donc du respect des délais prévisionnels. Malgré les efforts pour récupérer notre retard sur le planning nous avons rencontré un autre problème lors de l'installation de xen. Ce qui ne nous a pas permis de rendre les résultats de xen pour ce rapport, Nous avons donc plusieurs jours de retard dans notre planning. De plus nous avons eu un problème sur la récupération des données dans le script. Nous avons fait un grep (qui permet de trouver un mot dans un fichier texte) sur la commande top pour récupérer uniquement la charge CPU de l'algorithme. Dans un premier temps nous avons mis le nom complet du processus (svm_multiclass_ ou speeral_bin selon l'algorithme testé) mais nous nous sommes rendu compte que sur les machines virtuelles selon la taille de la fenêtre le nom complet du processus ne pouvait être inscrit et donc ne nous permettez pas d'avoir les données voulues. Nous avons donc décidé de filtrer uniquement sur les premières lettres du processus (svn ou spee). 2 - Capitalisation Au cours de ce projet nous avons pu développer nos compétences sur divers points, que ce soit sur la technique ou sur la gestion d'un projet. Tout d'abord, à travers ce projet nous avons pu appréhender la complexité d'un tel projet, en effet, ce projet était complet avec dans un premier temps une phase d'étude et de recherche sur la virtualisation et ses différentes techniques ainsi que les différentes solutions existantes. Puis une deuxième phase de mise en œuvre des différentes solutions de virtualisation ainsi que l'exécution d'un protocole de test. Nous pouvons même dire une troisième partie d'analyse des différents résultats obtenus. De plus nous avons pu voir la difficulté du reporting au cours d'un projet de ce type. Il est vraie que le temps de travail à fournir pour ce genre de projet et le temps qui nous est alloué, il est important d'avoir des réunions régulières avec les membres du projets pour permettre des échanges constructifs. En effet cela permet de régler certains problèmes ou de penser différents sur les tâches à effectuer avec des points de vues possédant un certain recul. Vandamme/Belfouz 12/17

13 Tout ceci nous permet donc d accroître nos compétences dans le domaine de la gestion de projet, avec la création d'un cahier des charges par rapport à un sujet pré-définis, la planification des différents travaux à faire, la rédaction de compte rendu de réunion... De plus nous avons pu accroître nos connaissances sur les nouvelles techniques de virtualisation notamment sur Docker, qui est une nouvelle solution qui fait beaucoup parler d'elle du fait de sa simplicité et de ses grandes capacités. Ce projet à donc été bénéfique sur tous les points de vues malgré une légère déception du non respect des délais. Vandamme/Belfouz 13/17

14 Conclusion A travers ce projet que nous avons eu la chance de mener dans le cadre de notre master informatique à l'université d'avignon. Nous avons pu appréhender dans un premier temps tout se qui porté sur la gestion de projet et nous a permis de mettre en application notre savoir sur ce domaine. De plus nous avons pu étudier et comprendre les enjeux de la mise en place des solutions de virtualisation et pourquoi il était important de regarder leurs performances. Ainsi nous avons pu constater que toute les solutions n'avaient pas les mêmes performances et n étaient pas faites pour les mêmes applications. Par rapport aux différentes solutions que nous avons testé, à savoir Docker, VirtualBox et Xen. Nous pouvons dire que Docker admet les meilleurs performances et offre une grande simplicité de mise en œuvre. En revanche VirtualBox admet de fortes pertes de performances par rapport à la machine native. C'est pourquoi cette solution n'est pas utilisée en production mais plutôt pour tester des nouveaux systèmes d'exploitations ou autre. Nous pouvons à présent grâce aux résultats obtenues dire que Docker parait être la solution qui permet d'avoir des capacité relativement proche d'une machine physique dans un contexte de calcul scientifique. En effet nous avons une utilisation de la ram et du cpu qui est presque identique à la consommation de la machine physique. Docker va t-il devenir la solution de virtualisation de référence? Nous avons respecté notre cahier des charges mais il est tout à fait envisageable de l'améliorer. En effet il existe de nombreuses solutions de virtualisation qu'il serait intéressante de tester et de comparer leurs performances par rapport à celles déjà testé. Vandamme/Belfouz 14/17

15 Bibliographie Nous nous sommes aidé de plusieurs sites internet pour pouvoir comprendre et déployer un conteneur Docker. Pour pouvoir comprendre le fonctionnement de l'outil de benchmarking que nous avons utilisé nous avons utilisé ce site internet. Vandamme/Belfouz 15/17

16 Annexes 1 - Déploiement d'un conteneur Docker. Comme on a pu le dire Docker est un outils relativement simple à utiliser et permet un déploiement rapide d'un conteneur. Première étape : Installation sudo apt-get install docker.io Deuxième étape : récupération d'une image de base docker pull ubuntu Troisième étape : Lancement de l'image docker run id-image Quatrième étape : enregistrement du conteneur pour créer une nouvelle image docker commit id-image nom-du-conteneur Ensuite pour relancer le conteneur avec avec une console il suffit de taper la commande suivante : docker start -i id-image ou nom-du-conteneur Pour stopper le conteneur il faut remplacer start par stop. Si nous voir les conteneurs disponible la commande docker ps -a peut être utile ou docker ps si nous voulons savoir les conteneurs actifs. 2 Résultats obtenus pour le premier algorithme Compress-7Zip RamSpeed CacheBench Unpack-Linux N-queens Native MIPS 12690,01MB/s 3129,41MB/s 7,90s 61,60s Native avec Algorith me MIPS 11243,79MB/s 3036,17MB/s 10,12s 82,44s Docker MIPS 11333,11MB/s 2990,31MB/s 10,42s 82.45s VirtualBo x 7472MIPS 10433,99MB/s 2654,21MB/s 19,84s 107,30s XEN EN ATTENTE EN ATTENTE EN ATTENTE EN ATTENTE EN ATTENTE Vandamme/Belfouz 16/17

17 3 Script de récupération de la ram et du cpu. Hyperviseur vs Docker, le choc des virtualisations Vandamme/Belfouz 17/17