Modernisation : Orange préfère exécuter des VM via Kubernetes
Alors que l’approche technique usuelle consiste à exécuter des applications en containers par-dessus des machines virtuelles, l’opérateur obtient de meilleurs résultats en les traitant au même niveau, via une solution de Red Hat.
C’est un indice important dans le cadre de la modernisation des datacenters. OINIS, la division d’Orange qui s’occupe notamment d’interconnecter les liaisons de l’opérateur dans des points de présence, a préféré la méthode des machines virtuelles installées à côté des containers à celle, plus consensuelle, de déployer des containers par-dessus des machines virtuelles.
« Nous avons fait ce choix, parce qu’objectivement le format de l’avenir, ce sont les containers. C’est le format le plus adapté à une infrastructure élastique, ce qui est essentiel dans notre secteur des télécoms. Accessoirement, les containers nous permettent de mieux isoler les flux, notamment sur les communications mobiles, et cela répond mieux aux exigences réglementaires ou, du moins, aux préconisations de l’ANSSI », explique Bess Diop, directrice de l’ingénierie au sein d’OINIS (en photo en haut de cet article).
« Objectivement le format de l’avenir, ce sont les containers. C’est le format le plus adapté à une infrastructure élastique, ce qui est essentiel dans notre secteur des télécoms. »
Bess DiopDirectrice de l’ingénierie, OINIS
En clair, même si la méthode de la virtualisation est archimaîtrisée pour déployer des applications, pas question de s’en servir pour déployer plus facilement des applications au format container, car cela annulerait les bénéfices de la containerisaton. Et pour que ce soit encore plus clair : plus question de déployer des hyperviseurs. Les machines virtuelles, quand on ne peut pas s’en passer, seront virtualisées par l’orchestrateur des containers : Kubernetes.
OINIS, alias Orange International Networks Infrastructures & Services, est l’entité responsable des infrastructures et des services réseau en France et à l’international pour Orange Business (ex-OBS) et Orange Wholesale, qui commercialise les infrastructures des réseaux filaires et mobiles. OINIS gère une infrastructure réseau à l’échelle mondiale, qui comprend des fibres terrestres, des câbles sous-marins et des connexions satellites. Et des data centers.
Appelés « points de présence de réseaux virtuels » (SDN POP) et répartis sur une cinquantaine de localités tout autour du globe (75 d’ici à 2026), ces datacenters ne font pas qu’interconnecter les liaisons. Ils exécutent également plus d’une trentaine de services télécoms liés au routage. Il s’agit notamment d’assurer la continuité et l’étanchéité de réseaux privés virtuels sur les infrastructures physiques. Ce sont ces services qui, par exemple, maintiennent les connexions SD-WAN, IP/MPLS ou FTTO. Ce sont également eux qui exécutent toutes les couches de cybersécurité.
L’enjeu : bénéficier de la souplesse des containers
Historiquement, Orange, comme la plupart des télécoms, motorisait ses datacenters opérateur avec le système OpenStack. Né comme une alternative Open source à VMware, OpenStack s’est plus particulièrement imposé chez les télécoms pour virtualiser sur des serveurs génériques des services (en particulier dans la téléphonie mobile), qui étaient auparavant livrés dans des boîtes noires par leurs fournisseurs.
Que ce soit sur VMware comme sur OpenStack, la virtualisation présente le défaut de déployer des applications avec leur système d’exploitation, ce qui oblige les entreprises utilisatrices à des efforts d’administration redondants liés à ces systèmes d’exploitation. Pour chaque nouvelle application déployée, y compris chaque mise à jour, il faut gérer le stockage, la sécurité et l’adressage IP de chaque machine virtuelle. Pire : il faut s’efforcer à faire en sorte que les paramètres de l’une n’entrent pas en conflit avec ceux d’une autre.
Les containers, et plus particulièrement leur orchestrateur Kubernetes, ont amplement simplifié le concept. Un container ne contient que le code de l’application qu’il exécute et tous les containers fonctionnent au-dessus d’un système d’exploitation commun. En lieu et place d’adresses IP ou de volumes de stockage, Kubernetes propose aux containers de communiquer entre eux avec uniquement des requêtes sur des URL. Il devient dès lors possible pour les développeurs de mettre eux-mêmes en production des applications, sans passer par les services informatiques.
« Du point de vue de l’infrastructure, le passage aux containers nous permet aussi de proposer des services qui n’auront que 10 millisecondes de latence. »
Bess DiopDirectrice de l’ingénierie, OINIS
Et, surtout, il devient très facile d’étendre à l’envi le cluster applicatif : Kubernetes se charge de la cohérence des URL, quel que soit le serveur physique qui exécute à un instant T un container. On parle de scalabilité, ou d’élasticité, à savoir la capacité à augmenter ou réduire en temps réel des copies de containers pour répondre à la demande sans cesse changeante du trafic. Mieux, comme seules certaines fonctions ont parfois besoin de plus de bande passante, il devient possible de fragmenter une application en microservices, chaque microservice ayant ses propres instances de containers.
« Nous parlons en ce qui concerne nos datacenters de POP v2. C’est-à-dire de la faculté de simplifier les opérations pour nos partenaires ; c’est par exemple Orange Business qui décide de déployer un SD-WAN pour un client. Partenaires qui pourront proposer plus de services à la carte, du pay-as-you-go. Du point de vue de l’infrastructure, le passage aux containers nous permet aussi de proposer des services qui n’auront que 10 millisecondes de latence », s’enthousiasme Bess Diop.
Pour autant, pas question de ne plus pouvoir exécuter de machines virtuelles. Les éditeurs de services télécoms sont loin d’avoir tous transformé leurs applicatifs au format container. Il faut réécrire tout le code pour qu’il accède à des ressources via des requêtes dans des URL, plus exactement via des APIs, plutôt qu’avec des adresses IP ou des points de montage. Ce n’est pas qu’une question de commandes différentes ; toute la logique est à revoir. On parle d’applicatifs Cloud-Native.
C’est dans ce contexte qu’OINIS lance, dès l’été 2023, un appel d’offres pour moderniser ses infrastructures OpenStack.
L’avantage de Red Hat : mettre des containers et VM au même niveau
Outre la capacité d’exécuter des VM (appelées VNF, pour Virtual Network Functions, dans le jargon des télécoms) et des containers (CNF, Containerized Network Functions, entretemps rebaptisés Cloud-native Networks Functions), OINIS ajoute dans son appel d’offres la faculté de pouvoir réutiliser son équipement existant.
« C’est l’un des objectifs de durabilité que nous nous fixons dans le groupe Orange. Sur 100 serveurs déployés, 15 doivent être du matériel recyclé », précise Bess Diop.
Dix fournisseurs répondent à l’appel d’offres. Quatre correspondent aux critères demandés. Parmi eux, Red Hat a une approche originale. Tous les autres proposent un hyperviseur pour exécuter nativement des machines virtuelles, puis ajoutent dans celles-ci Kubernetes afin d’orchestrer des containers, lesquels se basent sur l’OS de la machine virtuelle. Red Hat fait plus simple. Il propose OpenShift pour exécuter Kubernetes au plus bas niveau et l’extension OpenShift Virtualization qui permet à Kubernetes d’exécuter des machines virtuelles, comme s’il était lui-même un hyperviseur.
La différence fondamentale est que tous les accès physiques des machines virtuelles sont convertis à la volée par Kubernetes en appel vers des APIs. Cette approche a le mérite de ne pas surcharger l’exploitation informatique : les machines virtuelles sont aussi facilement déployables que des containers.
« Nous nous sommes fixé de tester dans nos propres laboratoires les solutions retenues, à raison de deux semaines de tests intensifs par fournisseur, soit huit semaines en tout. Le bilan est sans appel : la solution de Red Hat nous permet de diviser par quatre les temps de déploiement pour un service », témoigne Bess Diop.
Un autre avantage de Red Hat est l’accompagnement. Et c’est un point qui, de manière surprenante, s’est avéré plus déterminant que prévu : « Il se trouve que nous utilisions jusqu’à présent une technologie Contrail de l’équipementier Juniper pour relier nos datacenters entre eux. Or, le développement du produit Contrail a été arrêté justement à ce moment-là. Nous nous sommes donc retrouvés dans la situation de devoir développer nous-mêmes un palliatif », raconte Bess Diop.
« Le premier bilan positif est que la nouvelle architecture nous permet de réduire par deux le nombre de serveurs pour le contrôle du réseau, c’est donc un avantage très significatif dans notre quête d’économie de CO2. »
Bess DiopDirectrice de l’ingénierie, OINIS
« Avec l’aide de Red Hat, cela revenait à développer un pilote CNI (Container Network Interface) pour Kubernetes, », ajoute-t-elle, en précisant qu’il s’agit, selon elle, de l’approche la plus élégante.
Sans surprise, c’est donc avec Red Hat qu’OINIS signe en février 2024.
« Depuis, nous testons et testons encore l’automatisation, les performances obtenues et la solidité de l’isolation, selon différents scénarios. Le premier bilan positif est que la nouvelle architecture nous permet de réduire par deux le nombre de serveurs pour le contrôle du réseau, c’est donc un avantage très significatif dans notre quête d’économie de CO2 », dit Bess Diop.
« Nous déploierons les premiers POP v2 en novembre, dans de nouveaux data centers, sur de nouvelles régions, pour OBS. Nous continuerons cela tout au long de 2025. Nous travaillerons à la migration des anciens POP vers une architecture POP v2 à partir de 2026 », conclut-elle.
