Home Artículos técnicos Optimización del servidor a escala: Eliminación de caídas de paquetes y mejora de la capacidad
Applications

Optimización del servidor a escala: Eliminación de caídas de paquetes y mejora de la capacidad

About The Author

Outline

Mejorar el rendimiento de nuestra tecnología para el beneficio de nuestros clientes y sus audiencias es un curso de acción continuo en Verizon Media, ahora Edgio. Por ejemplo, en los últimos dos años, nuestros ingenieros de rendimiento y kernel han eliminado prácticamente todas las caídas de paquetes (más del 98% eliminadas), mejorado las comprobaciones de estado del rendimiento en nuestros servidores perimetrales en un 50% y aumentado la capacidad del servidor hasta en un 40%.

También hemos combinado lo anterior con la automatización de la red y la expansión orgánica de la red, actualmente más de 250 Tbps, para mejorar la experiencia del usuario. Ajustar cuidadosamente nuestro rendimiento ha jugado un papel importante en nuestra capacidad de soportar aumentos de red rápidamente cambiantes y a veces impredecibles, ya que entregamos actualizaciones de software para millones de consolas de juegos, transmisiones de video en vivo para eventos deportivos importantes y cuando los balanceadores de carga multi-CDN mueven la carga a nuestra red.

Mantener la calidad a escala implica optimizar el rendimiento en todas las partes de la pila de tecnología de Edgio Media Platform: Desde sus capas inferiores, en la CPU y NIC, hasta el sistema operativo y las aplicaciones. En última instancia, nuestro objetivo es siempre el mismo: Un gran rendimiento. Para lograrlo, realizamos análisis basados en datos, basándonos en cambios de rendimiento medibles para validar nuestra toma de decisiones.

Optimizaciones de caché de CPU

Ejecutamos 20.000 servidores en todo el mundo, en gran parte chipsets Broadwell y Haswell, típicamente con 32 a 40 núcleos. Hemos añadido 12.000 servidores solo en los últimos tres años. Sin embargo, la mayoría de los servidores no están optimizados para escalar nuestras cargas de trabajo de forma inmediata. Simplemente agregar más servidores no hace que el funcionamiento sea más eficiente y puede crear desafíos adicionales. El escalado efectivo requiere una optimización cuidadosa de los componentes existentes. Ser capaz de optimizar un servidor para que sea capaz de procesar dos o tres veces (o más) solicitudes que con la configuración predeterminada puede hacer una gran diferencia en el rendimiento general de la red.

El cambio de temprano snoop a casa snoop

Las CPU modernas emplean un protocolo snoop para garantizar que la caché de la CPU local sea consistente con la memoria. Esto permite que los cachés escuchen las modificaciones de las variables en cualquier CPU y actualicen sus versiones de estas variables en consecuencia. No es sorprendente que la técnica particular utilizada pueda afectar significativamente el rendimiento de la memoria.

Por defecto, nuestros proveedores de hardware utilizan un protocolo llamado Early Snoop. Tiene una latencia más baja para resolver la coherencia de la caché, ya que todos los núcleos pueden hacer solicitudes de coherencia de la caché simultáneamente y enviar transmisiones. Hemos encontrado que nuestros sistemas generan grandes cantidades de disco simultáneo y actividad NIC durante los escenarios de carga máxima. Estas actividades dan lugar a transmisiones de alto espionaje, lo que conduce a cuellos de botella en la comunicación. Esto hace que el dispositivo IO se ralentice y, eventualmente, puede provocar que el procesamiento se detenga por completo.

Al cambiar al modo Home Snoop, un enfoque que combina las solicitudes snoop, hemos visto una reducción significativa en el tráfico de transmisión. La interconexión de ruta rápida (QPI) del procesador ya no se muere de hambre durante los períodos de operaciones simultáneas de disco pesado y de IO de red; además, las caídas de paquetes que vimos con Early Snoop se redujeron significativamente en número.

Cambiar el protocolo snoop depende simplemente de cambiar una configuración del BIOS. Sin embargo, reiniciar servidores 20.000 sin interrumpir a los clientes requiere automatización. Podemos hacer que este tipo de cambio de implementación a gran escala funcione en la producción, en parte gracias a nuestra plataforma de automatización de TI basada en StackStorm, crayfish.

Un evento de failover inesperado

Durante la prueba del cambio a Home Snoop, se produjo una conmutación por error: Uno de nuestros clientes de medios más grandes, que tiene una implementación de múltiples CDN, experimentó un problema con otro proveedor y trasladó una parte significativa de su tráfico a nuestra CDN. Esto proporcionó una oportunidad para probar las mejoras a gran escala de Home Snoop, que fueron extremadamente impactantes.

La figura anterior muestra el efecto del cambio. El grupo que todavía usaba Early Snoop vio un aumento en las caídas en 13.75x (55K caídas de paquetes por servidor por día), mientras que el grupo que había cambiado a Home Snoop vio un aumento de solo 4.23x (27K caídas de paquetes por máquina por día). Home Snoop demostró inmediatamente su valor durante el evento de failover.

Optimización de la interfaz de red y sintonización de controladores

