Bref historique de la virtualisation
Le succès de la virtualisation s’est construit sur sa capacité à optimiser l’utilisation du hardware, réduire la multiplication des serveurs pour en maximiser le retour sur investissement. Cela fut réalisable grâce à la mutualisation et la virtualisation des ressources informatiques d’un serveur (CPU et mémoire RAM) afin de les partager parmi plusieurs applications virtualisées. A ce jour, 40 million(1) de machines virtuelles ont été déployées, ce qui démontre l’adoption de la technologie.
La technologie de migration des VM a été introduite en 2003, apportant avec elle une agilité construite sur le fondement de la mobilité et d’une installation flexible des VM. Le champ d’application et la capacité de cette technologie se sont par la suite développés, la rendant toujours meilleure et plus rapide. Il a fallu attendre 10 années de développement pour que la virtualisation soit vraiment utilisée telle qu’elle avait été conçue au départ.
Les défis de la virtualisation des réseaux
Cependant, malgré le développement continu des capacités de migration des VM, les défis posés aux réseaux continuent de se multiplier, à savoir :
- Reconfigurations onéreuses liées à la mobilité des VM
- Limitations de la virtualisation au-delà de la couche 2
- VLAN IDs non adaptés à l’extension des réseaux privés sécurisés
Finalement, la promesse d’une véritable agilité du SI reste partiellement atteinte. Les utilisateurs restent confrontés soit à une multiplication des serveurs virtuels, ou doivent dépenser près de 1 800 $ par migration de VM pour la reconfiguration de nombreux éléments du réseau lié à la migration. A l’évidence, les utilisateurs ont fait appel en priorité à la virtualisation pour la réduction des coûts matériels, et non pour gagner en agilité. De plus, les migrations de VM et les communications inter VM sont principalement réservées aux serveurs hôtes sur un ou plusieurs racks, appartenant tous à un seul et même segment LAN de couche 2, prérequis de base des communications inter-VM. Ajouté à cela, la limite des 4 096 VLAN ( 4094 + 2 ID restreints) empêche l’extension de groupes d’utilisateurs isolés et sécurisés dans une infrastructure cloud privée ou résident dans un cloud public/hybride.
Les réseaux Overlay à la rescousse
L’arrivée et le déploiement de réseau Overlay ont finalement permis aux administrateurs du réseau d’utiliser le potentiel de la virtualisation et d’apporter une véritable agilité au SI, jusqu’alors limitée au calcul et aux infrastructures de stockage. Comme l’indique une étude de VMware (3), ce n’est pas surprenant que la priorité pour 2015 est l’extension de la virtualisation au réseau et au stockage. Si l’on prend pour analogie, les dix années qu’il a fallu pour passer de DOS en 1985 à Windows 95 ont eu beaucoup plus d’impact dans l’amélioration de l’expérience utilisateur que la virtualisation du data center n’en a eu sur l’agilité du SI entre 2003 et 2012 !
Les réseaux Overlay : de quoi s’agit-il ?
Les réseaux Overlay, c’est d’abord construire un réseau virtuel de couche 2 au-dessus d’un réseau de couche 3, d’où le mot « Overlay ». Le trafic depuis une VM est mappé sur ce réseau virtuel. Les paquets du réseau sont encapsulés dans un format MAC-in-IP puis routés à travers l’infrastructure existante.
Il existe actuellement deux façons de construire des réseaux overlay qui ont été soumis à l’IETF (Internet Engineering Task Force) : le NVGRE (Network Virtualization using Generic Routing Encapsulation), soutenu par Microsoft et VXLAN (Virtual eXtensible Local Area Networks), soutenu par VMware. Ces deux standards sont conçus pour permettre la migration des machines virtuelles et ainsi garantir un déploiement à grande échelle dans le cloud :
- Le NVGRE encapsule les trames Ethernet L2 dans un paquet GRE
- Le VXLAN encapsule les trames Ethernet L2 dans un paquet UDP
Finalement, ces deux solutions encapsulent les trames Ethernet L2 dans un paquet IP et intègrent un identificateur de segment LAN de 24 bits (VNI). Cet identificateur peut faire fonctionner plus de 16 millions de sous-réseaux L2, ce qui augmente significativement l’évolutivité par rapport à la limite des 4 094 ID VLAN. Exemple de topologie d’une solution VXLAN:
Pourquoi cela a-t-il pris autant de temps pour répondre au problème de la mobilité des VM ?
Il n’y a rien de technologiquement avancé autour du réseau Overlay qui ne pouvait pas avoir été développé plus tôt. Les deux principales innovations, le tunneling et l’encapsulation MAC-in-IP, auraient pu être disponibles plus tôt et résoudre les problèmes évoqués précédemment.
Par exemple, l’OTV (Overlay Transport Virtualization) a rempli les mêmes objectifs d’extension des domaines de la couche 2 sur la couche 3, idem pour les WANs dans les commutateurs Cisco en 2009(5) et un effort de standardisation similaire autour des services LAN virtuels privés fut proposé en 2006 (6) à l’IETF !
Malgré ça, son adoption a pris son temps et le déploiement du réseau Overlay en 2012 est un cas courant. Comme le dit le proverbe : « Mieux vaut tard que jamais ! ».
Mobilité des VM – Tout est bien qui finit bien ?
Est-ce que l’arrivée de la technologie des réseaux overlay signifie que les défis liés à la mobilité des VM sont désormais résolus et que nous baissons le rideau sur le problème de l’agilité du SI ? Il est certain que les deux formats de réseau overlay gagnent de l’intérêt pour les Datacenters hautement virtualisés et permettent de tirer parti de la technologie de virtualisation tout en permettant aussi de déployer des réseaux à grande échelle. Toutefois, le fait de résoudre la mobilité des VM et la reconfiguration des réseaux a fait naître un autre problème. La mise en œuvre d’un réseau overlay dans le logiciel impose « une taxe CPU » sur le serveur, le privant des ressources initialement prévues à la consolidation des charges via la virtualisation !
Ce problème peut être résolu si l’on prend soin de choisir le bon adaptateur réseau (NIC) du serveur.
Recommandation : le choix des E/S réseaux du serveur est une décision stratégique
La plupart des interfaces réseaux intègrent des fonctions de décharge TCP/IP (TCP offload Engine) pour minimiser l’utilisation CPU du serveur et pour permettre d’augmenter la densité de virtualisation afin d’optimiser les retours sur investissements des serveurs. Cependant, les adaptateurs qui ne sont pas explicitement conçus pour prendre en charge la décharge des réseaux overlay n’assureront pas les fonctions de décharge TCP/IP. De telles cartes peuvent accroître l’utilisation CPU de plus de 50%, ce qui a un fort impact sur l’efficacité des serveurs et de l’évolutivité des VM.
Choisir une carte d’interface réseau prenant vraiment en charge le réseau overlay soulage votre data center dans vos efforts de virtualisation et vous emmène vers la mise en œuvre d’une infrastructure cloud privée ou hybride.
Vous avez patienté dix ans pour faire de la virtualisation un outil efficace pour l’agilité de votre SI ; ne perdez pas davantage de temps en faisant le mauvais choix de cartes réseaux (NIC) !
Citations:
- VMware Infographic
- Open Networking Summit 2012
- VMware CIO survey
- GRE IETF submission
- Data Center Virtualization Fundamentals
- MPLS IP IETF submission
puis