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

2 Sommaire Projet n 10 : Hyperviseur vs Docker, le choc des virtualisations Introduction...3 Planification du projet...4 Description du projet...5 Objectifs...5 Enjeux...5 Travail à réaliser...5 I Analyse technique A) La virtualisation...6 B) Les différents types de virtualisations...7 1)Hyperviseur de type )Hyperviseur de type ) Isolateur...9 4) Noyau en espace utilisateurs...10 C) Les Différentes solutions de virtualisations ) Xen ) KVM ) Docker ) OpenVZ ) VirtualBox ) Vagrant ) Adeos...16 II Le benchmarking...18 Bilan...21 Glossaire...22 Bibliographie...23 Indice des figures...24 Belfouz/Vandamme 2/24

3 Introduction : Les systèmes de virtualisation sont de plus en plus présents pour industrialiser l informatique. D abord exploités pour mutualiser les ressources et faciliter la vie des administrateurs système. Aujourd hui toutes les facettes de l informatique sont confrontées aux machines virtuelles. Les développeurs grâce à Vagrant travaillent facilement avec des environnements réplicables et normalisés. On peut démarrer un nouveau serveur et lancer de nouveaux services en quelques secondes avec les infrastructures cloud-computing moderne. Pourtant tous ces outils ont un coût non négligeable en termes de performances. Les hyperviseurs qui managent toutes ces machines ont des besoins en ressources aussi. Les systèmes de fichiers virtuels sont réputés pour être plus lent qu un système natif. La question auquel tentera de répondre ce projet est : «Comment se comportent ces outils modernes face aux conditions extrêmes du calcul scientifique» L enjeu est de proposer un mécanisme de mesure des performances et de l impact des nouveaux acteurs de la virtualisation (comme Docker et Vagrant) par rapport à la concurrence et à un environnement non virtualisé pour des applications scientifiques. Pour essayer de répondre à cette question nous allons déjà décrire la virtualisation, puis nous fairons une description des avantages et inconvénients des différents types (quatre au total) de virtualisation. Nous verrons par la suite quelques solutions (les plus connus et les plus pertinentes) dans chaque partie avec leurs avantages et inconvénients. Puis nous terminerons par étudier ce qu'est le benchmarking et voir si il existe des outils. Belfouz/Vandamme 3/24

4 Planification du projet Projet n 10 : Hyperviseur vs Docker, le choc des virtualisations Comme pour tous projets nous avons séparé celui ci en plusieurs parties d'études, avec les différentes personnes participant à ce travail. Le semestre 1 a été consacré à la recherche, dans un premier temps sur la virtualisation au sens large, ensuite sur les différents types de technologies existantes avec leurs différences, avantages et inconvénients. Nous avons aussi étudié des solutions de virtualisation dans chaque type, puis nous travaillé sur le benchmarking. Nous avons utilisé un logiciel libre Gantt project pour planifier notre projet, ce qui nous a permis de faire le point de temps en temps avec notre tuteur et de voir si nous étions dans les temps par rapport à nos prévisions. Figure 1 : Gantt project semestre 1 Le semestre 2 sera plus consacré à la pratique. Nous aurons dans un premier temps à déterminer un protocole de test, puis dans un second temps mettre en place et tester toutes les solutions de virtualisation, avec l'algorithme de calcul en place et le protocole de benchmarking. Et pour finir nous aurons à analyser toutes les données pour répondre à notre problématique de base qui est de savoir comment se comporte les solutions de virtualisation et de voir si il y en a une qui se rapproche des performances d'une machine native dans un contexte de calcul extrême. Figure 2 : Gantt project semestre2 Belfouz/Vandamme 4/24

