Home Articles techniques Surveillance des performances des sockets à grande échelle avec xTCP
Applications

Surveillance des performances des sockets à grande échelle avec xTCP

About The Author

Outline

Contexte

Les CDN et les fournisseurs de cloud fournissent de grands volumes de trafic sur Internet et utilisent des outils de surveillance complets pour garantir performances et fiabilité. Ceux-ci incluent des outils qui couvrent différentes couches de distribution du trafic telles que réseau, serveur, application, etc TCP/IP représente la majeure partie de ce trafic (alors que QUIC basé sur UDP est en hausse dans le monde, il représente encore une petite fraction du trafic total par rapport à TCP).

Les sockets sont des abstractions de système d’exploitation qui relient la connexion client et serveur sur laquelle les données sont transmises. Les problèmes de réseau sont donc directement reflétés dans les données stockées avec chaque socket. Par exemple, la congestion du réseau peut entraîner des temps de réponse lents et une augmentation des temps de trajet aller-retour (RTT). Il est également possible que la bande passante du réseau soit disponible, mais que l’application soit submergée par trop de requêtes et ne puisse pas remplir le tampon avec suffisamment de données pour utiliser pleinement la bande passante disponible, ce qui entraîne une anomalie limitée à l’application. Souvent, les serveurs gèrent plusieurs sockets en même temps, ce qui peut conduire à des conflits de ressources mettant à rude épreuve les ressources système telles que le processeur et la mémoire.

Ainsi, la surveillance des performances des sockets TCP à grande échelle peut fournir une compréhension critique des comportements du trafic, tels que les temps de réponse lents ou les connexions interrompues, et identifier les cas où des améliorations peuvent être apportées.

Outils existants

L’utilitaire « ss » dans Linux est un outil commun utilisé pour obtenir des statistiques de socket. Semblable à « netstat », ss fournit un mécanisme plus rapide et plus flexible pour obtenir des informations en autorisant des filtres sur les États, les protocoles et les adresses des sockets. Nous avons également commencé notre voyage de surveillance des sockets avec ss. Bien qu’il s’agisse d’un outil puissant pour obtenir rapidement une liste de sockets et de métriques pertinentes, le principal défi de ss est qu’il peut consommer des ressources importantes, en particulier lorsqu’il est utilisé sur des systèmes avec un grand nombre de sockets. Cela peut avoir un impact sur les performances du système et ralentir d’autres processus. En outre, la sortie ss n’est pas idéale pour l’analyse, en raison de l’utilisation incohérente de clé : valeur, et complique considérablement la capacité de diffuser les données collectées à partir de milliers de serveurs.

Notre première version de la collection de sockets utilisant ss était un script bash exécuté sur des serveurs de cache sélectionnés que nous exportons la sortie de “ss –tcp –info” dans un fichier. Ce fichier serait alors rsync-ed vers un hôte bastion à partir duquel un script python le lirait, l’analyserait et l’insérerait dans ElasticSearch. Cela a permis de faire le travail, mais était loin d’atteindre l’échelle dont nous avions besoin. La prochaine itération de ce travail était d’avoir un script python vivant sur les serveurs de cache qui serait appelé à partir d’une interface HTTP et renverrait les statistiques agrégées pour être insérées dans le cluster ElasticSearch. Cette méthode a fait évoluer le goulot d’étranglement d’analyse d’un emplacement central de back-office vers le serveur cache individuel, mais a entraîné une utilisation importante de la mémoire sur les serveurs avec un nombre significativement élevé de sockets. En fin de compte, nous avons reconnu la nécessité d’un remplacement léger pour la partie ss du système.

Nos principales exigences pour ce nouvel outil étaient qu’il soit léger et évolutif pour le grand nombre de sockets dont disposent nos serveurs CDN et qu’il soit capable de retransmettre les données à l’aide d’un mécanisme efficace tel que les tampons de protocole. L’outil TCP-info du MeasurementLab est un excellent utilitaire implémenté dans Golang. Cependant, il est conçu pour suivre les mêmes prises au fil du temps. Étant donné le grand volume de nos connexions de prises, nous avons fait un choix de conception de ne pas suivre les prises individuelles. Au lieu de cela, demandez à chaque boucle d’interrogation d’être indépendante, fournissant un instantané de l’état actuel des sockets ouverts. L’objectif principal ici est de suivre les performances globales du système et non les sockets individuels.

