Virtualisation du réseau local Gi : bonnes pratiques et erreurs à éviter

Bart SalaetsDirecteur de la technologie sur le terrain | F5

Après de nombreuses années de discussions et de validations de principe, la virtualisation des fonctions réseau (NFV) passe désormais du stade conceptuel à celui de la mise en œuvre.

Certains fournisseurs de services ont commencé à déployer des plateformes d’infrastructure NFV, tandis que certains d’entre eux ont déjà mis en œuvre leurs premiers cas d’usage et applications reposant sur la NFV sur ces plateformes.

La virtualisation du cœur de réseau de paquets évolué (EPC) et du LAN Gi est l’un des cas d’usage qui suscitent actuellement un vif intérêt dans le secteur.

Lors du déploiement d’un réseau local Gi virtuel, deux questions fondamentales doivent être tranchées. La première concerne la consolidation : faut-il regrouper plusieurs fonctions du réseau local Gi au sein d’une seule fonction réseau virtuelle (VNF), ou décomposer entièrement l’architecture du réseau local Gi en plusieurs VNF distinctes ?

La deuxième question concerne la mise à l’échelle. Comment faire évoluer efficacement cette architecture, sachant qu’une seule machine virtuelle peut ne pas offrir une capacité suffisante pour prendre en charge la charge de travail du réseau Gi LAN ?

Afin de sécuriser et de monétiser leurs réseaux, les opérateurs mobiles déploient de nombreuses technologies différentes sur le réseau local Gi, notamment l’optimisation TCP, l’optimisation vidéo, l’enrichissement des en-têtes, l’inspection approfondie des paquets, les pare-feu Gi et la traduction d’adresses réseau de classe opérateur (CGNAT).

Historiquement, nombre de ces fonctions étaient déployées sur des plateformes distinctes, souvent fournies par différents prestataires. Ces dernières années, les opérateurs mobiles ont entrepris de consolider et de simplifier l’architecture de leur réseau local Gi.

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 standard disponible dans le commerce, il peut être tentant de commencer à décomposer l’architecture en plusieurs VNF distinctes, chacune dédiée à une fonction unique.

Cette architecture décomposée est tout à fait pertinente si les différentes fonctions du réseau local Gi s’appliquent chacune à un sous-ensemble très spécifique de flux. En s’appuyant sur les politiques commerciales grâce à une interaction avec une fonction de règles de politique et de taxation (PCRF), un moteur intelligent de classification des services placé à l’entrée du réseau local Gi peut déterminer quels flux doivent être orientés et/ou chaînés vers des fonctions particulières déployées sous forme de VNF distinctes. Ces VNF n’auront alors à traiter que le trafic sur lequel elles doivent intervenir, ce qui permet de répartir très efficacement le trafic entre toutes les VNF.

Cependant, si les fonctions du réseau local Gi doivent être appliquées à la quasi-totalité du trafic, cette décomposition des fonctions n’apporte aucune valeur ajoutée. Prenons comme exemples l’optimisation TCP et les pare-feu Gi. La quasi-totalité du trafic du réseau local Gi doit être traitée par ces deux fonctions ; leur regroupement au sein d’une seule VNF permet donc d’obtenir des gains d’efficacité similaires à ceux d’un déploiement physique.

En effet, il n’est pas nécessaire ici de recourir à un classificateur de services intelligent pour sélectionner une VNF, ni de faire transiter le trafic à plusieurs reprises par la couche SDN pour le faire passer d’une VNF à la suivante. En outre, l’ajout d’une fonction de pare-feu à une fonction d’optimisation TCP n’entraîne qu’une très faible surcharge du processeur. La consolidation conserve donc tout son intérêt dans un environnement NFV.

Un autre défi consiste à gérer les flux de travail dont la charge dépasse la capacité de traitement d’une seule VNF. Certains fournisseurs ont choisi de permettre à une VNF de se composer 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 des mêmes flux doit être traité sur la même VM. Par conséquent, si le trafic sortant arrive sur une VM différente de celle qui a traité le trafic entrant, une communication inter-VM est nécessaire pour rediriger le trafic vers la bonne VM. 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 sous la forme d’une seule VM, la mise à l’échelle horizontale de l’architecture sur plusieurs VM devenant ainsi un facteur de conception externe. Différentes techniques de mise à l’échelle horizontale sont disponibles, des plus simples aux plus avancées.

Une architecture de mise à l’échelle horizontale très simple repose sur le hachage du trafic basé sur les adresses IP entre les différentes machines virtuelles, par exemple à l’aide du routage multichemin à coût égal (ECMP). Toutefois, cette technique présente plusieurs inconvénients et s’avère peu pratique pour la majorité des cas d’utilisation sur le réseau local Gi. Les approches basées sur le SDN pour contrôler la répartition du trafic permettent d’éviter certaines de ces limitations de l’ECMP, mais leurs capacités restent quelque peu limitées et dépendent fortement de la solution SDN choisie.

L’approche de loin la plus flexible et la plus avancée pour faire évoluer horizontalement n’importe quelle fonction du réseau local Gi, en toute indépendance vis-à-vis du réseau sous-jacent et/ou du SDN, consiste à utiliser un répartiteur de charge logiciel sans état (lui aussi déployé sous forme de machines virtuelles). Son fonctionnement sans état lui permet d’évoluer horizontalement de manière presque illimitée, car il est possible d’ajouter des machines virtuelles supplémentaires pour la répartition de charge sans état sans compromettre la cohérence de la distribution du trafic entre les machines virtuelles assurant les fonctions du réseau local Gi.

Compte tenu de ce qui précède, nous estimons qu’il est essentiel pour tout opérateur mobile d’examiner attentivement les aspects liés à la consolidation et à la mise à l’échelle horizontale lors de la migration de son architecture Gi LAN de la couche physique vers la couche virtuelle.

À propos de l’auteur

Bart SalaetsDirecteur de la technologie sur le terrain | F5

Autres articles de Bart Salaets