5 Description du projet Projet n 10 : Hyperviseur vs Docker, le choc des virtualisations Le projet «hyperviseur vs Docker, le choc des virtualisations» est un projet proposé par Mr Janod et Mr Cossu. Ce projet consiste dans un premier temps à comprendre «la virtualisation», voir quels sont les solutions les plus répandus, étudier leurs avantages et leurs inconvénients. Dans un second temps tester plusieurs solutions et les étudier dans un contexte de calcul scientifique grâce à un banc d'essai que nous aurons préalablement défini, pour voir certains points critiques du système. Cela nous permettra d'étudier le comportement de ces solutions dans ce genre d'applications et de voir si une solution est «meilleure» que les autres dans ce type de cas. Objectifs les objectifs finaux sont multiples, dans un premier temps tester les différentes solutions de virtualisation dans un contexte de calcul scientifique pour savoir quelle est la solution qui se rapproche le plus des capacités d'une machine dite «native» non virtualisé à capacité équivalente. Cela doit permettre de déterminer si oui ou non certaines solutions peuvent être utilisées dans des applications de calculs scientifiques. De plus cela nous permettra de voir aussi quels sont les points faibles et forts de chaque solution. Nous savons déjà quelles sont les meilleures solutions pour telle ou telle applications mais pas encore pour le calcul scientifique. Enjeux Nous avons déjà les enjeux pédagogiques du projet, puis nous avons surtout, je pense des enjeux économiques, nous savons déjà que la virtualisation permet de faire des économies en administration, mais aussi en énergie. Donc si les résultats sont concluants et que nous trouvons une solution de virtualisation qui permet d'avoir des performances presque aussi bonnes que celle d'une machine native dans un contexte de calcul scientifique. Nous pourrons dans ce cas la mettre en place pour faire du calcul scientifique et donc faire des économies. Travail à réaliser Le projet se déroule en deux semestre donc nous avons réparties les taches de travail selon deux axes, le premier qui a duré tout un semestre, qui concerne tout se qui est de la recherche sur la virtualisation, les avantages et inconvénients de cette technologie, les différents types de virtualisation avec leurs différences. Ils nous faut aussi proposer un protocole de test pour un benchmark que nous utiliserons dans la seconde phase du projet. La deuxième phase du projet qui va se dérouler au second semestre va consister de tester les différentes solutions de virtualisation que nous avons choisi et par la suite les faire fonctionner dans un contexte de calcul scientifique et obtenir des résultats sur différents points du système, que nous comparerons par la suite avec les données de toutes les solutions que nous avons testées pour essayer de répondre à la question de départ qui est «Comment se comportent ces outils modernes face aux conditions extrêmes du calcul scientifique?». Belfouz/Vandamme 5/24

6 I Analyse technique A) La virtualisation Dans un premier temps on va commencer par définir la virtualisation, quels sont les avantages et inconvénients de cette technologie. Pour cela nous allons tout simplement prendre la définition de wikipédia : «La virtualisation consiste à faire fonctionner un ou plusieurs systèmes d'exploitations/ applications comme un simple logiciel, sur un ou plusieurs ordinateurs - serveurs / système d'exploitation, au lieu de ne pouvoir en installer qu'un seul par machine.» Depuis plusieurs années la virtualisation est utilisée dans les entreprises pour virtualiser les serveurs/applications ou les postes de travail, cela a de multiples avantages comme notamment de simplifier l'administration des systèmes d'informations (car nous avons tout sur une ou quelques machines physiques), de diminuer les coûts économiques et énergétiques à long terme mais aussi d homogénéiser le système d'information. Mais comme tout, il y a des inconvénients avec le principal, qui est que si la machine tombe en panne c'est toutes les machines virtuelles de celle ci qui tombent en même temps. C'est pourquoi il est impératif de mettre en place des solutions de duplication dans ce genre de technologies. Figure 3 :La virtualisation Il existe différentes formes de virtualisation que nous allons étudier, comparer et voir quelle technologie utilise chaque forme. Nous notons quatre grands types de virtualisation : L'isolateur, le noyau en espace utilisateur et les Hyperviseurs de type 1 et 2. Le premier type de virtualisation que nous allons voir est l'hyperviseur de type 1 : Belfouz/Vandamme 6/24

7 B) Les différents Types de virtualisation 1. Hyperviseur de type 1 Un Hyperviseur de type 1 est un système de virtualisation beaucoup plus léger que le serait un hyperviseur de type 2. A la différence de son homologue de type 2 ce logiciel s exécute directement sur la couche matérielle. Il s'agit d'un noyau hôte allégé et optimisé pour la virtualisation. Sur des processeurs ayant les instructions de virtualisation matérielle (AMD-V et Intel VT) l'hyperviseur n'a plus à émuler les anneaux de protection et le fonctionnement s'en trouve accéléré. On peut également intégrer ce type d'hyperviseur dans le firmware de la plateforme. Les machines virtuelles utilisant un noyau Linux KVM, qui transforment un noyau Linux complet en hyperviseur, sont également considérées comme hyperviseurs de type 1. Exemples d'hyperviseur de type 1 "KVM (libre), Oracle VM (en), Citrix Xen Server (libre), VMware vsphere (anciennement VMware ESXi et VMware ESX)." Figure 4 : Hyperviseur de type 1 Avantages : -Os invité reste relativement proche du matériel et peut donc conserver des performances proches d'un système natif. -Isolation complète -Os complet Inconvénients : -lourdeur de mise en œuvre et de gestion -overhead moyen l'overhead est le temps passé par un système à ne rien faire d'autre que se gérer. Belfouz/Vandamme 7/24

