Autor: Lv Biao, responsable de Alibaba Cloud Network Qitian

Las redes en la nube consisten en redes físicas y virtuales, las cuales afectan el rendimiento de la red. Los estudios anteriores se centran principalmente en resolver la detección de redes físicas, pero hay menos estudios correspondientes en el campo de la detección de redes virtuales. Este artículo compartirá con usted un sistema de detección activo de Zoonet diseñado para redes virtuales multiusuario a gran escala e interpretará los antecedentes de diseño, los desafíos, la arquitectura técnica y el intercambio de experiencias de la implementación a gran escala del sistema Zoonet desde una perspectiva técnica.

Recientemente, la conferencia ACM CoNEXT 2022 aceptó un documento "Zonet: un sistema de telemetría proactivo para redes en la nube a gran escala" de Alibaba Cloud Luoshen Cloud Network. Este año CoNEXT recibió un total de 151 presentaciones, de las cuales 28 fueron seleccionadas con éxito, con una tasa de aceptación de solo el 18,5 %. Este documento realizó una exploración de investigación líder en el mundo en el campo de la detección de redes virtuales a gran escala, y el sistema de detección de redes Zoonet basado en esta investigación se implementó y aplicó en los centros de datos globales de Alibaba Cloud.

Para que sea más fácil para todos comprender este documento, este artículo explicará los antecedentes de diseño, los desafíos, la arquitectura técnica y el intercambio de experiencias de implementación a gran escala del sistema Zoonet desde una perspectiva técnica.

1. Introducción a los antecedentes

La nube pública de hoy es la infraestructura de toda una sociedad, sirviendo a millones de inquilinos simultáneamente. Entre ellos, la red en la nube puede ayudar a cada arrendatario a crear un entorno de red aislado y confiable para que los arrendatarios puedan ejecutar sus propias aplicaciones y comunicarse entre sí sin interferir entre sí. La red en la nube está compuesta por la red física subyacente y la red virtual superior. La red física proporciona principalmente la capacidad de conexión de la red básica, mientras que la red virtual puede proporcionar a los inquilinos servicios de red más avanzados, como aislamiento de espacio de direcciones de red, enrutamiento y reenvío virtual, ancho de banda compartido de múltiples IP, acceso a Internet, nivel de inquilino. red interregional, red de nube híbrida a nivel de inquilino, etc. Dado que tanto la red física como la red virtual afectarán el rendimiento de la red de los inquilinos, es necesario que los proveedores de la nube detecten ambas capas de la red para garantizar el acuerdo de nivel de servicio (SLA) de los inquilinos.

A través de la investigación bibliográfica, encontramos que la investigación anterior resolvió principalmente el problema de la detección de redes físicas, como Pingmesh[SIGCOMM'15], Everflow[SIGCOMM'15], 007[NSDI'18], dShark[NSDI'19], NetBouncer[ INDE' 19] et al. En el campo de la detección de redes virtuales, hay muy pocos estudios correspondientes. Nuestra investigación encontró que solo una VNET Pingmesh [IMC'18, artículo breve] intentó realizar la detección de red virtual. Sin embargo, solo realizó el diseño y la implementación del esquema preliminar, y no discutió ni resolvió los problemas que enfrenta la detección de redes virtuales a gran escala, como la actualización rápida de la red virtual, el soporte para middleware heterogéneo (middlebox), red pública a nivel de arrendatario y Detección de red interregional, cobertura completa de enlace de detección de VM-VM, etc.

Por lo tanto, este artículo propone un sistema de detección activa Zoonet diseñado para redes virtuales multiusuario a gran escala. El sistema incluye detección de cobertura de toda la red en la nube y detección bajo demanda de enlaces anormales. La detección de cobertura proporciona una alta cobertura de ruta con una sobrecarga de ancho de banda limitada, elimina las rutas redundantes y las rutas restringidas de enrutamiento/ACL, y luego utiliza el modo de detección de extremo a extremo más simple. La detección a pedido realiza una ubicación rápida de las anomalías de la red e inicia la detección de rutas anormales en modo salto por salto. En particular, Zoonet tiene un diseño brillante en los siguientes aspectos:

Zoonet admite middleware heterogéneo. Hay una gran cantidad de middleware heterogéneo en la red de la nube, por lo que Zoonet diseñó un conjunto de modelos generales de detección que pueden ayudar a que estos middleware se adapten rápidamente a Zoonet.

Actualizaciones rápidas de topología para redes virtuales Zoonet. Para hacer frente a las frecuentes actualizaciones de topología, Zoonet se suscribe a la información de cambio de topología y adopta una serie de estrategias de optimización para mejorar la eficiencia de la actualización. En cuanto al ruido de medición causado por actualizaciones inoportunas, Zoonet lo filtra verificando la topología más reciente.

Zoonet descubre más problemas en escenarios de redes virtuales al expandir continuamente el límite de detección. Además de la red privada ordinaria y los escenarios interregionales, Zoonet también admite la detección de redes públicas, middleware con estado, "última milla" de máquinas virtuales y otros escenarios.

