Pourquoi mon instance Amazon Elastic Compute Cloud (Amazon EC2) dépasse-t-elle les limites de son réseau alors que l'utilisation moyenne est faible ?

Dernière mise à jour : 26/05/2022

Pourquoi mon instance Amazon Elastic Compute Cloud (Amazon EC2) dépasse-t-elle les limites de son réseau alors que l'utilisation moyenne est faible ?

Brève description

Vous pouvez interroger les métriques de performances réseau en temps réel sur les instances qui prennent en charge la mise en réseau améliorée via Elastic Network Adapter (ENA). Ces métriques fournissent un nombre cumulé de paquets mis en file d'attente ou déposés sur chaque interface réseau depuis la dernière réinitialisation du pilote. Voici quelques-unes des métriques d'ENA :

  • bw_in_allowance_exceeded : nombre de paquets mis en file d'attente ou déposés parce que la bande passante agrégée entrante a dépassé le maximum pour l'instance.
  • bw_out_allowance_exceeded : nombre de paquets mis en file d'attente ou déposés parce que la bande passante agrégée sortante a dépassé le maximum pour l'instance.
  • pps_allowance_exceeded : nombre de paquets mis en file d'attente ou déposés parce que le nombre de paquets par seconde (PPS) bidirectionnels a dépassé le maximum pour l'instance.

Dans certains cas, vous pourrez remarquer des files d'attente ou des dépôts même si votre bande passante ou PPS moyen, tel qu'observé dans Amazon CloudWatch, est faible. Par exemple, les métriques NetworkIn, NetworkOut, NetworkPacketsIn ou NetworkPacketsOut dans CloudWatch peuvent afficher des montants qui ne suggèrent pas qu'une limite a été atteinte.

Solution

Les microrafales sont la cause la plus fréquente des symptômes précédents. Les microrafales sont de courts pics de demande suivis de périodes de faible activité ou d'inactivité. Ces rafales ne durent 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 dans 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 :

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

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

  • Divisez la valeur Sum par la valeur Period (par exemple, 300 secondes), pour obtenir une moyenne simple sur 5 minutes.
  • Divisez la valeur Maximum par 60 secondes, pour obtenir une moyenne dans la minute où l'activité est la plus élevée.

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

Voici un exemple de microrafale et de la façon dont elle est reflétée dans CloudWatch :

  • Les performances de bande passante du réseau de l'instance sont de 10 Gbit/s (1,25 Go/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 la hausse de bw_out_allowance_exceeded. Le transfert s'effectue en 20 secondes environ, 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 au débit de 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 en fonction de l'échantillon le plus élevé, la moyenne ne reflète toujours pas le débit :

MAXIMUM(NetworkOut) / 60 seconds = 20 GB / 60 = ~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 mise en forme ou de forte activité.

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

Linux

  • sar
  • nload
  • iftop
  • iptraf-ng

Windows

  • Performance Monitor

L'agent CloudWatch peut être utilisé sur Linux et Windows afin de publier ces métriques réseau au niveau du système d'exploitation vers CloudWatch en tant que métriques personnalisées. Ces mesures peuvent être publiées à des intervalles aussi courts qu'une seconde. Veuillez noter que les métriques haute résolution (celles dont la période est inférieure à 60 secondes) entraînent des frais plus élevés. Pour plus d'informations sur la tarification CloudWatch, veuillez consulter la tarification Amazon CloudWatch.

Il est recommandé de surveiller les métriques de performance réseau fournies par ENA. La version du pilote doit être supérieure ou égale à 2.2.10 (Linux) et 2.2.2 (Windows) pour que vous puissiez afficher les métriques. Pour plus d'informations, veuillez consulter les pages se rapportant à Linux et Windows. L'agent CloudWatch peut également publier des métriques ENA.

Pour obtenir des instructions sur la publication de métriques ENA pour Linux, veuillez consulter Récupérez des métriques des performances réseau. Pour Windows, les métriques ENA sont disponibles dans Performance Monitor, et l'agent CloudWatch peut y publier toutes les métriques disponibles.

Prévention des microrafales

Pour éviter les microrafales, le trafic doit être rythmé au niveau du ou 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. Définir le rythme du trafic au niveau de l'expéditeur nécessite généralement des modifications au niveau de l'application. Selon la façon dont ces modifications sont mises 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 chez l'expéditeur. Ce n'est peut-être pas toujours possible ou pratique. Les microrafales se produisent également à la suite d'un trop grand nombre de connexions envoyant des paquets sur une courte période, auquel cas définir le rythme des expéditeurs individuels n'aide pas.

Pour ces raisons, il est recommandé de surveiller les métriques ENA, comme indiqué précédemment. Si les limites sont souvent atteintes, ou si cela affecte vos applications, procédez comme suit :

  • Augmenter : passez à une taille d'instance supérieure. Les instances plus volumineuses ont généralement des limites plus élevées. Les instances optimisées pour le réseau (telles que les instances avec un « n », comme C5n) ont des limites plus élevées que leurs homologues non optimisées pour le réseau.
  • Monter en puissance : répartissez le trafic sur plusieurs instances afin de réduire le trafic et les conflits au niveau des instances individuelles.

Sous Linux, en plus des options précédentes, il existe des options d'atténuation potentielles pour les utilisateurs avancés :

  • SO_MAX_PACING_RATE : cette option de socket peut être transmise à setsockopt par une application afin de spécifier une fréquence de stimulation maximale (octets par seconde). Le noyau Linux stimule 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 du code au niveau de l'application.
    Prise en charge par le noyau.
    L'utilisation de la discipline de mise en file d'attente Fair Queue (FQ) ou la prise en charge par le noyau de la stimulation au niveau de la couche TCP (applicable uniquement à TCP).
  • Disciplines de mise en file d'attente (qdiscs) : certaines qdiscs prennent en charge la mise en forme du trafic à différents niveaux. Pour plus d'informations, veuillez consulter la page du manuel Traffic Control (TC).
  • Files d'attente de transmission superficielle (Tx) : dans certains scénarios, les files d'attente superficielles Tx aident à réduire la limitation PPS. Cela peut être réalisé de deux manières :
    Limites de la file d'attente d'octets (BQL) : BQL limite de manière dynamique la quantité d'octets en transit sur les files d'attente Tx. BQL est activé par défaut sur les versions du pilote ENA livrées avec le noyau Linux (celles se terminant par un « K »). Pour les versions du pilote ENA de GitHub (celles se terminant par un « g »), BQL est disponible depuis la version 2.6.1g et est désactivé par défaut. Vous pouvez activer BQL à l'aide du paramètre de module ENA enable_bql.
    Longueur de file d'attente Tx réduite : réduit 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.

Cet article vous a-t-il été utile ?


Avez-vous besoin d'aide pour une question technique ou de facturation ?