8 2. Hyperviseur de type 2 Projet n 10 : Hyperviseur vs Docker, le choc des virtualisations Un Hyperviseur de type 2 est un logiciel assez lourd permettant de virtualiser un ou plusieurs OS invités à partir d'un OS hôte. Cette méthode permet aux OS virtualisés d'accéder directement au matériel (à l'inverse des émulateurs qui doivent simuler l unité centrale de calcul). L'avantage de cette solution est l'isolation des OS invités de l'os hôte, en contrepartie le coût en performance est peu élevé. Cette isolation permet à tous les OS( hôte et invité(s) ) d'être hétérogènes. Tous ces OS peuvent communiquer avec des réseaux virtuels. Pour cela l'hyperviseur peut émuler plusieurs cartes réseaux sur la carte réseau réelle. Exemples d'hyperviseur de type 2 "logiciels libres (QEMU : émulateur de plateformes x86, PPC, Sparc, etbochs : émulateur de plateforme x86). Oracle VM VirtualBox (libre), logiciels VMware (VMware Fusion, VMware Player, VMware Server, VMware Workstation)," Figure 5 : Hyperviseur de type 2 Avantages : -OS complet (avec son noyau) et non modifié. -Isolation complète -Permet d'utiliser des OS rapidement, temporairement ou non Inconvénients : -Lourdeur de mise en œuvre et de gestion -Overhead «monstrueux» Belfouz/Vandamme 8/24

9 3. l'isolateur : Projet n 10 : Hyperviseur vs Docker, le choc des virtualisations l'isolateur tel que dans Docker, Linux-Vserver, chroot ou OpenVZ est un logiciel permettant d'isoler l'exécution des applications dans des contextes ou zones d'exécution, et donc faire tourner plusieurs fois la même application dans un mode pluri-instances même si au départ l'application n'est pas vraiment conçue pour cela. Le principe de l'isolation est très simple, il 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. Figure 6 : Isolateur Avantages : -Simple, rapide à mettre en œuvre -Peu d'overhead -Meilleur gestion des ressources(cpu, disque...) Inconvénients : -Un seul noyau -Nécessite une couche de sécurité (SELinux,APPArmor) Belfouz/Vandamme 9/24

10 4. Noyau en espace utilisateur Exécuté comme une application en espace utilisateur de l'os hôte. C'est à dire que le noyau de ce dernier tourne en mode privilégié et contrôle l'accès aux éléments matériels (clavier, écran, périphériques...) de la machine hôte. Le noyau en espace utilisateur a donc son propre espace utilisateur, son propre système de fichiers et il contrôle ses propres applications. Il possède donc son propre espace utilisateur dans lequel il contrôle ses applications par conséquent ce type de virtualisation est très peu performant à cause de l'empilement de 2 noyaux. Au sein de la machine virtuelle les appels systèmes pour l accès aux matériels sont interceptés par le noyau espace utilisateur et délégués au noyau de la machine hôte donc cela prend plus de temps. On peut citer: User Mode Linux : noyau tournant en espace utilisateur Cooperative Linux ou colinux : noyau coopératif avec un hôte Windows Adeos : micro noyau RT faisant tourner Linux en kernel-space non-rt L4Linux : micro noyau RT faisant tourner Linux en kernel-space non-rt Figure 7 : Virtualisation en espace utilisateur Inconvénients : -Isolation non gérée -peu performant Belfouz/Vandamme 10/24

11 c) Les différentes solutions de virtualisations. Maintenant que nous avons vu les différents types de virtualisation possible avec leurs avantages et inconvénients nous allons pouvoir étudier les différentes solutions existantes de chacun des types. Nous allons par la suite pouvoir faire un tableau comparatif de ces solutions. Nous allons commencer par les solutions de virtualisation par hyperviseur de type I qui sont KVM et XEN, ensuite nous verrons les solutions par hyperviseur de type II avec VirtualBox on parlera après des solutions par isolateur OpenVZ, Docker et Vagrant et nous terminerons par Adeos qui est une solution de virtualisation par noyau en espace utilisateur. 1 Xen Xen est un hyperviseur de type I «bare metal» qui est exécuté juste au dessus du matériel comme nous l'avons expliqué dans la partie concernant l'hyperviseur de type 1. Cela lui permet d'avoir un accès au ressources système (CPU, IO, RAM...) maximal. Il regroupe certaines fonctions qu'on retrouve dans tous les OS (ordonnanceur, un gestionnaire d'interruption...). Dans une solution de virtualisation de type hyperviseur une machine virtuelle appelée «domain 0» qui est un OS complet dont le noyau est complètement modifié pour communiquer avec l'hyperviseur et qui permet de gérer toutes les autres machines virtuelles. Les domu peuvent être paravirtualisés (ParaVirtualized PV) ou matériellement virtualisés (Hardware-assisted Virtualized Machine HVM). La paravirtualisation implique que le noyau de l OS de la machine virtuelle doit être modifié afin de coopérer avec l hyperviseur pour l accès aux ressources physiques. En pratique lorsqu une machine est paravirtualisée, c est le dom0 qui effectue les opérations d E/S au profit de la VM puis lui «retourne» les résultats. C est pourquoi il faut toujours s assurer que le dom0 possède suffisamment de mémoire vive et de ressource CPU pour opérer correctement en faveur des VM. La virtualisation matérielle ne nécessite pas de modifications de l OS invité car le CPU, au travers d un jeu d instructions spéciales (Intel VT-d ou AMD-V), fait croire au système invité (la VM) qu il a un accès direct au matériel. Cependant, cela entraîne un surcoût de fonctionnement car certaines demandes d accès aux ressources physiques effectués par la VM doivent être interceptés pour vérifier qu elles n affectent pas les autres VM. Figure 8 : Architecture de l'hyperviseur XEN Belfouz/Vandamme 11/24

12 Architecture de XEN : relation entre hyperviseur, systèmes hôte et invités Les performances des opérations d E/S des VM paravirtualisées sont significativement meilleures que celles des VM HVM. Les machines virtuelles Windows, dont le noyau ne peut être modifié, sont nécessairement HVM. Cependant, pour améliorer les performances de ces VM, des drivers additionnels peuvent être installés après le système d exploitation «de base», ces drivers étant spécialement optimisés pour être exécutés dans un contexte virtualisé. On parle alors de «PV on HVM» et les performances, comparées à la paravirtualisation, sont similaires. 2 KVM KVM pour Kernel Virtual Machine est une autre technologie de virtualisation Open Source et est distribuée sous licence GPLv2 ou LGPL. A l origine fork de l émulateur QEMU, les deux projets sont régulièrement synchronisés et la partie spécifique à KVM se concentre sur l accélération matérielle des VM (profitant des jeux d instructions des CPU) et sur l intégration dans le noyau Linux. Le module noyau KVM est disponible nativement dans le noyau Linux depuis février 2007 Architecture KVM L architecture de KVM est très différente de celle de Xen. KVM est disponible sous forme de module Linux, intégré au noyau Linux. Le processus de démarrage du serveur hôte n est pas modifié par la présence de KVM et une machine virtuelle se résume à un processus Linux comme un autre. On peut comparer KVM à Virtualbox ou VMWare Workstation (hyperviseur de «type 2 ), à ceci près que, bien que l administration de l hyperviseur se fait depuis «l espace utilisateur» (user-land), la machine virtuelle elle-même tourne en espace noyau (kernel-land). Architecture simplifiée de KVM : relation entre hyperviseur, systèmes hôte et invités KVM ne supporte pas la paravirtualisation donc nécessite une CPU avec le support de la virtualisation matérielle. Pour obtenir des performances d E/S satisfaisantes pour les VM HVM, KVM profite de l intégration native des pilotes VirtIO (Virtual IO) dans le noyau Linux depuis la version (avril 2008). Ces pilotes sont optimisés pour un contexte de virtualisation (PV on HVM). On profite ainsi de la facilité de la virtualisation complète (inutile de modifier le système invité) avec les performances de la paravirtualisation. Évidemment comme les drivers VirtIO ne sont pas intégrés d office dans Microsoft Windows, ainsi comme c est le cas pour Xen, il faudra les mettre en place a posteriori d une installation d une VM Windows. Bien qu il existe des implémentations de KVM pour *BSD, KVM est d abord développé pour Linux. Toutes les distributions majeures de GNU/Linux supportent KVM. Belfouz/Vandamme 12/24

13 3 Docker Docker est une solution de virtualisation de type isolateur basé sur des containers. Contrairement aux systèmes qui proposent une couche d'abstraction au-dessus d'un système physique comme par exemple (VirtualBox, Xen, KVM...) qui permet de simuler une machine physique, les containers virtualisent l'environnement d exécution de l'os et non pas le système dans son ensemble. Il s'agit d'un ensemble applicatifs s exécutant au sein du système hôte de manière virtuelle et isolée et contrainte (jails, chroot...). Le container est très performant et très léger du fait qu'il partage de nombreuses ressources avec la machine hôte (kernel, devices...). En revanche il est considéré comme peu sécurisé du fait qu'il partage la stack d exécution avec l'os hôte. 4 OpenVZ Figure 9 : Containers vs VMs OpenVZ est une solution de virtualisation pour linux qui fait un partitionnement logique au niveau des ressources du système : processeurs, réseau et «file system». C'est le noyau du système d'exploitation hôte qui fait une isolation entre les machines logiques, tout comme on isole déjà les processus entre eux. Chaque machine virtuelle est sous le seul contrôle du noyau de la machine hôte et à accès des ressources isolées dans un contexte Belfouz/Vandamme 13/24

14 -file system, CPU, adresse réseau et mémoire sont exécuté dans un contexte système particulier. Concrètement, un container openvz fonctionne par un système de contexte supplémentaire ajouté à chaque processus. C'est un système de virtualisation léger et peu intrusif. La machine physique démarre le noyau Linux. Tous les processus lancés par ce noyau (à partir d'init) le sont avec un contexte CT0, celui dédié à la machine hôte. => les machines virtuelles n'ont PAS de noyau Les principales fonctionnalités d'openvz est sa capacité à accueillir des centaines d'environnements virtuels ( les limitations principales sont la quantité de mémoire vive et le nombre de processeurs). Sa gestion de masse, le propriétaire (root) du serveur physique OpenVZ peu voir tous les processus et les fichiers des VM ce qui permet de faire de la gestion de masse comme par exemple faire tourner un simple script qui mettra à jours toutes les Vms. Contrairement aux autres technologies de virtualisation «pur» OpenVZ est moins flexible, il ne peut utiliser qu'un simple «patched Linux Kernel» et ne peut fonctionner que sous un système Linux. Tous les containers partagent la même architecture et la version du kernel. Il est toutefois très rapide et efficace du fait de la non surcharge d'un véritable hyperviseur. 5 VirtualBox VirtualBox est une solution de virtualisation de type hyperviseur de type 2 c'est à dire fonctionnant sur le système d'exploitation de la machine hôte. Il permet de créer des machines virtuelles rapidement sur une machine hôte d'architecture x86 et AMD64/Intel64 sur des systèmes d'exploitations Windows, Linux et Macintosh. VirtualBox possède de nombreuses caractéristiques comme : -portabilité -pas de matériel avec appels système pour la virtualisation. -supporte le partage de fichier et la 3D -supporte de vaste matriel -Guest multiprocessing (SMP) -USB device supportent -Full ACPI support -Multiscreen resolutions -built-in iscsi support -Multigeneration branched snapshots -VM groups Pour en savoir plus : Belfouz/Vandamme 14/24

