Surveillance de la perte de paquets et de la latence sur le réseau Roblox Cloud

L'équipe d'ingénierie réseau de Roblox gère un réseau vaste et en pleine expansion, avec des centres de données et des points de présence (POP) répartis à travers le monde. La qualité de l'expérience utilisateur sur la plateforme Roblox dépend des performances et de la fiabilité de ce réseau. Il est essentiel que les opérateurs réseau soient capables de dépanner et de détecter les problèmes au sein du réseau, et qu'ils aient une visibilité sur les performances de celui-ci. La surveillance du réseau s'effectue généralement en collectant périodiquement les statistiques des appareils, les métriques d'erreur et les journaux système, puis en les stockant dans une base de données chronologique ou de journaux. Les données sont collectées selon un modèle « push » ou « pull » à l'aide de protocoles standard tels que SNMP, Netconf, les API REST ou la télémétrie en continu.

La détection des défaillances réseau uniquement via la télémétrie des appareils présente plusieurs inconvénients, car il s'agit d'une technique de surveillance passive. Elle dépend de la capacité des nœuds du réseau à identifier et à signaler les situations anormales dès qu'elles se produisent. L'appareil peut ne pas toujours renvoyer les données ou, dans certains cas, ne pas exposer toutes ses statistiques de santé aux méthodes habituelles de collecte de télémétrie. De plus, les appareils réseau peuvent parfois fournir des données erronées ou bloquer silencieusement le trafic. Une limitation majeure de la télémétrie des appareils est qu'elle offre très peu de visibilité sur l'accessibilité de bout en bout, la perte de paquets et les statistiques de latence du réseau.

Un excellent moyen de surveiller activement un réseau consiste à transmettre régulièrement des sondes synthétisées à travers un maillage, comme illustré dans les figures ci-dessous.

Lorsqu'ils dépannent des pannes de production, les opérateurs réseau se voient fréquemment poser des questions telles que « Le réseau perd-il des paquets ? » ou « Y a-t-il une défaillance réseau en cours qui affecte la connectivité du service ? ». Pour répondre à ce type de questions sans avoir accès aux données historiques sur la perte de paquets et la latence, ils devraient examiner un grand nombre de liaisons et de nœuds au sein du réseau.

Conception d'un système de surveillance de réseau maillé fiable et évolutif

Pour qu’un système de surveillance de réseau de type « boîte noire » soit efficace dans la détection des pertes de paquets ou des pics de latence, il nécessite une exploration continue de différentes parties du réseau. Les réseaux de centres de données utilisent toutes les liaisons entre les nœuds pour le trafic utilisateur. Les équipements réseau de production exécutent le protocole BGP et équilibrent la charge du trafic sur plusieurs chemins à coût égal. Les changements de topologie du réseau se répercutent généralement en quelques secondes grâce aux mises à jour des tables de routage dans des conditions normales. Pour obtenir une mesure précise de la perte de paquets réseau, les sondes de test doivent parcourir autant de chemins que possible, couvrant tous les nœuds et liaisons du réseau. Avec un réseau de grande envergure, comme le nôtre, qui s'étend sur plusieurs sites à travers le monde, il n'est pas évolutif de sonder chaque paire de nœuds ou de racks. La solution plus durable que nous avons choisie, qui ne compromet pas le niveau de visibilité, consiste à sonder un maillage N² entre les racks au sein de chaque site, ainsi qu'un autre maillage N² entre tous les sites.

Avec quoi sondons-nous le réseau ?

