¿Por qué mi instancia de Amazon EC2 supera sus límites de red cuando mi uso promedio es bajo?

Descripción corta

Las métricas de rendimiento de red de Elastic Network Adaptor (ENA) bw_in_allowance_exceeded, bw_out_allowance_exceeded o pps_allowance_exceeded pueden aumentar incluso cuando el uso promedio es bajo. La causa más común de este problema son los picos breves en la demanda de recursos de red, denominados microrráfagas. Las microrráfagas normalmente solo duran segundos, milisegundos o incluso microsegundos. Las métricas de Amazon CloudWatch no son lo suficientemente detalladas como para reflejarlas. Por ejemplo, puedes usar las métricas de instancia de CloudWatch NetworkIn y NetworkOut para calcular el rendimiento promedio por segundo. Sin embargo, las tasas calculadas pueden ser inferiores al ancho de banda de instancia disponible para el tipo de instancia debido a las microrráfagas.

También se produce un aumento en las métricas bw_in_allowance_exceeded y bw_out_allowance_exceeded en las instancias más pequeñas que tienen un ancho de banda «máximo», como «hasta 10 gigabits por segundo (Gbps)». Las instancias más pequeñas utilizan créditos de E/S de red para superar su ancho de banda básico durante un tiempo limitado. Cuando se agotan los créditos, el tráfico se alinea con el ancho de banda de referencia y las métricas aumentan. Dado que la ráfaga de instancias se produce en función del mejor esfuerzo, las métricas pueden aumentar incluso cuando la instancia tenga créditos de E/S disponibles.

También se produce un aumento en la métrica pps_allowance_exceeded cuando los patrones de tráfico no óptimos provocan pérdidas de paquetes a velocidades de PPS más bajas. El enrutamiento asimétrico, los controladores desactualizados, los paquetes pequeños, los fragmentos y el seguimiento de conexiones afectan al rendimiento del PPS para una carga de trabajo.

Resolución

Cálculo promedio

CloudWatch toma muestras de las métricas de Amazon EC2 cada 60 segundos para capturar el total de bytes o paquetes que se transfieren en 1 minuto. Amazon EC2 agrega las muestras y las publica en CloudWatch en periodos de 5 minutos. Cada estadística del periodo muestra un valor diferente.

Cuando utilizas una supervisión detallada, CloudWatch publica las métricas NetworkIn y NetworkOut sin agregación en periodos de 1 minuto. Los valores de Suma, **Mínimo **, Promedio y Máximo son los mismos y el valor de SampleCount es 1. CloudWatch siempre agrega y publica las métricas NetworkPacketsIn y NetworkPacketsOut en periodos de 5 minutos.

Utiliza los métodos siguientes para calcular el rendimiento promedio en bytes por segundo (Bps) o PPS en un periodo:

• Para obtener un promedio simple en el periodo de tiempo especificado, divide la suma por el periodo o por la diferencia de marca de tiempo entre los valores (DIFF_TIME).
• Para obtener un promedio del minuto con la actividad más alta, divide Máximo por 60 segundos.

Para convertir Bps en Gbps, divide los resultados del cálculo entre 1 000 000 000 de bytes y, a continuación, multiplícalos por 8 bits.

Microrráfagas en las métricas de CloudWatch

El siguiente ejemplo muestra cómo aparece una microrráfaga en CloudWatch. La instancia tiene una asignación de ancho de banda de la red de 10 Gbps y utiliza una supervisión básica.

En una muestra de 60 segundos, una transferencia de datos saliente de aproximadamente 24 GB utiliza todo el ancho de banda disponible. La transferencia de datos aumenta el valor de bw_out_allowance_exceeded y se completa en aproximadamente 20 segundos con una velocidad promedio de 9,6 Gbps. Amazon EC2 no envía ningún otro dato y la instancia permanece inactiva durante las 4 muestras restantes de 240 segundos.

El rendimiento promedio en Gbps en un periodo de 5 minutos es mucho más bajo que el de la microrráfaga:

Fórmula: AVERAGE_Gbps = SUM(NetworkOut) / PERIOD(NetworkOut) / 1 000 000 000 bytes * 8 bits

SUM(NetworkOut) = (~24 GB * 1 muestra) + (~0 GB * 4 muestras) = ~24 GB

