Techniques de virtualisation choisies - Choix des techniques de virtualisation adéquates

CHAPITRE 6 : ANALYSE ET DISCUSSION

2. Objectifs

3.2 Choix des techniques de virtualisation adéquates

3.2.2 Techniques de virtualisation choisies

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 OpenIndiana¹⁸ et SmartOS¹⁹.

OpenIndiana est une distribution de la famille UNIX (System V release 4) et basée sur le noyau illumos²⁰. 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)²¹. 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 Zones²² 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)²³, 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 headless²⁴). 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.

4. CHAPITRE 4 : ARCHITECTURE VIRTUELLE DU CENTRE DE DONNEES ET RECOMMANDATIONS DE DEPLOIEMENT

CHAPITRE

ARCHITECTURE

VIRTUELLE DU CENTRE DE DONNEES ET

RECOMMANDATIONS DE DEPLOIEMENT



Réalisé par Joris Dagbégnon FAGBEMIRO 43

Après avoir choisi d’utiliser OpenIndiana combinée à VirtualBox comme solution de virtualisation pour le déploiement du centre de données de BJNet, nous avons conçu l’architecture de l’environnement de virtualisation et proposer des recommandations pour le déploiement de celui-ci.

4.1 Architecture de l’environnement virtuel

A l’analyse de la topologie physique présentée à la figure 1.1, nous avons déduit une première architecture présentée à la figure 4.1 ci-dessous :

Figure 4.1: Première approche d’architecture

Comme on peut le voir sur la figure précédente, l’idéal pour la mise en place des serveurs aurait été que les serveurs physiques disposent de quatre interfaces réseaux ; chacune étant dédiée à chacun des quatre réseaux qui constituent le centre de données de BJNet.

Cette architecture a donc été modifiée au regard des points suivants :

Réalisé par Joris Dagbégnon FAGBEMIRO 44

1) Concernant le routage du trafic entre les 4 réseaux

Le serveur n’ayant qu’une seule interface réseau, on a deux options : le routeur qui s’en occupera peut être physique (comme sur la figure 4.1) et donc situé à l’extérieur du serveur ou il peut être virtuel et donc situé à l’intérieur du serveur.

Dans le premier cas, il faudrait utiliser les VLAN. Chaque réseau sera donc associé à un VLAN (les paquets provenant de ce réseau seront marqués avec l’identifiant de ce VLAN). Ainsi, si un serveur d’un VLAN doit joindre un autre serveur appartenant à un VLAN différent, le paquet devra passer par l’interface réseau du serveur pour aller vers le routeur avant de revenir par cette interface pour aller vers sa destination. L’interface réseau du serveur sera donc sollicitée six fois, pour le traitement d’une seule requête par exemple :

 d’abord, lorsque la requête du client va vers l’un des relais dans l’une des DMZ ;

 ensuite, lorsque le relais doit joindre le serveur concerné et envoie donc le paquet au routeur (les VLANs étant différents) ;

 ensuite, lorsque le routeur doit envoyer ce paquet vers ledit serveur ;

 ensuite, lorsque le serveur, après avoir généré la réponse la renvoie au relais en passant une fois encore par cette interface pour joindre le routeur ;

 ensuite, lorsque le routeur envoie le paquet au relais et

 enfin lorsque le relais répond au client.

Réalisé par Joris Dagbégnon FAGBEMIRO 45

Puisque les requêtes vers le centre de données seront nombreuses et simultanées, les performances de cette carte réseau seraient fortement diminuées.

La deuxième option, qui suppose la création d’une zone routeur, est donc la mieux adaptée au besoin d’utilisation efficiente de la bande passante offerte par la carte réseau.

2) Concernant l’interconnexion entre les cartes réseau virtuelles (VNIC²⁵) des zones

Dans Crossbow, une VNIC est toujours liée à un lien de données (datalink) qui peut être une carte réseau physique (NIC) ou un etherstub (switch virtuel) (Nagarajayya, 2008). Donc pour interconnecter deux VNIC, il faut toujours un etherstub (Oracle, 2012).

3) Concernant la sécurité du trafic inter-zones

Certaines zones, dans un fonctionnement normal du centre de données, ne doivent pas initier de requêtes vers certaines autres zones. Par exemple, un relais HTTP ne doit pas initier de requêtes vers le serveur de bases de données situé dans le réseau de données critiques ; seuls les serveurs web et mail doivent y accéder. De telles requêtes peuvent donc être l’œuvre d’attaquants ayant pris le contrôle de ce relais web par exemple. Les pare-feux étant chargés de contrôler l’accès aux machines d’un réseau, le trafic venant d’une zone ou allant vers une zone doit donc toujours passer par eux.

A leur niveau, ils vérifient si les paquets respectent les règles de sécurité configurées ; si oui les paquets peuvent continuer, sinon ils sont supprimés.

25 VNIC : Virtual Network Interface Card

Réalisé par Joris Dagbégnon FAGBEMIRO 46

4) Concernant le réseau de données critiques

Une mesure supplémentaire de sécurité sera rajoutée à ce réseau, regroupant des serveurs sensibles, en ne le rendant pas directement accessible depuis l’extérieur du réseau du centre de données. Il ne sera donc pas directement connecté à la carte réseau physique. Les clients n’auront pas conscience de son existence et ce sont les DMZ qui se chargeront de transférer leurs requêtes.

5) Concernant le centre d’administration réseau

Les machines virtuelles qui hébergeront les systèmes d’exploitation adaptés aux outils prévus (Dude, Nagios et OpenVAS) seront créées dans VirtualBox, qui sera installée dans une zone (appelons la « zone_admin »).

