Virtualisation du réseau LAN Gi – À faire et à ne pas faire
Après de nombreuses années de discussions et de preuves de concepts, la virtualisation des fonctions réseau (NFV) passe désormais du stade conceptuel à celui de la réalisation.
Certains fournisseurs de services ont commencé à déployer des plateformes d’infrastructure NFV, tandis que certains d’entre eux ont déjà activé leurs premiers cas d’utilisation et applications compatibles NFV sur ces plateformes.
La virtualisation du cœur de paquets évolué (EPC) et du Gi LAN est l’un de ces cas d’utilisation qui bénéficie actuellement d’une forte traction industrielle.
Lors du déploiement d'un réseau local Gi virtuel, deux questions fondamentales doivent trouver une réponse. La première question concerne la consolidation : consolidons-nous plusieurs fonctions Gi LAN en une seule fonction de réseau virtuel (VNF) ou décomposons-nous complètement l'architecture Gi LAN en plusieurs VNF discrètes ?
La deuxième question concerne l’échelle. Comment pouvons-nous faire évoluer efficacement cette architecture, car une seule machine virtuelle peut ne pas fournir une capacité suffisante pour gérer la charge de travail du réseau local Gi ?
Afin de sécuriser et de monétiser leurs réseaux, les opérateurs mobiles ont déployé de nombreuses technologies différentes sur le LAN Gi, notamment, mais sans s'y limiter, l'optimisation TCP, l'optimisation vidéo, l'enrichissement des en-têtes, l'inspection approfondie des paquets, le pare-feu Gi et le NAT de qualité opérateur (CGNAT).
Historiquement, bon nombre de ces fonctions ont été déployées sur différentes plateformes, souvent auprès de fournisseurs différents. Au cours des dernières années, les opérateurs mobiles ont consolidé et simplifié leur architecture Gi LAN.
Grâce à la consolidation, les opérateurs mobiles ont pu réduire considérablement leur coût total de possession. Lors de la migration de cette architecture vers une plateforme NFV, qui repose sur du matériel courant disponible dans le commerce, il peut être tentant de commencer à décomposer l'architecture en différents VNF discrets, chacun dédié à une seule fonction.
Cette architecture décomposée a certainement du sens si les différentes fonctions du Gi LAN sont chacune applicables à un sous-ensemble très spécifique de flux. Sur la base des politiques commerciales via l'interaction avec une fonction de règles de politique et de facturation (PCRF), un moteur de classification de services intelligent qui se trouverait à l'entrée du LAN Gi peut déterminer quels flux doivent être dirigés et/ou chaînés vers des fonctions particulières qui sont déployées en tant que VNF distincts. Ces VNF n'auront alors plus qu'à traiter le trafic sur lequel ils doivent agir, ce qui se traduit par une répartition très efficace du trafic sur tous les VNF.
Cependant, si les fonctions Gi LAN doivent être appliquées à presque tout le trafic, cette décomposition des fonctions n'apporte aucune valeur. Prenons l’optimisation TCP et les pare-feu Gi comme exemples. Presque tout le trafic Gi LAN doit être traité par ces deux fonctions, donc les consolider dans un seul VNF entraîne des gains d'efficacité similaires à un déploiement physique.
En effet, il n’est pas nécessaire de disposer ici d’un classificateur de services intelligent pour effectuer une sélection VNF et il n’y a pas de passage obligé dans et hors de la couche SDN pour faire passer le trafic d’un VNF à l’autre. De plus, l'ajout d'une fonction de pare-feu sur une fonction d'optimisation TCP ajoute très peu de surcharge CPU, de sorte que la valeur de la consolidation s'applique toujours dans un environnement NFV .
Un autre défi est de savoir comment gérer des flux de travail plus volumineux que ce qu’un seul VNF peut gérer. Certains fournisseurs ont adopté l’approche permettant à un VNF d’être composé de plusieurs machines virtuelles (VM). La plupart des fonctions du réseau local Gi sont des opérations avec état, ce qui signifie que le trafic entrant et sortant pour les mêmes flux doit être traité sur la même machine virtuelle. Par conséquent, si le trafic de sortie arrive sur une autre machine virtuelle qui a traité le trafic entrant, une communication inter-machines virtuelles est nécessaire pour renvoyer le trafic vers la bonne machine virtuelle. Cela entraînera évidemment une dégradation des performances.
Chez F5, nous avons choisi l’ approche selon laquelle une VNF est toujours déployée en tant que VM unique et la mise à l’échelle de l’architecture vers plusieurs VM devient un facteur de conception externe. Différentes techniques de scale-out sont disponibles, allant des plus simples aux plus avancées.
Une architecture évolutive très simple est basée sur le hachage du trafic basé sur IP sur les différentes machines virtuelles telles que le multichemin à coût égal (ECMP). Cependant, cette technique présente plusieurs inconvénients et n’est pas pratique pour la majorité des cas d’utilisation sur le LAN Gi. Les approches basées sur SDN pour contrôler la distribution du trafic peuvent éviter certaines de ces limitations ECMP, mais les capacités seraient toujours quelque peu limitées et dépendent fortement de l’acteur SDN choisi.
De loin, l'approche la plus flexible et la plus avancée pour faire évoluer n'importe quelle fonction Gi LAN totalement indépendante du réseau sous-jacent et/ou du SDN est fournie par un équilibreur de charge logiciel sans état (qui est également déployé sous forme de machines virtuelles). Le fait qu'il soit sans état lui permet d'évoluer presque indéfiniment, car davantage de machines virtuelles pour l'équilibrage de charge sans état peuvent être ajoutées sans perdre la cohérence de la façon dont le trafic est réparti sur les machines virtuelles fournissant les fonctions LAN Gi.
Sur la base de ce qui précède, nous pensons qu’il est très important pour tout opérateur mobile de réfléchir attentivement aux aspects de consolidation et de mise à l’échelle lors de la migration de son architecture Gi LAN de la couche physique vers la couche virtuelle.