Zoonet se ha implementado en Alibaba Cloud durante más de dos años, cubriendo docenas de regiones. Durante la implementación, Zoonet encontró muchos casos interesantes, incluidos errores de pila de protocolo de red virtual, congestión de red virtual, anomalías de enrutamiento virtual, fallas de red física y anomalías de "última milla" de máquina virtual. Dado que muchos problemas de red sospechosos no son realmente causados por la red, Zoonet ayuda a los proveedores de la nube a lograr la autocertificación en la mayor medida posible.

2. Limitaciones de la detección de redes físicas

La mayoría de las personas siente intuitivamente que el estado de la red virtual se puede deducir de los resultados de la detección de la red física, pero luego analizaremos las limitaciones de la detección de la red física en detalle y explicaremos por qué debemos realizar la detección de la red virtual.

2.1 La detección de redes físicas no puede cubrir la pila de protocolos de redes virtuales

Como se muestra en la figura anterior, en el host físico, la pila de protocolos de red física y la pila de protocolos de red virtual se implementan por separado. La pila de protocolos de red física se basa en el reenvío del núcleo. En los primeros días de Alibaba Cloud, la pila de protocolos de red virtual se implementó con el apoyo conjunto del espacio del usuario y el espacio del kernel. Hoy en día, para un reenvío de mayor rendimiento, la pila de redes virtuales se implementa completamente en el espacio del usuario, utilizando un modelo de derivación del kernel basado en DPDK. De esta forma, la ruta de reenvío virtual está completamente desacoplada del espacio del núcleo. Debido a que las sondas de red física solo envían sondas a través de la pila de red física, no pueden detectar problemas con la pila de red virtual.

2.2 No existe un mapeo topológico preciso entre la red virtual y la red física

La figura anterior muestra un ejemplo de un mapa de topología. Una ruta simple de máquina virtual a máquina virtual en una red virtual corresponde a las cuatro rutas ECMP subyacentes en una red física. En este ejemplo, incluso si la red física detecta que se ha roto una ruta, es difícil deducir si hay un problema con la red virtual, porque el tráfico puede pasar por alto la ruta rota subyacente (por ejemplo, el flujo 2). Peor aún, incluso si notamos que un flujo está descartando paquetes en la red virtual (por ejemplo, el flujo 1), no podemos identificar la ubicación de la ruta física defectuosa porque cuatro rutas ECMP alteran la relación entre la topología virtual y física.

2.3 La detección de redes físicas puede pasar por alto el middleware

La figura anterior muestra la topología de la red física de Alibaba Cloud, que incluye servidores físicos, conmutadores, puertas de enlace fronterizas regionales y varios middleware montados bajo el balanceador de carga. En tales topologías, el middleware se implementa como un dispositivo separado de los servidores y conmutadores físicos. El reenvío de tráfico a este middleware requiere una reescritura adicional de la dirección de destino del paquete en el lado del remitente. Es decir, los métodos de sondeo de extremo a extremo que se basan en la iniciación del host evitarán este middleware "fuera del camino".

2.4 La detección de redes físicas no puede cubrir redes interregionales o límites de Internet en función de la granularidad de los inquilinos

Un arrendatario de Alibaba Cloud puede comprar varias VPC, que se distribuyen en diferentes regiones y se conectan a través de una red interregional. Sin embargo, la detección de redes físicas dentro de una región no puede cubrir las puertas de enlace fronterizas regionales y las redes interregionales en la granularidad de los inquilinos, y no puede proporcionar una resolución de problemas de un extremo a otro entre regiones para inquilinos específicos. Del mismo modo, existe una gran demanda de tráfico entre la máquina virtual e Internet, por lo que los proveedores de la nube deben resolver las dudas de los inquilinos sobre si las fallas de la red ocurren en la nube o en el lado del ISP. Por lo tanto, el sondeo de red debe cubrir el límite entre la nube e Internet para eliminar esta duda. Sin embargo, el sondeo de la red física no puede cumplir este requisito.

3. Desafíos de detección de redes virtuales

La detección de redes virtuales, especialmente la detección de redes virtuales a gran escala como Alibaba Cloud, enfrenta muchos desafíos únicos y no es factible copiar el método de detección de redes físicas. A continuación, presentamos brevemente los desafíos específicos de detección de redes virtuales.

3.1 Realización de detección de sobrecarga baja en redes virtuales de gran escala

Una gran región de la nube contiene cientos de miles de servidores en una red física. Sin embargo, una red virtual suele contener más nodos virtuales. En primer lugar, un servidor físico se puede virtualizar en cientos de máquinas virtuales (una máquina virtual puede albergar hasta 1024 contenedores si se utiliza la tecnología de enlace troncal ENI). En segundo lugar, la red virtual proporciona servicios para una gran cantidad de inquilinos; por ejemplo, una región atiende a millones de inquilinos. En tercer lugar, para grandes arrendatarios, una sola VPC puede albergar nodos virtuales de muy gran escala (por ejemplo, más de 500 000 máquinas virtuales). Según nuestro análisis, en una red virtual de gran escala, la sobrecarga de los esquemas de detección tradicionales será tres órdenes de magnitud mayor que la de la detección de la red física.

3.2 Adaptarse a la rápida actualización de la topología de red virtual

