¿Por qué la instancia de Amazon EC2 supera los límites de la red si la utilización media es baja?

Descripción breve

Puede consultar las métricas de rendimiento de la red en tiempo real en las instancias que admiten una red mejorada a través del adaptador de red elástico (ENA). Estas métricas proporcionan un número acumulado de paquetes en cola o descartados en cada interfaz de red desde el último reinicio del dispositivo. Las siguientes son algunas de las métricas del adaptador de red elástico:

• bw_in_allowance_exceeded: el número de paquetes puestos en cola o descartados porque el ancho de banda agregado de entrada superó el máximo para la instancia.
• bw_out_allowance_exceeded: el número de paquetes puestos en cola o descartados porque el ancho de banda agregado de salida superó el máximo para la instancia.
• pps_allowance_exceeded: el número de paquetes puestos en cola o descartados porque los paquetes por segundo (PPS) bidireccionales superaron el máximo para la instancia.

Las especificaciones de rendimiento de la red varían según el tipo de instancia. Para ver las especificaciones, consulte Current generation instances (Instancias de la generación actual). En algunos casos, es posible que haya paquetes en cola o descartados a pesar de que la media de ancho de banda o PPS que aparece en Amazon CloudWatch sea baja. Por ejemplo, es posible que las métricas NetworkIn, NetworkOut, NetworkPacketsIn o NetworkPacketsOut en CloudWatch indiquen cantidades que no sugieren que se haya alcanzado un límite.

Resolución

Las microrráfagas son la causa más común de los síntomas anteriores. Las microrráfagas son breves picos de demanda seguidos de periodos de poca o ninguna actividad. Por lo general, estas ráfagas solo duran segundos, milisegundos o incluso microsegundos. En el caso de las microrráfagas, las métricas de CloudWatch enumeradas en la sección anterior no son lo suficientemente detalladas como para reflejarlas.

Cómo se calculan las medias

Las métricas de EC2 en CloudWatch enumeradas en la sección anterior se muestrean cada minuto. Estas métricas capturan el total de bytes o paquetes transferidos en ese periodo. A continuación, estas muestras se agregan y se publican en CloudWatch en periodos de cinco minutos. Cada estadística del periodo devuelve un valor de muestra diferente:

• Sum (Suma) es la suma de todos los valores de muestra.
• SampleCount (Recuento de muestras) es el número de muestras agregadas (en este caso, 5).
• Minimum (Mínimo) es el valor de muestra con el menor recuento de bytes/paquetes.
• Average (Media) es el valor medio de la muestra, que se calcula al dividir Sum entre SampleCount.
• Maximum (Máximo) es el valor de muestra con el recuento más alto de bytes/paquetes.

El rendimiento medio o PPS se puede calcular de dos maneras:

• Divida el valor de Sum entre el valor de Period (por ejemplo, 300 segundos), para obtener una media simple de 5 minutos.
• Divida el valor de Maximum entre 60 segundos, para obtener una media en el minuto de mayor actividad.

Cómo se reflejan las microrráfagas en las métricas de CloudWatch

A continuación se muestra un ejemplo de microrráfaga y el modo en que se refleja en CloudWatch:

• La instancia tiene un rendimiento de ancho de banda de la red de 10 Gbps (1,25 GB/s).
• En una muestra determinada (60 segundos), una transferencia saliente de datos de 20 GB consume todo el ancho de banda disponible, lo que hace que bw_out_allowance_exceeded se incremente. La transferencia se completa en unos 20 segundos y no se envían más datos después.
• La instancia permanece inactiva durante las cuatro muestras restantes (240 segundos).

En este ejemplo, el rendimiento medio en un periodo de cinco minutos es mucho más bajo que el de la microrráfaga:

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

Aunque se calcule el rendimiento basado en la muestra más alta, la media aún no refleja la cantidad de rendimiento:

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

Supervisión de microrráfagas

Para medir el rendimiento y los PPS a un nivel más detallado, utilice las herramientas del sistema operativo (SO) para supervisar las estadísticas de la red. Supervise las estadísticas de la red con mayor frecuencia durante los periodos de conformación o de alta actividad.

Los siguientes son ejemplos de herramientas de sistema operativo:

Linux

• sar
• nload
• iftop
• iptraf-ng

Windows

• Supervisor de rendimiento

El agente de CloudWatch se puede utilizar tanto en Linux como en Windows para publicar estas métricas de red a nivel de sistema operativo en CloudWatch como métricas personalizadas. Estas métricas se pueden publicar a intervalos tan bajos como de un segundo. Tenga en cuenta que las métricas de alta resolución (aquellas cuyo periodo es inferior a 60 segundos) conllevan cargos más elevados. Para obtener más información sobre los precios de CloudWatch, consulte precios de Amazon CloudWatch.