15 6 Vagrant Vagrant permet d'offrir de manière simple avec un fichier de configuration et un ensemble de commande de définir le système utilisé et sa configuration souhaitée. Le principal avantage de vagrant est qu'il repose uniquement sur un fichier de configuration qui permet de définir le les configurations voulus. Les autres avantages de vagrant sont sa simplicité, la portabilité des VM, légèreté par rapport aux VM classiques et sa facilité de duplication et de reproduction d'un environnement autant de fois que l'on souhaite. Vagrant repose sur des boxes qui sont les OS qui sont utilisé s pour la virtualisation (ici VirtualkBox). Vagrant possède de nombreuses boxes toutes prêtes ce qui permet une installation rapide. Figure 10 : Vagrant Belfouz/Vandamme 15/24

16 7 Adeos (Adaptative Domain Environnement for Operating System) Adeos est une couche de virtualisation de ressources matérielles permettant de faire cohabiter plusieurs noyaux sur une même machine physique. Il permet aussi contrairement aux autres logiciels de virtualisation d'ajouter des fonctionnalités temps-réel notamment avec Xenomai qui est un noyau linux temps-réel juxtaposé sur un noyau linux. Adeos repose sur l'utilisation d'un pipeline d interruptions, nommé «I-pipe» pour «interrupt pipeline». Figure 11 : Adeos pipeline Chaque domaine possède une priorité plus ou moins grande, si nous prenons par exemple le kernel Xenomai il aura une priorité élevé puisque qu'il a certaines contraintes de temps réel. Pour ce faire, toutes les interruptions sont envoyés dans le pipeline dans lequel chaque domaine est mis en queue selon leur priorités. Pour en savoir plus sur Adeos: 152/Virtualisation-et-systemes-embarques-l-exemple-ADEOS Belfouz/Vandamme 16/24

