Au départ, le réseau pouvait utiliser une configuration avec des ports 1/10G — ce type de connexion côté abonné est d’ailleurs souvent encore utilisé aujourd’hui. Avec le temps, la charge et les volumes de trafic ont augmenté, et des interfaces 25/40G ont commencé à apparaître sur les nouveaux segments du réseau. Parallèlement, le trafic vers le backbone est agrégé et transmis via plusieurs ports 100G. Il en résulte que des équipements de générations différentes, avec des débits d’interface variés, peuvent fonctionner simultanément dans l’infrastructure de l’opérateur.
La plateforme Stingray prend en compte cette hétérogénéité et couvre tous les principaux scénarios de déploiement (in-line, on-stick, mirror), dans lesquels des interfaces de débits différents peuvent fonctionner simultanément. Pour cela, la plateforme propose un ensemble de « moteurs » — des configurations d’interfaces dpdk (ports de données), chacune décrivant sa propre combinaison de modes de fonctionnement. La configuration dpdk_engine=7 est celle qui assure la prise en charge simultanée d’interfaces de types différents au sein d’une même plateforme.
Pourquoi les moteurs standard ne suffisent plus
Tous les moteurs précédents (dpdk_engine=0..6) utilisent un seul et même schéma de répartition des dispatchers pour l’ensemble du cluster :
- dpdk_engine=0 — un dispatcher pour tout le cluster ;
- dpdk_engine=1 — un dispatcher par direction (in/out) ;
- dpdk_engine=2 — des dispatchers RSS par direction ;
- dpdk_engine=3 — un dispatcher par bridge ;
- dpdk_engine=4 — un dispatcher par port ;
- dpdk_engine=6 — des dispatchers RSS par bridge, pour les cartes hautes performances 100G+.
Pour plus de détails sur chaque mode, consultez la documentation Stingray.
Ce modèle fonctionne tant que les ports ont le même débit. Mais dans le réseau d’un opérateur, on rencontre plus souvent la situation suivante : de nombreux ports 10G côté abonnés et un ou deux ports 100G côté uplink. C’est typique, par exemple, d’une connexion BNG, où le débit du LAN et celui du WAN diffèrent fortement. Il existe aussi des configurations plus complexes, où des ports 100G, 40G et 10G sont utilisés simultanément avec différents schémas de répartition des dispatchers.
Dans ce type de situation, un schéma commun n’est plus toujours optimal. Certains ports peuvent disposer de plus de ressources que nécessaire, tandis que d’autres n’en ont pas assez pour traiter la charge efficacement.
Comment répartir les dispatchers de façon indépendante avec dpdk_engine=7
dpdk_engine=7, ou le moteur à configuration explicite des dispatchers, permet de définir manuellement quels ports sont pris en charge par chaque dispatcher et quelles ressources lui sont allouées. Contrairement aux modes précédents, où un seul schéma de répartition fixe était choisi pour l’ensemble du système, ce nouveau moteur permet de configurer le traitement de chaque groupe de ports de manière indépendante.
Pour chaque dispatcher, on peut définir séparément :
- la liste des ports pris en charge ;
- le mempool — le pool de mémoire pour les paquets, avec une taille donnée ;
- si nécessaire — le RSS avec le nombre de files d’attente requis.
Contrairement aux modes précédents, il n’est pas nécessaire ici de choisir un seul schéma de répartition pour l’ensemble du cluster. Les ports peuvent être répartis en groupes, chacun disposant de sa propre configuration de traitement.
dpdk_engine=7 est par ailleurs universel : il permet de mettre en œuvre n’importe quel schéma de répartition disponible dans dpdk_engine=0..6.
Par exemple, « un dispatcher par direction » (l’équivalent de dpdk_engine=1) s’écrit ainsi :
in_dev=port1:port2 out_dev=port3:port4 dpdk_dispatch=port1,port2;mempool=main dpdk_dispatch=port3,port4;mempool=main dpdk_mempool=name=main;size=1600000
Il est également possible de configurer un schéma mixte, où une partie des ports fonctionne via un dispatcher classique et l’autre via RSS :
in_dev=port1:port2 out_dev=port3:port4 dpdk_dispatch=port1:port2;mempool=main10G dpdk_dispatch=port3:port4;rss=16;mempool=main100G dpdk_mempool=name=main10G;size=1600000 dpdk_mempool=name=main100G;size=8000000
Ici, le groupe 10G est pris en charge par un seul dispatcher avec le mempool main10G, tandis que les ports 100G sont pris en charge par un dispatcher RSS (16 files d’attente) avec un mempool main100G distinct et plus grand. Les paramètres de traitement peuvent être ajustés séparément pour des groupes de ports aux performances différentes.
Figure 1 — Architecture de répartition dpdk_engine=7
Concernant les limites : la configuration sera considérée comme incorrecte si un port n’appartient à aucun dpdk_dispatch ou s’il appartient à plusieurs à la fois. Un port ne doit appartenir qu’à un seul dpdk_dispatch, et tous les ports d’un même dispatcher doivent appartenir au même cluster.
À quoi ressemblent les configurations mixtes des grands opérateurs
Un opérateur a eu besoin de ce type de schéma après la modernisation de ses liaisons montantes (uplinks). Des interfaces à haut débit sont apparues au niveau supérieur du réseau, tandis que des connexions 10G subsistaient au niveau inférieur. Moderniser entièrement ces interfaces n’était pas pertinent : le remplacement des équipements et des ports aurait nécessité des ressources considérables.
Par ailleurs, le trafic provenant de différentes sources convergeait vers un même serveur. Répartir son traitement sur des serveurs distincts aurait impliqué de mobiliser des équipements supplémentaires et d’utiliser les ressources de calcul de façon peu rationnelle.
Figure 2 — Schéma du réseau de l’opérateur
Auparavant, Stingray ne permettait de constituer des bridges qu’avec des interfaces de même débit. La configuration mixte nécessitait la possibilité de configurer indépendamment le traitement des différents groupes de ports.
dpdk_engine=7 permet de définir, pour chaque groupe, son propre nombre et type de dispatchers. Cela permet de tenir compte des différences de débit entre interfaces et d’éviter de répartir les mêmes ressources entre des ports soumis à des charges différentes.
Résultat : il n’a pas été nécessaire de reconstruire le système autour d’un débit d’interface unique, ni de déporter le traitement de certains groupes vers des serveurs supplémentaires. Il a ainsi été possible d’adapter le traitement à la configuration réseau existante et d’utiliser plus efficacement les ressources matérielles disponibles.
Ce qu’apporte dpdk_engine=7
dpdk_engine=7 lève une limitation des moteurs précédents : l’impossibilité d’appliquer différentes stratégies de répartition à différentes parties d’un même cluster. Cela est particulièrement important pour les installations de grande envergure disposant d’un parc de cartes hétérogène, où le réglage précis du nombre de dispatchers et de la mémoire pour un groupe de ports donné a un impact direct sur les performances et sur l’économie de cœurs.
Si des questions se posent sur le nombre de dispatchers, la taille du mempool ou d’autres paramètres lors du passage à dpdk_engine=7, contactez le support technique de VAS Expert. Nos spécialistes vous aideront à définir la configuration adaptée à votre schéma de connexion et à la charge de vos interfaces.
