Comprendre les indicateurs de performance des ADC

Introduction

Les services de mise à disposition d’applications sont essentiels à la réussite de celles-ci. Qu’ils apportent évolutivité, fiabilité ou sécurité, la plupart des applications s’appuient sur un ou plusieurs de ces services. Les contrôleurs de mise à disposition d’applications (ADC) occupent donc une place stratégique dans la plupart des architectures d’applications, de cloud et de centres de données.

Dans de nombreux environnements, notamment les installations de cloud privé, le matériel ADC dédié reste la plateforme privilégiée pour fournir des services de mise à disposition d’applications. En effet, une plateforme dédiée intègre des ressources maîtrisées, stables et homogènes. Une appliance dédiée et spécialement conçue peut fournir de manière constante les performances et la fiabilité requises, même par les charges applicatives les plus exigeantes, car son hyperviseur, ses logiciels et sa plateforme de calcul sous-jacente ne varient pas. Elle bénéficie en outre de composants matériels spécialisés qui permettent de décharger le processeur de certaines tâches.

Mais que signifie réellement le terme « performances » ? En général, les fournisseurs d’ADC publient quatre grands types d’indicateurs pour évaluer les performances :

• Requêtes par seconde (RPS)
• Connexions par seconde (CPS)
• Transactions par seconde (TPS)
• Débit (souvent mesuré en gigabits par seconde, Gbit/s)

Les fabricants fournissent des fiches techniques détaillées qui répertorient ces caractéristiques de plateforme ainsi que d’autres, notamment sous forme de tableaux indiquant le débit, le nombre de transactions SSL ou le nombre de connexions simultanées. Pour choisir la plateforme appropriée, il est essentiel de savoir interpréter ces chiffres et leur pertinence au regard de la charge de travail d’une application, ainsi que de comprendre les limites et les goulets d’étranglement probables d’un système. Apprendre à interpréter les fiches techniques des fournisseurs et à comprendre les indicateurs pertinents pour vos applications peut vous aider à mieux choisir les plateformes adaptées à votre entreprise.

À quoi sert un ADC ?

Un contrôleur de mise à disposition d’applications (ADC) est un composant d’infrastructure qui fait office de proxy applicatif et fournit des services de mise à disposition d’applications tels que la gestion du trafic, l’équilibrage de charge, le déchiffrement SSL, la sécurité de la couche applicative et le contrôle d’accès aux applications. Les appareils clients et les services se connectent à l’ADC, qui établit une connexion distincte avec l’application (ou réutilise une connexion existante). Dans cet espace logique, l’ADC intègre des services de mise à disposition d’applications.

Pour comprendre la charge de travail d’un ADC, il est utile d’examiner une connexion TCP et une requête de la couche applicative. L’ADC doit effectuer des tâches à plusieurs niveaux de la pile TCP et mener à bien un certain nombre d’opérations afin de fournir des services applicatifs au trafic des applications. (Voir la figure 1.) Cela peut compliquer l’interprétation des indicateurs de performance fournis par les éditeurs d’ADC. Pour déterminer quels indicateurs sont pertinents, il est essentiel d’identifier au préalable le type de charge de travail.

Figure 1 : Traitement des paquets

Il existe de nombreux types d’applications et, par conséquent, de nombreuses charges de travail différentes pour les ADC. Bien que la plupart des déploiements en production combinent plusieurs charges de travail, l’impact et les besoins de chacune d’elles déterminent les composants d’un ADC qui seront les plus sollicités. Même au sein d’un même composant, les besoins varient selon la charge de travail. Certaines charges de travail peuvent être plus sensibles à la latence, d’autres à la gigue ; certaines sont sensibles aux limites de débit, tandis que d’autres dépendent davantage de la disponibilité.

Voici les charges de travail les plus courantes, ainsi que les indicateurs clés qui les prennent en charge :

