Pourquoi mon instance Amazon EC2 dépasse-t-elle les limites de son réseau alors que le taux d'utilisation moyen est faible ?

Brève description

Les métriques de performance du réseau ENA (Elastic Network Adaptor bw_in_allowance_exceeded, bw_out_allowance_exceeded ou pps_allowance_exceeded peuvent augmenter même lorsque votre utilisation moyenne est faible. Ce problème est le plus souvent dû à de courtes périodes de demande de ressources réseau, appelées microrafales. Les rafales ne durent généralement que quelques secondes, millisecondes, voire microsecondes. Les métriques Amazon CloudWatch ne sont pas suffisamment précises pour les refléter. Par exemple, vous pouvez utiliser les métriques d’instance de CloudWatch NetworkIn et NetworkOut pour calculer le débit moyen par seconde. Toutefois, les débits calculés peuvent être inférieurs à la bande passante d'instance disponible pour le type d'instance en raison de microrafales.

Une augmentation des métriques bw_in_allowance_exceeded et bw_out_allowance_exceeded se produit également sur les instances de plus petite taille disposant d'une bande passante « maximale », telle que « jusqu'à 10 gigabits par seconde (Gbit/s). » Les instances de plus petite taille utilisent des crédits d'I/O réseau pour dépasser leur bande passante de base pendant une durée limitée. Lorsque les crédits sont épuisés, le trafic s'aligne sur la bande passante de référence et les métriques augmentent. Étant donné que la rafale d'instances se produit au mieux, les métriques peuvent augmenter même lorsque votre instance dispose de crédits d'I/O disponibles.

Une augmentation de la métrique pps_allowance_exceeded se produit également lorsque des modèles de trafic non optimaux entraînent des pertes de paquets à des débits PPS inférieurs. Le routage asymétrique, les pilotes obsolètes, les petits paquets, les fragments et le suivi des connexions affectent les performances PPS d'une charge de travail.

Résolution

Calcul de la moyenne

CloudWatch échantillonne les métriques Amazon EC2 toutes les 60 secondes afin de capturer le nombre total d'octets ou de paquets transférés en 1 minute. Amazon EC2 regroupe les échantillons et les publie sur CloudWatch par périodes de 5 minutes. Chaque statistique de la période présente une valeur différente.

Lorsque vous utilisez une surveillance détaillée, CloudWatch publie les métriques NetworkIn et NetworkOut sans agrégation par périodes d'une minute. Les valeurs de Somme, Minimum, Moyenne et Maximum sont les mêmes, et la valeur de SampleCount est 1. CloudWatch regroupe et publie toujours les métriques NetworkPacketsIn et NetworkPacketsOut de 5 minutes.

Utilisez les méthodes suivantes pour calculer le débit moyen en octets par seconde (o/s) ou PPS sur une période :

• Pour obtenir une moyenne simple sur la période que vous avez spécifiée, divisez la Somme par la Période ou par la différence d'horodatage entre les valeurs (DIFF_TIME).
• Pour obtenir la moyenne de la minute pendant laquelle l'activité est la plus intense, divisez Maximum par 60 secondes.

Pour convertir les octets/s en Gbit/s, divisez les résultats du calcul par 1 000 000 000 octets, puis multipliez-les par 8 bits.

Microrafales dans les métriques CloudWatch

L'exemple suivant montre comment une microrafale apparaît dans CloudWatch. L'instance dispose d'une allocation de bande passante réseau de 10 Gbit/s et utilise une surveillance de base.

Sur un échantillon de 60 secondes, un transfert de données sortant d'environ 24 Go utilise toute la bande passante disponible. Le transfert de données augmente la valeur de bw_out_allowance_exceeded et se termine en 20 secondes environ avec une vitesse moyenne de 9,6 Gbit/s. Amazon EC2 n'envoie aucune autre donnée et l'instance reste inactive pendant les 4 échantillons restants, soit 240 secondes.

Dans cet exemple, le débit moyen sur une période de 5 minutes est bien inférieur à celui enregistré pendant la microrafale :

Formule : AVERAGE_Gbps = SUM(NetworkOut) / PERIOD(NetworkOut) / 1 000 000 000 octets * 8 bits

SUM(NetworkOut) = (~24 GB * 1 échantillon) + (~0 Go * 4 échantillons) = ~24 Go

PERIOD(NetworkOut) = 300 secondes (5 minutes)

AVERAGE_Gbps = ~24 / 300 / 1 000 000 000 * 8 = ~0,64 Gbps

Même lorsque vous calculez le débit moyen sur la base de l'échantillon le plus élevé, la quantité ne reflète toujours pas le débit pendant la microrafale :

Formule : AVERAGE_Gbps = MAXIMUM(NetworkOut) / 60 secondes / 1 000 000 000 octets / 8 bits

MAXIMUM(NetworkOut) = ~24 Go

AVERAGE_Gbps = ~24 GB / 60 / 1 000 000 000 * 8 = ~3,2 Gbps

Lorsque des données haute résolution sont disponibles, vous pouvez obtenir des moyennes plus précises. Lorsque vous collectez des métriques d'utilisation du réseau du système d'exploitation (OS) à intervalles d'une seconde, le débit moyen atteint brièvement environ 9,6 Gbit/s.

Surveiller les microrafales

Vous pouvez utiliser l'agent CloudWatch sous Linux et Windows pour publier des métriques réseau au niveau du système d'exploitation sur CloudWatch à des intervalles allant jusqu'à 1 seconde. L'agent peut également publier des métriques de performances du réseau ENA.

Remarque : Des métriques à haute résolution sont proposées à des prix plus élevés.

Vous pouvez également utiliser les outils du système d'exploitation pour surveiller les statistiques du réseau à des intervalles allant jusqu'à 1 seconde. Pour les instances Windows, utilisez Surveillance des performances. Pour Linux, utilisez sar, nload, iftop, iptraf-ng ou netqtop.

Pour identifier clairement les microrafales, effectuez une capture de paquets du système d'exploitation, puis utilisez Wireshark pour tracer un graphique d'I/O à des intervalles d'une milliseconde. Pour plus d'informations, consultez les pages Télécharger Wireshark et 8.8. La fenêtre « Graphiques d’I/O » sur le site Web de Wireshark.

Cette méthode présente les limites suivantes :

• Les allocations réseau sont approximativement proportionnelles à la microseconde. Par exemple, un type d'instance doté d'une bande passante de 10 Gbit/s peut envoyer et recevoir environ 10 mégabits (Mo) en 1 milliseconde.
• Les captures de paquets entraînent une charge supplémentaire du système et peuvent réduire le débit global et les taux PPS.
• Les captures de paquets peuvent ne pas inclure tous les paquets en raison des pertes de paquets provoquées par une mémoire tampon pleine.
• Les horodatages ne reflètent pas exactement le moment où un réseau a envoyé des paquets ou la date à laquelle l'ENA les a reçus.
• Les graphiques d'I/O peuvent indiquer une activité plus faible pour le trafic entrant car Amazon EC2 façonne le trafic qui dépasse son quota avant qu'il n'atteigne l'instance.

Files d'attente de paquets et paquets perdus

Lorsque le réseau met un paquet en file d'attente, la latence qui en résulte est mesurée en millisecondes. Les connexions TCP peuvent augmenter leur débit et dépasser les quotas d'un type d'instance EC2. Par conséquent, certaines files d'attente de paquets sont attendues même lorsque vous utilisez la bande passante et l'aller-retour (BBR) ou d'autres algorithmes de contrôle de congestion utilisant la latence comme signal. Lorsqu'un réseau supprime un paquet, le TCP retransmet automatiquement les segments perdus. Les files d'attente de paquets et les paquets perdus peuvent entraîner une latence plus élevée et une réduction du débit. Cependant, vous ne pouvez pas afficher les actions de restauration. En général, les seules erreurs que vous pouvez voir sont celles qui surviennent lorsque votre application utilise de faibles délais d'attente ou lorsque le réseau supprime suffisamment de paquets pour que la connexion soit fermée de force.

Les mesures de performance du réseau ENA ne font pas de différence entre les paquets en file d'attente et les paquets abandonnés. Pour mesurer la latence TCP au niveau de la connexion sous Linux, utilisez les commandes ss ou tcprtt. Pour mesurer les retransmissions TCP, utilisez les commandes ss ou tcpretrans pour les statistiques au niveau de la connexion et nstat pour les statistiques à l'échelle du système. Pour télécharger les outils tcprtt et tcpretrans qui font partie de la collection de compilateurs BPF (BCC), consultez bcc sur le site Web de GitHub. Vous pouvez également utiliser des captures de paquets pour mesurer la latence et les retransmissions.

Remarque : Les paquets que le réseau a abandonnés en raison du dépassement des quotas d'instances n'apparaissent pas dans les compteurs de suppression pour ip ou ifconfig.

Prévenir les microrafales

Tout d'abord, comparez les métriques de performances du réseau ENA aux indicateurs clés de performance (KPI) de votre application afin de déterminer l'effet des files d'attente de paquets ou des paquets perdus.

Si les indicateurs clés de performance sont inférieurs à un seuil requis ou si vous recevez des erreurs dans le journal des applications, prenez les mesures suivantes pour réduire les files d'attente de paquets et les paquets perdus :

• Effectuer une mise à l'échelle verticale ascendante : Augmentez la taille d’instance afin qu'elle dispose d'une allocation réseau plus élevée. Les types d'instances comportant un « n », tels que C7gn, ont des allocations réseau plus élevées.
• Effectuer une mise à l'échelle horizontale ascendante : Répartissez le trafic entre plusieurs instances afin de réduire le trafic et les conflits au niveau des instances individuelles.

Pour les opérations basées sur Linux, vous pouvez également implémenter les stratégies suivantes afin d’éviter les microrafales. Il est recommandé de tester les stratégies dans un environnement de test afin de vérifier qu'elles réduisent la mise en forme du trafic sans affecter la charge de travail.

Remarque : Les stratégies suivantes concernent uniquement le trafic sortant.

SO_MAX_PACING_RATE

Utilisez l'option de socket SO_MAX_PACING_RATE pour spécifier un taux de régulation maximal en octets/s pour une connexion. Le noyau Linux introduit ensuite des délais entre les paquets provenant du socket afin que le débit ne dépasse pas le quota que vous avez spécifié.

Pour utiliser cette méthode, vous devez implémenter les modifications suivantes :

• Modifications du code de l'application.
• Support depuis le noyau. Pour plus d'informations, consultez la page net: introduce SO_MAX_PACING_RATE sur le site Web de GitHub.
• La discipline de file d'attente Fair Queue (FQ) ou la prise en charge par le noyau de la régulation au niveau de la couche TCP (pour le protocole TCP uniquement).

Pour plus d'informations, consultez la page de manuel de getsockopt (2) - Linux et la page de manuel de tc-fq (8) - Linux sur le site Web de man7. Consultez également la page tcp: internal implementation for pacing sur le site web de GitHub.

qdiscs

Linux utilise la configuration par défaut d'une discipline de file d'attente (qdisc) pfifo_fast pour chaque file d'attente ENA afin de planifier les paquets. Utilisez la qdisc fq pour réduire les rafales de trafic dues à des flux individuels et réguler leur débit. Vous pouvez également utiliser fq_codel et cake pour fournir des fonctionnalités de gestion active des files d'attente (AQM) qui réduisent la congestion du réseau et améliorent la latence. Pour plus d'informations, consultez la page de manuel tc (8) - Linux sur le site web de man7.

Pour TCP, activez la notification de congestion explicite (ECN) sur les clients et les serveurs. Combinez ensuite l'ECN avec une qdisc qui peut effectuer le marquage CE (ECN Congestion Experienced). Les marquages CE obligent le système d'exploitation à réduire le débit d'une connexion afin de réduire la latence et les pertes de paquets provoquées par un dépassement du quota d'instance. Pour utiliser cette solution, vous devez configurer la qdisc avec un seuil CE bas en fonction du temps aller-retour moyen (RTT) de vos connexions. Il est recommandé d'utiliser cette solution uniquement lorsque le RTT moyen entre les connexions varie peu. Par exemple, votre instance gère le trafic dans une zone de disponibilité unique.

En raison de problèmes de performances, il n'est pas recommandé de configurer la mise en forme agrégée de la bande passante au niveau de l'instance.

Files d'attente de transmission (Tx) superficielles

Utilisez des files d'attente Tx superficielles pour réduire la mise en forme du PPS. BQL (Byte Queue Limits) limite de façon dynamique le nombre d’octets en cours de traitement dans les files d'attente Tx. Pour activer BQL, ajoutez ena.enable_bql=1 à la ligne de commande de votre noyau dans GRUB.

Remarque : Vous devez disposer de la version 2.6.1g ou supérieure du pilote ENA pour utiliser cette solution. BQL est déjà activé sur les pilotes ENA dont les versions du noyau Linux se terminent par K.

Pour en savoir plus, consultez la page bql : Byte Queue Limits sur le site Web de LWN.net.

Lorsque vous utilisez ENA Express, vous devez désactiver BQL pour optimiser la bande passante.

Vous pouvez également utiliser ethtool pour réduire la longueur de la file d'attente Tx par rapport à sa valeur par défaut de 1 024 paquets. Pour plus d'informations, consultez la page de manuel d'ethtool (8) - Linux sur le site Web de man7.

Informations connexes

Bande passante du réseau de l'instance Amazon EC2