PERIOD(NetworkOut) = 300 segundos (5 minutos)

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

Incluso cuando se calcula el rendimiento promedio en función de la muestra más alta, la cantidad sigue sin reflejar el rendimiento durante la microrráfaga:

Fórmula: AVERAGE_Gbps = MAXIMUM(NetworkOut) / 60 segundos / 1 000 000 000 bytes / 8 bits

MAXIMUM(NetworkOut) = ~24 GB

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

Cuando hay datos de alta resolución disponibles, puedes obtener promedios más precisos. Al recopilar las métricas de uso de la red del sistema operativo (OS) en intervalos de 1 segundo, el rendimiento promedio alcanza brevemente 9,6 Gbps aproximadamente.

Supervisión de las microrráfagas

Puedes usar el agente de CloudWatch en Linux y Windows para publicar métricas de red a nivel de sistema operativo en CloudWatch en intervalos de hasta 1 segundo. El agente también puede publicar las métricas de rendimiento de la red ENA.

**Nota:**Las métricas de alta resolución tienen precios más altos.

También puedes utilizar las herramientas del sistema operativo para supervisar las estadísticas de la red en intervalos de hasta 1 segundo. Para las instancias de Windows, usa el Monitor de rendimiento. Para Linux, usa sar, nload, iftop, iptraf-ng o netqtop.

Para identificar con claridad las microrráfagas, realiza una captura de paquetes del sistema operativo y, a continuación, utiliza Wireshark para trazar un gráfico de E/S a intervalos de 1 milisegundo. Para obtener más información, consulta Download Wireshark (Descargar Wireshark) y 8.8. The "I/O Graphs" window (8.8. The "I/O Graphs" window) en el sitio web de Wireshark.

Este método tiene las siguientes limitaciones:

• Las asignaciones de red son aproximadamente proporcionales a un nivel de microsegundos. Por ejemplo, un tipo de instancia con un rendimiento de ancho de banda de 10 Gbps puede enviar y recibir aproximadamente 10 megabits (Mb) en 1 milisegundo.
• Las capturas de paquetes provocan una carga adicional en el sistema y pueden reducir el rendimiento general y las tasas de PPS.
• Es posible que las capturas de paquetes no incluyan todos los paquetes debido a las eliminaciones de paquetes provocadas por un búfer lleno.
• Las marcas de tiempo no reflejan con precisión cuándo una red envió paquetes o cuándo la ENA los recibió.
• Los gráficos de E/S pueden mostrar una menor actividad del tráfico entrante porque Amazon EC2 modela el tráfico que supera su cuota antes de que llegue a la instancia.

Colas y pérdidas de paquetes

Cuando la red pone en cola un paquete, la latencia resultante se mide en milisegundos. Las conexiones TCP pueden escalar su rendimiento y superar las cuotas de un tipo de instancia de EC2. Como resultado, se esperan algunas colas de paquetes incluso cuando se utiliza el ancho de banda de cuello de botella y de ida y vuelta (BBR) u otros algoritmos de control de congestión que utilizan la latencia como señal. Cuando una red pierde un paquete, el TCP retransmite automáticamente los segmentos perdidos. Tanto las colas como las pérdidas de paquetes pueden provocar una mayor latencia y un menor rendimiento. Sin embargo, no puedes ver las acciones de recuperación. Por lo general, los únicos errores que puedes ver son cuando la aplicación utiliza tiempos de espera bajos o cuando la red pierde suficientes paquetes como para forzar el cierre de la conexión.

Las métricas de rendimiento de la red ENA no diferencian entre paquetes en cola o paquetes perdidos. Para medir la latencia TCP a nivel de conexión en Linux, utiliza los comandos ss o tcprtt. Para medir las retransmisiones de TCP, utiliza los comandos ss o tcpretrans para las estadísticas del nivel de conexión y nstat para las estadísticas de todo el sistema. Para descargar las herramientas tcprtt y tcpretrans que forman parte de la colección de compiladores BPF (BCC), consulta bcc en el sitio web de GitHub. También puedes usar capturas de paquetes para medir la latencia y las retransmisiones.

Nota: Los paquetes que la red descartó debido a que se superaron las cuotas de instancias no aparecen en los contadores de descarte de ip o ifconfig.

Prevención de microrráfagas