La topología de la red física es relativamente estable. Según nuestra experiencia, la frecuencia de actualización de la red física de Alibaba Cloud es de unos miles de veces al mes. Por el contrario, la topología de una red virtual cambia muy rápidamente debido a una gran cantidad de inquilinos activos y una API de administración flexible. Como se muestra en la figura anterior, la asignación y liberación de recursos de inquilinos desencadena decenas de miles de actualizaciones de topología de red virtual por hora en la región de la nube. Para el sistema de detección, las actualizaciones frecuentes de la red virtual causarán una sobrecarga adicional: 1) Recálculo de topología en tiempo real basado en la configuración del arrendatario; 2) Cálculo en tiempo real de rutas de detección de extremo a extremo basado en actualizaciones de topología; 3) Tiempo real distribución de cinturones de ruta de detección desde el controlador hasta la sobrecarga de ancho de banda masivo.

3.3 Cobertura multiservicio y multimiddleware

Para dispositivos de capa 2 y capa 3 en la red física, el reenvío de paquetes de datos generalmente se basa en reglas de reenvío sin estado, lo que es más conveniente para realizar la detección bidireccional entrante y saliente. Sin embargo, la red virtual contiene una variedad de middleware con estado y no pueden implementar una detección bidireccional de entrada y salida simple. Como el middleware basado en sesiones, antes de que el cliente envíe el primer paquete de datos de la sesión, no existe una relación de sesión en este middleware, por lo que los paquetes de datos del servidor no se pueden reenviar correctamente a través del middleware. Por ejemplo, una máquina virtual depende de SNAT (proporcionado por una puerta de enlace NAT) para acceder a Internet, pero Internet no puede acceder activamente a la máquina virtual a menos que se establezca una sesión SNAT. Además, diferentes middleware pueden tener diferentes implementaciones, e incluso middleware con la misma función se puede construir en diferentes plataformas (por ejemplo, bare metal, NFV, FPGA, ASIC). Por lo tanto, el marco de detección de redes virtuales debe adaptarse a la heterogeneidad del middleware.

3.4 Detección de VM a VM insensible al arrendatario

Para redes físicas, extremo a extremo significa host a host, mientras que para redes virtuales, extremo a extremo significa máquina virtual a máquina virtual. Para la detección de redes físicas, la función de generación de tareas de detección o recopilación de datos se puede implementar en el proceso del sistema operativo en el host terminal. Sin embargo, el mismo método no se puede aplicar directamente a las máquinas virtuales de los inquilinos, porque los proveedores de la nube no pueden invadir las máquinas virtuales de los inquilinos y deben proteger la privacidad del usuario. Sin embargo, la "última milla" de la ruta de un extremo a otro no se puede cubrir fácilmente sin las sondas integradas de VM. Discutiremos el uso de ARP Ping para resolver este problema a continuación.

3.5 Distinguir entre problemas de red física y virtual

Cuando ocurre una anomalía en la red, es necesario distinguir entre los problemas de la red virtual y los problemas de la red física para reducir el alcance de la falla. En una red física, podemos confiar en traceroute para la medición y el diagnóstico salto por salto. Sin embargo, al extender traceroute a la red virtual, a pesar de que arrojó una pérdida de paquetes relacionada con el conteo de saltos exacto en la red virtual, aún no pudimos confirmar si se trataba de un problema con el dispositivo virtual o el dispositivo físico subyacente, porque entre existen dos dominios de red física virtual adyacentes entre dispositivos de red. En este artículo abordamos este problema a través de un modo de salto por salto de Zoonet especialmente diseñado.

4. Solución Zoonet

4.1 Diseño general

Como se muestra en la figura anterior, Zoonet consta de un plano de datos y un plano de control. El plano de datos recibe tareas de detección del plano de control y luego inyecta activamente paquetes de detección para detectar redes virtuales. La ruta de detección de una tarea de detección es de vSrc a vDst a través de múltiples vBoxes. vSrc y vDst son puntos de detección virtuales, implementados por Zoonet-agent (un programa de desarrollo propio que se ejecuta en la máquina host, independientemente del hipervisor de la VM). vBox se refiere a una serie de middleware de red virtual (como hipervisores, balanceadores de carga, puertas de enlace NAT, puertas de enlace de Internet, etc.). En Zoonet, se puede utilizar un soporte especial para vBox para la localización rápida de rutas anómalas. Para cubrir las sondas de Internet, Zoonet amplía el límite de la sonda a los ISP estableciendo el punto de sonda pDst en el límite de la nube. pDst puede simular Internet para devolver el paquete de detección.

El plano de control consta de tres módulos: planificador de tareas de telemetría, analizador de topología de telemetría y analizador de datos de telemetría. El planificador de la misión de exploración es responsable de la planificación de la misión de exploración normalizada y exploración de diagnóstico bajo demanda. El analizador de topología de la sonda es responsable del cálculo de la topología de la red virtual y el análisis de la ruta de la sonda potencial para todos los inquilinos. También debe actualizar la topología y las rutas en función de las operaciones de actualización de la topología del arrendatario. El analizador de datos de la sonda es responsable de recopilar datos de la sonda del plano de datos para un análisis en profundidad y enviar alertas cuando se encuentran anomalías. Para eliminar las tareas de detección no válidas causadas por actualizaciones inoportunas, es necesario leer la topología más reciente para verificar la coherencia antes de que se emita una alarma.

4.2 Plano de datos de Zoonet

4.2.1 Tareas de detección