XTCP

Pour résoudre ces défis, nous introduisons xTCP open-source (extract, export, Xray TCP). XTCP est un utilitaire Golang pour capturer et diffuser des données de socket à grande échelle. XTCP utilise Netlink pour capturer les informations de socket, empaqueter les données dans protobufs, et les envoyer via un port UDP (pour être finalement envoyé à Kafka, etc.) ou écrire à NSQ.

NetLink fournit une interface générique pour la communication entre l’espace utilisateur et l’espace noyau. Outils de surveillance des sockets ss, tcp-info utilisez NETLINK_INET_DIAG, qui fait partie de la famille de protocoles Netlink, pour obtenir des informations sur les sockets du noyau dans l’espace utilisateur (note de la page de manuel : NETLINK_INET_DIAG a été introduit dans Linux 2.6.14 et ne supporte que les sockets AF_INET et AF_INET6. Dans Linux 3,3, il a été renommé NETLINK_SOCK_DIAG et étendu pour prendre en charge les sockets AF_UNIX.)

XTCP extrait les données TCP INET_DIAG du noyau à des débits élevés et exporte ces données via protobufs. Sur une machine avec environ ~120k sockets, les messages Netlink sont environ ~5-6MB, cependant, la sortie ASCII de ss est environ ~60MB. De plus, ss lit à partir du noyau en morceaux d’environ 3 Ko par défaut. XTCP lit les blocs de 32 Ko et minimise ainsi les appels système. XTCP lit simultanément les données de socket Netlink en utilisant plusieurs workers pour vider la file d’attente aussi rapidement que possible et analyse simultanément les messages Netlink pour le streaming. Toutes ces optimisations réduisent l’encombrement de xTCP pour une exécution sur des serveurs de cache de production.

Utilisation à Edgio

Nous utilisons largement les données xTCP pour analyser les performances des clients. Généralement, nous suivons RTT et retransmettons agrégés par point de présence (POP) et ASN.

Contrairement à Aging Rate, TTL nous permet de modifier la capacité de cache d’un élément particulier. Pour la durée définie à l’aide de la fonction TTL, un élément ne vieillit pas lorsqu’il est sur le disque, il est donc moins probable (même très improbable) d’être expulsé. Une fois le TTL expiré, l’élément peut commencer à vieillir de la manière traditionnelle LRU ou avec un vieillissement rapide ou lent (selon la façon dont l’opérateur le configure). Dans la figure ci-dessous, TTL avec vieillissement lent a conservé un élément sur le disque au point où il ne dépassait pas le seuil d’éviction du cache. À l’autre extrémité, TTL a veillé à ce qu’un flux vidéo en direct soit mis en cache pendant au moins la durée de l’événement, mais après cela a été rapidement supprimé du disque en utilisant un vieillissement rapide.

Un exemple de tableau de bord xTCP montrant RTT, retransmissions et nombre de sockets échantillonnés pour POPS AGA et CHB pour un grand fournisseur américain.

Dans un article de blog précédent, nous avons présenté notre pipeline pour le réglage dynamique du contrôle de la congestion pour activer automatiquement BBR pour les clients qui sont sous-performants et où nous savons que le mécanisme de BBR serait le plus utile. Les données xTCP sont la source principale de l’analyse.

Nous trouvons constamment de nouvelles façons d’utiliser les données xTCP pour répondre à des questions complexes telles que l’impact de la congestion et l’apprentissage automatique pour prédire les performances et détecter les anomalies. Nous prévoyons de rendre compte de cette analyse des données de socket dans un prochain billet de blog.

Aujourd’hui, xTCP rejoint vFlow (sflow, netflow, ipfix Collector) dans notre suite d’outils de surveillance de réseau open source. Nous espérons que cela servira la communauté de surveillance des performances de l’infrastructure pour la collecte de données socket et nous attendons avec impatience de participer activement à faire avancer cet outil.

Accusé de réception

Le succès et la grande facilité d’utilisation de xTCP sont le résultat des contributions des individus et des équipes à travers Edgio. Nous tenons à remercier tout particulièrement David Seddon qui est le développeur initial de xTCP. Nous remercions tout particulièrement tous les réviseurs de code internes et les contributeurs pour les tests, l’acquisition, les tableaux de bord et les commentaires sur xTCP.