En primer lugar, compara las métricas de rendimiento de la red de ENA con los indicadores clave de rendimiento (KPI) de la aplicación para determinar el efecto de las colas o pérdidas de paquetes.

Si los KPI están por debajo del umbral requerido o si recibes errores en el registro de la aplicación, toma las siguientes medidas para reducir las colas y las pérdidas de paquetes:

• Escala verticalmente: Aumenta el tamaño de la instancia a una instancia que tenga una asignación de red más alta. Los tipos de instancia con una «n», como C7gn, tienen asignaciones de red más altas.
• Escala horizontalmente: Distribuye el tráfico en varias instancias para reducir el tráfico y la contención en las instancias individuales.

Para las operaciones basadas en Linux, también puedes implementar las siguientes estrategias para evitar microrráfagas. Se recomienda probar las estrategias en un entorno de prueba para comprobar que reducen la configuración del tráfico sin efectos negativos en la carga de trabajo.

Nota: Las siguientes estrategias son solo para el tráfico saliente.

SO_MAX_PACING_RATE

Utiliza la opción de socket SO_MAX_PACING_RATE para especificar una velocidad de ritmo máxima en Bps para una conexión. A continuación, el kernel de Linux introduce retrasos entre los paquetes del socket para que el rendimiento no supere la cuota especificada.

Para usar este método, debes implementar los siguientes cambios:

• Cambios en el código de la aplicación.
• Soporte desde el kernel. Para obtener más información, consulta net: introduce SO_MAX_PACING_RATE en el sitio web de GitHub.
• Disciplina de colas justas (FQ) o soporte del kernel con el ritmo en la capa TCP (solo para TCP).

Para obtener más información, consulta getsockopt(2): página del manual de Linux y c-fq(8) - Linux manual page (tc-fq(8): página del manual de Linux) en el sitio web de man7. Consulta también tcp: implementación interna para el ritmo en el sitio web de GitHub.

qdiscs

Linux usa la configuración predeterminada de una disciplina de cola (qdisc) pfifo_fast para cada cola de ENA para programar los paquetes. Utiliza el qdisc fq para reducir las ráfagas de tráfico causadas por un flujo individual y regular su rendimiento. O bien, utiliza fq_codel y cake para ofrecer capacidades de gestión activa de colas (AQM) que reducen la congestión de la red y mejoran la latencia. Para obtener más información, consulta tc(8) - Linux manual page (tc(8): página del manual de Linux) en el sitio web de man7.

Para TCP, activa la notificación de congestión explícita (ECN) en los clientes y servidores. A continuación, combina ECN con un qdisc que pueda realizar el marcado de la congestión experimentada (CE) de ECN. Las marcas de CE hacen que el sistema operativo reduzca el rendimiento de una conexión para reducir la latencia y las pérdidas de paquetes provocadas por la superación de la cuota de instancias. Para usar esta solución, debes configurar el qdisc con un umbral de CE bajo en función del promedio de tiempo de ida y vuelta (RTT) de tus conexiones. Se recomienda usar esta solución solo cuando el RTT promedio entre conexiones no varíe mucho. Por ejemplo, la instancia administra el tráfico solo en una zona de disponibilidad.

Debido a problemas de rendimiento, no se recomienda configurar el modelado del ancho de banda agregado a nivel de instancia.

Colas de transmisión (Tx) poco profundas

Utiliza colas de Tx poco profundas para reducir el modelado de PPS. Los límites de cola de bytes (BQL) limitan dinámicamente la cantidad de bytes en vuelo en las colas Tx. Para activar BQL, agrega ena.enable_bql=1 a la línea de comandos del kernel en GRUB.

Nota: Debes tener la versión 2.6.1g o superior del controlador de ENA para usar esta solución. BQL ya está activado en los controladores de ENA con versiones del kernel de Linux que terminan en K.

Para obtener más información, consulta bql: Byte Queue Limits (bql: límites de cola de bytes) en el sitio web de LWN.net.

Cuando utilices ENA Express, debes desactivar BQL para maximizar el ancho de banda.

También puedes usar ethtool para reducir la longitud de la cola de Tx de su valor predeterminado de 1024 paquetes. Para obtener más información, consulta ethtool(8) - Linux manual page (ethtool(8): página del manual de Linux) en el sitio web de man7.

Información relacionada

Ancho de banda de la red de instancias de Amazon EC2