El plano de datos de Zoonet recibe y ejecuta las tareas de detección emitidas por el plano de control. Una tarea de detección se define como:

Tarea = Sondeo (vSrc, vDst, opciones, modos)

Entre ellos, vSrc y vDst son los puntos de origen y final de una tarea de detección, que pasará por múltiples nodos intermedios (vBox). En la mayoría de los casos, vSrc y vDst se refieren a máquinas virtuales y vBox se refiere al middleware de red virtual. Para ser independiente del inquilino, el sondeo de extremo a extremo de Zoonet comienza y termina en el agente de VM (es decir, el agente de Zoonet). En el sondeo de Internet, vDst también puede ser el VIP de la puerta de enlace de Internet o el dispositivo de sondeo físico pDst colocado cerca del límite de Internet. Las opciones definen cómo encapsular y enviar paquetes de prueba, como el intervalo, la cantidad, el tamaño del paquete de prueba, el protocolo, etc. Los modos definen cómo responde vBox a los paquetes de sondeo. Usando opciones y modos, el plano de control se puede programar para sondear el plano de datos.

Zoonet contiene los siguientes tres tipos de paquetes de detección:

Paquete de solicitud (Request paquete) , un paquete de detección de vSrc a vDst;

Paquete de respuesta (paquete de respuesta) , un paquete de detección de vSrc a vDst;

Paquete de informe , un mensaje que lleva datos de detección, vBox puede enviar un paquete de informe cuando recibe un paquete de solicitud o respuesta.

Al mismo tiempo, para simplificar la lógica de detección en el vBox, el vSrc de la prueba final será responsable de todas las interacciones con el plano de control, incluida la generación e inyección de paquetes de datos de detección, el cálculo del retraso de detección y la pérdida de paquetes. , etc. vBox solo es responsable de realizar el reenvío de paquetes de sondeo y la respuesta de mensajes.

4.2.2 Modo de detección

El sondeo simple de extremo a extremo no es suficiente para cubrir todos los escenarios de sondeo en la nube:

1) La red en la nube tiene una gran cantidad de middleware con estado, y la detección sin estado solo puede monitorear la ruta virtual desde una dirección;

2) Las soluciones existentes solo brindan cobertura de detección dentro de la región, y la frontera de Internet es actualmente un punto ciego para la detección;

3) La detección de extremo a extremo puede detectar rutas anormales, pero cuando ocurre una falla, no se puede ubicar el punto exacto de falla (es decir, el dispositivo/enlace).

Para satisfacer estas necesidades de detección, Zoonet ha desarrollado tres pares de modos de detección de átomos, como se muestra en la tabla anterior. Entre estos modos, los modos One-Way y PingPong indican detección unidireccional o bidireccional, los modos Non-Transparent y Transparent indican si se debe extender el límite de detección de vDst a pDst, End-to-End y Hop-by-Hop. indicar las rutas de reenvío si cada vBox participará en el proceso de sondeo. Hay 8 combinaciones de los tres pares de modos de detección. Aquí hay ejemplos de 4 casos de uso de combinación comunes y escenarios de detección de red en la nube comunes correspondientes:

Ejemplo 1: Detección normalizada, middleware sin estado. En el caso de uso de detección normalizado (combinación de patrones de OW+EE+NT), vSrc envía un paquete de detección de solicitud, que llega a vDst a través de la ruta de extremo a extremo. Luego, vDst envía un mensaje de informe a vSrc. Tenga en cuenta que, en el caso de la detección normalizada, vBox solo reenvía los paquetes de detección. Para la cobertura de ruta virtual en toda la red, la detección normalizada está habilitada de forma predeterminada.

Ejemplo 2: Detección normalizada, middleware con estado. En el caso de uso de sondeo con estado (utilizando la combinación de modos de PP+EE+NT), además del paquete de informe, vDst también enviará un paquete de respuesta. Dichos casos de uso son principalmente para sondear middleware con estado como SNAT. Tenga en cuenta que PingPong no es equivalente a dos sondas unidireccionales separadas que van en ambas direcciones. Porque antes de que el middleware con estado establezca la sesión, los paquetes de datos que ingresen desde la dirección inversa serán descartados.

Ejemplo 3: Detección normalizada, límite de Internet. En el caso de uso de detección de límites de Internet (combinación de modo OW+EE+TR), confiamos en el modo transparente y pDst para la cobertura de detección de límites de Internet. El paquete de sondeo se reenviará a pDst después de pasar por vDst. Aquí, no colocamos pDst en Internet (por ejemplo, en la sala de computadoras del ISP), principalmente porque el pDst en Internet está fuera del control de los proveedores de la nube, e incluso si se monitorea una falla en la ruta, no podemos determinar si la anomalía de la red ocurrió en la nube o en la red ISP. En Zoonet, colocamos pDst en una nube pública cerca del límite de Internet.

