Los centros de datos modernos tienen cientos de dispositivos activos instalados, cubiertos por diferentes tipos de monitoreo. Pero incluso un ingeniero ideal con un control perfecto será capaz de responder correctamente a un fallo de la red en sólo unos minutos. En un informe en la conferencia Next Hop 2020, presenté una metodología de diseño de redes DC, que tiene una característica única: el centro de datos se repara a sí mismo en milisegundos. Más precisamente, el ingeniero soluciona el problema con calma, mientras que los servicios simplemente no lo notan.
Para muchos ingenieros de redes, la red de un centro de datos comienza, por supuesto, con ToR, con un conmutador en el bastidor. Los TdR suelen tener dos tipos de vínculos. Los pequeños van a los servidores, otros - hay N veces más - van hacia las espinas del primer nivel, es decir, a sus enlaces ascendentes. Los enlaces ascendentes generalmente se consideran iguales y el tráfico entre enlaces ascendentes se equilibra en función de un hash de 5 tuplas, que incluye proto, src_ip, dst_ip, src_port, dst_port. No hay sorpresas aquí.
A continuación, ¿cómo es la arquitectura del plan? Las espinas del primer nivel no están conectadas entre sí, sino que están conectadas a través de superespinas. La letra X será responsable de las superespinas; es casi como una conexión cruzada.
Y está claro que, por otro lado, los tori están conectados a todas las espinas del primer nivel. ¿Qué es importante en esta imagen? Si tenemos interacción dentro del rack, entonces la interacción, por supuesto, pasa a través de ToR. Si la interacción ocurre dentro del módulo, entonces la interacción ocurre a través de las espinas del primer nivel. Si la interacción es intermodular, como aquí, ToR 1 y ToR 2, entonces la interacción pasará por las espinas tanto del primer como del segundo nivel.
En teoría, una arquitectura de este tipo es fácilmente escalable. Si tenemos capacidad portuaria, espacio libre en el centro de datos y fibra preinstalada, siempre se puede aumentar el número de carriles, aumentando así la capacidad general del sistema. Esto es muy fácil de hacer en papel. Así sería en la vida. Pero la historia de hoy no se trata de eso.
Quiero que se saquen las conclusiones correctas. Tenemos muchos caminos dentro del centro de datos. Son condicionalmente independientes. Un camino dentro del centro de datos sólo es posible dentro de ToR. Dentro del módulo, tenemos el número de caminos igual al número de carriles. El número de caminos entre módulos es igual al producto del número de planos por el número de superespinas en cada plano. Para que quede más claro, para tener una idea de la escala, daré números que son válidos para uno de los centros de datos de Yandex.
Hay ocho aviones, cada avión tiene 32 superespinas. Como resultado, resulta que hay ocho caminos dentro del módulo, y con la interacción entre módulos ya hay 256.
Es decir, si estamos desarrollando Cookbook, tratando de aprender cómo construir centros de datos tolerantes a fallas que se reparen a sí mismos, entonces la arquitectura plana es la opción correcta. Resuelve el problema de escala y, en teoría, es fácil. Hay muchos caminos independientes. La pregunta sigue siendo: ¿cómo sobrevive una arquitectura así a los fracasos? Hay varios fracasos. Y discutiremos esto ahora.
Dejemos que una de nuestras superespinas se “enferme”. Aquí volví a la arquitectura de dos planos. Nos quedaremos con estos como ejemplo porque simplemente será más fácil ver lo que sucede con menos partes móviles. Deja que X11 se enferme. ¿Cómo afectará esto a los servicios que residen dentro de los centros de datos? Mucho depende de cómo se vea realmente el fallo.
Si la falla es buena, se detecta en el nivel de automatización del mismo BFD, la automatización felizmente coloca las juntas problemáticas y aísla el problema, entonces todo está bien. Tenemos muchos caminos, el tráfico se desvía instantáneamente a rutas alternativas y los servicios no notarán nada. Este es un buen guión.
Un mal escenario es si tenemos pérdidas constantes y la automatización no nota el problema. Para comprender cómo afecta esto a una aplicación, tendremos que dedicar un poco de tiempo a analizar cómo funciona TCP.
Espero no sorprender a nadie con esta información: TCP es un protocolo de confirmación de transmisión. Es decir, en el caso más simple, el remitente envía dos paquetes y recibe un acuse de recibo acumulativo sobre ellos: "Recibí dos paquetes".
Después de eso, enviará dos paquetes más y la situación se repetirá. Pido disculpas de antemano por alguna simplificación. Este escenario es correcto si la ventana (la cantidad de paquetes en tránsito) es dos. Por supuesto, en el caso general esto no es necesariamente así. Pero el tamaño de la ventana no afecta el contexto de reenvío de paquetes.
¿Qué pasa si perdemos el paquete 3? En este caso, el destinatario recibirá los paquetes 1, 2 y 4. Y le dirá explícitamente al remitente usando la opción SACK: “Sabes, llegaron tres, pero se perdió el del medio”. Él dice: "Ack 2, SACK 4".
En este momento, el remitente repite sin problemas exactamente el paquete que se perdió.
Pero si se pierde el último paquete de la ventana, la situación será completamente diferente.
El destinatario recibe los primeros tres paquetes y primero comienza a esperar. Gracias a algunas optimizaciones en la pila TCP del kernel de Linux, esperará un paquete emparejado a menos que las banderas indiquen explícitamente que es el último paquete o algo similar. Esperará hasta que expire el tiempo de espera de ACK retrasado y luego enviará un acuse de recibo en los primeros tres paquetes. Pero ahora el remitente esperará. No sabe si el cuarto paquete se ha perdido o está a punto de llegar. Y para no sobrecargar la red, intentará esperar una indicación explícita de que el paquete se ha perdido o que expire el tiempo de espera de RTO.
¿Qué es el tiempo de espera de RTO? Este es el máximo del RTT calculado por la pila TCP y una constante. Qué tipo de constante es esta, lo discutiremos ahora.
Pero lo importante es que si volvemos a tener mala suerte y se vuelve a perder el cuarto paquete, entonces el RTO se duplica. Es decir, cada intento fallido supone duplicar el tiempo de espera.
Ahora veamos a qué es igual esta base. De forma predeterminada, el RTO mínimo es 200 ms. Este es el RTO mínimo para paquetes de datos. Para paquetes SYN es diferente, 1 segundo. Como puede ver, incluso el primer intento de reenviar paquetes tardará 100 veces más que el RTT dentro del centro de datos.
Ahora volvamos a nuestro escenario. ¿Qué está pasando con el servicio? El servicio comienza a perder paquetes. Deje que el servicio tenga suerte condicional al principio y pierda algo en el medio de la ventana, luego recibe un SACK y reenvía los paquetes que se perdieron.
Pero si la mala suerte se repite, entonces tenemos un RTO. ¿Qué es importante aquí? Sí, tenemos muchos caminos en nuestra red. Pero el tráfico TCP de una conexión TCP particular seguirá pasando por la misma pila rota. La pérdida de paquetes, siempre que este mágico X11 nuestro no se apague por sí solo, no provoca que el tráfico fluya hacia zonas que no son problemáticas. Estamos intentando entregar el paquete a través de la misma pila rota. Esto conduce a una falla en cascada: un centro de datos es un conjunto de aplicaciones que interactúan, y algunas de las conexiones TCP de todas estas aplicaciones comienzan a degradarse, porque superspine afecta a todas las aplicaciones que existen dentro del centro de datos. Como dice el refrán: si no herrabas un caballo, el caballo quedaba cojo; el caballo quedó cojo; el informe no fue entregado; el informe no se entregó: perdimos la guerra. Solo que aquí el conteo es en segundos desde que surge el problema hasta la etapa de degradación que comienzan a sentir los servicios. Esto significa que es posible que los usuarios se estén perdiendo algo en alguna parte.
Hay dos soluciones clásicas que se complementan. El primero son los servicios que intentan poner pajitas y resolver el problema de esta manera: “Modifiquemos algo en la pila TCP. Hagamos tiempos de espera a nivel de aplicación o sesiones TCP de larga duración con controles de estado internos”. El problema es que tales soluciones: a) no escalan en absoluto; b) están muy mal controlados. Es decir, incluso si el servicio configura accidentalmente la pila TCP de una manera que la mejore, en primer lugar, es poco probable que sea aplicable a todas las aplicaciones y a todos los centros de datos y, en segundo lugar, lo más probable es que no comprenda lo que se hizo. correctamente y qué no. Es decir, funciona, pero funciona mal y no escala. Y si hay un problema en la red, ¿quién tiene la culpa? Por supuesto, NOC. ¿Qué hace NOC?
Muchos servicios creen que en el trabajo de los NOC ocurre algo como esto. Pero para ser honesto, no sólo eso.
NOC en el esquema clásico se dedica al desarrollo de muchos sistemas de monitoreo. Se trata de monitorización tanto de caja negra como de caja blanca. Acerca de un ejemplo de monitoreo de lomo de caja negra Alexander Klimenko en el último Next Hop. Por cierto, este seguimiento funciona. Pero incluso el seguimiento ideal tendrá un retraso. Generalmente esto es unos minutos. Después de que se activa, los ingenieros de servicio necesitan tiempo para volver a verificar su funcionamiento, localizar el problema y luego extinguir el área problemática. Es decir, en el mejor de los casos, tratar el problema lleva 5 minutos, en el peor de los casos, 20 minutos, si no es inmediatamente evidente dónde se producen las pérdidas. Está claro que durante todo este tiempo (5 o 20 minutos) nuestros servicios seguirán sufriendo, lo que probablemente no sea bueno.
¿Qué te gustaría realmente recibir? Tenemos tantas maneras. Y los problemas surgen precisamente porque los flujos TCP que tienen mala suerte siguen utilizando la misma ruta. Necesitamos algo que nos permita utilizar múltiples rutas dentro de una única conexión TCP. Parecería que tenemos una solución. Existe TCP, que se llama TCP multiruta, es decir, TCP para múltiples rutas. Es cierto que fue desarrollado para una tarea completamente diferente: para teléfonos inteligentes que tienen varios dispositivos de red. Para maximizar la transferencia o hacer modo primario/de respaldo, se desarrolló un mecanismo que crea múltiples subprocesos (sesiones) de forma transparente para la aplicación y le permite cambiar entre ellos en caso de falla. O, como dije, maximizar la racha.
Pero aquí hay un matiz. Para entender qué es, tendremos que observar cómo se establecen los hilos.
Los hilos se instalan secuencialmente. El primer hilo se instala primero. Luego, los subprocesos posteriores se configuran utilizando la cookie que ya se acordó dentro de ese subproceso. Y aquí está el problema.
El problema es que si el primer hilo no se establece, el segundo y tercer hilo nunca surgirán. Es decir, TCP multiruta no soluciona la pérdida de un paquete SYN en el primer flujo. Y si se pierde el SYN, el TCP multiruta se convierte en TCP normal. Esto significa que en un entorno de centro de datos no nos ayudará a resolver el problema de las pérdidas en fábrica y aprender a utilizar múltiples rutas en caso de fallo.
¿Qué puede ayudarnos? Algunos de ustedes ya habrán adivinado por el título que un campo importante en nuestra historia adicional será el campo del encabezado de la etiqueta de flujo IPv6. Efectivamente este es un campo que aparece en la v6, no está en la v4, ocupa 20 bits y existe controversia sobre su uso desde hace mucho tiempo. Esto es muy interesante: hubo disputas, algo se solucionó dentro del RFC y, al mismo tiempo, apareció una implementación en el kernel de Linux, que no estaba documentada en ninguna parte.
Te invito a que me acompañes en una pequeña investigación. Echemos un vistazo a lo que ha estado sucediendo en el kernel de Linux en los últimos años.
año 2014. Un ingeniero de una empresa grande y respetada agrega a la funcionalidad del kernel de Linux la dependencia del valor de la etiqueta de flujo del hash del socket. ¿Qué estaban tratando de arreglar aquí? Esto está relacionado con el RFC 6438, que analizó el siguiente tema. Dentro del centro de datos, IPv4 a menudo está encapsulado en paquetes IPv6, porque la fábrica en sí es IPv6, pero IPv4 de alguna manera debe entregarse afuera. Durante mucho tiempo hubo problemas con los conmutadores que no podían buscar debajo de dos encabezados de IP para llegar a TCP o UDP y encontrar src_ports, dst_ports allí. Resultó que el hash, si nos fijamos en los dos primeros encabezados de IP, resultó estar casi arreglado. Para evitarlo y que el balanceo de este tráfico encapsulado funcione correctamente, se propuso añadir el hash del paquete encapsulado de 5 tuplas al valor del campo etiqueta de flujo. Se hizo aproximadamente lo mismo para otros esquemas de encapsulación, para UDP, para GRE, este último utilizó el campo Clave GRE. De una forma u otra, los objetivos aquí son claros. Y al menos en ese momento fueron útiles.
En 2015, llega un nuevo parche del mismo respetado ingeniero. Él es muy interesante. Dice lo siguiente: aleatorizaremos el hash en caso de un evento de enrutamiento negativo. ¿Qué es un evento de enrutamiento negativo? Este es el RTO que comentamos anteriormente, es decir, la pérdida de la cola de la ventana es un evento verdaderamente negativo. Es cierto que es relativamente difícil adivinar que esto es todo.
2016, otra empresa de renombre, también grande. Desmonta las últimas muletas y hace que el hash, que anteriormente hicimos aleatorio, ahora cambie para cada retransmisión SYN y después de cada tiempo de espera de RTO. Y en esta carta, por primera y última vez, se declara el objetivo final: garantizar que el tráfico, en caso de pérdidas o congestión del canal, tenga la capacidad de redirigirse suavemente y utilizar múltiples rutas. Por supuesto, después de esto hubo muchas publicaciones, puedes encontrarlas fácilmente.
Aunque no, no se puede, porque no ha habido ni una sola publicación sobre este tema. ¡Pero lo sabemos!
Y si no entiendes completamente lo que se hizo, te lo diré ahora.
¿Qué se hizo, qué funcionalidad se agregó al kernel de Linux? txhash cambia a un valor aleatorio después de cada evento RTO. Este es el resultado muy negativo del enrutamiento. El hash depende de este txhash y la etiqueta de flujo depende del hash skb. Aquí hay algunos cálculos sobre funciones; todos los detalles no se pueden colocar en una sola diapositiva. Si alguien tiene curiosidad, puede revisar el código del kernel y comprobarlo.
¿Qué es importante aquí? El valor del campo de etiqueta de flujo cambia a un número aleatorio después de cada RTO. ¿Cómo afecta esto a nuestro desafortunado flujo TCP?
Si ocurre un SACK, nada cambia porque estamos intentando reenviar un paquete perdido conocido. Hasta ahora, todo bien.
Pero en el caso de RTO, siempre que hayamos agregado una etiqueta de flujo a la función hash en ToR, el tráfico puede tomar una ruta diferente. Y cuantos más carriles, mayores serán las posibilidades de que encuentre un camino que no se vea afectado por una falla en un dispositivo en particular.
Queda un problema: el RTO. Por supuesto, hay otra ruta, pero se pierde mucho tiempo en ella. 200 ms es mucho. Un segundo es absolutamente salvaje. Anteriormente hablé de los tiempos de espera que tienen los servicios configurados. Entonces, el segundo es un tiempo de espera, que generalmente lo configura el servicio a nivel de aplicación, y en esto el servicio incluso tendrá relativamente razón. Además, repito, el RTT real dentro de un centro de datos moderno es de alrededor de 1 milisegundo.
¿Qué se puede hacer con los tiempos de espera de RTO? El tiempo de espera responsable del RTO en caso de pérdida de paquetes de datos se puede configurar con relativa facilidad desde el espacio del usuario: existe una utilidad IP y uno de sus parámetros contiene el mismo rto_min. Teniendo en cuenta que el RTO, por supuesto, no debe ajustarse globalmente, sino para determinados prefijos, dicho mecanismo parece bastante viable.
Es cierto que con SYN_RTO todo es algo peor. Está naturalmente clavado. El kernel tiene un valor fijo de 1 segundo y listo. No puedes llegar allí desde el espacio del usuario. Solo hay una manera.
eBPF viene al rescate. En pocas palabras, estos son pequeños programas en C. Se pueden insertar en ganchos en diferentes lugares durante la ejecución de la pila del kernel y la pila TCP, con los que se pueden cambiar una gran cantidad de configuraciones. En general, eBPF es una tendencia a largo plazo. En lugar de eliminar docenas de nuevos parámetros sysctl y expandir la utilidad IP, el movimiento avanza hacia eBPF y expande su funcionalidad. Con eBPF, puede cambiar dinámicamente los controles de congestión y otras configuraciones de TCP.
Pero es importante para nosotros que se pueda utilizar para cambiar los valores de SYN_RTO. Además, hay un ejemplo publicado públicamente: . ¿Qué se ha hecho aquí? El ejemplo funciona, pero en sí mismo es muy aproximado. Aquí se supone que dentro del centro de datos comparamos los primeros 44 bits; si coinciden, entonces estamos dentro del centro de datos. Y en este caso cambiamos el valor del tiempo de espera de SYN_RTO a 4 ms. La misma tarea se puede realizar de forma mucho más elegante. Pero este sencillo ejemplo muestra que esto es a) posible; b) relativamente simple.
¿Qué sabemos ya? El hecho de que la arquitectura del plano permita el escalado resulta extremadamente útil para nosotros cuando habilitamos la etiqueta de flujo en ToR y obtenemos la capacidad de fluir alrededor de áreas problemáticas. La mejor manera de reducir los valores de RTO y SYN-RTO es utilizar programas eBPF. La pregunta sigue siendo: ¿es seguro utilizar una etiqueta de flujo para equilibrar? Y aquí hay un matiz.
Suponga que tiene un servicio en su red que reside en anycast. Desafortunadamente, no tengo tiempo para entrar en detalles sobre qué es Anycast, pero es un servicio distribuido con diferentes servidores físicos accesibles a través de la misma dirección IP. Y aquí hay un posible problema: el evento RTO puede ocurrir no solo cuando el tráfico pasa a través de la estructura. También puede ocurrir en el nivel del buffer ToR: cuando ocurre un evento de transmisión, incluso puede ocurrir en el host cuando el host derrama algo. Cuando ocurre un evento RTO y cambia la etiqueta de flujo. En este caso, el tráfico puede ir a otra instancia de anycast. Supongamos que se trata de un anycast con estado, que contiene un estado de conexión; podría ser un equilibrador L3 o algún otro servicio. Entonces surge un problema, porque después de RTO la conexión TCP llega al servidor, que no sabe nada sobre esta conexión TCP. Y si no compartimos el estado entre los servidores anycast, dicho tráfico se eliminará y la conexión TCP se interrumpirá.
¿Qué puedes hacer aquí? Dentro de su entorno controlado, donde habilita el equilibrio de etiquetas de flujo, debe registrar el valor de la etiqueta de flujo al acceder a servidores Anycast. La forma más sencilla es hacerlo a través del mismo programa eBPF. Pero aquí hay un punto muy importante: ¿qué hacer si no opera una red de centro de datos, pero es un operador de telecomunicaciones? Este también es su problema: a partir de ciertas versiones de Juniper y Arista, incluyen una etiqueta de flujo en sus funciones hash de forma predeterminada; francamente, por una razón que no me queda clara. Esto puede provocar que se pierdan las conexiones TCP de los usuarios que pasan por su red. Por lo tanto, recomiendo verificar la configuración de su enrutador aquí.
De una forma u otra, me parece que estamos listos para pasar a los experimentos.
Cuando habilitamos la etiqueta de flujo en ToR, preparamos el agente eBPF, que ahora vive en los hosts, decidimos no esperar al próximo gran fallo, sino realizar explosiones controladas. Tomamos ToR, que tiene cuatro enlaces ascendentes, y configuramos caídas en uno de ellos. Dibujaron una regla y dijeron: ahora estás perdiendo todos los paquetes. Como podéis ver a la izquierda, tenemos la monitorización por paquete, que ha bajado al 75%, es decir, se pierde el 25% de los paquetes. A la derecha se encuentran los gráficos de los servicios que se encuentran detrás de estos TdR. Básicamente, se trata de gráficos de tráfico de las interfaces con los servidores dentro del rack. Como puede ver, se hundieron aún más. ¿Por qué cayeron más abajo, no un 25%, sino en algunos casos entre 3 y 4 veces? Si la conexión TCP no tiene suerte, continúa intentando llegar a través del cruce roto. Esto se ve agravado por el comportamiento típico del servicio dentro del DC: para una solicitud de usuario, se generan N solicitudes a servicios internos y la respuesta irá al usuario cuando todas las fuentes de datos respondan o cuando se agote el tiempo de espera en la aplicación. nivel, que aún necesita ser configurado. Es decir, todo está muy, muy mal.
Ahora el mismo experimento, pero con el valor de etiqueta de flujo habilitado. Como puede ver, a la izquierda nuestro monitoreo de lotes cayó en el mismo 25%. Esto es absolutamente correcto, porque no sabe nada sobre retransmisiones, envía paquetes y simplemente cuenta la proporción entre el número de paquetes entregados y perdidos.
Y a la derecha está el horario de servicio. Aquí no encontrará el efecto de una articulación problemática. En esos mismos milisegundos, el tráfico fluyó desde el área del problema a los tres enlaces ascendentes restantes que no se vieron afectados por el problema. Tenemos una red que se cura sola.
Esta es mi última diapositiva, es hora de resumir. Ahora espero que sepas cómo construir una red de centro de datos autorreparable. No necesitarás revisar el archivo del kernel de Linux y buscar parches especiales allí; sabes que la etiqueta Flow en este caso resuelve el problema, pero debes abordar este mecanismo con cuidado. Y enfatizo una vez más que si es un operador de telecomunicaciones, no debe usar la etiqueta de flujo como función hash, de lo contrario interrumpirá las sesiones de sus usuarios.
Los ingenieros de redes deben realizar un cambio conceptual: la red comienza no con los TdR, no con el dispositivo de red, sino con el host. Un ejemplo bastante sorprendente es cómo usamos eBPF tanto para cambiar el RTO como para corregir la etiqueta de flujo hacia los servicios anycast.
Los mecanismos de etiquetas de flujo son ciertamente adecuados para otras aplicaciones dentro del segmento administrativo controlado. Puede ser tráfico entre centros de datos o puede utilizar dichos mecanismos de una manera especial para gestionar el tráfico saliente. Pero espero que te lo cuente la próxima vez. Muchas gracias por su atención.
Fuente: habr.com