17 Tableau comparatif des différentes solutions Docker Linux conteneurs, LXC OpenVZ Xen KVM VirtualBox Vagrant Développeur Solomon Hykes,Docke r, Inc. même que kernel (Intel, IBM, Parallels) Parallels (ex. SwSoft) Citrix XenSour ce, RedHat Oracle Corporation Mitchell Hashimot o et John Bender Disponibilité depuis mars 2013 partiellement dans le noyau partiellemen t dans le noyau kernel partielle ment dans le noyau depuis 2012 (client Kernel ) depuis 2007 ( Kernel ) Première version, janvier 2007 État stable Problèmes de réseau, disque Matériel même que Linux même que Linux identique à la virtualisatio n sous Linux stable stable stable stable En développe ment actif seulemen t nombre fixe de matériel, voir HCL identique à la virtualisatio n Linux x86 and AMD64/Intel 64 Type Gestionnaire de containers Os level virtualisation, de la conteneurisation Os level virtualisatio n, de la conteneurisa tion la virtualisa tion complète, paravirtu alisation la virtualisatio n complète Virtualisation de type 2 Gestionna ire de containers OS Linux Linux Linux Linux, FreeBSD, Windows Linux, FreeBSD, Windows Linux, Windows, Macintosh Linux, Mac, Windows Figure 12 : Tableau comparatif Belfouz/Vandamme 17/24