Cette zone doit avoir les cartes réseaux nécessaires pour permettre la visibilité depuis l’extérieur du serveur et la connexion avec le reste du réseau du centre de données.

Nous avons deux options pour la création du centre d’administration réseau : on peut installer le pare-feu dans une zone et installer les machines abritant les outils d’administration dans une autre zone hébergeant VirtualBox ou installer lesdites machines et le pare-feu dans VirtualBox.

Dans le premier cas, la zone pare-feu aurait trois VNICs pour se connecter aux deux zones routeurs et à la zone où VirtualBox serait installé. Les machines créées dans VirtualBox devront être en mode “pont“²⁶ sur la ou les VNICs de la zone hôte pour pouvoir communiquer avec le pare-feu. Or dans

26 Le mode pont est un mode réseau de VirtualBox où la carte réseau de la machine virtuelle est liée à la carte réseau de la machine qui héberge VirtualBox ; et la machine virtuelle apparaît dans le réseau auquel est connectée la machine hôte comme une nouvelle machine (Oracle, 2013). Ainsi la machine virtuelle peut avoir accès à Internet par exemple.

Réalisé par Joris Dagbégnon FAGBEMIRO 47

le mode pont, une VNIC doit être exclusivement dédiée à la machine virtuelle (Oracle, 2013). Alors, il faudrait autant de VNIC que de machines à créer.

Dans le second cas, le réseau entre le pare-feu et les machines clientes serait entièrement contenu dans VirtualBox et c’est le pare-feu qui sera connecté aux VNICs de la zone. Il faudrait donc dans ce cas, juste deux VNICs.

L’ajout de nouvelles machines au centre d’administration réseau ne nécessiterait pas la reconfiguration de la zone hôte et peut en outre permettre d’installer un pare-feu différent de celui de OpenIndiana (pfSense par exemple).

Nous avons donc choisi la seconde option.

En tenant compte des contraintes sus-citées, nous avons conçu l’architecture présentée à la figure 4.2.

Réalisé par Joris Dagbégnon FAGBEMIRO 48

Figure 4.2 : Architecture de l’environnement virtuel du centre de données de BJNet

Réalisé par Joris Dagbégnon FAGBEMIRO 49

Il convient, afin de mieux faire comprendre notre architecture, de faire les remarques suivantes:

a) Concernant la zone routeur 1 (zrouter1)

Elle est l’interface entre le réseau extérieur au centre de données et celui-ci. Elle se charge de router les requêtes des clients vers la DMZ concernée et ensuite de renvoyer la réponse ;

b) Concernant la zone routeur 2 (zrouter2)

Elle est chargée de router le trafic entre les zones. C’est donc par elle que les relais joindront les serveurs auxquels ils correspondent ; et que les outils d’administration joindront les machines à administrer.

c) Concernant les passerelles par défaut

Les passerelles par défaut, auxquelles les machines adresseront les paquets à destination d’un réseau qui leur est inconnu, sont réparties comme suit :

 celles des serveurs, relais et des machines d’administration sont les pare-feux de leur réseau respectif ;

 celle des pare-feux des DMZ et du centre d’administration réseau est la zone routeur 1 ;

 celle du pare-feu du réseau de données critiques est la zone routeur 2 ;

 et celle de la zone routeur 1 est le routeur physique auquel est connecté le serveur.

Réalisé par Joris Dagbégnon FAGBEMIRO 50

d) Concernant le centre d’administration réseau

VirtualBox voit comme cartes réseau physiques, les deux cartes réseau virtuelles créées pour la zone (zone_admin) qui l’héberge. Ainsi la machine virtuelle faisant office de pare-feu a aussi trois cartes réseau:

- l’une en mode “pont“ sur la carte réseau virtuelle de la zone, qui est connectée à la zone routeur 1 (et donc à l’extérieur) ;

- la seconde en mode “pont“ sur la carte réseau virtuelle de la zone, qui est connectée à la zone routeur 2 ;

- la dernière en mode “réseau interne privé“²⁷ et reliée aux machines virtuelles hébergeant Nagios, Dude et OpenVAS.

Les cartes réseaux des machines Nagios, Dude et OpenVAS sont aussi en mode “réseau interne privé“.

4.2 Définition des recommandations pour le déploiement

Nous abordons ici certains points importants ayant trait au déploiement du centre de données et faisons des recommandations pour une bonne mise en place de ce centre de données.

4.2.1 Plan d’adressage des zones

Les machines de la DMZ publique auront des adresses IP publiques, puisqu’elles sont les machines répondant aux requêtes provenant d’Internet.

27 Le mode réseau interne privé est un mode réseau de VirtualBox qui établit un réseau limité exclusivement aux machines virtuelles (Oracle, 2013)

Réalisé par Joris Dagbégnon FAGBEMIRO 51

Le reste de l’adressage des machines du centre de données se fera avec des adresses IP privées. Le nombre d’adresses IP privées à attribuer est actuellement de 30 (puisqu’il y a 30 VNICs). On prévoit une augmentation de 15 nouvelles machines pour la fourniture des services additionnels. Une adresse réseau de classe C, qui offre jusqu’à 254 adresses hôtes, est donc suffisante pour cet adressage. Puisque les VNIC sont regroupés dans des réseaux différents, nous allons donc créer des sous-réseaux au sein de cette

Dans le document CONCEPTION D’UN ENVIRONNEMENT VIRTUEL POUR LE DEPLOIEMENT D’UN CENTRE DE DONNEES (Page 45-0)