Les sondes de test doivent émuler le trafic réel transitant par un réseau de production. La majeure partie du trafic sur notre réseau est soit TCP, soit UDP, soit HTTP, et chacun de ces protocoles pourrait potentiellement être utilisé pour les sondes. L'un des problèmes liés à l'utilisation de TCP est qu'il n'est pas assez léger pour s'adapter au nombre de connexions nécessaires à la surveillance d'un grand réseau. Un autre inconvénient du TCP réside dans le fait que le contrôle de flux intégré et les transmissions basées sur une fenêtre glissante entraînent un débit de transmission variable des sondes, ce qui n'est pas idéal pour quantifier ou détecter les pertes momentanées de paquets. L'ICMP, utilisé par les commandes ping et traceroute, est généralement limité en débit sur les serveurs ou les nœuds du réseau. Cela plafonne le débit global des sondes ICMP pouvant être utilisées. Les requêtes HTTP se situent plus haut dans la couche application et dépendent de certains facteurs externes au réseau, tels que les performances du serveur ou de l'application. Le protocole HTTP ajoute un facteur variable supplémentaire aux résultats, difficile à isoler. L'objectif de ce système est de surveiller les performances de l'infrastructure réseau sous-jacente qui opère principalement aux couches OSI 4 et inférieures. Nous avons choisi les sondes UDP pour ces raisons, en plus du fait qu'il s'agit du principal protocole de la couche transport sur notre réseau.

D'où effectuons-nous les sondages ?

Une façon d’atteindre un taux de sondage agrégé élevé tout en couvrant un grand nombre de chemins réseau consiste à utiliser autant de nœuds de calcul que possible pour transmettre les sondes. Cela présente deux avantages : cela aide à répartir la charge sur les systèmes qui génèrent les sondes, et cela augmente le nombre de ports réseau qui les acheminent. Cependant, cela nécessite un agent très stable et aussi peu gourmand que possible en ressources du système hôte. Parallèlement, l'agent doit être capable de mesurer avec précision la perte de paquets et la latence sur plusieurs chemins sans être affecté par les fluctuations d'utilisation du CPU, de la mémoire ou des E/S sur le système hôte. L'agent doit constamment maintenir cet équilibre délicat entre légèreté et haute performance.

Comment mesurons-nous la perte de paquets et la latence sur le réseau ?

Cela peut sembler être un calcul trivial sur un seul flux de sondes, mais certains défis apparaissent à grande échelle et ne sont pas immédiatement évidents. Pour s’adapter à un maillage aussi vaste, l’agent doit calculer rapidement et avec précision le nombre de paquets émis (Tx) et reçus (Rx) avec horodatage sur de nombreux flux simultanément. Il est important que les mesures de perte réseau n’incluent pas les paquets perdus au niveau de l’hôte exécutant l’agent lorsque son CPU est occupé ou que ses tampons réseau débordent. La latence réseau doit être calculée à partir du temps total pendant lequel les sondes ont été sur le réseau ou sur des nœuds intermédiaires, tout en excluant le temps passé en attente dans les tampons d’E/S et le temps d’attente du processus de l’agent pour la planification du système d’exploitation.

Le système Ping Mesh de Roblox

Le besoin d'une surveillance des pertes et de la latence du réseau de type « boîte noire » existe depuis l'essor des infrastructures cloud publiques et privées. Il s'est avéré difficile de trouver une solution prête à l'emploi capable de s'adapter à notre vaste réseau. Plusieurs grands opérateurs cloud et fournisseurs d'outils réseau ont conçu leurs propres solutions pour surveiller les pertes et la latence du réseau. Nous avons testé certains outils librement accessibles, mais nous avons rencontré des problèmes de stabilité et d'évolutivité, tout en n'obtenant qu'une visibilité limitée sur les performances du réseau. Cela nous a amenés à développer notre propre système de surveillance maillé, qui a permis une meilleure détection des erreurs à faible fréquence avec une faible surcharge. Voici quelques-uns des points forts de notre système :