18 II Le Benchmarking Tout d'abord avant de commencer à définir les différentes solutions que nous allons traiter, nous nous posons la question qu'est ce qu'un Benchmark? Selon Wikipédia, «un benchmark est un point de référence servant à effectuer une mesure. Le terme vient du vocabulaire professionnel des géomètres, et désigne à l'origine un repère de nivellement. En français, il désigne plusieurs choses. En informatique, un benchmark est un banc d'essai permettant de mesurer les performances d'un système pour le comparer à d'autres.» Il existe un ensemble de tests possibles que voici : (liste provenant de wikipédia). Test de charge : il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs virtuels prédéfinis, afin de valider l'application pour une charge attendue d'utilisateurs. Ce type de test permet de mettre en évidence les points sensibles et critiques de l architecture technique. Il permet en outre de mesurer le dimensionnement des serveurs, de la bande passante nécessaire sur le réseau, etc. Test de performance : proche du Test de Charge, il s'agit d'un test au cours duquel on va mesurer les performances de l'application soumise à une charge d'utilisateurs. Les informations recueillies concernent les temps de réponse utilisateurs, les temps de réponse réseau et les temps de traitement d une requête sur le(s) serveur(s). La nuance avec le type précédent réside dans le fait qu'on ne cherche pas ici à valider les performances pour la charge attendue en production, mais plutôt vérifier les performances intrinsèques à différents niveaux de charge d'utilisateurs. Test de dégradations des transactions : il s'agit d'un test technique primordial au cours duquel on ne va simuler que l'activité transactionnelle d'un seul scénario fonctionnel parmi tous les scénarios du périmètre des tests, de manière à déterminer quelle charge le système est capable de supporter pour chaque scénario fonctionnel et d'isoler éventuellement les transactions qui dégradent le plus l'ensemble du système. Ce test peut tenir compte ou non de la cadence des itérations, la représentativité en termes d'utilisateurs simultanés vs. sessions simultanées n'étant pas ici un objectif obligatoire, s'agissant ici plutôt de déterminer les points de contention générés par chaque scénario fonctionnel. La démarche utilisée est d'effectuer une montée en charge linéaire jusqu'au premier point de blocage ou d'inflexion. Pour dépasser celui-ci, il faut paramétrer méthodiquement les composants systèmes ou applicatifs afin d'identifier les paramètres pertinents, ce jusqu'à obtention des résultats satisfaisants. Méthodologiquement, ce test est effectué avant les autres types de tests tels que performance, robustesse, etc. où tous les scénarios fonctionnels sont impliqués. Test de stress : il s'agit d'un test au cours duquel on va simuler l'activité maximale attendue tous scénarios fonctionnels confondus en heure de pointe de l'application, pour voir comment le système réagit au maximum de l'activité attendue des utilisateurs. La durée du palier en pleine charge, en général de 2 heures, doit tenir compte du remplissage des différents caches applicatifs et clients, ainsi que de la stabilisation de la plateforme de test suite à l'éventuel effet de pic-rebond consécutif à la montée en Belfouz/Vandamme 18/24