Ejemplo 4: Detección de diagnóstico bajo demanda. En el caso de uso de diagnóstico a pedido (combinación de patrones de OW+HH+NT), a diferencia de los casos de uso anteriores, el paquete de solicitud enviado desde vSrc activará cada vBox en la ruta de reenvío para responder con un paquete de informe. Este enfoque de salto por salto es similar a traceroute, pero con un diseño más limpio y versátil. Específicamente, el vBox envía el paquete de informe dos veces, una en la dirección de entrada y otra en la dirección de salida. Este diseño puede distinguir rápidamente entre fallas de enlace y fallas de nodo. Suponiendo que los dos paquetes de informes de entrada y salida experimentan problemas diferentes, la falla está en ese nodo. De lo contrario, el enlace en el medio debe haber fallado. Debido a que un enlace virtual corresponde a un dominio de red física, el modo Hop-by-Hop de Zoonet puede distinguir entre problemas de red física y red virtual. Hop-by-Hop es computacionalmente intensivo tanto en el vBox como en el plano de control. Por lo tanto, lo mejor es usar End-to-End para la detección de cobertura de red primero y luego usar Hop-by-Hop para la ubicación de anomalías.

4.2.3 Soporte de otro plano de datos

Protocolo Zoonet: hemos desarrollado un conjunto de protocolos de detección de red virtual y el formato de paquete de este protocolo se ha divulgado en el documento.

Agente de Zoonet: software de agente de paquete de envío y recepción de desarrollo propio, implementado en el host de VM, es un proceso independiente y tiene un núcleo de control de CPU de enlace especial. Esto puede evitar efectivamente la interferencia y el impacto en los inquilinos y las máquinas virtuales de los inquilinos.

Hipervisor de VM: después de identificar el paquete de datos de Zoonet, encapsula y desencapsula principalmente el encabezado del túnel y marca algunos bits de marcado.

Middleware: El middleware de software admite mejor Zoonet. Para algunos middleware programables, como los chips Tofino, debido a sus recursos limitados en el chip, los paquetes de datos de Zoonet generalmente se envían al plano de control para su procesamiento.

Detección de última milla: el paquete de detección enviado desde el agente de Zoonet no puede cubrir el pequeño enlace de la máquina virtual al hipervisor, que se pasa por alto fácilmente.Utilizamos la detección ARP para resolver este problema. La razón por la que se selecciona la detección ARP es porque el protocolo ARP es un protocolo básico y de muy bajo nivel, y las VM generales lo admiten de forma predeterminada.

4.3 Plano de control de Zoonet

El plano de control de Zoonet resuelve principalmente los siguientes tres problemas:

Enormes gastos generales de medición incurridos por las tareas de sondeo;

Problemas causados por frecuentes actualizaciones de topología;

Explorar la enorme sobrecarga de la recopilación y el consumo de datos.

4.3.1 Planificación jerárquica del trayecto de detección

Antes de discutir cómo Zoonet calcula la ruta de detección, echemos un vistazo a la topología de la red en la nube. La figura anterior muestra una descripción general de la red virtual de un arrendatario en Alibaba Cloud. Podemos ver que la VM está montada en el conmutador virtual (el conmutador virtual es un nodo lógico y la cantidad de máquinas virtuales que transporta es teóricamente ilimitada). Los enlaces entre conmutadores virtuales en una región son completamente interoperables. Se pueden conectar múltiples VPC distribuidas en diferentes regiones a través de enlaces entre dominios. Además, la máquina virtual también puede acceder a Internet a través de la red pública IP o SNAT. A continuación, analizamos cómo Zoonet reduce la sobrecarga de detección a través de un método de detección en capas.

Nivel 1: las máquinas virtuales bajo el mismo conmutador virtual se detectan en pares. Si las máquinas virtuales debajo de cada conmutador virtual pueden detectarse entre sí con malla completa, causará una complejidad de detección O(n^2), donde n representa la cantidad de máquinas virtuales. Para una red virtual, la cantidad de máquinas virtuales bajo un conmutador virtual es teóricamente ilimitada (hemos observado miles de máquinas virtuales conectadas al mismo conmutador virtual en la implementación real). Por lo tanto, la detección de malla completa sufre el problema de la complejidad de la detección. Pingmesh puede realizar una detección de malla completa entre servidores bajo los mismos ToR, porque cada ToR físico tiene un número fijo de puertos, por lo que la complejidad de la detección está bien controlada. Para reducir la sobrecarga de detección, en cada conmutador virtual, dividimos la VM en dos grupos de igual número y realizamos la detección de pares de VM, lo que reduce la complejidad de detección de O(n^2) a O(n/2). Además, diferenciamos intencionalmente las máquinas virtuales en función de su distribución en diferentes servidores para garantizar el máximo sondeo en los servidores físicos.

Nivel 2: detección de malla completa entre conmutadores virtuales. Para cubrir completamente una red virtual, una solución sencilla es realizar sondeos de malla completa en cada máquina virtual de extremo a extremo en la red virtual. Sin embargo, tal sobrecarga de sondeo de malla completa es demasiado grande. Para reducir la complejidad, utilizamos el sondeo agregado. Específicamente, las sondas de malla completa se pueden iniciar desde conmutadores virtuales de nivel agregado en lugar de máquinas virtuales de nodo hoja.

Nivel 3: Poda de camino interregional. Los inquilinos establecerán configuraciones de enrutamiento/ACL en las puertas de enlace fronterizas regionales para limitar el tráfico entre regiones. De esta forma, aunque la red subyacente para la comunicación interregional es de malla completa, el tráfico de la red superpuesta no tomará todas las rutas. De acuerdo con las características de esta red de superposición, realizamos una poda de ruta entre regiones basada en tablas de enrutamiento y reglas de ACL para reducir aún más la complejidad de la detección entre regiones.