• Nous avons choisi Go pour implémenter tous les composants de notre système, ce qui nous a permis d'atteindre un haut niveau de performance tout en utilisant un minimum de ressources système.
• Nos agents sont très stables et peuvent fonctionner sur un large éventail d'hôtes de production, y compris ceux qui exécutent des services critiques sur la plateforme Roblox, tels que les serveurs de trafic, de mise en cache et d'applications.
• L'agent est optimisé pour regrouper les opérations d'E/S de paquets à l'aide de fonctions wrapper Go sur les appels système sendmmsg() et recvmmsg() de Linux, ce qui lui permet de transmettre un nombre élevé de sondes avec une faible surcharge. Chaque agent de notre déploiement transmet simultanément des sondes à jusqu'à 100 autres hôtes, à un débit de 100 paquets par seconde (PPS). L'agent transmet des rafales de paquets toutes les secondes vers chaque destination.
• Les sondes transportent différentes valeurs de champ de type de service (TOS) dans l'en-tête IP vers chaque destination et sont comptabilisées séparément pour la perte de paquets et la latence sur le réseau. Chaque rafale de paquets comprend un mélange de plusieurs valeurs TOS vers toutes les autres destinations. Cela permet de surveiller les performances du réseau pour différentes classes de qualité de service (QoS).
• L'agent peut détecter des pertes de paquets aussi faibles que 1 paquet sur 6 000 par minute sur chaque chemin de sonde. Les pertes de paquets au cœur ou à la périphérie du réseau d'une durée inférieure à 1 seconde peuvent être détectées, comme celles survenant lors d'un flap BGP.
• Les graphiques de perte de paquets des sondes imitent ceux des taux d'erreur des interfaces des périphériques réseau lorsque ces erreurs sont à l'origine des pertes. Nous avons pu découvrir des bogues de « black-holing » du trafic sur le réseau, qui sont difficiles à détecter.
• Les agents utilisent les horodatages de lecture du noyau de la carte réseau (NIC) pour obtenir une grande précision dans les mesures de latence réseau. Une latence aller-retour intra-site constante de 50 à 100 microsecondes peut être mesurée tout en excluant la latence de planification du système d'exploitation de l'hôte et la dérive de l'horloge réseau.
• Faible utilisation du CPU et faible empreinte mémoire. L'agent utilise moins de 25 % d'un seul cœur aux débits de transmission et de réception maximaux (5 kpps chacun). La plupart des agents déployés n'utilisent qu'environ 5 % d'un cœur. Seuls 10 Mo de mémoire heap sont nécessaires pour gérer les tampons de paquets Tx et Rx et les compteurs de l'agent. Lorsque le réseau s'étend, nous pouvons évoluer verticalement ou horizontalement en ajustant les limites ou en ajoutant des agents supplémentaires.
• L'agent est rarement affecté lorsque le système hôte est soumis à une charge importante. Nous avons obtenu des résultats précis même lorsque la charge du processeur de l'hôte a approché les 99 % à plusieurs reprises.
• Des données de télémétrie sont collectées auprès de chaque agent afin de surveiller leur état de santé. Les agents peuvent identifier des situations problématiques, par exemple lorsque le système hôte redémarre, lorsque le processus de l'agent redémarre ou lorsque des paquets sont perdus en raison d'un débordement des tampons de sockets.

Les agents sont déployés avec Chef sur un large ensemble de clusters de serveurs afin de maintenir un nombre élevé de nœuds participant à l'analyse du réseau. Le binaire de l'agent est exécuté et géré avec systemd sous Linux, de sorte qu'il redémarre automatiquement après un redémarrage de l'hôte ou une mise à niveau de l'agent. Le planificateur de maillage détecte et ajuste dynamiquement les flux selon les besoins lorsqu'un des agents tombe en panne ou que de nouveaux agents apparaissent. Notre application de planification interroge périodiquement l'inventaire des périphériques et un système de découverte de services afin de détecter les nouveaux agents et l'état de santé des serveurs avant d'attribuer des cibles pour les sondages intra-pod, intra-site et inter-site. Un bus de messages est utilisé pour communiquer la liste des hôtes cibles à chaque agent qui transmet des sondes de test. Les flux individuels qui proviennent ou aboutissent à un rack spécifique sont répartis entre tous les agents disponibles au sein de ce rack. Cela nous aide à tester un grand nombre de chemins à coût égal au sein de notre structure réseau, comme le montrent les figures ci-dessous.

