Comprendre les indicateurs de performance ADC

Les services de livraison d’applications sont essentiels au succès des applications. Que ces services ajoutent de l’évolutivité, de la fiabilité ou de la sécurité, la plupart des applications s’appuient sur un ou plusieurs d’entre eux. Les contrôleurs de distribution d'applications (ADC) occupent donc une place critique dans la plupart des conceptions d'applications, de cloud et de centres de données.

Pour de nombreux environnements, y compris les installations de cloud privé, le matériel ADC dédié reste la plate-forme préférée pour fournir des services de distribution d'applications. Cela est dû au fait qu’une plateforme dédiée intègre des ressources contrôlées, stables et cohérentes. Un appareil dédié et spécialement conçu peut fournir en permanence les performances et la fiabilité requises même par la charge de travail d'application la plus exigeante, car il ne présente aucune variation d'hyperviseur, de logiciel ou de plate-forme de calcul sous-jacente. De plus, il présente les avantages de composants matériels spécialisés pour décharger les tâches du processeur.

Mais que signifie réellement « performance » ? En général, les fournisseurs d’ADC publient quatre principaux types de mesures pour démontrer les performances :

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

Les fabricants fournissent des fiches techniques complètes répertoriant ces caractéristiques et d'autres caractéristiques de la plate-forme, y compris des tableaux de débit, des numéros de transaction SSL ou des connexions simultanées. L’interprétation de ces chiffres et leur pertinence par rapport à la charge de travail d’une application, ainsi que la compréhension des limites et des goulots d’étranglement probables d’un système, sont essentielles pour sélectionner la bonne plateforme. Apprendre à interpréter les fiches techniques des fournisseurs et à comprendre les mesures pertinentes pour vos applications peut vous aider à mieux sélectionner les plates-formes adaptées à votre entreprise.

Un contrôleur de distribution d'applications est un composant d'infrastructure qui agit comme un proxy d'application, fournissant des services de distribution d'applications tels que la gestion du trafic, l'équilibrage de charge, le décryptage SSL, la sécurité de la couche d'application et le contrôle d'accès aux applications. Les périphériques et services clients se connectent à l'ADC, et l'ADC crée une connexion distincte (ou réutilise une connexion existante) à l'application. Dans cet espace logique, l'ADC insère des services de livraison d'applications.

Pour comprendre la charge de travail d’un ADC, il est utile d’examiner une connexion TCP et une demande de couche application. L'ADC doit effectuer des tâches sur plusieurs couches de la pile TCP et accomplir un certain nombre d'activités pour fournir des services d'application au trafic d'application. (Voir la figure 1.) Cela peut rendre difficile l’interprétation des mesures de performances des fournisseurs d’ADC. Une condition préalable essentielle pour comprendre quelles mesures sont pertinentes est d’identifier le type de charge de travail.

Il existe de nombreux types d'applications et donc de nombreuses charges de travail ADC différentes. Bien que la plupart des déploiements de production contiennent un mélange de charges de travail, l’impact et les besoins de chaque charge de travail influencent les composants d’un ADC qui seront les plus utilisés. Même au sein des composants, les besoins en charge de travail varient. Certaines charges de travail peuvent être plus sensibles à la latence, d’autres plus sensibles à la gigue ; certaines charges de travail 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 transactionnelles HTTP, utilisant souvent SSL et TLS. Les mesures les plus importantes pour cette charge de travail sont toutes les mesures SSL : RPS, TPS et débit, ainsi que RPS et CPS de couche 7.
• Le DNS est une autre charge de travail courante utilisée dans presque tous les échanges Internet. Le DNS est fréquemment utilisé, avec un volume de trafic faible et généralement déployé à l'aide d'UDP au lieu de TCP. Par conséquent, les mesures les plus importantes sont le débit des couches 3 et 4.
• L'utilisation de l'API REST se développe rapidement et fait référence à un transport d'API commun pour les services. Par conséquent, l’API REST est souvent utilisée dans la communication de machine à machine. Étant donné que l'API REST est basée sur HTTP, les mesures clés sont les mêmes que pour HTTP (toutes les mesures SSL) : RPS, TPS et débit, ainsi que RPS et CPS de couche 7.
• MQTT est un protocole de messagerie émergent qui a de nombreuses utilisations et qui se développe rapidement dans la communication de l'Internet des objets (IoT). Comme l’API REST, MQTT se trouve principalement dans les applications machine à machine. Les indicateurs clés de MQTT sont le CPS de couche 4 et le débit.
• Diameter est un remplacement du protocole d'authentification RADIUS qui fonctionne au niveau de la couche 4 et maintient les connexions TCP ouvertes pendant de longues périodes. Ses indicateurs clés sont le CPS de couche 4 et la robustesse de la table de connexion de couche 4.
• Les protocoles de trading financier tels que FIX, SAIL et OUCH sont sensibles à la latence au niveau des couches 4 et 7. Cela fait de ses indicateurs clés la couche 4 CPS, plus la couche 7 RPS et CPS.
• La technologie WebSockets est un ajout relativement récent aux types de charges de travail, grâce auquel le serveur peut initier une communication avec le client via une connexion de couche 4 et de couche 7 de longue durée. Les indicateurs clés sont le CPS de couche 4, le RPS et le CPS de couche 7, ainsi que la robustesse des tables de connexion de couche 4 et de couche 7.
• Les charges de travail de journalisation et d’alerte fonctionnent toutes au niveau de la couche 4 et certaines sont basées sur l’API REST, qui fonctionne au niveau de la couche 7. Par conséquent, une mesure clé est le CPS de couche 4 et, pour ceux basés sur l'API REST, le RPS et le CPS de couche 7.