Nivel 4: Detección de rutas de puntos de acceso top-N de VM a VM. Descubrimos que el tráfico de la red en la nube sigue la regla 80/20, es decir, la mayor parte del tráfico es transportado por una pequeña cantidad de rutas. Con esto, podemos optimizar aún más la estrategia de detección. Específicamente, podemos analizar regularmente los registros de tráfico y seleccionar las principales N rutas de puntos de acceso de VM a VM como las rutas de detección clave, que pueden cubrir la mayor parte del tráfico de manera rentable. La cobertura de ruta Top-N puede ser un buen complemento para la estrategia de planificación de ruta anterior.

4.3.2 Actualizaciones de topología frecuentes

La figura anterior muestra el proceso de actualización de la topología. Una operación de actualización de arrendatarios afectará todos los aspectos de la red virtual, como:

Instancia de red virtual, como VPC, conmutador virtual, VM, etc.;

Enrutamiento intrarregional, interregional, Internet/IDC;

Otros como ACL, ancho de banda de Internet de cada arrendatario, etc.

Cuando cambia la configuración de la red virtual, se envían al analizador de topología de sondeo. Debido a la alta frecuencia de actualizaciones, es imposible responder cada vez que llega una actualización. Por lo tanto, Zoonet utiliza colas de mensajes para almacenar en búfer actualizaciones recientes y lecturas por lotes a intervalos regulares. Al procesar actualizaciones, implementamos las siguientes estrategias para mejorar la eficiencia y la precisión:

Estrategia 1: eliminar las actualizaciones independientes de la topología. Algunos cambios de inquilinos no afectarán la topología de la red virtual, como los inquilinos que ajustan el ancho de banda de Internet. Estas actualizaciones se eliminan de la cola de mensajes.

Estrategia 2: elimine la actualización add-del. Para un lote de actualizaciones leídas de la cola de mensajes, si hay las mismas instancias, rutas u otras configuraciones que se agregan antes de eliminarlas o se eliminan antes de agregarlas, las identificaremos y las eliminaremos juntas.

Estrategia 3: Actualizaciones agregadas en la granularidad de VPC. Los analizadores de topología de sondeo se suscriben a las actualizaciones de topología de los controladores de dispositivos. Los controladores de dispositivos se implementan de forma distribuida para lograr una alta disponibilidad, lo que puede provocar que las actualizaciones lleguen desordenadas. Por ejemplo, un analizador de topología de sondeo puede recibir una actualización para crear una VM en una VPC, pero es posible que el evento de creación de la VPC correspondiente no se lea de la cola hasta la próxima ronda, lo que daría como resultado una actualización incorrecta. Nuestra solución es agregar todas las actualizaciones leídas de la cola en la granularidad de VPC.

4.3.3 Recopilación y consumo de datos de detección

Zoonet utiliza el marco de procesamiento de flujo distribuido Flink para procesar datos de sondeo a escala de la nube en tiempo real. Al implementar más unidades informáticas, Zoonet puede escalar fácilmente los analizadores de datos para manejar cargas de trabajo crecientes. Inicialmente, utilizamos una función unificada definida por el usuario (UDF) para abordar el procesamiento de datos para todos los modos de detección. Sin embargo, la diferencia en la complejidad computacional de los diferentes modos de detección es grande. Después de analizar la frecuencia de llamadas y la sobrecarga informática de diferentes modos de detección, diseñamos un UDF dedicado para el modo Hop-by-Hop y un Flink SQL más simple para otros modos. Cuando se separa dicha lógica informática, el costo informático de Zoonet se reduce en un 75 %.

5. Problemas encontrados en la implementación en línea

Zoonet se ha implementado a gran escala en el sistema de producción de Alibaba Cloud durante más de dos años. Ayúdenos a descubrir y solucionar muchos problemas de red durante este período. A continuación, compartiremos los 307 casos de excepción encontrados en base a Zoonet dentro de un mes. En total, los dividimos en 6 grandes categorías:

5.1 Error de pila de protocolo de red virtual

Dado que la detección de redes físicas no pasa a través de la pila de protocolos de redes virtuales, Zoonet detecta muchos errores de pila de protocolos de redes virtuales que no se pueden encontrar con los métodos de detección de redes físicas. Estos errores se pueden subdividir en las siguientes tres categorías:

Error en el host final. Las redes en la nube son muy dinámicas y generan decenas de miles de actualizaciones de topología por hora en una región. Cuando se producen actualizaciones de topología, los hosts finales también deben actualizar sus tablas de configuración. En implementaciones reales, Zoonet ha ayudado a detectar muchas inconsistencias de configuración entre los planos de control y de datos de los hosts finales, la mayoría de las cuales afectan el reenvío de tráfico de las VM de inquilinos. Por ejemplo, Zoonet una vez detectó la pérdida de paquetes de VM debido a una mala configuración del ancho de banda. Por supuesto, podemos comenzar la comparación de entradas en cada host de terminal para encontrar tales errores, pero debido a la gran cantidad de entradas, el tiempo de comparación de entradas será muy largo. Zoonet puede ayudarnos a descubrir dichos problemas de manera más oportuna.