• Actuellement, la charge de travail la plus courante, utilisée par les sites web et de nombreuses applications mobiles, est celle des applications web HTTP transactionnelles, qui utilisent souvent SSL et TLS. Les indicateurs les plus importants pour cette charge de travail sont tous les indicateurs SSL : RPS, TPS et débit, ainsi que les RPS et CPS de couche 7.
• Le DNS est un autre type de charge de travail courant, utilisé dans la quasi-totalité des échanges Internet. Il est fréquemment sollicité, génère un faible volume de trafic et est généralement déployé avec UDP plutôt que TCP. Par conséquent, les indicateurs les plus importants sont les débits des couches 3 et 4.
• L’utilisation de l’API REST connaît une croissance rapide. Il s’agit d’un mode de transport d’API couramment employé pour les services. Par conséquent, l’API REST est souvent utilisée pour les communications de machine à machine. Comme elle repose sur HTTP, les indicateurs clés sont les mêmes que pour HTTP (tous les indicateurs SSL) : RPS, TPS et débit, ainsi que RPS et CPS de couche 7.
• MQTT est un protocole de messagerie émergent qui offre de nombreux cas d’usage et connaît une croissance rapide dans les communications de l’Internet des objets (IoT). À l’instar de l’API REST, MQTT est principalement utilisé dans les applications de communication de machine à machine. Les indicateurs clés pour MQTT sont le nombre de connexions par seconde (CPS) au niveau de la couche 4 et le débit.
• Diameter remplace le protocole d’authentification RADIUS. Il fonctionne au niveau de la couche 4 et maintient les connexions TCP ouvertes pendant de longues périodes. Ses principaux indicateurs sont le nombre de connexions par seconde (CPS) au niveau de la couche 4 et la robustesse de la table de connexions de cette couche.
• Les protocoles de négociation financière tels que FIX, SAIL et OUCH sont sensibles à la latence, tant au niveau de la couche 4 que de la couche 7. Leurs indicateurs clés sont donc le nombre de connexions par seconde (CPS) au niveau de la couche 4, ainsi que le nombre de requêtes par seconde (RPS) et le CPS au niveau de la couche 7.
• La technologie WebSockets est un ajout relativement récent aux types de charges de travail. Elle permet au serveur d’établir une communication avec le client via une connexion persistante de couche 4 et de couche 7. Les indicateurs clés sont le nombre de connexions par seconde (CPS) de couche 4, le nombre de requêtes par seconde (RPS) et le CPS de couche 7, ainsi que la robustesse des tables de connexions de couches 4 et 7.
• Les charges de travail de journalisation et d’alerte fonctionnent toutes au niveau de la couche 4, et certaines reposent sur l’API REST, qui fonctionne au niveau de la couche 7. Par conséquent, le nombre de connexions par seconde (CPS) au niveau de la couche 4 constitue une métrique clé, de même que le nombre de requêtes par seconde (RPS) et le CPS au niveau de la couche 7 pour les charges reposant sur l’API REST.

Les combinaisons de charges de travail continuent d’évoluer et de nouvelles charges de travail sont constamment introduites, chacune ayant ses propres métriques ADC critiques, déterminées en fonction de ses opérations principales.

Indicateurs de performance et comment les interpréter

Le débit de tout équipement réseau dépend de la latence, c’est-à-dire du délai induit par le traitement du trafic réseau. La vitesse de la lumière impose à elle seule une latence minimale aux signaux électriques circulant dans des fils de cuivre ou aux signaux optiques parcourant une fibre optique. Toutefois, outre le simple acheminement des données par câble ou fibre, un contrôleur de mise à disposition d’applications (ADC) effectue plusieurs opérations sur le trafic réseau. Les capacités maximales d’un ADC correspondent à la somme des latences des opérations séquentielles, c’est-à-dire celles qui ne sont pas exécutées en parallèle. Heureusement, de nombreuses opérations sont réalisées en parallèle, mais le temps nécessaire à leur exécution reste une contrainte pour le débit global. L’un des objectifs des concepteurs d’ADC est de réduire ces latences afin de maximiser le débit.