Otro conjunto de ajustes de rendimiento importante involucró la interfaz de red y el controlador. Aquí, nos centramos en reducir las caídas de paquetes que generalmente ocurren con el tráfico de ráfaga. Durante los grandes eventos, el tráfico entrante era tan pesado que NIC no podía mantenerse al día, y vimos caídas de paquetes antes de lo esperado. A medida que profundizamos en por qué, encontramos varios parámetros en la propia NIC que necesitaban ajustarse, incluido el número de colas, el tamaño de la cola y la programación de interrupciones. Para optimizar estas especificaciones para nuestra carga de trabajo y configuración de hardware en particular, nos concentramos en ajustar el Escalado lateral de recepción (RSS) haciendo que las colas entrantes sean más largas, reduciendo su número total y equilibrando las interrupciones entre los nodos NUMA.

El gráfico anterior muestra una prueba que ejecutamos en América del Norte, en la que cada pop se divide en un grupo de control (es decir, no afinado) y un grupo de prueba (es decir, afinado). Aquí, presentamos el número de gotas sumadas diariamente durante una semana. Después de las afinaciones, nuestro grupo de pruebas vio aproximadamente un 95% menos de caídas de paquetes que el grupo de control, lo que permitió procesar significativamente más solicitudes. Esto también significa que se requiere menos acción para administrar manualmente la salud de la red durante las sobretensiones, lo que deja a nuestros ingenieros libres para centrarse en otras áreas.

Ajustes de programación de CPU

Mientras que el ajuste de NIC y de nivel de controlador se concentró en mejorar la capacidad total que podemos ofrecer, los ajustes de programación de CPU se centraron en mejorar la consistencia con la que podemos entregar contenido.

Sin estas afinaciones, los mensajes entrantes y salientes tienen que competir por los recursos. Cuando comenzamos a investigar la causa raíz, encontramos que la contención sobre los recursos era el resultado de cómo el kernel estaba programando el manejo de estos mensajes. Esto significaba que la carga no se migró durante el tráfico pico hasta después de que las CPU en cuestión se saturaron. Para solucionar esto, establecemos la afinidad de la CPU de nuestros procesos de servidor web para excluir las CPU dedicadas al procesamiento del tráfico de red entrante.

Los gráficos anteriores muestran el impacto de habilitar las afinaciones de programación de la CPU a nivel mundial en toda la CDN del 21 al 22 de marzo. Evaluamos el impacto basado en el percentil 95 y los valores medios de una métrica de verificación de estado del rendimiento, una métrica compuesta que demuestra el tiempo de respuesta relativo de un servidor. Como era de esperar, los valles de bajo tráfico no se redujeron significativamente; sin embargo, los picos revelan una contención significativamente reducida entre el tráfico entrante y saliente. Esto se traduce en una mejora importante tanto en los valores atípicos como en las medianas, particularmente durante las cargas pico. Ahora podemos manejar mejor las subidas de tráfico y resolver los problemas relacionados con un comportamiento atípico alto, como los rebuffers en los flujos de video o la capacidad de respuesta general de un servidor para todos los usuarios.

Actualizaciones de rendimiento del kernel

Optimizar las capas superiores de nuestra pila de tecnología es igual de importante que afinar los elementos de la capa inferior. En el proceso de actualización reciente de nuestro sistema operativo, también actualizamos nuestros kernels Linux para aprovechar el trabajo de ingeniería ascendente de la comunidad de kernel Linux. El nuevo kernel tuvo alrededor de cuatro años de desarrollo más allá de la versión anterior implementada, incluyendo mejoras en el sistema de administración de memoria, que reduce las asignaciones de páginas de bloqueo y mejora la distribución de carga y el rendimiento al usar la API de epoll y el compartimiento de sockets.

En el gráfico anterior, puede ver el efecto del proceso de actualización desde finales de noviembre hasta principios de enero como una disminución en las comprobaciones de estado del rendimiento del percentil 99. Las mejoras subyacentes del kernel llevaron a una distribución de carga más uniforme en todos nuestros procesadores de solicitudes de servidor web. Esto resultó en una caída sustancial en estos valores atípicos, haciendo que las solicitudes para todos nuestros clientes sean más confiables.

Las afinaciones de rendimiento tienen un efecto significativo

En los últimos dos años, los ajustes de sistema de gran alcance que el rendimiento y la ingeniería del kernel han implementado han eliminado prácticamente todas las caídas de paquetes (más del 98% eliminadas) y han reducido a la mitad nuestras comprobaciones de rendimiento en nuestros servidores perimetrales. La capacidad de nuestro servidor ha aumentado entre un 10 y un 40% (la cantidad exacta varía según el perfil del cliente y el evento), lo que nos permite ofrecer más tráfico más rápido. El comportamiento atípico ha mejorado significativamente, lo que hace que la experiencia sea más consistente, y hemos visto una buena mejora en las medianas, particularmente durante la carga máxima. En resumen, el ajuste del rendimiento de toda la pila de tecnología nos ha permitido manejar mejor cualquier aumento de tráfico inesperado (ya sea de una actualización de consola de juegos muy esperada o un evento popular de transmisión de video en vivo) y ofrecer un rendimiento más consistente para todos nuestros usuarios.