Error en el software intermedio. En el proceso de desarrollo de middleware, inevitablemente se introducirán errores del sistema. Aunque haremos muchas pruebas antes de que el middleware entre en funcionamiento, para algunas fallas grises (fallas grises), especialmente aquellas que solo involucran inquilinos específicos, máquinas virtuales o tráfico, nos llevará mucho tiempo localizarlas, e incluso muchas veces No pudo ser encontrado. Con el modo Hop-by-Hop, Zoonet mejora enormemente la probabilidad de encontrar fallas grises a través de tareas masivas con diferentes parámetros. En el último mes, Zoonet nos ayudó a descubrir 10 errores de configuración de middleware causados por errores del programa de control de SDN. Estos errores solo los desencadenan inquilinos específicos y son extremadamente difíciles de localizar utilizando métodos tradicionales. Por ejemplo, Zoonet detectó que la función hash SNAT de un arrendatario estaba mal configurada, lo que impedía que el arrendatario estableciera nuevas sesiones SNAT.

Un error en el actualizador de red virtual. La red en la nube proporciona servicios de red flexibles de forma externa. Con el fin de adaptarse continuamente a los nuevos servicios de red, por lo general se somete a actualizaciones frecuentes. Un pequeño número de ellos usa actualizaciones en frío y tenemos suficiente tiempo para verificar que la actualización fue exitosa. Pero la mayoría de los dispositivos virtuales usan actualización en caliente. La interrupción temporal del negocio o la falla de actualización causada por la actualización en caliente a veces es inevitable. Pero queremos detectarlo temprano y luego reducir el daño retrocediendo rápidamente o pasando por alto el punto de falla. Con Zoonet, utilizaremos el monitoreo continuo en banda de Zoonet para reflejar la calidad del servicio de red actual durante el proceso de actualización y responder rápidamente una vez que se encuentren los problemas.

5.2 Congestión de la red virtual

Los inquilinos crean un entorno de red en el que los inquilinos están aislados entre sí en la nube pública y luego ejecutan las aplicaciones de forma independiente. Pero la congestión de la red virtual puede romper este aislamiento al agotar los recursos compartidos subyacentes. De todas las situaciones de congestión de la red, la sobrecarga de la CPU es la más común. Muchos dispositivos virtuales se basan en el reenvío de CPU. Pero debido al rendimiento limitado de un solo núcleo (por ejemplo, 1 Mpps), una gran ráfaga de tráfico puede agotar la CPU y causar congestión en la red virtual. Si bien estos problemas se detectan fácilmente al monitorear la utilización de la CPU, la forma de evaluar con precisión el alcance del impacto (por ejemplo, cuántos inquilinos/máquinas virtuales/servicios se ven afectados) es una pregunta abierta. Zoonet resuelve este problema haciendo coincidir las tareas de detección de anomalías con la información de los inquilinos para los componentes congestionados. Por ejemplo, en un caso real, cuando los núcleos de la CPU del middleware estaban sobrecargados, Zoonet detectó exactamente 157 tareas relacionadas que experimentaron pérdida de paquetes (un 3 % del número total de tareas de middleware).

5.3 Excepción de enrutamiento virtual

La red virtual lanzará varios tipos de IP virtual (VIP) para drenaje de tráfico. Específicamente, el clúster de middleware anunciará el VIP al resto de la nube y la nube pública anunciará la IP pública al ISP. Normalmente, estos lanzamientos VIP son transparentes para los inquilinos. Pero a veces, los anuncios de rutas anormales (como errores de configuración de rutas) afectarán el reenvío de tráfico de inquilinos. En un caso, el lanzamiento anómalo de VIP del clúster de middleware de servicios de Internet provocó la pérdida silenciosa de paquetes reenviados por una pequeña cantidad de redes de inquilinos. Zoonet ayuda a identificar tales anomalías al detectar la pérdida aparente de paquetes en múltiples instancias de Internet.

5.4 Fallo de enlace virtual/fallo de red física

Zoonet puede distinguir entre fallas de nodos virtuales y fallas de enlaces virtuales. En la implementación real, Zoonet ayuda a detectar muchas fallas de enlaces virtuales. Debido a que los enlaces virtuales se componen de varios conmutadores y enlaces físicos, también se les puede llamar fallas de la red física. El sondeo de la red física puede detectar estas fallas de la red; sin embargo, el sondeo de la red física no puede correlacionarlos con inquilinos/máquinas virtuales/servicios. Por ejemplo, si la detección de la red física detecta un evento de interrupción de ToR, es imposible confirmar si el evento afecta el reenvío de paquetes del negocio de un arrendatario, porque el tráfico de los ToR fallidos puede cambiarse silenciosamente a los ToR de respaldo. En este escenario, si Zoonet detecta que el enlace virtual correspondiente tiene una pérdida de paquetes obvia, Zoonet puede inferir con mayor precisión que el evento ToR inactivo ha afectado el reenvío de paquetes del arrendatario.

5.5 Anomalías de "última milla" de VM