Es una práctica recomendada supervisar las métricas de rendimiento de la red proporcionadas por el adaptador de red elástico. La versión del controlador debe ser posterior o igual a la 2.2.10 (Linux) y a la 2.2.2 (Windows) para poder ver las métricas. Para obtener más información, consulte las páginas pertinentes correspondientes a Linux y Windows.

El agente de CloudWatch también puede publicar métricas del adaptador de red elástico. Para obtener instrucciones sobre cómo publicar las métricas del adaptador de red elástico para Linux, consulte Recopilar métricas de rendimiento de la red. En el caso de Windows, las métricas del adaptador de red elástico se encuentran disponibles en el Monitor de rendimiento, y el agente de CloudWatch se puede configurar para publicar cualquier métrica que se encuentre disponible ahí.

Prevención de microrráfagas

Para evitar las microrráfagas, el ritmo del tráfico en los emisores debe ser tal que no supere un rendimiento máximo o una tasa de paquetes. Por ello, es difícil evitar las microrráfagas. Para regular el tráfico en los emisores normalmente se necesitan cambios a nivel de la aplicación. En función de cómo se implemente este cambio, es posible que la compatibilidad del sistema operativo con la regulación del ritmo del tráfico deba estar disponible y activada en el emisor. Esto no siempre es posible, ni práctico. La microrráfaga también puede ocurrir debido a que hay demasiadas conexiones que envían paquetes en un período corto. Cuando esto sucede, no sirve de ayuda regular el tráfico de los emisores individuales.

Debido a estas razones, una práctica recomendada consiste en supervisar las métricas del adaptador de red elástico. Si los límites se alcanzan con frecuencia, o si hay pruebas de que la conformación del tráfico afecta a las aplicaciones, haga lo siguiente:

• Escale verticalmente: cambie a un tamaño de instancia más grande. Las instancias más grandes por lo general tienen asignaciones más altas. Las instancias optimizadas para la red (aquellas con una “n”, como en C5n), tienen mayores asignaciones que sus respectivas homólogas no optimizadas para la red.
• Escale horizontalmente: reparta el tráfico entre varias instancias para reducir el tráfico y la contención en las instancias individuales.

En Linux, además de las opciones anteriores, existen posibles opciones de mitigación para los usuarios avanzados. Puede implementar estas opciones solas o en combinación. Es una práctica recomendada comparar las mitigaciones en un entorno de pruebas para verificar que estas reduzcan o eliminen la conformación del tráfico sin afectar negativamente a la carga de trabajo.

• SO_MAX_PACING_RATE: esta opción de socket puede ser transmitida por una aplicación a la llamada al sistema setsockopt para especificar una tasa de ritmo máxima (bytes por segundo). A continuación, el kernel de Linux controla el ritmo del tráfico de ese socket de manera que no exceda el límite. Esta opción requiere lo siguiente:

• Cambios a nivel de código de la aplicación.
• Compatibilidad del kernel.
• El uso de la disciplina de colas Espera equitativa (FQ) o la compatibilidad del kernel con el control del ritmo en la capa TCP (solo se aplica a TCP).

• Disciplinas de cola (qdiscs): las qdiscs son responsables de la programación de paquetes y la conformación opcional. Algunas qdiscs, como fq, ayudan a suavizar las ráfagas de tráfico de los flujos individuales. Para obtener más información, consulte la página del manual de Control de tráfico (TC).
• Colas de transmisión poco profundas (Tx): en algunos escenarios, las colas de transmisión poco profundas ayudan a reducir la conformación de los paquetes por segundo. Esto se puede lograr de dos maneras:

• Límites de cola de bytes (BQL): BQL limita dinámicamente la cantidad de bytes en tránsito en las colas de transmisión. BQL se encuentra activado de forma predeterminada en las versiones de los controladores del adaptador de red elástico que se envían con el kernel de Linux (las que terminan con una “K”). En el caso de las versiones del controlador del adaptador de red elástico de GitHub (aquellas que terminan en “g”), BQL se encuentra disponible a partir de la v2.6.1g, y está desactivada de forma predeterminada. Puede activar los BQL mediante el parámetro del módulo del adaptador de red elástico enable_bql.
• Longitud de la cola de transmisión reducida: reduzca la longitud de la cola de transmisión de su valor predeterminado de 1024 paquetes a una cantidad inferior (mínimo 256). Puede cambiar esta longitud mediante ethtool.

---

Información relacionada

• Ancho de banda de la red de la instancia de Amazon EC2
• Supervise el rendimiento de la red de la instancia de EC2 (Linux)
• Supervise el rendimiento de la red de la instancia de EC2 (Windows)