Chapitre 14. Accord à faible latence

L'émergence de l'Edge computing dans le domaine Telco / 5G joue un rôle clé dans la réduction des problèmes de latence et de congestion et dans l'amélioration des performances des applications.

En termes simples, la latence détermine la vitesse à laquelle les données (paquets) se déplacent de l'expéditeur au destinataire et reviennent à l'expéditeur après avoir été traitées par le destinataire. Le maintien d'une architecture de réseau avec un délai de latence le plus faible possible est essentiel pour répondre aux exigences de performance du réseau de la 5G. Par rapport à la technologie 4G, dont le temps de latence moyen est de 50 ms, la 5G vise à atteindre des temps de latence de 1 ms ou moins. Cette réduction du temps de latence multiplie par 10 le débit des réseaux sans fil.

De nombreuses applications déployées dans l'espace Telco nécessitent une faible latence qui ne peut tolérer qu'une perte de paquets nulle. Le réglage pour une perte de paquets nulle permet d'atténuer les problèmes inhérents qui dégradent les performances du réseau. Pour plus d'informations, voir Tuning for Zero Packet Loss dans Red Hat OpenStack Platform (RHOSP).

L'initiative Edge computing entre également en jeu pour réduire les taux de latence. Il s'agit d'être à la périphérie du nuage et plus proche de l'utilisateur. Cela réduit considérablement la distance entre l'utilisateur et les centres de données éloignés, ce qui permet de réduire les temps de réponse des applications et la latence des performances.

Les administrateurs doivent pouvoir gérer leurs nombreux sites Edge et services locaux de manière centralisée afin que tous les déploiements puissent fonctionner au coût de gestion le plus bas possible. Ils ont également besoin d'un moyen simple de déployer et de configurer certains nœuds de leur cluster pour des applications en temps réel à faible latence et à haute performance. Les nœuds à faible latence sont utiles pour des applications telles que Cloud-native Network Functions (CNF) et Data Plane Development Kit (DPDK).

OpenShift Container Platform fournit actuellement des mécanismes pour régler les logiciels sur un cluster OpenShift Container Platform pour un fonctionnement en temps réel et une faible latence (environ <20 microsecondes de temps de réaction). Cela inclut le réglage du noyau et des valeurs d'ensemble d'OpenShift Container Platform, l'installation d'un noyau et la reconfiguration de la machine. Mais cette méthode nécessite de configurer quatre opérateurs différents et d'effectuer de nombreuses configurations qui, lorsqu'elles sont effectuées manuellement, sont complexes et peuvent être sujettes à des erreurs.

OpenShift Container Platform utilise le Node Tuning Operator pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift Container Platform. L'administrateur du cluster utilise cette configuration de profil de performance qui facilite la réalisation de ces changements de manière plus fiable. L'administrateur peut spécifier s'il faut mettre à jour le noyau vers kernel-rt, réserver les CPU pour les tâches d'entretien du cluster et du système d'exploitation, y compris les conteneurs pod infra, et isoler les CPU pour les conteneurs d'application afin d'exécuter les charges de travail.

OpenShift Container Platform prend également en charge les indices de charge de travail pour le Node Tuning Operator qui peut régler le site PerformanceProfile pour répondre aux exigences des différents environnements industriels. Des indices de charge de travail sont disponibles pour highPowerConsumption (très faible latence au prix d'une consommation d'énergie accrue) et realTime (priorité donnée à une latence optimale). Une combinaison de paramètres true/false pour ces conseils peut être utilisée pour traiter les profils et les exigences de charge de travail spécifiques à l'application.

Les indices de charge de travail simplifient l'ajustement des performances aux paramètres sectoriels. Au lieu d'une approche "unique", les indices de charge de travail peuvent s'adapter aux schémas d'utilisation, par exemple en donnant la priorité à.. :

Dans un monde idéal, tous ces éléments seraient prioritaires : dans la réalité, certains le sont au détriment d'autres. L'opérateur d'optimisation des nœuds est maintenant conscient des attentes de la charge de travail et est mieux à même de répondre aux exigences de la charge de travail. L'administrateur du cluster peut maintenant spécifier dans quel cas d'utilisation cette charge de travail s'inscrit. L'opérateur de réglage des nœuds utilise le site PerformanceProfile pour affiner les paramètres de performance de la charge de travail.

L'environnement dans lequel une application fonctionne influence son comportement. Pour un centre de données typique sans exigences strictes en matière de temps de latence, seul un réglage par défaut minimal est nécessaire pour permettre le partitionnement de l'unité centrale pour certains modules de charge de travail à haute performance. Pour les centres de données et les charges de travail où la latence est une priorité plus importante, des mesures sont toujours prises pour optimiser la consommation d'énergie. Les cas les plus complexes sont les clusters situés à proximité d'équipements sensibles à la latence, tels que les machines de production et les radios logicielles. Cette dernière catégorie de déploiement est souvent appelée "Far edge". Pour les déploiements en périphérie lointaine, une latence ultra-faible est la priorité absolue et est obtenue au détriment de la gestion de l'énergie.

Dans OpenShift Container Platform version 4.10 et les versions précédentes, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence. Désormais, cette fonctionnalité fait partie de l'opérateur Node Tuning.