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

Vous pouvez interroger les mesures de performance réseau en temps réel sur les instances qui prennent en charge la mise en réseau améliorée via l'Elastic Network Adapter (ENA). Ces métriques fournissent une valeur cumulée du nombre de paquets mis en file d'attente ou supprimés sur chaque interface réseau depuis la dernière réinitialisation de l'appareil.

Voici certaines des mesures de l'ENA :

• bw_in_allowance_exceeded : le nombre de paquets mis en file d'attente ou supprimés parce que la bande passante agrégée entrante a dépassé le maximum pour l'instance.
• bw_out_allowance_exceeded : le nombre de paquets mis en file d'attente ou supprimés parce que la bande passante agrégée sortante a dépassé le maximum pour l'instance.
• pps_allowance_exceeded: le nombre de paquets mis en file d'attente ou supprimés car le nombre de paquets bidirectionnels par seconde (PPS) a dépassé le maximum pour l'instance.
• conntrack_allowance_exceeded : le nombre de paquets mis en file d'attente ou supprimés parce que le trafic réseau de l'instance a dépassé le nombre maximum de connexions pouvant être suivies.

Les spécifications de performance réseau varient en fonction du type d'instance. Pour consulter les spécifications, consultez la section Instances de la génération actuelle. Dans certains cas, vous pouvez constater des files d'attente ou des interruptions même si votre bande passante moyenne ou votre nombre de PPS, comme indiqué dans Amazon CloudWatch, est faible. Par exemple, les métriques NetworkIn, NetworkOut, NetworkPacketsIn, ou NetworkPacketsOut peuvent afficher des montants qui ne suggèrent pas qu'une limite a été atteinte.

Résolution

Les microrafales sont la cause la plus fréquente des symptômes précédents. Les microrafales sont de brèves pointes de demande suivies de périodes d'activité faible ou nulle. Ces rafales ne durent généralement que quelques secondes, millisecondes, voire microsecondes. Dans le cas des microrafales, les métriques CloudWatch répertoriées dans la section précédente ne sont pas suffisamment précises pour les refléter.

Comment sont calculées les moyennes

Les métriques EC2 de CloudWatch répertoriées dans la section précédente sont échantillonnées toutes les minutes. Ces métriques capturent le nombre total d'octets ou de paquets transférés au cours de cette période. Ces échantillons sont ensuite agrégés et publiés sur CloudWatch par périodes de 5 minutes. Chaque statistique de la période renvoie une valeur d'échantillon différente :

• La somme est la somme de toutes les valeurs de l'échantillon.
• SampleCount est le nombre d'échantillons agrégés (dans ce cas, 5).
• Le minimum est la valeur d'échantillon avec le plus faible nombre d'octets/paquets.
• La moyenne est la valeur moyenne de l'échantillon, calculée en divisant Sum par SampleCount.
• La valeur maximale est la valeur d'échantillon avec le nombre d'octets/paquets le plus élevé.

Le débit moyen ou PPS peut être calculé de deux manières :

• Divisez la somme par période (par exemple, 300 secondes) pour obtenir une moyenne simple sur 5 minutes.
• Divisez Maximum par 60 secondes pour obtenir la moyenne de la minute pendant laquelle l'activité est la plus intense.

Comment les microrafales sont reflétées dans les métriques CloudWatch

Voici un exemple de microrafale et comment il est reflété dans CloudWatch :

• Les performances de bande passante réseau de l'instance sont de 10 Gbit/s (1,25 Gbit/s).
• Dans un échantillon donné (60 secondes), un transfert de données sortantes de 20 Go utilise toute la bande passante disponible, ce qui entraîne l'incrémentation de bw_out_allowance_exceeded. Le transfert prend environ 20 secondes et aucune autre donnée n'est envoyée par la suite.
• L'instance reste inactive pendant les 4 échantillons restants (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 :

SUM(NetworkOut) / PERIOD = ((20 GB * 1 sample) + (0 GB * 4 samples)) / 300 seconds = ~0.066 GB/s * 8 bits = ~0.533 Gbps

Même si vous calculez le débit sur la base de l'échantillon le plus élevé, la moyenne ne reflète toujours pas le débit :

MAXIMUM(NetworkOut) / 60 = 20 GB / 60 seconds = ~0.333 GB/s * 8 bits = ~2.667 Gbps

Surveillance des microrafales

Pour mesurer le débit et le PPS à un niveau plus précis, utilisez les outils du système d'exploitation (OS) pour surveiller les statistiques du réseau. Surveillez les statistiques de votre réseau plus fréquemment pendant les périodes de forte activité ou de forte activité.

Voici des exemples d'outils du système d'exploitation :

Linux

• sar
• décharger
• iftop
• iptraf-ng

Windows

• Moniteur de performance

