Contexto
Centros, las ralentizaciones de redes pueden aparecer de la nada. Una repentina explosión de tráfico de sistemas distribuidos, microservicios o trabajos de capacitación de IA puede abrumar los buffers de cambio en segundos. El problema no es solo saber cuándo algo sale mal. Es capaz de verlo venir antes de que suceda.
Los sistemas de telemetría se utilizan ampliamente para monitorear la salud de la red, pero la mayoría funciona en un modo reactivo. Marcan la congestión solo después de que el rendimiento se haya degradado. Una vez que un enlace está saturado o una cola está llena, ya ya ha pasado el punto de diagnóstico temprano, y el rastreo de la causa original se vuelve significativamente más difícil.
La telemetría de la red en banda, o int, intenta resolver esa brecha etiquetando paquetes en vivo con metadatos a medida que viajan a través de la red. Le brinda una vista en tiempo real de cómo fluye el tráfico, dónde se están acumulando colas, dónde se está arrastrando la latencia y cómo cada interruptor está manejando el reenvío. Es una herramienta poderosa cuando se usa cuidadosamente. Pero viene con un costo. Habilitar int en cada paquete puede introducir una sobrecarga grave y llevar una avalancha de datos de telemetría al plano de control, gran parte de los cuales quizás ni siquiera necesite.
¿Qué pasaría si pudiéramos ser más selectivos? En lugar de rastrear todo, pronosticamos dónde es probable que se formen problemas y habilitan INT solo para esas regiones y solo por un corto tiempo. De esta manera, obtenemos una visibilidad detallada cuando más importa sin pagar el costo total de la monitorización siempre en el monitoreo.
El problema con la telemetría siempre encendida
INT le ofrece una visión poderosa y detallada de lo que está sucediendo dentro de la red. Puede rastrear la longitud de la cola, la latencia de lúpulo por salto y las marcas de tiempo directamente desde la ruta del paquete. Pero hay un costo: estos datos de telemetría agregan peso a cada paquete, y si lo aplica a todo el tráfico, puede comer un ancho de banda significativo y una capacidad de procesamiento.
Para evitar eso, muchos sistemas toman atajos:
Muestreo: Etiquete solo una fracción (por ejemplo, 1%) de paquetes con datos de telemetría.
Telemetría activada por eventos: Encienda int solo cuando algo malo ya está sucediendo, como una cola que cruza un umbral.
Estas técnicas ayudan a controlar la cabeza, pero se pierden los primeros momentos críticos de un aumento de tráfico, la parte que más desea comprender si está tratando de prevenir la desaceleración.
Introducir un enfoque predictivo
En lugar de reaccionar a los síntomas, diseñamos un sistema que puede pronosticar la congestión antes de que ocurra y activar la telemetría detallada de manera proactiva. La idea es simple: si podemos anticipar cuándo y dónde va a aumentar el tráfico, podemos habilitar selectivamente INT solo para ese punto de acceso y solo para la ventana de tiempo correcta.
Esto se mantiene en lo alto, pero le da una visibilidad profunda cuando realmente importa.
Diseño del sistema
Se nos ocurrió un enfoque simple que hace que el monitoreo de la red sea más inteligente. Puede predecir cuándo y dónde realmente se necesita monitoreo. La idea no es probar cada paquete y no esperar a que ocurra la congestión. En cambio, queremos un sistema que pueda captar signos de problemas temprano y habilitar selectivamente el monitoreo de alta fidelidad solo cuando sea necesario.
Entonces, ¿cómo hicimos esto? Creamos los siguientes cuatro componentes críticos, cada uno para una tarea distinta.
Recolector de datos
Comenzamos recopilando datos de red para monitorear cuántos datos se mueven a través de diferentes puertos de red en cualquier momento dado. Utilizamos SFLOW para la recopilación de datos porque ayuda a recopilar métricas importantes sin afectar el rendimiento de la red. Estas métricas se capturan a intervalos regulares para obtener una vista en tiempo real de la red en cualquier momento.
Motor de pronóstico
El motor de pronóstico es el componente más importante de nuestro sistema. Se construye utilizando un modelo de memoria a largo plazo (LSTM) a largo plazo. Fuimos con LSTM porque aprende cómo los patrones evolucionan con el tiempo, lo que lo hace adecuado para el tráfico de red. No estamos buscando perfección aquí. Lo importante es detectar picos de tráfico inusuales que generalmente aparecen antes de que comience la congestión.
Controlador de telemetría
El controlador escucha esos pronósticos y toma decisiones. Cuando un Spike predicho cruza el umbral de alerta, el sistema respondería. Envía un comando a los interruptores para cambiar a un modo de monitoreo detallado, pero solo para los flujos o puertos que importan. También sabe cuándo retroceder, apagando la telemetría adicional una vez que las condiciones vuelven a la normalidad.
Plano de datos programable
La pieza final es el interruptor en sí. En nuestra configuración, utilizamos interruptores BMV2 programables P4 que nos permiten ajustar el comportamiento de los paquetes en la marcha. La mayoría de las veces, el cambio simplemente reenvía el tráfico sin hacer cambios. Pero cuando el controlador enciende INT, el interruptor comienza a incorporar metadatos de telemetría en paquetes que coinciden con reglas específicas. El controlador presiona estas reglas y nos dirigimos solo el tráfico que nos importa.
Esto evita la compensación entre el monitoreo constante y el muestreo ciego. En cambio, obtenemos una visibilidad detallada exactamente cuando es necesario, sin inundar el sistema con datos innecesarios el resto del tiempo.
Configuración experimental
Construimos una simulación completa de este sistema usando:
- Mininet para emular una red de colocación de hojas
- BMV2 (conmutador de software P4) Para el comportamiento del plano de datos programable
- sflow-rt para estadísticas de tráfico en tiempo real
- TensorFlow + Keras Para el modelo de pronóstico de LSTM
- Python + GRPC + P4Runtime Para la lógica del controlador
El LSTM fue entrenado en trazas de tráfico sintéticas generadas en Mininet usando IPERF. Una vez entrenado, el modelo funciona en un bucle, haciendo predicciones cada 30 segundos y almacenando pronósticos para que actúe el controlador.
Aquí hay una versión simplificada del bucle de predicción:
For every 30 seconds:
latest_sample = data_collector.current_traffic()
slinding_window += latest_sample
if sliding_window size >= window size:
forecast = forecast_engine.predict_upcoming_traffic()
if forecast > alert_threshold:
telem_controller.trigger_INT()Los interruptores responden inmediatamente al cambiar los modos de telemetría para flujos específicos.
¿Por qué LSTM?
Fuimos con un modelo LSTM porque el tráfico de red tiende a tener estructura. No es del todo aleatorio. Hay patrones vinculados a la hora del día, la carga de fondo o los trabajos de procesamiento por lotes, y los LSTM son particularmente buenos para captar esas relaciones temporales. A diferencia de los modelos más simples que tratan cada punto de datos de forma independiente, un LSTM puede recordar lo que vino antes y usar esa memoria para hacer mejores predicciones a corto plazo. Para nuestro caso de uso, eso significa detectar signos tempranos de un próximo aumento simplemente observando cómo se comportaron los últimos minutos. No lo necesitábamos para pronosticar números exactos, solo para marcar cuando algo anormal podría venir. LSTM nos dio la precisión suficiente para activar la telemetría proactiva sin sobrecarsar al ruido.
Evaluación
No ejecutamos puntos de referencia de rendimiento a gran escala, pero a través de nuestro prototipo y comportamiento del sistema en condiciones de prueba, podemos describir las ventajas prácticas de este enfoque de diseño.
Ventaja de tiempo de entrega
Uno de los principales beneficios de un sistema predictivo como este es su capacidad para atrapar problemas temprano. Las soluciones de telemetría reactiva generalmente esperan hasta que un umbral de cola se cruza o el rendimiento se degrada, lo que significa que ya está detrás de la curva. Por el contrario, nuestro diseño anticipa la congestión en función de las tendencias de tráfico y activa de antemano, lo que le da a los operadores una imagen más clara de lo que condujo al problema, no solo los síntomas una vez que aparecen.
Eficiencia de monitoreo
Un objetivo clave en este proyecto era mantener bajos sin comprometer la visibilidad. En lugar de aplicar el INT completo en todo el tráfico o depender del muestreo de grano grueso, nuestro sistema permite selectivamente la telemetría de alta fidelidad para ráfagas cortas, y solo cuando los pronósticos indican problemas potenciales. Si bien no hemos cuantificado el ahorro de costos exactos, el diseño limita naturalmente la sobrecarga al mantener int enfocado y de corta duración, algo que el muestreo estático o la activación reactiva no pueden coincidir.
Comparación conceptual de estrategias de telemetría
Si bien no registramos métricas generales, la intención del diseño era encontrar un término medio, ofreciendo una visibilidad más profunda que los sistemas de muestreo o reactivo, pero a una fracción del costo de la telemetría siempre encendida. Así es como el enfoque se compara a un alto nivel:
Conclusión
Queríamos encontrar una mejor manera de monitorear el tráfico de red. Al combinar el aprendizaje automático y los interruptores programables, construimos un sistema que predice la congestión antes de que ocurra y activa la telemetría detallada en el lugar y el tiempo correctos.
Parece un cambio menor para predecir en lugar de reaccionar, pero abre un nuevo nivel de observabilidad. A medida que la telemetría se vuelve cada vez más importante en los centros de datos a escala de IA y los servicios de baja latencia, este tipo de monitoreo inteligente se convertirá en una expectativa de línea de base, no solo una agradable de tener.