Nous avons commencé avec 150 agents lors de notre premier déploiement, et avons désormais multiplié ce nombre par 10. Le maillage couvre notre réseau fédérateur reliant 25 sites répartis à travers le monde. Sur l'un de nos principaux sites de centre de données, nous disposons d'un maillage intra-site couvrant plus de 200 racks avec environ 33 000 flux, pour un taux de sondage total de 1,65 Mpps. Chaque rack reçoit entre 5 000 et 10 000 sondes par seconde provenant d'autres racks. L'application de planification calcule et répartit uniformément plus de 35 000 cibles entre tous nos agents sur les différents sites.

Collecte et visualisation des données

Nous exécutons une application collectrice distincte qui interroge périodiquement tous les agents Ping Mesh pour obtenir les résultats de perte de paquets et de latence. Ces données sont automatiquement filtrées pour exclure les résultats invalides en fonction des états de santé mis en cache localement au niveau du collecteur. Par exemple, nous excluons les résultats provenant d’un agent s’exécutant sur un serveur qui n’a pas répondu aux contrôles de santé ou sur un serveur qui vient de redémarrer. Notre collecteur peut interroger et filtrer de manière synchrone les résultats de plus de 1 500 nœuds, puis ingérer les données dans une base de données de séries chronologiques en moins de 2 secondes.

Les résultats agrégés et par flux sont visualisés à l’aide de tableaux de bord Grafana. Les grilles de cartes thermiques peuvent être difficiles à utiliser avec de grands ensembles de données, en particulier pour notre vaste site de centre de données. Nous utilisons une requête Prometheus topk() pour afficher les chemins présentant la perte de paquets individuelle la plus élevée parmi des milliers de résultats, qui ne sont généralement qu’une poignée. Les résultats sont minutieusement recoupés avec les statistiques de santé des agents et des systèmes hôtes, fréquemment interrogées par le collecteur. Cela nous confère un haut niveau de confiance dans chaque résultat individuel, quelle que soit l’ampleur des variations de perte de paquets. Considérés dans leur ensemble, les résultats individuels peuvent nous fournir des indices sur l’emplacement de la défaillance réseau. Vous trouverez ci-dessous quelques exemples de pertes de paquets détectées par notre système de surveillance maillé.

Résumé et prochaines étapes

Notre système Ping Mesh s'est révélé un outil puissant pour l'équipe d'ingénierie réseau afin de surveiller la perte de paquets et la latence de bout en bout. Ces données permettent de répondre instantanément à la question : « Le réseau perd-il des paquets ? » D'après notre expérience, les incidents réseau majeurs ayant un impact sur les clients sont généralement détectés et signalés par le système de surveillance télémétrique des appareils. Ce système permet également de mettre en lumière des problèmes à faible impact mais potentiellement problématiques, tels que la mise en mémoire tampon du réseau ou des cas isolés de « black-holing » du trafic.

Notre système peut également fournir des informations sur la fiabilité globale du réseau Roblox Cloud. Sur l’un de nos principaux sites de centre de données, nous disposons de plus de 100 millions de sondes par minute surveillant l’état du réseau et nous enregistrons rarement plus de 50 pertes de paquets par minute. Cela indique une fiabilité d’environ 6 9 (99,9999 %) pour le réseau de notre centre de données. Très souvent, aucune perte de paquets n’est constatée parmi les 100 millions de paquets. Lorsqu’un nombre important de paquets est perdu, ce système permet de déterminer où et pendant combien de temps la perte de paquets s’est produite. Un moteur de correction automatique répare le réseau de manière autonome et empêche le trafic utilisateur de subir d’autres pertes en le redirigeant vers un autre chemin au sein du réseau. L’équipe Réseaux de Roblox a mis en place un réseau cloud extrêmement fiable.

À l'avenir, nous avons l'intention d'utiliser un moteur d'analyse pour corréler les données issues de la télémétrie des appareils, des journaux système et d'autres ensembles de données. Nous prévoyons ensuite de comparer ces données avec celles de Ping Mesh afin d'aider à localiser l'endroit où la défaillance réseau s'est produite. À mesure que le réseau cloud de Roblox continue de s'étendre et d'évoluer, nous prévoyons d'améliorer nos mécanismes de sondage pour inclure l'IPv6 et les trames jumbo, tout en ajoutant davantage d'agents afin d'accroître la couverture entre les sites.