Home Artículos técnicos Supervisión del rendimiento del zócalo a gran escala con xTCP
Applications

Supervisión del rendimiento del zócalo a gran escala con xTCP

About The Author

Outline

Antecedentes

Las CDN y los proveedores en la nube ofrecen grandes volúmenes de tráfico en Internet y emplean amplias herramientas de monitoreo para garantizar el rendimiento y la fiabilidad. Estos incluyen herramientas que cubren varias capas de entrega de tráfico como Red, Servidor, Aplicación, etc. TCP/IP representa la mayoría de este tráfico (mientras que el QUIC basado en UDP está en aumento a nivel mundial, sigue siendo una pequeña fracción del tráfico total en comparación con TCP).

Los sockets son abstracciones del sistema operativo que vinculan la conexión cliente y servidor sobre el cual se transmiten los datos. Los problemas de red, por lo tanto, se reflejan directamente en los datos almacenados con cada socket. Por ejemplo, la congestión en la red puede provocar tiempos de respuesta lentos y un aumento de los tiempos de viaje redondo (RTT). También es posible que el ancho de banda de la red esté disponible, pero la aplicación está abrumada con demasiadas solicitudes y no puede llenar el búfer con suficientes datos para utilizar completamente el ancho de banda disponible, lo que resulta en una anomalía limitada por la aplicación. A menudo, los servidores manejan múltiples sockets al mismo tiempo, lo que puede conducir a la contención de recursos que pone estrés en los recursos del sistema como la CPU y la memoria.

Por lo tanto, el monitoreo del rendimiento de los sockets TCP a escala puede proporcionar una comprensión crítica de los comportamientos del tráfico, como tiempos de respuesta lentos o conexiones caídas, e identificar casos en los que se pueden realizar mejoras.

Herramientas existentes

La utilidad “ss” en Linux es una herramienta común utilizada para obtener estadísticas de socket. Similar a “netstat”, ss proporciona un mecanismo más rápido y flexible para obtener información al permitir filtros en los estados de socket, protocolos y direcciones. Comenzamos nuestro viaje de monitoreo de socket con ss también. Si bien es una herramienta poderosa para obtener rápidamente una lista de sockets y métricas relevantes, el principal desafío de ss es que puede consumir recursos significativos, especialmente cuando se utiliza en sistemas con un gran número de sockets. Esto puede afectar el rendimiento del sistema y ralentizar otros procesos. Además, la salida ss no es ideal para analizar, debido a la inconsistencia de la clave: El uso de valor, y complica significativamente la capacidad de transmitir datos recopilados de miles de servidores.

Nuestra primera versión de la colección de socket usando ss fue un script bash que se ejecuta en servidores de caché seleccionados, que exportamos la salida de “ss –tcp –info” a un archivo. Este archivo sería entonces rsync-ed a un host bastion desde el cual un script python lo leería, analizaría e insertaría en ElasticSearch. Esto hizo el trabajo, pero no estaba cerca de la escala que necesitábamos. La siguiente iteración de este trabajo fue tener un script de python vivo en los servidores de caché que se llamaría desde una interfaz HTTP y devolvería las estadísticas agregadas para ser insertadas en el clúster ElasticSearch. Este método escaló el cuello de botella de análisis desde una ubicación central de back-office hasta el servidor de caché individual, pero resultó en una gran utilización de memoria en servidores con un número significativamente alto de sockets. En última instancia, reconocimos la necesidad de un reemplazo ligero para la porción ss del sistema.

Nuestros requisitos clave para esta nueva herramienta fueron que debería ser ligera y escalar a la gran cantidad de sockets que tienen nuestros servidores CDN y ser capaz de transmitir datos de vuelta utilizando un mecanismo eficiente como búferes de protocolo. La herramienta TCP-INFO de MeasurementLab es una gran utilidad implementada en Golang. Sin embargo, está diseñado para rastrear los mismos sockets a lo largo del tiempo. Dado el gran volumen de nuestras conexiones de zócalo, hicimos una elección de diseño para no rastrear zócalos individuales. En su lugar, haga que cada bucle de votación sea independiente, proporcionando una instantánea del estado actual de los sockets abiertos. El objetivo principal aquí es rastrear el rendimiento general del sistema y no los sockets individuales.

