Thèse de Doctorat Université Pierre et Marie Curie Paris 6 EDITE de Paris Spécialité INFORMATIQUE, TELECOMMUNICATIONS ET ÉLECTRONIQUE présentée par Ahmed Amamou pour obtenir le grade de Docteur de l Université Pierre et Marie Curie Paris 6 Isolation réseau dans un datacenter virtualisé Jury Bernard Cousin Rapporteur Professeur, Université de Rennes Otto Duarte Rapporteur Professeur, Universidade Federal do Rio de Janeiro Djamal Zeghlache Examinateur Professeur, Télécom SudParis Raouf Boutaba Examinateur Professeur, University of Waterloo Pierre Sens Examinateur Professeur, Université Pierre et Marie Curie Pascal Bouchareine Examinateur Directeur Recherche et Developpement, Gandi SAS Guy Pujolle Directeur Professeur, Université Pierre et Marie Curie Kamel Haddadou Encadrant Ingénieur de Recherche, Gandi SAS
Table des figures 2.1 Les types de services fournis par le Cloud Computing............. 8 2.2 Architecture de Vserver............................. 12 2.3 Architecture réseau conventionnelle d un datacenter............. 15 2.4 Architecture d un datacenter virtualisé..................... 17 2.5 Entête VXLAN.................................. 24 2.6 Entête DOVE................................... 25 2.7 Entête NVGRE.................................. 26 3.1 Architecture de communication basée sur les I/O de XEN.......... 32 3.2 Bande passante résultante dans le cas standard................ 37 3.3 Bande passante résultante avec notre algorithme............... 37 3.4 Variation de la consommation CPU en fonction de la periode de réajustement 39 3.5 Variation du nombre de transactions mémoire consommées en fonction de la periode de réajustement............................. 40 3.6 Limite en nombre de paquets par seconde de notre système......... 41 3.7 Débit d émission suivant la taille des paquets pour le DBA-VM....... 45 3.8 Débit en nombre de paquets pour les trois scénarios............. 46 3.9 Délai moyen pour les trois scénarios...................... 47 3.10 Jitter pour les trois scénarios.......................... 47 3.11 Nombre de cycles CPU consommés par le DBA-VM en fonction de la période de réajustement.................................. 48 3.12 Nombre de transactions mémoire consommées par le DBA-VM en fonction de la période de réajustement.......................... 49 4.1 Architecture réseau d un data center basé sur TRILL............. 53 4.2 Structure d un paquet TRILL.......................... 54 4.3 Structure d un entête TRILL.......................... 55 4.4 Processus d envoi des paquets TRILL..................... 63 4.5 Processus de réception des paquets TRILL................... 65 4.6 Implémentation d un Rbridge sous Linux................... 67 4.7 Délai de convergence pour le protocole TRILL................ 69 I
4.8 Évolution du temps de réelection en fonction de la période LSP....... 71 4.9 Performances réseau du protocole TRILL................... 73 4.10 Nombre d entrées dans la table de commutation pour un réseau Ethernet standard...................................... 75 4.11 Nombre d entrées dans la table de commutation pour un réseau TRILL.. 75 4.12 Surcharge du protocle TRILL.......................... 76 5.1 Isolation basé sur le Host............................ 81 5.2 Isolation de bout en bout............................ 82 5.3 Champ d extension................................ 84 5.4 Champ Flux.................................... 85 5.5 Champ résumant les extensions......................... 86 5.6 Composition d un paquet VNT......................... 86 5.7 Commutateur Virtuel.............................. 88 5.8 Processus d envoi d un paquet VNT...................... 89 5.9 Processus de réception d un paquet VNT................... 91 5.10 Performances réseau du protocole VNT.................... 93 5.11 Nombre d entrées dans la table de commutation pour un réseau VNT... 95 5.12 Diagramme d états des VNI........................... 97 5.13 Processus de découverte des VNI........................ 100 5.14 Processus d envoi en tenant compte de la propagation des VNI....... 102 5.15 Processus de reception en tenant compte de la propagation des VNI.... 103 5.16 Délai de convergence pour le protocole VNT.................. 105 5.17 Performances réseau du VNT.......................... 107 5.18 Nombre d entrées dans la table de commutation pour un réseau VNT avec propagation du VNI............................... 108 5.19 Nombre d entrées dans la table de commutation pour un réseau VNT avec propagation du VNI en fonction du nombre de VM par VNI......... 109 5.20 Plateforme de test pour le multichemin..................... 110 5.21 Reprise du flux TCP après panne........................ 111 5.22 Évolution du flux TCP pendant une migration................ 112
Liste des tables 3.1 Scénario d émission................................ 37 4.1 Délai de ping pour les paquets TRILL..................... 72 5.1 Délai de ping pour les paquets VNT...................... 106 III
Table des matières 1 Introduction 1 1.1 Motivations.................................... 2 1.2 Contributions................................... 3 1.3 Plan de la thèse.................................. 4 2 Datacenter virtualisé 5 2.1 Introduction.................................... 6 2.2 Cloud Computing................................ 6 2.3 La virtualisation................................. 9 2.3.1 Définition................................. 9 2.3.2 Terminologie............................... 9 2.3.3 La mutualisation des ressources systèmes............... 10 2.3.3.1 La para virtualisation..................... 10 2.3.3.2 La virtualisation complète.................. 10 2.3.3.3 La virtualisation par conteneurs............... 11 2.3.4 La virtualisation des réseaux...................... 12 2.3.4.1 la virtualisation des routeurs (nœuds)............ 12 2.3.4.2 La virtualisation des liens................... 13 2.4 Architecture réseau pour un datacenter traditionnel............. 13 2.4.1 Limitation d Ethernet (L2)....................... 13 2.4.2 Architecture réseau L2 + L3...................... 15 2.4.3 Réseau local virtuel (VLAN)...................... 16 2.5 Architecture réseau pour un datacenter virtualisé (VDC)........... 16 2.5.1 Architecture du VDC.......................... 16 2.5.2 Nouvelles recommandations....................... 18 2.5.2.1 Mobilité des VMs....................... 18 2.5.2.2 Connectivité any to any non bloquante.......... 19 2.5.2.3 Tolérance aux pannes..................... 19 2.5.2.4 Passage à l échelle....................... 19 2.5.2.5 Simplicité de gestion...................... 20 V
2.5.2.6 Réseaux privés......................... 20 2.5.3 Travaux de recherche sur les architectures réseaux pour un VDC.. 20 2.5.3.1 Passage à l échelle....................... 21 2.5.3.2 Réseau Privé.......................... 23 2.6 Conclusion.................................... 27 3 Dimensionnement dynamique des capacités d émission des Machines Virtuelles 29 3.1 Introduction.................................... 30 3.2 Hyperviseur Xen................................. 30 3.3 Problématique du partage de la bande passante................ 31 3.3.1 Architecture I/O Réseau de XEN.................... 31 3.4 Dimensionnement dynamique de la bande passante.............. 33 3.5 Évaluation de performances........................... 35 3.5.1 Plateforme de test............................ 35 3.5.2 Performances Réseaux.......................... 36 3.5.2.1 Évaluation de la bande passante............... 36 3.5.3 Performances système.......................... 38 3.5.3.1 Performances CPU...................... 38 3.5.3.2 Évaluation des transactions mémoire consommées..... 39 3.5.4 Limitations................................ 40 3.6 Discussion..................................... 40 3.7 Dimensionnement dynamique de la bande passante couplé avec le nombre de paquets par seconde.............................. 42 3.8 Évaluation de performance........................... 44 3.8.1 Plateforme de test............................ 44 3.8.2 Performances Réseaux.......................... 45 3.8.2.1 Évaluation de la bande passante............... 45 3.8.2.2 Évaluation du délai de bout en bout............. 46 3.8.2.3 Évaluation de la Jitter..................... 47 3.8.3 Performances système.......................... 48 3.8.3.1 Performances CPU...................... 48 3.8.3.2 Évaluation des transactions mémoire consommées..... 49 3.9 Conclusion.................................... 49 4 Intégration du TRILL au niveau des noeuds physiques 51 4.1 Introduction.................................... 52 4.2 Inadéquation de la couche L2 actuelle pour les datacenters.......... 52 4.3 Introduction au protocole TRILL........................ 53 4.3.1 Présentation............................... 53 4.3.2 Présentation de la structure d un paquet TRILL........... 54 4.3.3 Plan de contrôle............................. 55 4.3.4 Plan de données............................. 56 4.4 Intégration du RBridge au niveau du nœud physique............. 57
4.4.1 Choix de l emplacement des RBridges................. 57 4.4.1.1 Déploiement des RBridges comme équipements dédiés... 57 4.4.1.2 Déploiement des RBridges dans les nœuds physiques.... 58 4.4.1.3 Déploiement des RBridges au niveau des interfaces des VMs 58 4.4.1.4 Discussion........................... 58 4.4.2 Plan de Contôle............................. 59 4.4.3 Plan de données............................. 61 4.4.3.1 Processus d envoi....................... 62 4.4.3.2 Processus de Réception.................... 64 4.5 Évaluation des performances.......................... 66 4.5.1 Implémentation du RBridge....................... 66 4.5.2 Plateforme de Test............................ 67 4.5.3 Plan de contrôle............................. 68 4.5.3.1 Convergence.......................... 68 4.5.3.2 Tolérance aux pannes..................... 70 4.5.4 Plan de données............................. 71 4.5.4.1 Délai de bout en bout..................... 72 4.5.4.2 Bande passante........................ 72 4.5.4.3 Impacte sur la table de commutation des ToR....... 74 4.5.4.4 Surcharge protocolaire..................... 76 4.6 Conclusion.................................... 77 5 VNT : Virtual Network over TRILL 79 5.1 Introduction.................................... 80 5.2 Notion de réseau privé dans un datacenter................... 80 5.3 Types d isolations................................ 81 5.3.1 Isolation basé sur le Host........................ 81 5.3.2 Isolation de bout en bout........................ 82 5.4 Présentation du VNT : Virtual Network over TRILL............. 82 5.5 Tag VNI...................................... 83 5.6 Format des paquets VNT............................ 84 5.7 Intégration de l extension VNT dans les RBridges............... 87 5.7.1 Description de l approche........................ 87 5.7.1.1 Introduction des Virtuals Switches.............. 87 5.7.1.2 Processus d envoi....................... 88 5.7.1.3 Processus de réception..................... 90 5.7.2 Évaluation de performances....................... 90 5.7.2.1 Plateforme de test...................... 90 5.7.2.2 Plan de contrôle........................ 92 5.7.2.3 Plan de données........................ 92 5.7.2.3.1 Délai de bout en bout................ 92 5.7.2.3.2 Bande passante................... 93 5.7.2.3.3 Impacte sur les tables de commutation...... 94 5.8 Discussion..................................... 96
5.9 Intégration des extensions VNT dans les RBridges avec annonce des VNI. 96 5.9.1 Description de l approche........................ 97 5.9.1.1 Exemple de découverte de la topologie selon le VNI.... 100 5.9.2 Changement au niveau du plan de contrôle.............. 101 5.9.3 Changement au niveau du plan de données.............. 101 5.9.4 Évaluation des performances...................... 104 5.9.4.1 Plateforme de test....................... 104 5.9.4.2 Plan de contrôle........................ 104 5.9.4.2.1 Convergence..................... 104 5.9.4.2.2 Reprise après panne................. 106 5.9.4.3 Plan de données........................ 106 5.9.4.3.1 Délai de bout en bout................ 106 5.9.4.3.2 Bande passante................... 107 5.9.4.3.3 Impacte sur la table de commutation....... 108 5.9.4.3.4 Tolérance aux pannes (Multipath)......... 109 5.9.4.3.5 Migration....................... 110 5.10 Rétrocompatibilité................................ 112 5.10.1 Rétrocompatibilité du plan de contrôle................. 113 5.10.2 Rétrocompatibilité du plan de données................. 113 5.11 Conclusion.................................... 114 6 Conclusion 115 6.1 Contributions................................... 117 6.2 Perspectives.................................... 121 Publications 123 Bibliographie 124
Chapitre 1 Introduction Sommaire 1.1 Motivations............................... 2 1.2 Contributions.............................. 3 1.3 Plan de la thèse............................ 4 1
2 CHAPITRE 1. 1.1 Motivations Nous assistons, ces dernières années, à l émergence d un nouveau modèle économique dans l exploitation des ressources informatiques. Ce nouveau modèle, c est l informatique dans les nuages communément appelé Cloud Computing. Plusieurs PME choisissent aujourd hui ce modèle pour des raisons de coût et de flexibilité. En effet, ce modèle permet une rationalisation et un lissage du coût des ressources dans le temps. Le Cloud computing est aujourd hui en pleine expansion avec une demande qui ne cesse d augmenter, à titre d exemple, le cabinet Gartner [1] estime la croissance pour l année 2013 à 18% atteignant ainsi un chiffre d affaires totale de 131 millions de dollars. Outre l aspect économique du cloud, ce dernier est important par la quantité de données qui y sont stockées et la quantité de trafics qu il génère. Ainsi selon Cisco [2], le total de la bande passante consommée pour le cloud sera de l ordre de 3.3 zetta (10 21 ) octets en 2013 et le double à savoir 6.6 zetta octets en 2016. Toujours selon [2], ce trafic se répartit de la manière suivante : 76% est un trafic au sein même du datacenter, 17% est un trafic entre l utilisateur et le datacenter, et enfin, 7% est un trafic entre différents datacenters. 76% du trafic global du Cloud Computing reste dans le datacenter, ceci est dû entre autres à la séparation des serveurs de calcul et des serveurs de stockage, ainsi qu à la réplication et la sauvegarde des données. Cette énorme quantité de données qui circule dans le datacenter, impose de revoir la communication en son sein. En plus de la quantité de données, il y a le nombre important de clients par datacenter. Ceux-ci imposent de nouvelles contraintes aux opérateurs cloud, ainsi, avec ce nombre important de clients, il est essentiel de garantir le passage à l échelle. Il est tout aussi primordial de pouvoir isoler le trafic de chaque client dans un réseau qui lui est privé. Avec toute la quantité de trafics internes dans un datacenter, les opérateurs cloud ont besoin d un protocole réseau capable de maximiser les débits entre les nœuds avec des connections any to any non bloquantes. Enfin, les opérateurs ont besoin de mécanismes permettant la continuité de service tels que la migration des VMs et l auto configuration pour la reprise après panne. Tout ceci devrait idéalement se faire avec un minimum de configurations. Ces nouvelles contraintes, notamment celles de l isolation et du passage à l échelle, nous imposent de revoir la couche réseau des datacenters, pour qu elle puisse les gérer. Afin d aboutir à cet objectif ultime, et après l évaluation des procédés existants dans le but d isoler le trafic de deux clients au sein d un même datacenter virtualisé, nous avons pu détecter un ensemble de points qui nécessitaient une adaptation aux nouvelles exigences des réseaux dans un environnement Cloud computing. Nous avons, pour cela, adopté une démarche ascendante en partant des contraintes que doit respecter un nœud physique pour
CHAPITRE 1. 3 arriver à l architecture réseau d un datacenter virtualisé. 1.2 Contributions Le travail effectué dans le cadre de cette thèse a pour objectif d introduire un ensemble de mécanismes permettant de répondre aux différents besoins susmentionnés des opérateurs Cloud. Ces mécanismes permettent d aboutir à une isolation des réseaux dans un datacenter virtualisé tout en assurant le passage à l échelle de la couche réseau. Ainsi, notre contribution à travers cette thèse peut se résumer en trois parties essentielles. La première contribution se focalise sur l équité de partage des ressources réseau dans un même nœud physique. Elle consiste en un système d allocation dynamique de la bande passante. Il permet de maximiser l utilisation des réseaux dans le Cloud pour les clients qui en ont besoin, tout en respectant des contraintes de service minimum garanti pour les autres. Cet allocateur dynamique de la bande passante impose l utilisation de nouvelles formesdecontratsdeserviceousla[3].nousavonsdéfinitoutd abordunslas appuyant sur un intervalle de la bande passante [4]. Nous avons par la suite enrichi cet intervalle en le couplant avec une bande passante maximale en paquets par seconde [5]. L utilisation de ces SLA permet la diminution de l utilisation des ressources système lors de fortes charges, tout en garantissant à l ensemble des clients leurs SLA. En définissant des valeurs maximales pour la bande passante, ce système assure, également, une protection contre les attaques de dénis de service internes. Après avoir amélioré l équité de partage des ressources au sein d un même nœud physique, nous nous sommes focalisés sur les interconnexions réseau entre les différents nœuds physiques. Nous avons alors constaté l inadéquation de la couche L2 standard aux besoins du réseau d un datacenter. Nous avons étudié plusieurs alternatives et avons fini par adopter le protocole TRILL [RFC6325] [6], en effet le protocole TRILL introduit un nouveau équipement appelé RBridge combinant les avantages de la couche L2 et de la couche L3. Néanmoins, l approche de déploiement proposée dans l RFC 6325 ne nous semblait pas la plus pertinente. En effet, le déploiement des équipements TRILL pour interconnecter les nœuds physiques nous paraît moins intéressant que l implémentation du protocole directement au sein du nœud physique. Notre deuxième contribution consiste dans l adaptation du protocole TRILL pour l intégrer directement dans un nœud physique [7]. Cette approche permet d améliorer de façon considérable la capacité de passage à l échelle tout en assurant un premier niveau d isolation entre les réseaux des clients et le réseau de gestion.
4 CHAPITRE 1. Notre troisième contribution s articule au tour de la création de réseaux virtuels sur la couche réseau TRILL [8]. Ces réseaux virtuels permettent une création flexible de réseaux logiques qui ne souffrent pas des limitations des infrastructures réseau actuelles comme la limitation des 4096 segments de réseau logique du IEEE 802.1Q[9]. Ces limitations sont surmontées à travers l introduction d un identifiant VNI codé sur 24 bits. Cet identifiant est transporté dans le nouveau entête TRILL, permettant ainsi d atteindre un nombre de segments réseau logique dépassant les 16 millions, tout ceci sans aucune modification des domaines d administration niveau L2 déjà existants. L isolation des ces différents réseaux virtuels est effectuée tout d abord à travers un mécanisme de suppression au niveau du Rbridge destination. Puis dans un deuxième temps, en exploitant le plan de contrôle des RBridges, nous sommes parvenus à construire des arbres topologiques par VNI. Ceci à permis le confinement des flux d un VNI aux seuls RBridges concernés, permettant ainsi une isolation de bout en bout. Par ailleurs, cette solution appelée VNT(Virtual Network over TRILL), apporte une augmentation de la bande passante et une réduction de la latence, répond aux limitations des réseaux actuels (épuisement des VLAN, limite de la taille des tables de commutation des ToRs, manque de redondance des chemins dans les STP, etc) et assure une compatibilité ascendante avec les équipements niveau L2 actuels et les équipements qui supportent le protocole TRILL. 1.3 Plan de la thèse Ce manuscrit sera présenté de la manière suivante : Tout d abord nous débuterons à travers une description de l état de l art en définissant les datacenters virtualisés à travers une introduction au Cloud. Ensuite, nous dégagerons les différents défis à satisfaire afin d aboutir à un datacenter virtualisé efficace d un point de vue réseau. Une fois les défis dégagés, nous commencerons leur résolution en adoptant une démarche ascendante à travers la présentation des différentes contributions. Tout d abord, à travers le dimensionnement dynamique des capacités d émission des machines virtuelles (VMs). Ensuite, nous passerons à l intégration du TRILL au niveau des nœuds physiques à travers une présentation du protocole ainsi que le portage des équipements RBridges au niveau des nœuds physiques. Nous enchaînerons, par la suite, avec une description du VNT qui permettra d étendre la capacité de nombre de réseaux logiques dans un datacenter virtualisé. Enfin, pour conclure, nous allons résumer l ensemble des travaux effectués et présenter les perspectives à courts, moyens et longs termes.
Chapitre 2 Datacenter virtualisé Sommaire 2.1 Introduction.............................. 6 2.2 Cloud Computing........................... 6 2.3 La virtualisation............................ 9 2.3.1 Définition................................ 9 2.3.2 Terminologie.............................. 9 2.3.3 La mutualisation des ressources systèmes.............. 10 2.3.4 La virtualisation des réseaux..................... 12 2.4 Architecture réseau pour un datacenter traditionnel...... 13 2.4.1 Limitation d Ethernet (L2)...................... 13 2.4.2 Architecture réseau L2 + L3..................... 15 2.4.3 Réseau local virtuel (VLAN)..................... 16 2.5 Architecture réseau pour un datacenter virtualisé (VDC)... 16 2.5.1 Architecture du VDC......................... 16 2.5.2 Nouvelles recommandations...................... 18 2.5.3 Travaux de recherche sur les architectures réseaux pour un VDC. 20 2.6 Conclusion............................... 27 5
6 CHAPITRE 2. 2.1 Introduction Le Cloud computing est selon le NIST(Nation Institue of Standard and technology) [10] un modèle permettant un accès ubiquitaire, à la demande et via un réseau distant à un ensemble de ressources informatiques. Toujours suivant cette définition, ces ressources informatiques doivent pouvoir être acquises puis relâchées avec un minimum d opérations de configuration et une interaction minimale du fournisseur de services. Afin de fournir ces ressources informatiques suivant le modèle Cloud Computing, il est essentiel de les stocker dans des centres de données (datacenters). Pour fournir ces services via un réseau, il est crucial de connecter les datacenters à internet, mais il est aussi essentiel d interconnecter l ensemble des équipements du datacenter de manière convenable. Ces travaux de thèse vont se focaliser sur la partie réseau des datacenters d une manière ascendante en partant du fonctionnement du réseau au sein des ressources informatiques, pour arriver aux communications au sein d un même datacenter. Mais avant d entamer la présentation de ces travaux, il est essentiel d introduire le contexte général. Pour cela, nous allons d abord introduire plus en détail le concept de Cloud Computing à travers sa signification et l ensemble des services qu il fournit. Nous allons, ensuite, nous focaliser sur l une des principales technologies permettant l établissement du Cloud Computing qui est la Virtualisation. Nous allons présenter la signification de la virtualisation, définir un ensemble de terminologies relatives à la virtualisation et les types possibles de virtualisation. Nous allons, par la suite, introduire l architecture réseau des datacenters classiques. Enfin, nous allons présenter la notion de datacenters virtualisés (appelés aussi VDC) qui sont utilisés dans le contexte du Cloud Computing. Nous allons, pour cela, définir le VDC à travers la description de son architecture, puis, introduire l ensemble des recommandations qui nous semblent vitales pour l établissement d un VDC et énumérer, à la fin, les travaux les plus pertinents proposés afin d assurer l isolation réseau et le passage à l échelle des réseaux privés au sein d un VDC. 2.2 Cloud Computing Le Cloud Computing selon[11] et[12] est la concrétisation de l informatique comme service. En effet, le Cloud Computing est le déploiement des ressources informatiques en les offrant en tant que service permettant ainsi d éviter le surprovisionnement des ressources physiques pour des tâches qui n en requièrent pas tant et le sousprovisonnement des services dont la croissance n était pas espérée. Le terme Cloud Computing désigne à la fois le service offert aux clients ainsi que les ressources matérielles et logicielles nécessaires pour offrir ce service.
CHAPITRE 2. 7 Les centres de données offrant des services de Cloud Computing sont alors appelés Cloud, ce terme regroupe à la fois les composantes logicielles et matérielles des centres de données. Il existe plusieurs sortes de Cloud [10], on retrouve : Le Cloud public qui comme son nom l indique est un Cloud ouvert à toutes sortes de clients dans un modèle de payement à la demande. Google Application Engine [13] et Amazon EC2 [14] sont des exemples de Cloud public. Le Cloud privé, ce type de Cloud est un Cloud dédié à une entreprise ou à une organisation pour ses propres besoins. l accès à ce type de Cloud n est pas autorisé au public mais uniquement à un groupe prédéfini de personnes appartenant à l entité qui gère le Cloud. Windows Azure [15] est une des solutions utilisées pour mettre en place ce type de Cloud. Le Cloud hybrid est une combinaison entre le Cloud privé et le Cloud public, concrètement c est l utilisation d un ou plusieurs Clouds privés associés à un ou plusieurs Clouds publics, un exemple serait l utilisation d un Cloud privé avec un stockage en Cloud public. Le Cloud communautaire[16] est un ensemble d infrastructures partagées entre différentes organisations qui soutiennent une certaine communauté avec des besoins partagés un exemple de Clouds communautaires c est celui initié par les hôpitaux de Toronto [17] Quelque soit le type du Cloud utilisé les services qu il offre peuvent varier selon les besoins des utilisateurs. Afin de mieux comprendre les types de services susceptibles d être fournis par un cloud, il est essentiel de décrire l architecture d un Cloud présentée par la figure 2.1. Ainsi il est possible d avoir les types de services suivants [10] : SaaS (Software as Service) : ou logiciel comme service, dans ce type de service le fournisseur du Cloud a le contrôle de toute l infrastructure ainsi que des systèmes d exploitations et du logiciel dont le client va se servir, le client n aura le contrôle que sur une partie des données, celle qu il fournira au logiciel. PaaS (Platform as a Service) : ou plateforme comme service, dans ce type de service le client aura un contrôle restreint sur les logiciels de base typiquement des options de configuration. En revanche il aura un contrôle total sur le code applicatif à exécuter ainsi que sur les données qu il fournira à ce code applicatif. IaaS (Infrastructure as a Service) : ou infrastructure comme service, dans ce type de service le client aura le contrôle total du système d exploitation de son instance et
8 CHAPITRE 2. Figure 2.1 Les types de services fournis par le Cloud Computing de ce fait il aura aussi le contrôle total sur l ensemble des logiciels de base, des codes applicatifs à exécuter et bien sûr, sur les données qu il pourra fournir à ses codes applicatifs. L architecture d un Cloud se base sur un composant essentiel afin de pouvoir offrir ses différents services aux clients finaux. Ce composant essentiel est la virtualisation. Cette couche permet l exécution simultanée de plusieurs systèmes d exploitation sur le même environnement matériel. Il est donc essentiel afin de mieux comprendre le fonctionnement du Cloud Computing d introduire la notion de virtualisation.
CHAPITRE 2. 9 2.3 La virtualisation 2.3.1 Définition La virtualisation en termes simples est une technologie permettant le représentation d un équipement physique en un ensemble d autres équipements virtuels. Ainsi au travers de la virtualisation, il devient possible de faire cohabiter plusieurs environnements d exécution sur la même infrastructure physique. Ces environnements d exécution seront isolés les uns des autres, c est à dire aucune interaction entre ces différents environnements ne sera possible. Pour réaliser cette isolation, chacun de ces environnements aura sa propre perception du système. Cette technologie n est pas une invention récente. En effet, la mutualisation des ressources systèmes est une problématique classique qui est étudiée depuis une cinquantaine d années maintenant. La virtualisation des systèmes a commencé depuis les années soixante [18] où en absence d ordinateurs personnels, il fallait permettre à plusieurs utilisateurs de partager le même super ordinateur. Mais avec les performances des machines actuelles et les coûts de maintenance élevée, la virtualisation revient au devant de la scène avec de nouvelles problématiques. 2.3.2 Terminologie Afin d introduire le concept de virtualisation, nous devons d abord introduire un ensemble de termes techniques nécessaires à la compréhension du concept. Nous désignerons l ensemble des équipements physiques hébergeant des instances virtuelles comme nœuds physiques. Afin de permettre l exécution de plusieurs systèmes d exploitation en parallèle sur un nœud physique, il est nécessaire d avoir un Hyperviseur. L hyperviseur est un pseudo système d exploitation permettant la coordination entre les différents systèmes d exploitation. L hyperviseur peut aussi être désigné par VMM (Virtual Machine Manager) ou en Français GMV (Gestionnaire des Machines Virtuelles). Le terme VM (Virtual Machine) ou MV (Machine Virtuelle) désigne l ensemble des instances virtuelles s exécutant par dessus l hyperviseur, ces instances possèdent des composants virtuels. Parmi les composants virtuels d une VM on trouve principalement une mémoire virtuelle, une ou plusieurs CPU appelées vcpu pour virtual cpu et enfin des interfaces réseau virtuelles appelées vif pour virtual interface.
10 CHAPITRE 2. 2.3.3 La mutualisation des ressources systèmes La virtualisation a tout d abord été utilisée dans le but de la mutualisation des ressources systèmes. Elle a ainsi permis de décomposer les ressources systèmes en un ensemble de ressources virtualisées fournies simultanément à plusieurs clients. Afin de mettre en place cette mutualisation, plusieurs techniques peuvent être utilisées. Nous dégageons parmi elles les trois suivantes : la virtualisation par conteneurs [19] la para virtualisation [20] la full virtualisation [21] ou virtualisation complète. 2.3.3.1 La para virtualisation La para virtualisation ou pseudo virtualisation, est un type de virtualisation utilisant un Hyperviseur. Au dessus de l Hyperviseur, plusieurs systèmes d exploitation cohabitent. Parmi ces instances, il existe une qui est particulière appelée DOM0. Cette instance privilégiée est la seule ayant un accès direct aux périphériques, les autres instances doivent être modifiées et leurs interruptions matérielles doivent être converties en interruptions logicielles. Ainsi au niveau des OS modifiés, toutes les instructions sont modifiées avant d être transmises à l Os privilégié. Ces derniers en recevant les interruptions logicielles, les convertissent en interruptions matérielles avant de les transmettre aux périphériques. Ils permettent ainsi aux OS non privilégiés d accéder aux périphériques. Une telle technique de virtualisation impose la modification du code des OS qui y seront hébergés. Un exemple d Hyperviseur utilisant la para virtualisation est Xen [22]. 2.3.3.2 La virtualisation complète La virtualisation complète ou full virtualisation ou encore virtualisation matérielle se base aussi sur le déploiement du pseudo système d exploitation Hyperviseur. Mais contrairement à la para virtualisation, les OS ne sont pas modifiés dans un tel système. En effet dans ce genre de système, un type particulier de nœuds physiques est utilisé. Ces nœuds doivent avoir des composants capables de supporter la virtualisation tels que les processeurs de la famille intel-vt [23]. Dans de tels systèmes, les interruptions matérielles des OS non privilégiés ne sont pas converties en interruptions logicielles et sont directement envoyées aux périphériques. Grâce au caractère spécifique du matériel utilisé, les OS non privilégiés ne sont pas modifiés et se comportent comme s ils étaient dans un environnement non virtualisé. L hyperviseur grâce aux particularités matérielles pourra gérer les interrup-
CHAPITRE 2. 11 tions envoyées par l ensemble des Os. Plusieurs Hyperviseurs supportant la virtualisation matérielle existent tels que KVM [24], Virtual Box [25] ou encore VMware [26]. 2.3.3.3 La virtualisation par conteneurs La virtualisation par conteneurs [19] consiste à déployer un système d exploitation (OS) virtualisé. Ce système est partagé entre plusieurs instances. En outre ces différentes instances, s exécutant en parallèle, se partagent un ensemble de librairies d une manière sécurisée. L architecture d un système utilisant la virtualisation par conteneur est illustrée par la figure 2.2 extraite de [19]. Ce type de virtualisation se base sur la présence d une VM host possédant un accès privilégié au système, d autres VM s exécutent sur le même OS en utilisant les librairies exposées par le système. Un exemple de système utilisant la virtualisation par conteneur est Linux VServer [27]. L isolation entre les différentes VM est effectuée à travers l isolation des trois composants, à savoir le CPU, les I/O et le stockage. Tout d abord, afin d effectuer une isolation entre les différents CPU un filtre TBF (Token Bucket Filter) est déployé au dessus de l ordonnanceur standard de CPU linux. Chaque VM possède un nombre de crédits; à chaque fois qu un processus associé à une VM est exécuté pendant un intervalle donné, le crédit est décrémenté. Une fois ces crédits épuisés, l ensemble des processus associé à cette VM est enlevé de la file d attente du CPU. Ces processus sont repris une fois que la VM a acquis suffisamment de crédits. Concernant l isolation des I/O, cette dernière est effectuée de la manière suivante, grâce à l utilitaire Trafic Control de linux [28], une file d attente de type HTB (Hierarchical Token Bucket) est crée. Pour chaque VM, un débit est réservé grâce à ces files d attentes. Concernant les I/O de stockage, ces derniers sont gérés grâce à l ordonnanceur Linux CFQ (Completely Fair Queuing). Enfin concernant le stockage, Vserver permet de définir une limite de la quantité de mémoire associée à chaque VM. Pour le stockage, les limites suivantes peuvent être définies: le nombre maximum de RSS (Resident Set Size) le nombre de pages anonymes (ANON) le nombre de pages qui peuvent être bloquées en mémoire en utilisant le mlockc() et mlockall() que des processus peuvent avoir dans une seule VM (MEMLOCK) Ainsi contrairement à la virtualisation avec l utilisation d Hyperviseur (para virtualisation et virtualisation complète), la virtualisation par conteneurs n exige que l utilisation d une seule image.
12 CHAPITRE 2. Figure 2.2 Architecture de Vserver 2.3.4 La virtualisation des réseaux La virtualisation des systèmes est la premier type de virtualisation à voir le jour. Mais ultérieurement avec l émergence d un besoin de changement globale dans les réseaux actuels un nouveau type de virtualisation vit le jour, c est la virtualisation des réseaux. Ce nouveau concept fut proposé afin de remédier aux différentes problématiques structurelles et conceptuelles que pose l expansion de l Internet [29]. Le principe d une telle virtualisation est assez simple. Il propose de subdiviser un réseau physique déjà existant en un ensemble de réseaux de protocoles indépendants tout en étant isolés les uns des autres. Un tel principe se base sur la virtualisation de deux composantes essentielles à savoir la virtualisation des routeurs (nœuds) et la virtualisation des liens [30]. 2.3.4.1 la virtualisation des routeurs (nœuds) Afin d aborder la virtualisation des réseaux, il est essentiel de commencer par la virtualisation des routeurs [31] [32]. Suite à l émergence de plusieurs routeurs applicatifs tels que Quagga[33], XORP[34], ou Click[35], il est devenu assez simple de s affranchir des routeurs traditionnels au profit de tels routeurs software. Il est alors apparu comme évident qu il serait possible de déployer sur une même machine physique plusieurs VM avec les logiciels de routages différents, permettant ainsi à chaque client d avoir une gestion de son propre réseau. C est ainsi que suivant ce principe plusieurs recherches ont été menées notamment parmi lesquels le projet VRouter [36]. D autres recherches comme la plateforme PlanetLab [37] optent pour la séparation du plan
CHAPITRE 2. 13 de contrôle du plan de données et utilisent des processus réseau pour un traitement rapide des paquets. 2.3.4.2 La virtualisation des liens La virtualisation des liens est un autre volet de la la virtualisation des réseaux. Un lien virtuel représente le lien interconnectant deux nœuds virtuels. Ce lien peut correspondre à un lien physique ou bien à l association de plusieurs liens physiques. La virtualisation des liens s intéresse à l association optimales des liens physiques avec les liens virtuels. Ce problème d association des liens physiques/virtuels revient à un problème d association des topologies virtuelles avec la topologie physique. DesétudesontétémenéesdanscedomainecommeZhuetal[38]quimodélisentleproblème sous forme de graphe et proposent deux variantes de cet algorithme. La première variante est une association sans re-configuration, la deuxieme est une association avec re-configuration. 2.4 Architecture réseau pour un datacenter traditionnel 2.4.1 Limitation d Ethernet (L2) De nos jours, les réseaux Ethernet sont les réseaux les plus utilisés par les opérateurs du Cloud pour interconnecter les nœuds physiques au sein d un datacenter. Cette popularité est entre autres due à la simplicité du fonctionnement de l Ethernet et à la facilité de ses opérations de configuration. En effet, dans un réseau Ethernet chaque interface de chaque nœud physique possède une adresse MAC, unique. Les bridges Ethernet interconnectant les nœuds physiques vont automatiquement découvrir ces adresses MAC et les associer à un port donné. Cet apprentissage automatique permettra de créer au niveau de chaque Bridge une table de commutation. Ces Bridges vont ainsi permettre la commutation des paquets niveau Ethernet à travers leurs tables de commutation. Les règles de commutation sont assez simples. A chaque fois qu un paquet atteint un bridge donné, ce dernier mémorise son adresse source et l associe au port par lequel il l a reçu dans sa table de commutation. Ainsi lors de la décision de commutation, le bridge cherche l adresse destination, s il la trouve associée à un port il commute le paquet vers ce port. En revanche, si l adresse de destination n est associée à aucun port ou si elle est de type diffusion (ff :ff :ff :ff :ff :ff) le bridge duplique le paquet et le commute sur tous les ports mis à part le port source. Cette simplicité dans le fonctionnement implique un inconvénient. En effet, Les paquets Ethernet ne possèdent pas une limite de nombre de sauts comme c est le cas pour
14 CHAPITRE 2. les paquets IP, donc en cas d existence d une boucle toute l infrastructure s effondre instantanément. Dans le cas d une boucle, les paquets en brodcast ou vers une destination inconnue seront dupliqués à chaque arrivée à un bridge puis à cause de la boucle les paquets seront dupliqués de nouveau jusqu à ce que le nombre total des paquets dupliqués dépasse la capacité de commutation des bridges entraînant ainsi des ruptures de liens. Afin de remédier à toute éventuelle boucle dans les interconnections physiques, le protocole Spanning Tree Protocol (STP) [39] assure un réseau sans boucle. Pour les enlever, le protocole STP transforme tout type de topologie, en une topologie logique en arbre. Cette topologie logique, permet la désactivation des éventuels ports des bridges causant d éventuelles boucles laissant ainsi une seule connexion entre chaque deux nœuds physiques. L algorithme STP se base sur des priorités pour chaque port pour déterminer quels ports permettront de commuter les paquets et lesquels seront bloqués. Ces priorités peuvent être configurées ou non. en cas de non configuration, ce sont les adresses MAC qui seront pris comme référence pour départager deux ports. L algorithme STP permet ainsi de garder la simplicité de fonctionnement du réseau Ethernet. Il permet ainsi une extension très simple du nombre de bridges avec zéro configuration. Dés le branchement d un nouvel équipement, ce dernier trouvera automatiquement sa position dans l arbre logique représentant le topologie grâce à la priorité associée à ses ports. Entre autres, cette unicité d adressage MAC permet une migration transparente des VMs dans un même réseau Ethernet. Cependant, dans un contexte Cloud, les réseaux Ethernet sont confrontés à des défis de taille. Tout d abord, les réseaux de type Ethernet se basent sur l inondation du réseau par des paquets broadcasts afin de construire les tables de commutation. Or dans un datacenter avec des dizaines de milliers de VM, cette quantité de paquets inondés sur tous les bridges surcharge énormément la table de commutation de ces derniers. D ailleurs cette dernière est généralement sauvegardée dans une mémoire de type CAM ( Content Addressable Memory) afin d avoir des temps de réponses assez courts. Les mémoires CAM étant assez chères, il se révèle très coûteux de remplacer les bridges d un datacenter par d autres ayant des mémoires CAM plus grandes afin de répondre à l augmentation du nombre de MAC des VM. Ensuite, le protocole STP se base sur la désactivation des ports des bridges, c est à dire la suppression pure et simple des liens causants une boucle dans le réseau. Or dans le contexte d un datacenter les besoins en bande passante sont très importants et nécessitent l existence de plus d un lien entre deux bridges. De plus le protocole STP se révèle très pénalisant si nous prenons en considération les besoins de redondance de lien pour pallier
CHAPITRE 2. 15 Figure 2.3 Architecture réseau conventionnelle d un datacenter d éventuelles pannes. Enfin, à grande échelle, les paquets des protocoles de diffusion se révèlent coûteux en terme de quantité de trafics. Nous entendons par protocole de diffusion les protocoles tels que l ARP (Address Resolution Protocol) pour la résolution d adresse IP ou le DHCP (Dynamic Host Configuration Protocol ) pour la configuration automatique des adresses IP. Ces paquets en diffusion vont atteindre tous les nœuds physiques dans un même réseau Ethernet ce qui entraînera à la fois une congestion des liens, et d autre part une consommation supplémentaire au niveau des nœuds physiques non concernés par ce trafic. Exemple : selon [40] un millions de machines (VMs) générera plus de 468,240 ARP par seconde soit l équivalent de 239 Mbits par seconde. 2.4.2 Architecture réseau L2 + L3 Les problématiques de la couche L2 du réseau que nous venons de présenter impose la segmentation de la couche L2 standard dans un même datacenter afin de limiter le domaine de diffusion (paquets en broadcasts). Si nous voulons construire une topologie comprenant un seul segment couche L2 pour l ensemble du datacenter, ceci serait quasi impossible avec la couche liaison actuelle. En effet, comme nous l avons déjà mentionné un trop grand nombre de nœuds physiques dans un même segment Ethernet risque de congestionner les tables de commutations des commutateurs. Afin de remédier à cette problématique, les architectures standards adoptées dans un datacenter se composent de la manière suivante : tout d abord, un ensemble de nœuds physiques est relié à un premier commutateur appelé ToR [41](Top of the Rack switch) ce ToR connecte l ensemble des nœuds physiques contenus dans un même Rack.
16 CHAPITRE 2. L ensemble des ToR est connecté à d autres commutateurs plus performants appelés AS (Aggregation switch) cette couche d agrégation rassemble les trafics d un ensemble de ToR tout en permettant un redondance des liens entre les ToR et les CR comme l illustre la figure 2.3. Enfin dans le dernier niveau ( le niveau cœur), se trouve les CR (Core Router). Les CR permettront la connexion des AS vers internet, les CR étant des éléments de réseau de niveau 3, il devient possible de faire des boucles pour pouvoir garantir une redondance des liens. 2.4.3 Réseau local virtuel (VLAN) Le réseau local virtuel ou VLAN(Virtual Local Area Network) est un concept permettant la subdivision d un réseau physique existant en un ensemble de réseaux virtuels indépendants les uns des autres. Afin de réaliser la différenciation des différents réseaux virtuels, un tag sur 16 bits est utilisé. Ce tag de 16 bits est composé de deux parties, les premiers 4 bits qui spécifient la priorité, puis les 12 autres bits qui spécifient le numéro du VLAN. Il devient ainsi possible de décomposer un réseau Ethernet en 4095 réseaux virtuels. L ajout et la suppression des tags VLAN sont effectués au niveau des ports des commutateurs. Si un port ne supporte pas un VLAN donné le paquet est détruit au niveau de ce port. C est ainsi qu il devient possible d isoler l ensemble des réseaux virtuels. L utilisation des VLAN permet ainsi plusieurs fonctionnalités dont : La sécurisation d un réseau La segmentation des réseaux L isolation des réseaux L ajout d une pseudo QoS à travers la priorité du VLAN Mais ce nombre de 4095 VLAN qui est plus que suffisant dans un réseau Ethernet Standard devient largement sous dimensionné dans un réseau de datacenter. En effet, un datacenter de taille standard est capable de servir des dizaines de milliers de clients en parallèle. IL devient alors évident que pour effectuer un isolation réseau entre les différents clients, l utilisation des VLAN est complètement inadaptée. 2.5 Architecture réseau pour un datacenter virtualisé (VDC) 2.5.1 Architecture du VDC Un VDC ou datacenter virtualisé possède une architecture spécifique. Elle est illustrée par la figure 2.4. Trois éléments essentiels forment les piliers d un VDC, ces trois éléments sont :
CHAPITRE 2. 17 Figure 2.4 Architecture d un datacenter virtualisé Une architecture réseau L2 + L3 Un ensemble de serveurs de calcul Un ensemble de serveurs de stockage (filer) Nous avons déjà évoqué l architecture réseau L2 + L3 spécifique à un VDC dans la partie 2.4.2. Cette architecture réseau se caractérise par trois couches à savoir : La couche d accès. La couche d agrégation. La couche cœur du réseau. Un deuxième pilier de cette architecture, c est l ensemble des serveurs de calcul. Nous désignerons ces serveurs par nœuds physiques. Les nœuds physiques hébergent les VMs. Ils fourniront aux VMs les ressources nécessaires en CPU et en mémoire vive. Enfin le dernier pilier c est l ensemble des serveurs de stockage. Ces serveurs hébergent les disques de données des VMs. Ils sont essentiels pour permettre une séparation entre la VM et les données qu elle contient. Ainsi, en cas de défaillance du serveur hébergeant la VM, il n y a pas de risque de perte de données, de plus, la reprise après panne peut se faire directement en redémarrant le disque de VM sur un autre serveur de calcul. Il est bien sûr essentiel que les serveurs de stockage soient redondants pour éviter les éventuelles pertes
18 CHAPITRE 2. de données. Une fois l architecture d un VDC présentée, nous passons à la présentation de notre vision des principales recommandations à satisfaire pour le bon fonctionnement d un datacenter. 2.5.2 Nouvelles recommandations Contrairement aux centres de données (datacenters) classiques, les centres de données virtualisées ou VDC requièrent des exigences complexes afin de satisfaire les besoins demandés. Ces exigences complexes nous poussent à préconiser les recommandations suivantes pour tout VDC : La mobilité des VMs La connectivité any to any non bloquante La tolérance aux pannes Le passage à l échelle La simplicité de gestion Les réseaux privés. Nous tenons à préciser que l ensemble de ces recommandations ne constitue pas une liste exhaustive des exigences à satisfaire pour un VDC. Ce sont celles que nous avons jugés les plus intéressantes et les plus importantes pour le bon fonctionnement d un VDC. 2.5.2.1 Mobilité des VMs Un VDC doit être conçu de manière à permettre la mobilité des VMs. En effet, il doit permettre la migration des VMs de manière transparente. Aussi, cette migration ne doit pas être limitée ni dans le nombre ni dans l emplacement de destination dans le datacenter. Elle pourra être déclenchée de manière manuelle ou automatisée. Elle est essentielle afin de permettre un ensemble d opérations; telles que l optimisation de l utilisation des ressources, l exécution des maintenances ou même pour satisfaire des besoins d économie d énergie. Pour permettre à cette migration de se dérouler de manière transparente, il est primordial que les VMs ne changent pas de plan d adressage suite à une migration. Il est aussi essentiel que ces VMs ne changent pas leurs politiques de sécurité suite à une telle opération.
CHAPITRE 2. 19 2.5.2.2 Connectivité any to any non bloquante Le routage au sein d un VDC doit permettre une communication any to any entre l ensemble des nœuds physiques. Le protocole de routage devra assurer l établissement d un ou plusieurs chemins entre deux nœuds physiques en utilisant les liens physiques disponibles entre eux. Avec une demande toujours plus accrue en bande passante, le VDC devra garantir une connectivité riche afin d augmenter la bande passante agrégée et éviter la congestion des liens à travers l utilisation d un routage multi-chemin. L objectif ultime est d arriver à représenter l ensemble des liens comme un seul commutateur géant permettant l interconnexion de tous les nœuds physiques d une manière non bloquante. 2.5.2.3 Tolérance aux pannes Dans un VDC la défaillance ne doit pas être considérée comme une exception mais comme une règle. En effet, à cette échelle la défaillance est inévitable. Donc, un VDC doit être capable de détecter, diagnostiquer et de résoudre les défaillances sans intervention extérieure. Cette tolérance aux pannes doit couvrir à la fois les liens physiques, les switches, les nœuds physiques et enfin les VMs. La défaillance d une VM ou d un nœud physique peut être corrigée par la migration transparente, mais la défaillance d un lien physique ou d un commutateur ne peut être réalisée qu à travers la représentation des différents liens physiques comme un commutateur géant non bloquant, permettant ainsi d établir plusieurs chemins possibles entre chaque couple de nœuds physiques. 2.5.2.4 Passage à l échelle La définition même du Cloud impose de concevoir un VDC capable d augmenter de manière considérable le nombre de VMs, de liens et d interfaces qu il accueille. Ceci implique que le VDC devra pouvoir gérer une surcharge considérable du nombre de VMs et ce qui en résulte d augmentation d adresses MAC et IP. Dans le cas d une telle augmentation, il faut gérer de manière très prudente la saturation possible des mémoires des commutateurs. En effet, dû à leur coûts de production élevés, les mémoires des commutateurs ont tendance à être très limitées. La saturation de ces mémoires est assez dangereuse du fait du principe de fonctionnement des commutateurs. Effectivement, ce principe de fonctionnement engendre une inondation des paquets dont la destination est inconnue. Avec la saturation des mémoires des commutateurs, chaque nouvelle adresse enregistrée implique la suppression d une ancienne adresse ce qui entraînera l inondation des paquets destinés à l ancienne adresse. À terme, ceci peut entraîner l arrêt total du réseau du VDC à cause du nombre important de paquets inondés. Afin d éviter ce genre de phénomène, les VDC ont deux choix possibles :
20 CHAPITRE 2. Remplacer les anciens commutateurs par des nouveaux avec des mémoires plus importantes, mais ceci impliquerait une augmentation du coût pour le client final. Trouver des solutions pour éviter la saturation des mémoires des commutateurs. 2.5.2.5 Simplicité de gestion Vu la taille et le caractère critique d un VDC, l ensemble des opérations de gestion doit être simplifié au maximum. En effet, le VDC doit être capable de gérer d une manière transparente les migrations des VMs sans impliquer de nouvelles configurations. Il doit pouvoir gérer automatiquement les changements qui peuvent intervenir dans l infrastructure physique ainsi que son redimensionnement avec l ajout ou la suppression de plusieurs nœuds physiques. Tout ceci doit se faire d une manière automatique sans devoir passer par des configurations complexes. 2.5.2.6 Réseaux privés Il faut que le VDC puisse être capable d offrir aux clients finaux des fonctions automatisées leur permettant de construire des réseaux privés. Ces fonctionnalités doivent assurer la construction des réseaux aussi bien simples que complexes. Les réseaux privés doivent permettre d isoler les clients les uns des autres. Ils peuvent ainsi limiter la propagation des paquets unicasts et multicasts de chacun des réseaux dans un domaine donné. Le VDC permet ainsi de restreindre les flux d un client donné aux seuls ports (interfaces) appartenant à ses VMs. Enfin, le VDC est tenu d offrir un nombre suffisant de réseaux privés pour répondre aux besoins de tous ses clients. 2.5.3 Travaux de recherche sur les architectures réseaux pour un VDC Nous avons présenté un ensemble de recommandations pour le bon fonctionnement des VDC. Cet ensemble de recommandations peut se distinguer en deux catégories principales : Le passage à l échelle Les réseaux privés. Chacune des recommandations précédentes peut être classifiée sous l une ou l autre ou bien les deux catégories. Plusieurs études récentes ont essayé de satisfaire un ensemble de critères afin d aboutir à la réalisation de l un de ces critères ou bien les deux. Nous allons dans ce qui suit présenter une illustration des ces recherches à commencer par celles proposant une satisfaction du critère du passage à l échelle.
CHAPITRE 2. 21 2.5.3.1 Passage à l échelle Le premier critère à avoir été pris en considération était le passage à l échelle. Ainsi, plusieurs études se sont concentrées sur la résolution de l ensemble des problèmes reliés au passage à l échelle. Par exemple Portland [42] [43] suggère l utilisation d une nouvelle couche de liaison. C est ainsi que Portland suggère la modification de l entête MAC. Il faut tout d abord préciser que le protocole portland n est valable qu avec un seul type d architecture à savoir l architecture Fat Tree. Il se base ainsi sur les caractéristiques de cette architecture pour effectuer les opérations de routage. En effet, ce protocole remplace les entêtes MAC par des entêtes (pseudo MAC) PMAC spécifiant la position des VMs. L adresse MAC étant codée sur 48 bits, Portland utilise ces bits pour convertir l adresse MAC destination en un codage spécifiant la position sous la forme : pod.position.port.vmid. Les 16 premiers bits servent à identifier le numéro de pod destination, les 8 bits suivants permettent de déterminer la position du switch local vers la destination, les 8 bits qui suivent servent à déterminer le numéro du port dans le switch menant vers la destination et enfin, les 16 derniers bits servent d identifiant de la VM destination. Ce type de procédé permet un adressage hiérarchique des VMs. Afin de garantir ce fonctionnement, les commutateurs de bordures effectuent le changement des PMAC vers les MAC et vis versa. Les positions des commutateurs peuvent, soit être définies manuellement, soit assignées automatiquement en recourant à un serveur LDP[44] (Location Discovery Protocole). Reste alors le problème des adresses en diffusion ARP(Address Resolution Protocol)[45]. Afin de résoudre correctement les paquets de protocole ARP, un contrôleur centralisé est rajouté à la topologie. Ce contrôleur centralisé appelé Fabric Manager. Les commutateurs de bordures transmettront toutes les requêtes ARP au Fabric Manager. Le Fabric Manager jouera le rôle d un proxy ARP en fournissant l adresse PMAC correspondante à une IP donnée. En cas de non présence de la correspondance au sein la table du Fabric Manager, la solution de repli est d inonder la requête ARP sur tous les commutateurs. Bien que le protocole Portland propose une méthode de routage L2 qui soit sans boucles, cette solution reste dépendante de la topologie. Elle n est applicable qu au sein de la topologie de type multi-rooted fat-tree et ne peut pas être adaptée à d autres types d architectures. De plus, le caractère centralisé de la résolution des ARP rend les datacenters utilisant Portland dépendants du Fabric Manager. Ceci, impose l accord d une attention particulière à cet élément du réseau. En effet, la défaillance ou bien une attaque malicieuse sur le Fabric Manager peut générer une interruption du réseau.
22 CHAPITRE 2. À la différence de Portland, le protocole SPB (shortest path bridging) ou 802.1aq [46] ne modifie pas les entêtes des adresses MAC déjà existants. Mais en revanche, il rajoute un nouvel entête avec des adresses MAC identifiant les nœuds physiques hébergeant les VMs ou des identifiants des VLAN. Le SPB requiert l utilisation d un plan de contrôle. Le plan de contrôle utilisé est un démon IS-IS [47]. Il existe deux variantes de ce protocole : le SPBV(Shortest Path Bridging-VID) et le SPBM (Shortest Path Bridging-MAC) aussi appelé SPBB. Le SPBV utilise les identifiants de VLAN pour construire plusieurs arbres de diffusion selon le commutateur source, limitant ainsi la propagation des paquets multicasts. Le SPBM utilise l encapsulation MAC-in-MAC afin de n exposer aux commutateurs intermédiaires que les adresses MAC des commutateurs de bordures éliminant ainsi l apprentissage des adresses MAC des VMs. L apprentissage des correspondances des adresses MAC internes et externes est géré par le plan de contrôle. Concernant les paquets multicasts, ces derniers seront envoyés suivant des arbres de multicast déjà calculés au niveau du plan de contrôle. Le protocole SPB semble être une bonne alternative pour palier à cette problématique de la couche L2 standard, sauf que pour la propagation des paquets multicasts, ce protocole se base sur les informations fournies par le plan de contrôle sans prévoir de mécanisme de replis pour éviter les boucles en cas de réception de données erronées. Les Protocoles SPB et Portland proposent la modification de la couche liaison afin de palier les problèmes de la couche L2 standard. Il existe également d autres protocoles tels que Seattle [48] ou équipements tel que EtherProxy [49] qui proposent également de palier ces problèmes mais sans modifier les paquets d origine. Tout d abord, le protocole Seattle prend en considération les protocoles DHCP [50] et ARP comme origine des problèmes de passage à l échelle de la couche L2 standard. Ce protocole considère qu en absence des paquets multicasts de ces deux protocoles, le réseau standard peut passer à l échelle. C est ainsi que le protocole Seattle se propose de convertir les ARP en messages unicasts en utilisant une table de hash distribuée (distributed hash table) DHT [51]. Concernant le protocole DHCP, quand le commutateur de bordure en reçoit un, il l envoie en unicast au serveur DHCP. Seattle implémente ceci en utilisant un standard déjà défini pour agent de relais DHCP [52]. Pour finir, EtherProxy n est pas un protocole à implémenter au niveau du réseau mais plutôt un nouvel équipement réseau qui fera littéralement office de Proxy pour les protocoles
CHAPITRE 2. 23 nécessitant des paquets en diffusion. En effet, cet équipement réseau est conçu suivant le principe que la plupart des messages multicasts ne nécessite pas forcement d arriver à la destination ciblée par ce message pour pouvoir recevoir une réponse cohérente. EtherProxy fonctionne en suivant ce principe. Il doit être placé au plus près des commutateurs de bordures. Idéalement, il devra être placé en tant que relais entre les nœuds physiques et les commutateurs de bordures. EtherProxy va ainsi mémoriser au sein de son cache l ensemble des réponses à des messages multicasts. Une fois qu il reçoit un message multicast dont il connaît la réponse, il va répondre à la source du message avec les informations qu il a préalablement enregistrées. Il va également supprimer la requête reçue avant qu elle n arrive au commutateur de bordure. Ainsi, il aura éliminé tout le trafic que la requête aurait dû générer. En absence de réponse dans le cache du EtherProxy, ce dernier va envoyer une demande à la place de la source d origine pour obtenir une réponse. Une fois la réponse obtenue, il la sauvegardera dans son cache et répondra à la source d origine avec un message unicast. Bien que Seattle et EtherProxy arrivent à limiter les problèmes de montée en charge de la couche L2 du réseau, ils restent tous les deux focalisés sur les paquets multicasts générés par le protocole ARP et DHCP. Ils nécessitent encore l implémentation de solutions pour le reste des trafics multicasts. Enfin, Seattle bien qu il réduise les trafics multicasts, augmente par la même occasion les trafics en unicast à travers la conversion d un seul paquet multicast en N paquets unicasts. P our compenser les problématiques de montée en charge, d autres protocoles et procédés ont été proposés. Nous avons essayé de présenter dans cette sous section la variété des méthodes proposées pour aborder ce problème : Les méthodes avec modifications des paquets originaux. Les méthodes sans modifications des paquets originaux. Une fois ces différentes méthodes présentées, nous allons nous focaliser sur les différents mécanismes disponibles afin de réaliser des réseaux privés. Il est important de signaler que les différents mécanismes permettant l établissement des réseaux privés, permettent également de répondre à la montée en charge nous avons évité d aborder ces mécanismes dans la partie passage à l échelle pour éviter les redondances. 2.5.3.2 Réseau Privé Comme nous l avons déjà précisé, le passage à l échelle est l un des principaux défis des réseaux des VDC. Le deuxième plus gros défi auxquels sont confrontés les réseaux des datacenters, c est la possibilité d offrir des réseaux privés entre les instances d un même client. Derrière cette exigence qui peut paraître assez simple, se cache un niveau de complexité
24 CHAPITRE 2. Figure 2.5 Entête VXLAN insoupçonné. En effet dans un contexte cloud, une complexité de sécurité relative à la nature même du Cloud se rajoute. Vu la nature dynamique et partagée des ressources et plus spécifiquement du réseau, il est délicat d établir des réseaux privés. Un ensemble de travaux de recherche s est focalisé sur la problématique des réseaux privés. Une première approche consiste à encapsuler les paquets dans des paquets UDP. VXLAN [53] [54] par exemple se base sur l encapsulation des paquets avec un entête UDP. Ce nouveau entête UDP contient un champ addition contenant l entête VXLAN. Cet entête VXLAN contient un champ sur 24 bits exprimant le tag VNI (Virtual Network Identifier) ou identifiant de réseau virtuel. Ce tag permet d identifier le réseau privé du client. C est ainsi qu à travers ce tag, ce protocole permet une séparation entre les différents flux des différents réseaux. Afin de pouvoir réaliser cette différenciation entre les flux, il faut au préalable effectuer une assignation des tags et des entêtes UDP aux paquets originaux. Il faut aussi enlever ces nouveaux entêtes avant que la destination ne puisse les traiter. Pour réaliser ces fonctionnalités d encapsulation et de décapsulation, un nouveau équipement est nécessaire. Ce nouvel équipement fera office de passerelle délimitant ainsi le tunnel VX- LAN du réseau couche L2 classique. Cet équipement est appelé VTEP (VXLAN Tunnel End Points) ou point délimitant le tunnel VXLAN. À l intérieur du tunnel VXLAN, le paquet sera routé de manière classique suivant les adresses IPs contenues dans son entête UDP. Concernant les paquets de destinations inconnues ou bien avec une destination multicast, ces derniers seront émis vers un groupe multicast. Ainsi pour chaque VNI, il faut établir un groupe multicast afin que les paquets appartenant à un VNI donné soient envoyés vers l adresse multicast de ce groupe. VXLAN permet donc la séparation des différents flux des différents réseaux à travers une encapsulation avec un nouvel entête UDP, mais ce protocole comprend quelques inconvénients. En effet, il nécessite une configuration des groupes multicasts correspondant à chaque VNI d une part; d autre part et comme présenté dans son RFC [53], l encapsulation de la couche L2 avec un entête de la couche L3 expose le réseau du datacenter à de nouvelles problématiques de sécurité. Effectivement, les attaques depuis l extérieur qui
CHAPITRE 2. 25 Figure 2.6 Entête DOVE étaient impossibles quand les communications entre les nœuds physiques s effectuaient au niveau L2 deviennent maintenant possibles quand les nœuds communiquent en couche L3. Il faut ainsi bien concevoir son datacenter pour éviter de recevoir des paquets de couche L3 de l extérieur qui encapsulent des paquets malicieux de niveau L2. DOVE[55] [56] (Distributed Overlay Virtual Ethernet) utilise les mêmes principes que VXLAN à deux différences prés. La première est que le commutateur DOVE ou point d entrée au réseau DOVE est forcement déployé au niveau des nœuds physiques contrairement au VXLAN qui n impose pas cette exigence. La deuxième différence se situe au niveau des entêtes utilisés. En effet bien que les deux soient encapsulés par un entête UDP standard, l entête DOVE est différent de l entête VXLAN comme le montre la figure 2.5 [53] et la figure 2.6. L entête DOVE spécifie en plus du réseau privé utilisé l identifiant de l instance. NVGRE (Network Virtualization using Generic Routing Encapsulation) [57] ou Virtualisation réseau en utilisant une encapsulation de routage générique. Le principe de ce protocole est d encapsuler les paquets des clients avec des entêtes IP auxquels se rajoute un entête GRE. L entête GRE est décrit par la figure 2.7 issue de [57]. Le réseau de chaque client est identifié par un identifiant sur 24 bits appelé TNI (Tenant Network Identifier). Tout comme le VXLAN, NVGRE associe à chaque identifiant du client une adresse IP multicast. Cette adresse sera utilisée lors de l encapsulation des paquets Multicasts ou en diffusion. Tout comme DOVE et VXLAN, NVGRE implique plus de prudence dans les régles de sécurité du datacenter vu que ce dernier importe les failles de sécurité de la couche L3 vers la couche L2. Netlord [58][43]est un autre protocole utilisant l encapsulation des paquets dans des