3. CHAPITRE 3 : CHOIX DE LA SOLUTION DE VIRTUALISATION
CHAPITRE
CHOIX DE LA SOLUTION DE
VIRTUALISATION
Réalisé par Joris Dagbégnon FAGBEMIRO 27
Dans les chapitres précédents, nous avons présenté plus en détail le centre de données de BJNet ; mais nous avons aussi présenté l’état de l’art sur la virtualisation, technologie qui offre entre autres intérêts celui de pouvoir faire fonctionner simultanément plusieurs serveurs sur une seule machine physique. Il s’agira dans ce chapitre de présenter les choix techniques effectués pour pouvoir choisir la solution de virtualisation la plus adéquate pour le déploiement de ce centre de données ; ainsi que les outils à utiliser sur les serveurs.
Le choix de la solution de virtualisation idoine étant crucial pour un projet de virtualisation, il convient de prendre en compte un certain nombre de paramètres comme le matériel de la machine hôte, l’approche de virtualisation adéquate, etc. En effet, chaque type de virtualisation a ses avantages et inconvénients qui conditionnent l’application qui en est faite (Kolyshkin, 2006). La démarche suivie est la suivante :
- présentation des caractéristiques du serveur,
- comparaison entre les approches de virtualisation et choix des plus adéquates,
- choix des solutions de virtualisation à employer pour le déploiement, - et choix des outils à utiliser sur les serveurs.
3.1 Présentation des caractéristiques de la machine hôte
Le matériel sur lequel va être déployée une solution de virtualisation joue un grand rôle dans le choix de ladite solution (Golden, 2008). En effet, les caractéristiques du serveur peuvent orienter dans le choix d’une solution de
Réalisé par Joris Dagbégnon FAGBEMIRO 28
virtualisation. Que ce soit la mémoire physique disponible, la quantité de RAM (Random Access Memory)12 disponible, le nombre de processeurs et le nombre de cœurs par processeur ou le nombre de cartes réseau, tous ces paramètres influencent la couche applicative de virtualisation à utiliser, le nombre de machines virtuelles qu’on peut créer et aussi le nombre de machines virtuelles pouvant fonctionner simultanément.
Le tableau suivant récapitule les caractéristiques des serveurs du projet BJNet :
Tableau III.I : Caractéristiques matérielles des serveurs du projet BJNet
CARACTERISTIQUES VALEURS
Marque Chenbro
Type RM 217 2U
Processeur AMD Opteron 4170 Lisbon 64 bits (x 2)
Nombre de cœurs par processeur 6
Support matériel de la virtualisation Oui (AMD-V)
RAM 8 Go13
13 Go : Gigaoctet (Go) égal à 1000 Mo dans le Système International (BIPM, 2014)
14 To : Téraoctet
Réalisé par Joris Dagbégnon FAGBEMIRO 29
L’un des ports RJ45 Intel est celui qui sera utilisé par les services et l’autre est dédié à l’administration du serveur. Le port ASMB4-iKVM (Asus Server Management Board-internet Keyboard Video Mouse) est fonctionnel seulement quand on installe une carte ASMB4 permettant de connecter le serveur à un switch KVM15 ; et le dernier port permet, au travers du réseau de se connecter au contrôleur RAID (Redundant Array of Inexpensive Disks) des disques SAS (Serial Attached SCSI)16 du serveur.
Le choix de la bonne solution de virtualisation dans l’absolu est très difficile, et la pléthore d’offres de virtualisation disponibles (VMWare vSphere Hypervisor, VMWare Workstation, Oracle VM VirtualBox, Microsoft Virtual PC, Microsoft HyperV, Citrix Xen Server, Citrix XenApp, ProxMox VE, Solaris Zones, KVM, Parallels Desktop, Linux-VServer, OpenVZ, etc.) ne facilite pas la décision. C’est pourquoi il est nécessaire de réduire le champ d’étude aux solutions applicables dans un cas bien spécifique (Bonnet, 2008). Notre cas ici est celui de l’utilisation de solutions libres pour la virtualisation de serveurs, répartis sur 4 réseaux différents, avec des distributions UNIX/Linux comme systèmes d’exploitation dominants.
15 Un switch KVM est un équipement permettant de contrôler plusieurs serveurs à partir d’un seul ensemble de clavier, écran et souris.
16 Le SAS est une technique d’interface pour disque dur, qui apporte le mode de transmission en série et constitue une amélioration des bus SCSI (Small Computer System Interfaces) en termes de performances.
Réalisé par Joris Dagbégnon FAGBEMIRO 30
3.2 Choix des techniques de virtualisation adéquates
3.2.1 Comparaison entre les techniques de virtualisation
Les critères sur lesquels nous avons basé notre comparaison entre les techniques de virtualisation sont les performances qu’elles offrent, les systèmes d’exploitation supportés nativement et la demande en ressources matérielles de l’hôte.
3.2.1.1 La virtualisation au sein d’un OS ou cloisonnement
Ce type de virtualisation est essentiellement utilisé sur les systèmes UNIX et Linux (Benkemoun et Hinfray, 2008).L’intérêt de cette technique réside principalement dans le fait qu’elle offre les meilleures performances17, c’est-à-dire qu’elles sont très proches de celle d’un système natif (Kolyshkin, 2006), et il y a un net gain en sécurité et simplicité d’administration du fait de la séparation entre les systèmes invités (Bonnet, 2008). Les systèmes invités se basant tous sur le même noyau que celui du système hôte, ce noyau n’est chargé en RAM qu’une seule fois ; il est donc possible d’exécuter un grand nombre d’environnements virtuels en parallèle. La limite théorique est au-delà de 8000 (Victor et Cotten, 2010).
17 Victor et Cotten (2010) donnent l’exemple suivant : sur un serveur physique ayant 2 processeurs de 300MHz, 512 Mo de RAM et 40 Go d’espace disque, on fait tourner 40 zones exécutant chacune 5 copies du service web Apache. Avec toutes les zones fonctionnant simultanément et de multiples requêtes adressées à chaque zone, l’overhead engendré est si faible qu’il n’est pas mesurable (< à 5%).
Réalisé par Joris Dagbégnon FAGBEMIRO 31
La principale contrainte de ce modèle de virtualisation réside dans le fait que les systèmes invités doivent impérativement être du même type (UNIX ou Linux) que le système hôte (Santy, 2010) ;
3.2.1.2 La virtualisation complète
Il est ici utile de rappeler que l’utilisation de cette technique passe par l’installation d’un hyperviseur de type 2 ou de type 1 qui va émuler le matériel sous-jacent et le présenter au système d’exploitation invité.
Un des gros intérêts de cette technique de virtualisation est de pouvoir émuler n’importe quelle architecture matérielle. On peut donc faire fonctionner les systèmes d’exploitation que l’on désire indépendamment de l’architecture du système hôte (Kolyshkin, 2006). De plus, dans le cas d’utilisation d’un hyperviseur de type 1, on a un contrôle plus fin de l’accès au matériel et de l’utilisation des ressources (Bonnet, 2008).
Un désavantage de la virtualisation complète est que l’émulation du matériel est coûteuse et la performance limitée ; car toutes les instructions au matériel émulé doivent être traduites au vol avant d’être exécutées sur le matériel réel (Anhalt et Primet, 2008) et l’empilement des couches d’abstraction (cas d’un hyperviseur de type 2), réduit les performances des machines virtuelles (Benkemoun et Hinfray, 2008). Aussi, pour son utilisation, le noyau de l’hyperviseur doit être chargé dans la RAM et ensuite celui de chacune des machines virtuelles créées aussi. C’est donc une méthode très consommatrice en ressources (DRTIC et Eduter-Cnerta, 2013). La virtualisation assistée matériellement (Intel VT-x et AMD-V) vient cependant
Réalisé par Joris Dagbégnon FAGBEMIRO 32
réduire un peu cette perte de performances (toutes les instructions n’ayant plus besoin d’être traduites).
3.2.1.3 La paravirtualisation
Cette technique suppose aussi l’utilisation d’un hyperviseur de type 1, mais sans émulation de matériel ici car le système invité est modifié. Il est conscient d’être virtualisé et collabore ainsi avec l’hyperviseur à l’optimisation des performances.
Le principal atout de la paravirtualisation réside dans ses faibles coûts de virtualisation (une grande partie du travail de virtualisation ayant déjà été réalisée en modifiant le noyau du système invité). Il offre de meilleures performances par rapport à la virtualisation complète (Kolyshkin, 2006) et elles sont assez proches de celles d’un système natif (Golden, 2008).
Son principal facteur limitant vient du fait qu’il ne supporte que les systèmes ayant été modifiés pour être compatible avec l’hyperviseur utilisé (Kolyshkin, 2006) (mais sur un processeur bénéficiant de la virtualisation matérielle, on peut installer n’importe quel système). De plus, la consommation en ressources matérielles (surtout la RAM) est aussi importante qu’en virtualisation complète car les noyaux de l’hyperviseur et des machines à créer sont chargés dans la RAM.
Le tableau suivant résume donc cette comparaison.
Réalisé par Joris Dagbégnon FAGBEMIRO 33
Tableau III.IV : Tableau comparatif des techniques de virtualisation TECHNIQUE DE
VIRTUALISATION CARACTERISTIQUES
Virtualisation au sein d’un OS
(containers ou zones)
- Performances : très bonnes, très proches du natif
- Performances : bonnes, proches du natif et meilleures qu’en virtualisation complète - Systèmes supportés : ceux ayant été modifiés
pour fonctionner avec le paravirtualiseur solution idoine lorsqu’on voudrait pouvoir utiliser dans son environnement virtuel, n’importe quel système d’exploitation (moyennant l’intégration par le
Réalisé par Joris Dagbégnon FAGBEMIRO 34
processeur de la virtualisation matérielle). Cependant, il ne convient pas à notre cas.
En effet, la quantité de RAM disponible sur les serveurs du projet ne permettra pas de mettre en place les serveurs virtuels présentés à la figure 1.1 dans un environnement paravirtualisé. Supposons qu’on utilise le paravirtualiseur Xen, qui nécessite au minimum 2Go de RAM (Citrix, 2014) et que pour les pare-feux et les serveurs des DMZ et du réseau de données critiques (16 au total) on utilise le système Debian, qui nécessite généralement 512 Mo de RAM (Debian, 2013). Il faudrait donc 10,2 Go de RAM or les serveurs ne disposent que de 8Go de RAM.
Ainsi, le choix le plus adéquat est celui de la technique de virtualisation au sein d’un OS. La majorité des services à déployer fonctionnant dans des environnements Linux et UNIX, leur virtualisation dans les zones nous garantit une bonne performance ; et de plus, les zones sont bien adaptées aux scénaris où il y a un grand nombre d’environnements d’exécution identiques (Golden, 2008).
Il s’est alors posé le problème de la virtualisation des systèmes d’exploitation n’étant pas supporté dans les zones. On a décidé, comme solution, d’utiliser la technique de virtualisation complète. On installera donc un hyperviseur de type 2 (étant donné que c’est une application) dans une zone et au sein de cet hyperviseur, seront créées les machines virtuelles nécessaires à l’installation desdits systèmes.
Réalisé par Joris Dagbégnon FAGBEMIRO 35
En résumé, pour la mise en place de l’environnement virtuel du datacenter de BJNet, nous avons combiné deux techniques : celle de la virtualisation au sein d’un OS et celle de la virtualisation complète.
3.3 Solutions de virtualisation retenues pour le centre de données
Après le choix des techniques de virtualisation à utiliser pour le déploiement du centre de données de BJNet, nous sommes passés au choix des solutions implémentant lesdites techniques.
La plupart des systèmes d’exploitation basés sur UNIX proposent un moyen d’isoler les processus (chroot, BSD Jails, etc.) ; mais l’UNIX de Sun Microsystems, Solaris, propose un système de zones très évolué, plus proche d’une machine virtuelle que d’une isolation de processus (Bonnet, 2008). Sa version libre et open-source, OpenSolaris a été abandonnée après le rachat de Sun Microsystems par Oracle en 2010. Les solutions open-source phares qui en ont découlé sont OpenIndiana18 et SmartOS19.
OpenIndiana est une distribution de la famille UNIX (System V release 4) et basée sur le noyau illumos20. C’est un fork d’OpenSolaris et est présenté comme son successeur (Klimov, 2014). Il est actuellement compatible avec Solaris 11 et Solaris 11 Express et constitue donc une alternative open-source aux produits commerciaux Solaris d’Oracle (Lumsden, 2011). Il est distribué
18 Site officiel : www.openindiana.org (consulté le 16 Décembre 2014)
19 Site officiel : http://www.smartos.org (consulté le 16 Décembre 2014)
20 illumos est un noyau dérivé de celui d’OpenSolaris (OS/Net) et géré par l’illumos Foundation, créée après l’arrêt du projet OpenSolaris par Oracle. (Site officiel : www.illumos.org) (consulté le 16 Décembre 2014)
Réalisé par Joris Dagbégnon FAGBEMIRO 36
sous licence CDDL (Common Development and Distribution License)21. Il bénéficie des fonctionnalités très intéressantes (pour une utilisation en tant que serveur) qu’offre le noyau illumos :
- ZFS (Z ou Zettabyte File System) : système de fichiers révolutionnaire 128 bits créé par Sun Microsystems (Oracle, 2010a) ; qui supporte jusqu’à 16 exbioctets et qui offre le RAID, la déduplication, le snapshot, etc.
- Solaris zones
- Crossbow : outil de virtualisation réseau permettant la création de cartes réseau virtuelles, de switch virtuels, l’attribution de pile TCP/IP exclusive à une zone, la gestion de la bande passante, etc.
- DTrace : outil permettant de suivre les performances des services et de détecter les problèmes en temps réel
- SMF (System Management Facility) : outil de gestion des services et qui permet par exemple le démarrage en parallèle de services, le redémarrage automatique après incident, etc.
- Etc.
SmartOS est aussi une distribution basée sur le noyau illumos, et bénéficiant donc de ses fonctionnalités. Cependant SmartOS offre l’avantage, par rapport à OpenIndiana, de pouvoir installer dans ses zones n’importe quel autre système d’exploitation compatible x86. En effet, OpenIndiana est limité dans ses Branded Zones22 Linux (LxBrand) aux systèmes RedHat et CentOS
21La CDDL est une licence open source créée par Sun Microsystems, basée sur la Mozilla Public License, version 1.1. Elle était notamment destinée au projet OpenSolaris. (Plus d’informations sur le site de l’Open Source Initiative : http://opensource.org/licenses/cddl1.php ) (consulté le 16 Décembre 2014)
22 Une Branded Zones (BrandZ) est une zone permettant de faire marcher un environnement d’exécution différent de celui de l’OS qui héberge les zones
Réalisé par Joris Dagbégnon FAGBEMIRO 37
(Oracle, 2010b). Le support des autres systèmes d’exploitation est rendu possible par le fait que KVM (Kernel-based Virtual Machine)23, une technologie de virtualisation complète, a été porté au sein de SmartOS et intégré aux zones (à la création d’une zone, on spécifie si la zone sera du type natif ou du type KVM afin d’installer des systèmes Linux, Windows ou UNIX).
La limite à cette intégration de KVM au sein de SmartOS est qu’elle n’est utilisable que sur des serveurs ayant un processeur Intel bénéficiant des technologies VT-x et EPT (Extended Page Tables) (McWhirter et Wiedenroth, 2014).
Ainsi, vu que les serveurs du projet BJNet sont équipés de processeurs AMD (cf. Tableau III.I), nous ne pouvions que choisir OpenIndiana comme solution de virtualisation pour la création des zones.
Quant à l’hyperviseur de type 2 à utiliser, notre choix s’est porté sur VirtualBox d’Oracle (en mode headless24). Les raisons en sont que ce produit est libre d’utilisation, bénéficie d’une communauté active et offre le support pour la plupart des systèmes d’exploitation du marché.
3.4 Choix des outils à utiliser sur les serveurs
OpenIndiana combiné à VirtualBox étant retenues, le choix des outils à utiliser pour mettre en place les services sera fait en conséquence.
23 Site officiel : https://www.linux-kvm.org (consulté le 18 Décembre 2014)
24 Le mode headless désigne la version de VirtualBox n’intégrant pas d’interface graphique. Une interface web, phpvirtualbox, est cependant disponible pour accéder aux systèmes invités ayant d’interface graphique.
Réalisé par Joris Dagbégnon FAGBEMIRO 38
3.4.1 Le serveur DNS
Il existe plusieurs logiciels open-source faisant office de serveur DNS : BIND, OpenDNS, MaraDNS, etc.
Le logiciel le plus utilisé sur les serveurs de noms est BIND (ISC, 2014).
Il est intégré à OpenIndiana et constitue donc notre choix.
3.4.2 Le serveur web
Parmi le grand nombre de serveurs web existants (Apache HTTP Server, Microsoft IIS, Litespeed, Nginx, Varnish, Apache Tomcat, etc.), les plus populaires parmi ceux libres et open-source sont Apache HTTP Server et Nginx.
Apache HTTP Server est le serveur web le plus utilisé au monde avec 58,9% de parts de marché et devance Nginx qui a 22,8% (w3techs, 2014). Il est préféré à Nginx pour son extensibilité, sa fiabilité et son grand nombre de modules (permettant d’héberger des sites écrits avec différents langages ou différents frameworks) ; alors que Nginx est un serveur web léger mieux adapté pour servir du contenu statique (Rowe, 2014).
Puisqu’il peut être installé dans OpenIndiana, Apache HTTP Server constitue notre choix pour le serveur web.
3.4.3 Le relais inverse HTTP (HyperText Transfer Protocol)
Le relais inverse HTTP (encore appelé serveur mandataire ou reverse proxy en anglais) est un serveur qui apparaît au client comme un serveur web
Réalisé par Joris Dagbégnon FAGBEMIRO 39
ordinaire alors qu’il n’est pas en réalité le serveur qui génère les pages demandées. Il est souvent utilisé lorsque le vrai serveur web se trouve derrière un pare-feu et peut-être aussi utilisé pour équilibrer les charges entre plusieurs serveurs (back-end servers) ou encore pour mettre des pages en cache (Apache, 2014).
Nginx est reconnu comme l’un des meilleurs serveurs pour un usage en relais inverse HTTP car il utilise moins de RAM et très peu de threads pour un grand nombre de connexions simultanées alors qu’Apache HTTP Server en utilise un par connexion (Rowe, 2014). Utiliser Nginx comme relais et Apache HTTP Server comme serveur back-end est un scénario très utilisé (Rowe, 2014). De plus, il peut être installé dans OpenIndiana.
On choisit donc Nginx pour le relais inverse HTTP.
3.4.4 Le serveur mail
C’est le serveur qui stockera les mails des utilisateurs et qui se chargera d’envoyer les mails des utilisateurs.
Pour le serveur de mail sortant et entrant, nous choisissons Postfix, car il est plus simple de configuration que Sendmail et est largement répandu.
Pour le serveur POP/IMAP (Post Office Protocol/Internet Message Access Protocol), nous avons retenu d’utiliser Dovecot, car il forme avec Postfix le couple le plus utilisé pour les serveurs de mails.
3.4.5 Le relais SMTP (Simple Mail Transfer Protocol)
Ce relais se chargera de transférer les requêtes SMTP effectuées vers le serveur de mail sortant et entrant.
Réalisé par Joris Dagbégnon FAGBEMIRO 40
Nous avons choisi d’utiliser Nginx car il est très léger, rapide, libre, capable de faire proxy SMTP et peut être installé sur OpenIndiana.
3.4.6 Le relais POP/IMAP
Le relais POP/IMAP se chargera, lorsqu’un client voudra consulter ses mails, d’aller les récupérer sur le serveur mail du centre de données critiques.
Nous avons choisi d’utiliser Perdition car il est libre, puissant et largement utilisé.
3.4.7 Le serveur de bases de données
Nous avons choisi d’utiliser MySQL car il est libre et est le moteur de bases de données libre le plus utilisé (DB-engines, 2014).
3.4.8 Les pare-feux
Pour les pare-feux, nous avons retenu d’utiliser celui intégré à OpenIndiana et qui est IPFilter.
Tableau III.V : Récapitulatif des outils pour les serveurs, relais et pare-feux
Elément à mettre en
Réalisé par Joris Dagbégnon FAGBEMIRO 41
En conclusion, pour le déploiement du datacenter de BJNet, la solution retenue combine les zones de OpenIndiana et l’hyperviseur VirtualBox. Nous sommes passés ensuite à la conception de l’architecture de l’environnement virtuel du datacenter.
42