XTCP

Para resolver estos desafíos, presentamos xTCP de código abierto (extracto, exportación, Xray TCP). XTCP es una utilidad Golang para capturar y transmitir datos de socket a escala. XTCP utiliza Netlink para capturar información de socket, empaqueta los datos en protobufs, y los envía a través de un puerto UDP (que eventualmente se enviará a Kafka, etc) o escribir a NSQ.

NetLink proporciona una interfaz genérica para la comunicación entre el espacio de usuario y el espacio del kernel. Las herramientas de monitoreo de socket ss, tcp-INFO utilizan NETLINK_INET_DIAG, parte de la familia de protocolos Netlink, para obtener información de socket del kernel en el espacio de usuario (nota de la página man: NETLINK_INET_DIAG se introdujo en Linux 2.6.14 y solo admitía sockets AF_INET y AF_INET6. En Linux 3,3, se cambió el nombre a NETLINK_SOCK_DIAG y se extendió para admitir sockets AF_UNIX).

XTCP extrae los datos del kernel TCP INET_DIAG a altas tasas y exporta esos datos a través de protobufs. En una máquina con aproximadamente ~120k sockets, los mensajes de Netlink son aproximadamente ~5-6MB, sin embargo, la salida ASCII de ss es aproximadamente ~60MB. Además, ss lee desde el kernel en trozos de ~3KB por defecto. XTCP lee fragmentos de 32KB y por lo tanto minimiza las llamadas al sistema. XTCP lee los datos del socket de Netlink simultáneamente utilizando varios trabajadores para drenar la cola lo más rápido posible y analiza simultáneamente los mensajes de Netlink para la transmisión. Todas estas optimizaciones hacen que la huella de xTCP sea más pequeña para ejecutarse en servidores de caché de producción.

Uso en Edgio

Utilizamos datos xTCP en gran medida para analizar el rendimiento del cliente. Comúnmente rastreamos RTT y retransmitimos agregados por Punto de Presencia (POP) y ASN.

A diferencia de Aging Rate, TTL nos permite cambiar la capacidad de caché de un elemento en particular. Para la duración establecida usando la función TTL, un elemento no envejece mientras está en el disco, por lo que es menos probable (incluso muy poco probable) que sea desalojado. Después de que el TTL expira, el elemento puede comenzar a envejecer de la manera tradicional de LRU o con un envejecimiento rápido o lento (dependiendo de cómo lo configure el operador). En la figura siguiente, TTL con envejecimiento lento mantuvo un elemento en el disco hasta el punto en que no superó el umbral de desalojo de caché. En el extremo opuesto, TTL se aseguró de que una transmisión de video en vivo se almacenara en caché durante al menos la duración del evento, pero después de eso se eliminó rápidamente del disco utilizando el envejecimiento rápido.

Un ejemplo de panel xTCP que muestra RTT, retransmisiones y número de sockets muestreados para pops AGA y CHB para un proveedor grande de EE.UU.

En una publicación anterior del blog, presentamos nuestra canalización para la sintonización dinámica del control de congestión para habilitar automáticamente la BBR para los clientes que tienen un rendimiento inferior y donde sabemos que el mecanismo de BBR sería más útil. Los datos xTCP son la fuente principal para el análisis.

Constantemente estamos encontrando nuevas formas de usar los datos xTCP para responder preguntas complejas como el impacto de la congestión y el aprendizaje automático para predecir el rendimiento y detectar anomalías. Planeamos informar sobre dicho análisis de datos de socket en una futura publicación de blog.

Hoy xTCP se une a vFlow (sflow, netflow, ipfix collector) en nuestro conjunto de herramientas de monitoreo de red de código abierto. Esperamos que esto sirva a la comunidad de monitoreo del rendimiento de la infraestructura para la recopilación de datos de socket y esperamos con interés la participación activa en llevar esta herramienta más allá.

Reconocimiento

El éxito y la amplia usabilidad de xTCP son el resultado de las contribuciones de individuos y equipos de todo Edgio. Nos gustaría agradecer especialmente a David Seddon, que es el desarrollador inicial de xTCP. Un agradecimiento especial a todos los revisores de código internos y colaboradores por probar, ingerir, paneles y comentarios sobre xTCP.