Existen principalmente dos tipos de problemas en la "última milla" entre la máquina virtual y el hipervisor, a saber, la excepción de la máquina virtual y la excepción de cola virtual (cola entre la máquina virtual y el hipervisor). Por lo general, estos problemas son causados por la pila de protocolos subyacentes y los errores ocultos, y cuando ocurren, pueden afectar a miles de hosts finales. Usamos ARP Ping para cubrir la "última milla". En la implementación real, encontramos que el retraso del ping ARP es inestable y se ve afectado por el uso de la CPU de la máquina virtual y el host. Por lo tanto, confiamos principalmente en la tasa de pérdida de paquetes de ARP Ping para detectar problemas. El gráfico anterior muestra la latencia del ping ARP y la tasa de pérdida de paquetes durante los eventos de falta de memoria de la máquina virtual. Se puede ver que el retraso de ARP Ping fluctúa alrededor de 100~300 microsegundos, y la tasa de pérdida de paquetes alcanza el 100 % en el punto anormal exacto.

5.6 Prueba de inocencia

El presunto problema de red del que se queja el arrendatario en realidad se debe a que el tráfico del arrendatario supera la cuota de ancho de banda/sesión comprada, o su propio error de configuración y su propio problema de aplicación. También hemos tenido problemas de red sospechosos que terminaron siendo diagnosticados como problemas de VM o problemas de red de ISP. Aunque estos casos no son problemas de red, ocupan una gran parte de nuestras órdenes de trabajo de solución de problemas excepcionales y consumen una gran cantidad de mano de obra de I+D. Zoonet detecta y cubre activamente las rutas de la red virtual a través de una red virtual a gran escala, lo que mejora la capacidad de la iniciativa de red en la nube para demostrar su inocencia. Y hemos estado ampliando el límite de detección, esperando lograr un rango más alto de autodemostración de inocencia.

6. Compartir experiencias

Experiencia 1: hay muchos casos de esquina para las actualizaciones de topología de red virtual. Al comienzo del diseño de Zoonet, consideramos los eventos que pueden causar cambios en la topología virtual, como el apagado de la VM, el lanzamiento de la VM, la migración de la VM, etc. Sin embargo, la complejidad de los servicios en la nube conduce a muchos casos de esquina en los que nunca pensamos. Por ejemplo, un escenario es la migración de máquinas virtuales entre VPC, que inicialmente se consideró imposible porque una máquina virtual siempre se considera vinculada a su VPC. Otra situación que no se considera es que si se detecta que una máquina virtual tiene ataques a la red (o es atacada), su IP virtual será bloqueada. La figura anterior muestra la proporción de tareas de detección de anomalías (es decir, ruido de detección) debido a una cobertura incompleta de casos de esquina. Zoonet ha experimentado primero una implementación a pequeña escala y luego una implementación a gran escala. El ruido de sondeo crece rápidamente con el tamaño de la implementación a medida que se exponen los errores ocultos. Después de un mes de corrección de errores, el ruido de detección finalmente convergió.

Experiencia 2: Múltiples optimizaciones del plano de control de Zoonet. Las configuraciones de red virtual se almacenan inicialmente en una base de datos relacional. Zoonet necesita leer varias tablas relacionales antes del cálculo de la topología, como la tabla de recursos de VPC, la tabla de enrutamiento de VPC, la tabla de mapeo de VM-servidor, la tabla de mapeo de VM-pubIP, etc. Sin embargo, las bases de datos relacionales tienen velocidades de lectura y escritura limitadas y poca escalabilidad. Por lo tanto, desarrollamos una caché de topología de red virtual con una base de datos en memoria de valor clave para la aceleración. Además, ampliamos aún más el plano de control de Zoonet utilizando técnicas como la fragmentación de bases de datos basada en regiones.

Experiencia 3: Diagnóstico automatizado de fallas a través del árbol de diagnóstico. Zoonet ejecuta una detección de red regular y envía una alarma a los operadores de red cuando detecta anomalías en la red. Los operadores de red son responsables de analizar las alarmas y localizar las causas raíz. Nos vimos abrumados por una "tormenta de alertas" al principio de la implementación, por lo que comenzamos a escribir scripts automatizados para la resolución de problemas. Gradualmente, la base de datos de secuencias de comandos crece hasta convertirse en un árbol de diagnóstico, en el que cada nodo hoja contiene una causa raíz. Con el árbol de diagnóstico, cuando se encuentra una anomalía, primero atraviesa el árbol y luego encuentra el nodo hoja para notificar al operador de la red. Los beneficios de esto son enormes, por ejemplo, reduce la cantidad de personas en el equipo de VPC que trabajan en la resolución de problemas de red de 11 a 1,5.

7. Resumen

Alibaba Cloud Luoshen Cloud Network intenta resolver dos problemas principales que se enfrentan en el funcionamiento real de la red en la nube: uno es cómo demostrar que un problema no es un problema de red, y el otro es descubrir y localizar rápidamente problemas de red con un pequeño impacto. . Zoonet adopta un método de detección ligero normalizado en tiempo real y coopera con el amplio soporte de protocolos de detección de muchos nodos de redes virtuales para resolver mejor los problemas anteriores. El sistema fue desarrollado con el esfuerzo de docenas de estudiantes de I+D, y el sistema ha sido completamente verificado en un sistema de red en la nube a gran escala. Se espera que compartir Zoonet pueda aportar un valor de referencia importante para la industria y la academia.

Otras lecturas

Artículo original de Zoonet:

https://dl.acm.org/doi/pdf/10.1145/3555050.3569116

Artículo principal de la conferencia | Exploración y práctica de la tecnología de detección de redes virtuales