L'agent CloudWatch peut être utilisé à la fois sous Linux et Windows pour publier ces métriques réseau au niveau du système d'exploitation sur CloudWatch sous forme de métriques personnalisées. Ces mesures peuvent être publiées à des intervalles d'une seconde seulement. Notez que les métriques à haute résolution (celles dont la période est inférieure à 60 secondes) entraînent des charges plus élevées. Pour plus d'informations sur la tarification de CloudWatch, consultez la page de tarification d'Amazon CloudWatch.

Il est recommandé de surveiller les indicateurs de performance du réseau fournis par l'ENA. La version du pilote doit être supérieure ou égale à 2.2.10 (Linux) et 2.2.2 (Windows) pour que vous puissiez consulter les métriques. Pour en savoir plus, consultez les rubriques suivantes :

• Surveillez les performances réseau de votre instance EC2 (Linux)
• Surveillez les performances réseau de votre instance EC2 (Windows)

CloudWatch Agent peut également publier des métriques ENA. Pour obtenir des instructions sur la publication de métriques ENA pour Linux, voir Collecter des métriques de performance réseau. Pour Windows, les métriques ENA sont disponibles dans Performance Monitor. Vous pouvez configurer l'agent CloudWatch pour publier les métriques disponibles dans Performance Monitor.

Prévenir les microrafales

Pour éviter les microrafales, le trafic doit être rythmé au niveau des expéditeurs, afin qu'il ne dépasse pas un débit ou un débit de paquets maximum. Cela rend les microrafales difficiles à éviter. La régulation du trafic au niveau des expéditeurs nécessite généralement des modifications au niveau de l'application. Selon la manière dont cette modification est mise en œuvre, la prise en charge de la régulation du trafic par le système d'exploitation devra peut-être être disponible et activée au niveau des expéditeurs. Cela n'est peut-être pas toujours possible ou pratique, toutefois. Les microrafales peut également se produire en raison d'un trop grand nombre de connexions envoyant des paquets sur une courte période. Dans ce cas, le suivi du rythme des expéditeurs individuels n'est pas utile.

Il est recommandé de surveiller les métriques de l'ENA. Si les limites sont souvent atteintes ou s'il est prouvé que la régulation du trafic a un impact sur vos applications, procédez comme suit :

• Passez à la vitesse supérieure : passez à une taille d'instance plus grande. Les instances plus importantes ont généralement des allocations plus élevées. Les instances optimisées pour le réseau (celles comportant un « n », par exemple C5n) ont des tolérances plus élevées que leurs homologues non optimisées pour le réseau.
• Élargir l'échelle : répartissez le trafic entre plusieurs instances afin de réduire le trafic et les conflits au niveau des instances individuelles.

Pour les systèmes d'exploitation basés sur Linux, outre les options précédentes, il existe des options d'atténuation pour les utilisateurs avancés. Vous pouvez implémenter ces options seules ou en combinaison. Il est recommandé de comparer les mesures d'atténuation dans un environnement de test afin de vérifier qu'elles réduisent ou éliminent le façonnage du trafic sans nuire à votre charge de travail.

• **SO_MAX_PACING_RATE :**Cette option de socket peut être transmise par une application à l'appel système setsockopt pour spécifier un rythme maximal (octets par seconde). Le noyau Linux rythme ensuite le trafic provenant de ce socket afin qu'il ne dépasse pas la limite. Cette option nécessite les éléments suivants :

• Modifications au niveau du code de l'application.

• Support depuis le noyau.

• L'utilisation de la discipline de file d'attente Fair Queue (FQ) ou la prise en charge par le noyau du pacing au niveau de la couche TCP (applicable au protocole TCP uniquement).

• **Disciplines de mise en file d'attente (qdiscs) : **les qdiscs sont responsables de la planification des paquets et de la mise en forme optionnelle. Certains qdiscs, tels que fq, aident à atténuer les pics de trafic provenant de flux individuels. Pour plus d'informations, consultez la page du manuel Traffic Control (TC).

• **Files d'attente Slow Transmission (Tx) :**Dans certains scénarios, les files d'attente Tx peu profondes contribuent à réduire la mise en forme du PPS. Cela peut être réalisé de deux manières :

• Limites de file d'octets (BQL) :BQL limite dynamiquement le nombre d'octets en cours de traitement dans les files d'attente Tx. BQL est activé par défaut sur les versions du pilote ENA fournies avec le noyau Linux (celles se terminant par un « K »). Pour les versions du pilote ENA disponibles sur GitHub (celles se terminant par un « g »), BQL est disponible à partir de la version 2.6.1g et est désactivé par défaut. Vous pouvez activer BQL à l'aide du paramètre enable_bql du module ENA.

• Longueur de file d'attente Tx réduite : réduisez la longueur de la file d'attente Tx de sa valeur par défaut de 1 024 paquets à une quantité inférieure (256 au minimum). Vous pouvez modifier cette longueur à l'aide de l'outil ethtool.

Informations connexes

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