Évaluer les performances d’un ADC donné et tenter de déterminer s’il convient à un déploiement particulier peut s’avérer complexe. Les fournisseurs de solutions réseau publient des indicateurs issus de tests visant à maximiser un indicateur donné au détriment des autres. Cette approche a pour but de fournir une valeur exploitable pouvant orienter l’architecture et les décisions, mais les fournisseurs savent que toutes les valeurs publiées ne peuvent pas être atteintes simultanément. Prenons une analogie automobile : Toyota annonce que le modèle de base de sa Camry 2017 développe 178 chevaux et consomme 33 miles par gallon sur autoroute. Il serait toutefois déraisonnable de s’attendre à ce que la voiture développe la totalité de ses 178 chevaux — en appuyant à fond sur l’accélérateur à 6 000 tr/min — tout en parcourant simultanément 33 miles par gallon. De même, les fournisseurs de solutions réseau présentent chaque indicateur de performance selon le scénario le plus favorable. En règle générale, bon nombre des performances publiées ne peuvent pas être reproduites simultanément.

Relations entre les métriques et les couches OSI

Certaines des métriques publiées peuvent s’appliquer à différents niveaux de traitement. Par exemple, le nombre de requêtes par seconde peut correspondre à des valeurs de traitement de la couche 2 (L2) ou de la couche 7 (L7) du modèle OSI. En revanche, le nombre de transactions par seconde (TPS) désigne souvent uniquement la négociation des clés SSL, tandis que le nombre de requêtes par seconde au niveau de la couche 7 correspond aux requêtes cryptographiques ultérieures utilisant une session SSL établie. Une charge de travail donnée sollicitera les différents composants de traitement de l’ADC différemment d’une autre charge de travail. Un autre point essentiel concernant les métriques publiées pour les ADC est que les limites de performances rencontrées varient selon les charges de travail.

Chaque couche réseau du modèle OSI possède plusieurs indicateurs couramment publiés. Par exemple, les indicateurs de couche 4 sont souvent exprimés en connexions par seconde, tandis que d’autres mesurent le débit de cette couche. Les couches OSI 5 et 6 ne correspondent pas directement à la pile IP, mais des services tels que SSL/TLS et la compression peuvent être considérés comme relevant de ces couches. Comme indiqué précédemment, les tests portant sur chacun de ces indicateurs sont souvent réalisés avec un trafic conçu pour solliciter spécifiquement l’indicateur concerné et ne sont donc pas représentatifs des charges de trafic réelles. Par exemple, le nombre maximal de transactions SSL par seconde (TPS) sera obtenu lors d’un test utilisant une charge utile SSL de longueur nulle, de sorte qu’aucun temps de traitement de l’ADC ne soit consacré au déchiffrement des données SSL. Si cette méthode est pertinente pour mesurer uniquement les performances du matériel SSL, aucune application en production n’enverra de charges utiles de longueur nulle. De même, le débit de couche 2 sera testé sans activation de SSL ni traitement de couche 7, car ces fonctions ralentissent l’ADC, alors que de nombreux déploiements en production les utilisent. La plupart des indicateurs d’un ADC sont testés séparément, tandis que la plupart des environnements de production utilisent plusieurs fonctions de l’ADC conjointement, chaque indicateur sollicitant différents composants ou combinaisons de composants. Les composants concernés peuvent notamment inclure le processeur, la carte d’interface réseau (NIC), les circuits intégrés spécifiques à une application (ASIC) et les réseaux de portes programmables (FPGA). Lorsqu’un ADC ne dispose pas d’un composant particulier, le processeur est utilisé à sa place.

La métrique des paquets indique le nombre de paquets par seconde que l’ADC peut traiter, et les composants les plus sollicités par ce traitement varient selon la couche. Par exemple, le traitement des paquets de couche 2 sollicite principalement la carte d’interface réseau (NIC), tandis que celui des paquets de couche 4 sollicite principalement le FPGA. Pour toutes les couches, la métrique de débit désigne le débit total disponible en gigabits par seconde, tandis que la métrique des connexions mesure le nombre de connexions par seconde pouvant être établies au niveau de la couche concernée. Par exemple, la métrique des connexions de couche 4 mesure le nombre de connexions TCP pouvant être établies par seconde.

Métriques de traitement SSL