Les combinaisons de charges de travail continuent d'évoluer et de nouvelles charges de travail sont constamment introduites, chacune avec ses propres mesures ADC critiques basées sur les opérations principales de la charge de travail.

Le débit de tout périphérique réseau est fonction de la latence, c’est-à-dire du délai introduit par le traitement du trafic réseau. Au minimum, la vitesse de la lumière impose une latence minimale pour les signaux électriques circulant sur des fils de cuivre ou les signaux optiques traversant des fibres optiques. Cependant, en plus de simplement déplacer les données via un fil ou une fibre, un ADC effectue plusieurs opérations sur le trafic réseau. Les capacités maximales d'un CAN sont la somme des latences des opérations en série, c'est-à-dire des opérations non effectuées en parallèle. Heureusement, de nombreuses opérations sont effectuées en parallèle, mais le temps nécessaire pour effectuer ces opérations reste une contrainte pour le débit total. L’un des objectifs des concepteurs d’ADC est de minimiser ces latences pour maximiser le débit.

Évaluer les performances d’un ADC particulier et tenter de l’adapter à un déploiement particulier peut être intimidant. Les fournisseurs de réseaux publient des mesures basées sur des tests destinés à maximiser une mesure particulière au détriment des autres. La raison de cette approche est de publier un numéro utilisable qui peut guider l’architecture et les décisions, mais les fournisseurs comprennent que tous les numéros publiés ne seront pas vrais simultanément. En utilisant une analogie avec une voiture : Toyota annonce que son modèle de base Camry 2017 produit 178 chevaux et atteint 33 miles par gallon sur l'autoroute, mais il serait déraisonnable de s'attendre à ce que la voiture produise la totalité des 178 chevaux (en poussant l'accélérateur au plancher à 6 000 tr/min) tout en fournissant simultanément 33 miles par gallon. De la même manière, les fournisseurs de réseau présentent des mesures de performance individuelles en utilisant un scénario du meilleur cas pour chacun. En règle générale, de nombreuses mesures de performance publiées ne peuvent pas être reproduites simultanément.

Certaines des mesures publiées peuvent être appliquées à différents niveaux de traitement. Par exemple, les requêtes par seconde peuvent représenter des valeurs pour le traitement de la couche OSI 2 (L2) ou de la couche OSI 7 (L7). D'autre part, le TPS fait souvent uniquement référence à la négociation de clés SSL, tandis que les requêtes de couche 7 par seconde font référence aux requêtes cryptographiques ultérieures utilisant une session SSL établie. Une charge de travail particulière exercera les différents composants de traitement ADC différemment d’une autre charge de travail. Un autre point clé à retenir concernant les mesures publiées par l’ADC est que différentes charges de travail rencontreront différentes limites de performances.

Chaque couche de réseau OSI dispose de plusieurs mesures généralement publiées pour ces couches. Par exemple, il est courant de voir des mesures de couche 4 indiquées en connexions par seconde et d’autres mesures pour le débit de couche 4. Les couches OSI 5 et 6 ne sont pas facilement mappées à la pile IP, mais des services tels que SSL/TLS et la compression peuvent être considérés comme des couches 5 et 6. Comme indiqué ci-dessus, les tests pour chacune de ces mesures sont souvent effectués avec un trafic conçu pour solliciter cette mesure particulière et ne représentent pas les charges de trafic réelles. Par exemple, le TPS SSL maximal résultera d'un test avec une charge utile SSL de longueur nulle, de sorte qu'aucun temps de traitement ADC n'est consacré au décryptage des données SSL. Bien que raisonnable pour déterminer uniquement les performances du matériel SSL, aucune application de production n'enverra de charges utiles de longueur nulle. De même, le débit de la couche 2 sera testé sans SSL activé et sans traitement de couche 7, car cela ralentira l'ADC, bien que de nombreux déploiements de production utiliseront ces fonctionnalités. La plupart des mesures ADC sont testées de manière isolée, mais la plupart des environnements de production utilisent une combinaison de fonctionnalités ADC, chaque mesure mettant l'accent sur différents composants ou combinaisons de composants. Les composants impliqués peuvent inclure le processeur, la carte d'interface réseau (NIC), les circuits intégrés spécifiques à l'application (ASIC) et les réseaux de portes programmables sur site (FPGA), entre autres. Lorsqu'un ADC manque d'un composant particulier, le processeur est utilisé à la 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 le traitement des paquets de couche 4 sollicite principalement le FPGA. La mesure du débit sur toutes les couches fait référence au débit total disponible en gigabits par seconde, tandis que la mesure des connexions mesure le nombre de connexions par seconde pouvant être établies sur cette couche particulière. Par exemple, la mesure de connexion de couche 4 mesure le nombre de connexions TCP pouvant être établies par seconde.

Le traitement SSL est unique dans le sens où les sessions sont établies et gérées sur plusieurs connexions. Une connexion peut établir une session SSL (appelée transaction), tandis que les connexions suivantes peuvent réutiliser une session SSL (appelée demande). Par conséquent, les mesures de transaction et de demande sont répertoriées séparément. De loin, les transactions SSL durent plus longtemps que les requêtes SSL suivantes, de sorte que le nombre limitant les performances de débit est souvent la métrique des transactions. Une fois qu'une session SSL est établie et qu'une demande ultérieure est effectuée, la charge utile des données doit être cryptée ou décryptée. L'ASIC cryptographique gère le cryptage et le décryptage ; les performances sont mesurées par la métrique de débit.

Il est souvent utile de compresser la charge utile des données. La compression est effectuée par l'ASIC de compression et sa mesure est également le débit.

Enfin, la couche 7 est unique dans le sens où, compte tenu des options de gestion du trafic complexes et variées disponibles, tout le traitement de la couche 7 est effectué via le processeur. La persistance des cookies est une capacité de couche 7 courante qui lie chaque session utilisateur à un serveur particulier du pool et est exécutée par le processeur. La métrique des requêtes de couche 7 fait référence au nombre de requêtes de couche 7 par seconde que l'ADC peut exécuter. De même, la mesure du débit de la couche 7 fait référence au débit total possible au niveau de la couche 7.

Enfin, toute couche qui doit préserver l’état de connexion nécessitera que l’ADC maintienne une table de connexion. Les tables de connexion sont communes aux connexions TCP de couche 4, aux sessions SSL et aux sessions HTTP de couche 7. Les protocoles avec des connexions de longue durée peuvent épuiser ou stresser une table de connexion ADC.

Chaque mesure peut aider à déterminer un aspect spécifique de la performance. Comprendre les différentes opérations effectuées à chaque couche, ainsi que les composants affectés par ces opérations, aide à évaluer les mesures de performances ADC pour un déploiement particulier.

Chaque aspect de la fonctionnalité ADC peut être fourni par un processeur. En fait, de nombreux fournisseurs de matériel ADC proposent une version uniquement logicielle. Cela est possible parce qu’un processeur est le type de matériel le plus flexible disponible, capable d’effectuer presque toutes les tâches centrées sur les données.

Confier chaque aspect des fonctionnalités ADC à un processeur a cependant ses limites. Parmi les trois principaux types de matériel de traitement du trafic réseau (CPU, ASIC et FPGA), le CPU est le plus lent et sans doute le plus cher, nécessitant le support de la mémoire et des contrôleurs de mémoire. Les deux autres types de matériel pour le traitement du trafic réseau sont l'ASIC et le FPGA. Un ASIC est conçu pour effectuer une tâche spécifique, d'où son nom. Aucun autre type de matériel n’est plus rapide qu’un ASIC pour effectuer une tâche, mais ses capacités sont limitées à ce qui est conçu dans la puce. Si une application a besoin de fonctionnalités non disponibles sur l'ASIC, l'application doit plutôt utiliser un processeur et effectuer les tâches dans le logiciel.

Si un CPU est flexible et lent, et qu'un ASIC est inflexible et rapide, une troisième technologie opère au milieu : le FPGA. Un FPGA est plus lent qu'un ASIC mais beaucoup plus rapide qu'un CPU, et il peut être programmé pour effectuer des tâches non envisagées par les concepteurs du FPGA.

Un ADC bien conçu utilisera au maximum les capacités de chaque type de matériel : en reléguant les tâches courantes et simples aux composants ASIC, en effectuant des tâches plus complexes dans les composants FPGA et en gérant les tâches les plus complexes et les moins courantes dans le processeur. Une grande partie de la magie de l’ingénierie dans un ADC est le résultat de la coordination des différents types de composants pour gérer le plus efficacement possible les différentes charges de travail.

La tâche la plus fréquente, de loin, effectuée dans un ADC est le traitement des paquets au niveau des interfaces réseau. Une carte réseau standard prête à l'emploi est soit optimisée pour un trafic entrant à volume élevé (par exemple, sur un ordinateur de bureau ou un autre périphérique utilisateur), soit optimisée pour un trafic sortant à volume élevé (par exemple, sur un serveur). Un ADC est unique dans le sens où il nécessite une carte réseau réglée pour un débit maximal dans les deux sens. Aucune carte réseau standard n’a été conçue pour offrir un débit maximal dans les deux sens. Le traitement des paquets ADC étant fréquent et relativement simple, il est parfaitement adapté à un ASIC. Dans les environnements ADC en cluster, un ASIC désagrégateur (DAG) agit comme un équilibreur de charge frontal, garantissant que les mêmes sessions client et serveur circulent toujours via le même nœud de cluster. L’utilisation d’un DAG dans un environnement en cluster facilite la mise à l’échelle horizontale des appareils ADC pour répondre aux demandes de trafic. Dans un ADC correctement conçu, tout le traitement et la commutation des paquets de couche 2 peuvent être effectués dans 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 capacités de routage ainsi que des protections contre le pare-feu et les dénis de service distribués (DDoS), y compris les cookies TCP SYN. L'utilisation d'un FPGA à ce niveau permet un traitement et des protections de couche 4, garantissant que le trafic considéré pour un traitement ultérieur a été correctement assemblé et filtré.

Le traitement du chiffrement et de la compression, comme SSL ou TLS, ainsi que les nouvelles fonctionnalités introduites par HTTP/2, constituent une autre utilisation du matériel dédié. Souvent, un ASIC spécialisé sera utilisé pour le traitement cryptographique, y compris la négociation de clés SSL à forte intensité de calcul des chiffrements modernes tels que le cryptage Diffie-Hellman à courbe elliptique (ECDHE). Une fois la négociation de la clé SSL effectuée, le cryptage et le décryptage en masse des requêtes ultérieures peuvent également être gérés par le matériel ASIC. De même, la compression et la décompression utilisant des algorithmes courants peuvent être effectuées par du matériel ASIC. L'utilisation de composants ASIC dédiés permet un traitement rapide du cryptage et de la compression.

Tout traitement restant du trafic réseau non géré par les ASIC et les FPGA doit être traité par le processeur. Bien que lent par rapport aux ASIC et aux FPGA, le processeur est le composant le plus flexible du convertisseur analogique-numérique. Le processeur est également chargé de tâches non liées au traitement du réseau, telles que l'interface utilisateur graphique et d'autres tâches de configuration, la gestion des interruptions d'E/S ou même le traitement des requêtes de disque. Étant donné que les exigences imposées au processeur peuvent varier en fonction de la latence et que le processeur est le dernier type de matériel à traiter le trafic réseau, les ADC sont intentionnellement conçus pour diriger le moins de traitement de trafic possible vers le processeur, en traitant autant que possible sur des ASIC et des FPGA plus rapides à la place.

Il peut être difficile de traduire les mesures publiées par les fournisseurs en performances réelles. Comprendre l’interaction entre les différents types de charges de travail, les ressources qu’elles consomment et les capacités d’une plate-forme matérielle, bien que complexe, peut vous aider à prendre la meilleure décision d’achat pour votre organisation.

Les fiches techniques publiées et autres ressources contribuent à faciliter la spécification de la bonne plateforme, mais il est également important de s’appuyer directement sur l’expérience et l’expertise du fournisseur dans la mesure du possible. Les principaux fournisseurs disposeront d’une expertise approfondie dans l’adéquation des charges de travail aux plateformes, une expertise qui devrait être facilement accessible aux clients.

En combinant une bonne compréhension des caractéristiques du trafic de votre application et des capacités de votre plateforme avec l'expertise de votre fournisseur, vous réduirez le risque et les dépenses potentielles liées au sous-provisionnement ou au sur-provisionnement de votre plateforme.