19 charge. Dans le cadre de ces tests, il est possible de pousser le stress jusqu'à simuler des défaillances systèmes ou applicatives afin d'effectuer des tests de récupération sur incident (Fail-over) ou pour vérifier le niveau de service en cas de défaillance. Test de robustesse, d'endurance, de fiabilité : il s'agit de tests au cours desquels on va simuler une charge importante d'utilisateurs sur une durée relativement longue, pour voir si le système testé est capable de supporter une activité intense sur une longue période sans dégradations des performances et des ressources applicatives ou système. Le résultat est satisfaisant lorsque l'application a supporté une charge supérieure à la moitié de la capacité maximale du système, ou lorsque l'application a supporté l'activité d'une journée ou plusieurs jours/mois/années, pendant 8 à 10 heures, sans dégradation de performance (temps, erreurs), ni perte de ressources systèmes. Test de capacité, test de montée en charge : il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs sans cesse croissant de manière à déterminer quelle charge limite le système est capable de supporter. Éventuellement, des paramétrages peuvent être effectués, dans la même logique que lors des tests de dégradation, l'objectif du test étant néanmoins ici de déterminer la capacité maximale de l'ensemble systèmeapplicatif dans une optique prévisionnelle. Test aux limites : il s'agit d'un test au cours duquel on va simuler en général une activité bien supérieure à l'activité normale, pour voir comment le système réagit aux limites du modèle d'usage de l'application. Proche du test de capacité, il ne recouvre pas seulement l'augmentation d'un nombre d'utilisateurs simultanés qui se limite ici à un pourcentage en principe prédéfini, mais aussi les possibilités d'augmentation du nombre de processus métier réalisés dans une plage de temps ou en simultané, en jouant sur les cadences d'exécutions, les temps d'attente, mais aussi les configurations de la plateforme de test dans le cadre d'architectures redondées (Crash Tests). Il existe d'autres types de tests, plus ciblés et fonction des objectifs à atteindre dans la campagne de tests : Test de Benchmark (comparaisons de logiciel, matériels, architectures...), Tests de nonrégression des performances, Tests de Composants, Tests de Volumétrie des données, etc. Étant entendu qu'en principe un type de test correspond à un type d'objectif, et que dans une matrice de couverture des tests les résultats se recoupent obligatoirement, il est rare (et coûteux) de réaliser l ensemble de ces tests pour une application donnée. Source : Wikipédia Dans notre projet nous devrons mettre en place un benchmark qui nous permettra d'après les résultats obtenus de voir si la virtualisation dans un contexte extrême de calcul scientifique se rapproche des performances d'une machine native et de voir quelle solution est «la meilleure», c'est à dire qui peut, peut être mis en place pour faire du calcul scientifique. Parmis les solutions de virtualisation que nous allons comparé : KVM,OpenVz,Docker,VirtualBox,XEN,Vagrant et Adeos. Nous avons choisi les solutions qui nous semblent les plus connus et les plus pertinentes. Belfouz/Vandamme 19/24