Le traitement SSL présente la particularité que les sessions sont établies et gérées sur plusieurs connexions. Une connexion peut établir une session SSL (ce que l’on appelle une transaction), tandis que les connexions suivantes peuvent réutiliser une session SSL (ce que l’on appelle une requête). Les métriques relatives aux transactions et aux requêtes sont donc indiquées séparément. Les transactions SSL prennent nettement plus de temps que les requêtes SSL suivantes ; la métrique des transactions constitue donc souvent le facteur limitant des performances en matière de débit. Une fois qu’une session SSL est établie et qu’une requête ultérieure est effectuée, la charge utile des données doit être chiffrée ou déchiffrée. L’ASIC cryptographique prend en charge le chiffrement et le déchiffrement ; les performances sont mesurées à l’aide de la métrique de débit.

Il est souvent utile de compresser les données utiles. La compression est effectuée par l’ASIC de compression et se mesure également en débit.

Traitement de la couche applicative

Enfin, la couche 7 se distingue par le fait que, compte tenu de la complexité et de la diversité des options de gestion du trafic disponibles, l’ensemble de son traitement est effectué par le processeur. La persistance par cookie est une fonctionnalité courante de la couche 7 qui associe chaque session utilisateur à un serveur particulier du pool et qui est gérée par le processeur. La métrique des requêtes de couche 7 correspond au nombre de requêtes de couche 7 par seconde que l’ADC peut traiter. De même, la métrique de débit de couche 7 correspond au débit total possible au niveau de cette couche.

Enfin, toute couche devant préserver l’état des connexions nécessitera que l’ADC maintienne une table de connexions. Les tables de connexions sont couramment utilisées pour les connexions TCP de couche 4, les sessions SSL et les sessions HTTP de couche 7. Les protocoles utilisant des connexions de longue durée peuvent saturer ou solliciter fortement la table de connexions d’un ADC.

Chaque métrique peut aider à évaluer un aspect spécifique des performances. Comprendre les différentes opérations effectuées à chaque couche, ainsi que les composants affectés par ces opérations, facilite l’évaluation des métriques de performance de l’ADC pour un déploiement donné.

Matériel spécialisé et performances

Tous les aspects des fonctionnalités d’un ADC peuvent être pris en charge par un processeur. De fait, de nombreux fournisseurs de matériel ADC proposent une version entièrement logicielle. Cela est possible parce qu’un processeur est le type de matériel le plus polyvalent qui soit, capable d’effectuer presque toutes les tâches axées sur les données.

Cependant, confier l’intégralité des fonctionnalités d’un ADC à un processeur présente certaines limites. Parmi les trois principaux types de matériel utilisés pour traiter le trafic réseau — processeur, ASIC et FPGA —, le processeur est le plus lent et sans doute le plus coûteux, car il nécessite de la mémoire et des contrôleurs de mémoire. Les deux autres types de matériel utilisés pour traiter le trafic réseau sont l’ASIC et le FPGA. Un ASIC est conçu pour accomplir une tâche spécifique, d’où son nom. Aucun autre type de matériel n’est plus rapide qu’un ASIC pour exécuter une tâche, mais ses capacités se limitent à celles intégrées à la puce lors de sa conception. Si une application nécessite des fonctionnalités que l’ASIC ne propose pas, elle doit alors utiliser un processeur et exécuter les tâches de manière logicielle.

Si un processeur est flexible mais lent, et qu’un ASIC est rapide mais peu flexible, une troisième technologie se situe entre les deux : le FPGA. Un FPGA est plus lent qu’un ASIC, mais beaucoup plus rapide qu’un processeur, et il peut être programmé pour effectuer des tâches que ses concepteurs n’avaient pas envisagées.

Figure 2 : avantages des CPU, ASIC et FPGA

Un ADC bien conçu exploitera pleinement les capacités de chaque type de matériel : les tâches courantes et simples seront confiées aux composants ASIC, les tâches plus complexes aux composants FPGA, tandis que les tâches les plus complexes et les moins courantes seront traitées par le processeur. Une grande partie de l’ingéniosité technique d’un ADC réside dans la coordination des différents types de composants afin de gérer le plus efficacement possible les diverses charges de travail.

La tâche de loin la plus fréquemment effectuée dans un ADC est le traitement des paquets au niveau des interfaces réseau. Une carte réseau (NIC) standard du commerce est optimisée soit pour un volume élevé de trafic entrant (par exemple, sur un ordinateur de bureau ou un autre appareil utilisateur), soit pour un volume élevé de trafic sortant (par exemple, sur un serveur). La particularité d’un ADC est qu’il nécessite une carte réseau optimisée pour offrir un débit maximal dans les deux sens. Aucune carte réseau du commerce n’a été conçue pour assurer un débit maximal dans les deux sens. Le traitement des paquets par un ADC étant fréquent et relativement simple, il se prête particulièrement bien à une mise en œuvre sur un ASIC. Dans les environnements ADC en cluster, un ASIC de désagrégation (DAG) fait office d’équilibreur de charge frontal, garantissant que les sessions d’un même client et d’un même serveur transitent toujours par le même nœud du cluster. L’utilisation d’un DAG dans un environnement en cluster facilite la mise à l’échelle horizontale des appliances ADC afin de répondre aux besoins en matière de trafic. Dans un ADC correctement conçu, l’ensemble du traitement et de la commutation des paquets de couche 2 peut être pris en charge par du matériel ASIC spécialisé.

Les tâches de traitement des couches 3 et 4 sont plus complexes, ce qui les rend particulièrement adaptées à un FPGA. Un FPGA peut fournir des fonctions de routage ainsi que des protections de type pare-feu et contre les attaques par déni de service distribué (DDoS), notamment à l’aide de cookies TCP SYN. L’utilisation d’un FPGA à ce niveau permet d’assurer le traitement et la protection de la couche 4, afin de garantir que le trafic soumis à un traitement ultérieur a été correctement réassemblé et filtré.

Le traitement du chiffrement et de la compression, notamment avec SSL ou TLS, ainsi que les nouvelles fonctionnalités introduites par HTTP/2, constitue un autre cas d’utilisation du matériel dédié. Un ASIC spécialisé est souvent utilisé pour les opérations cryptographiques, notamment pour la négociation des clés SSL, particulièrement gourmande en ressources de calcul, avec des algorithmes de chiffrement modernes tels que l’échange de clés Diffie-Hellman sur courbes elliptiques (ECDHE). Une fois la négociation des clés SSL effectuée, le chiffrement et le déchiffrement en masse des requêtes suivantes peuvent également être pris en charge par le matériel ASIC. De même, la compression et la décompression à l’aide d’algorithmes courants peuvent être effectuées par du matériel ASIC. L’utilisation de composants ASIC dédiés permet de traiter rapidement le chiffrement et la compression.

Tout traitement restant du trafic réseau qui n’est pas pris en charge par les ASIC et les FPGA doit être effectué par le processeur. Bien qu’il soit plus lent que les ASIC et les FPGA, le processeur est le composant le plus polyvalent de l’ADC. Il est également chargé de tâches sans rapport avec le traitement réseau, telles que la gestion de l’interface graphique et d’autres fonctions de configuration, le traitement des interruptions d’E/S, voire celui des requêtes disque. Étant donné que la charge du processeur peut varier, ce qui influe sur la latence, et que le processeur est le dernier type de matériel à traiter le trafic réseau, les ADC sont délibérément conçus pour lui confier le moins de traitement possible et en effectuer autant que possible sur les ASIC et les FPGA, plus rapides.

Conclusion

Il peut être difficile de déterminer les performances réelles à partir des indicateurs publiés par les fournisseurs. Bien que complexe, la compréhension des interactions entre les différents types de charges de travail, les ressources qu’elles consomment et les capacités d’une plateforme matérielle peut vous aider à prendre la meilleure décision d’achat pour votre organisation.

Les fiches techniques publiées et d’autres ressources facilitent le choix de la plateforme appropriée, mais il est également important de s’appuyer directement sur l’expérience et l’expertise du fournisseur chaque fois que possible. Les principaux fournisseurs disposent d’une solide expertise pour associer les charges de travail aux plateformes, une expertise qui doit être facilement accessible aux clients.

En combinant une bonne compréhension des caractéristiques du trafic de vos applications et des capacités de la plateforme avec l’expertise de votre fournisseur, vous réduirez les risques et les coûts potentiels liés au sous-dimensionnement ou au surdimensionnement de votre plateforme.

PUBLIÉ LE 28 MARS 2017