Hemos desarrollado un diseño de red de centro de datos que permite el despliegue de clústeres informáticos de más de 100 mil servidores con un ancho de banda de bisección máximo de más de un petabyte por segundo.
En el informe de Dmitry Afanasyev aprenderá sobre los principios básicos del nuevo diseño, las topologías de escalado, los problemas que surgen con esto, las opciones para resolverlos, las características de enrutamiento y escalado de las funciones del plano de reenvío de los dispositivos de red modernos en "densamente conectados". topologías con una gran cantidad de rutas ECMP. Además, Dima habló brevemente sobre la organización de la conectividad externa, la capa física, el sistema de cableado y las formas de aumentar aún más la capacidad.
- ¡Buenas tardes a todos! Mi nombre es Dmitry Afanasyev, soy arquitecto de redes en Yandex y principalmente diseño redes de centros de datos.
Mi historia será sobre la red actualizada de centros de datos de Yandex. Es en gran medida una evolución del diseño que teníamos, pero al mismo tiempo hay algunos elementos nuevos. Esta es una presentación general porque había mucha información que debía agruparse en poco tiempo. Comenzaremos eligiendo una topología lógica. Luego habrá una descripción general del plano de control y los problemas con la escalabilidad del plano de datos, una elección de lo que sucederá a nivel físico y veremos algunas características de los dispositivos. Toquemos un poco lo que ocurre en un centro de datos con MPLS, del que hablamos hace un tiempo.
Entonces, ¿qué es Yandex en términos de carga y servicios? Yandex es un hiperescalador típico. Si miramos a los usuarios, procesamos principalmente las solicitudes de los usuarios. También diversos servicios de streaming y transferencia de datos, porque también contamos con servicios de almacenamiento. Si está más cerca del backend, allí aparecen cargas y servicios de infraestructura, como almacenamiento de objetos distribuidos, replicación de datos y, por supuesto, colas persistentes. Uno de los principales tipos de cargas de trabajo es MapReduce y sistemas similares, procesamiento de flujo, aprendizaje automático, etc.
¿Cómo está la infraestructura sobre la que sucede todo esto? Nuevamente, somos un hiperescalador bastante típico, aunque quizás estemos un poco más cerca del lado del hiperescalador menor del espectro. Pero tenemos todos los atributos. Utilizamos hardware básico y escalamiento horizontal siempre que sea posible. Tenemos un conjunto completo de recursos: no trabajamos con máquinas individuales, bastidores individuales, sino que los combinamos en un gran conjunto de recursos intercambiables con algunos servicios adicionales que se ocupan de la planificación y la asignación, y trabajamos con todo este conjunto.
Así que tenemos el siguiente nivel: el sistema operativo en el nivel del clúster informático. Es muy importante que controlemos completamente la pila de tecnología que utilizamos. Controlamos los endpoints (hosts), la red y la pila de software.
Disponemos de varios centros de datos grandes en Rusia y en el extranjero. Están unidos por una columna vertebral que utiliza tecnología MPLS. Nuestra infraestructura interna está construida casi en su totalidad sobre IPv6, pero dado que necesitamos atender el tráfico externo que todavía llega principalmente a través de IPv4, de alguna manera debemos entregar las solicitudes que llegan a través de IPv4 a los servidores frontend, y un poco más ir a IPv4 externo (Internet) para por ejemplo, para indexar.
Las últimas iteraciones de diseños de redes de centros de datos han utilizado topologías Clos multicapa y son solo L3. Dejamos la L2 hace un rato y respiramos aliviados. Finalmente, nuestra infraestructura incluye cientos de miles de instancias informáticas (servidores). El tamaño máximo del clúster hace algún tiempo era de unos 10 mil servidores. Esto se debe en gran medida a cómo pueden funcionar esos mismos sistemas operativos, programadores, asignación de recursos, etc. Tenemos una tarea: poder construir fábricas de redes que permitan la agrupación eficiente de recursos en dicho clúster.
¿Qué queremos de una red de centro de datos? En primer lugar, hay mucho ancho de banda barato y distribuido de manera bastante uniforme. Porque la red es la columna vertebral a través de la cual podemos agrupar recursos. El nuevo tamaño objetivo es de unos 100 servidores en un clúster.
Por supuesto, también queremos un plano de control escalable y estable, porque en una infraestructura tan grande surgen muchos dolores de cabeza incluso por eventos simplemente aleatorios, y no queremos que el plano de control también nos traiga dolores de cabeza. Al mismo tiempo, queremos minimizar el estado que contiene. Cuanto menor sea la afección, mejor y más estable funcionará todo y más fácil será de diagnosticar.
Por supuesto, necesitamos automatización, porque es imposible gestionar una infraestructura de este tipo manualmente, y lo ha sido desde hace algún tiempo. Necesitamos apoyo operativo tanto como sea posible y apoyo de CI/CD en la medida que sea posible.
Con tales tamaños de centros de datos y clústeres, la tarea de respaldar la implementación y expansión incrementales sin interrupción del servicio se ha vuelto bastante crítica. Si en grupos de un tamaño de mil máquinas, tal vez cerca de diez mil máquinas, aún pudieran implementarse como una sola operación, es decir, estamos planeando una expansión de la infraestructura, y se agregan varios miles de máquinas como una sola operación, entonces un cluster de un tamaño de cien mil máquinas no surge inmediatamente, sino que se construye a lo largo de un período de tiempo. Y es deseable que durante todo este tiempo esté disponible lo que ya se ha bombeado, la infraestructura que se ha desplegado.
Y un requisito que teníamos y dejamos: soporte para multitenancy, es decir, virtualización o segmentación de red. Ahora no necesitamos hacer esto a nivel de estructura de red, porque la fragmentación ha ido a los hosts y esto nos ha facilitado mucho el escalado. Gracias a IPv6 y al gran espacio de direcciones, no necesitábamos utilizar direcciones duplicadas en la infraestructura interna; todas las direcciones ya eran únicas. Y gracias a que hemos llevado el filtrado y la segmentación de red a los hosts, no necesitamos crear ninguna entidad de red virtual en las redes del centro de datos.
Una cosa muy importante es lo que no necesitamos. Si algunas funciones se pueden eliminar de la red, esto hace la vida mucho más fácil y, por regla general, amplía la elección de equipos y software disponibles, lo que simplifica mucho el diagnóstico.
Entonces, ¿qué es lo que no necesitamos, a qué hemos podido renunciar, no siempre con alegría en el momento en que sucedió, pero con gran alivio cuando el proceso se completa?
En primer lugar, abandonar la L2. No necesitamos L2, ni real ni emulada. No utilizado en gran parte debido al hecho de que controlamos la pila de aplicaciones. Nuestras aplicaciones son escalables horizontalmente, funcionan con direccionamiento L3, no les preocupa mucho que se haya apagado alguna instancia individual, simplemente implementan una nueva, no es necesario implementarla en la dirección anterior, porque hay una Nivel separado de descubrimiento de servicios y monitoreo de máquinas ubicadas en el clúster. No delegamos esta tarea a la red. El trabajo de la red es entregar paquetes desde el punto A al punto B.
Tampoco tenemos situaciones en las que las direcciones se muevan dentro de la red y esto debe ser monitoreado. En muchos diseños, esto suele ser necesario para admitir la movilidad de las máquinas virtuales. No utilizamos la movilidad de las máquinas virtuales en la infraestructura interna del gran Yandex y, además, creemos que incluso si esto se hiciera, no debería suceder con el soporte de red. Si realmente es necesario hacerlo, debe hacerse a nivel de host y enviar direcciones que puedan migrar a superposiciones, para no tocar ni realizar demasiados cambios dinámicos en el sistema de enrutamiento de la propia capa subyacente (red de transporte). .
Otra tecnología que no utilizamos es la multidifusión. Si quieres te puedo contar en detalle por qué. Esto hace la vida mucho más fácil, porque si alguien se ha ocupado de ello y ha observado exactamente cómo se ve el plano de control de multidifusión, en todas las instalaciones excepto en las más simples, esto es un gran dolor de cabeza. Y lo que es más, es difícil encontrar una implementación de código abierto que funcione bien, por ejemplo.
Finalmente, diseñamos nuestras redes para que no cambien demasiado. Podemos contar con el hecho de que el flujo de eventos externos en el sistema de enrutamiento es pequeño.
¿Qué problemas surgen y qué restricciones hay que tener en cuenta cuando desarrollamos una red de centro de datos? Costo, por supuesto. Escalabilidad, el nivel al que queremos crecer. La necesidad de ampliar sin parar el servicio. Ancho de banda, disponibilidad. Visibilidad de lo que sucede en la red para los sistemas de monitoreo, para los equipos operativos. Soporte de automatización: nuevamente, tanto como sea posible, ya que se pueden resolver diferentes tareas en diferentes niveles, incluida la introducción de capas adicionales. Bueno, [posiblemente] no depender de los proveedores. Aunque en diferentes periodos históricos, según en qué apartado se mire, esta independencia fue más fácil o más difícil de conseguir. Si tomamos una muestra representativa de los chips de dispositivos de red, hasta hace poco era muy condicional hablar de independencia de los proveedores, si también queríamos chips con un alto rendimiento.
¿Qué topología lógica usaremos para construir nuestra red? Este será un Clos de varios niveles. De hecho, por el momento no existen alternativas reales. Y la topología Clos es bastante buena, incluso en comparación con varias topologías avanzadas que ahora están más en el área de interés académico, si tenemos conmutadores de base grandes.
¿Cómo se estructura a grandes rasgos una red Clos multinivel y cómo se denominan en ella los distintos elementos? En primer lugar se levantó el viento, para orientarse dónde está el norte, dónde está el sur, dónde está el este, dónde está el oeste. Las redes de este tipo suelen ser construidas por quienes tienen un tráfico muy grande de oeste a este. En cuanto al resto de elementos, en la parte superior se encuentra un conmutador virtual ensamblado a partir de conmutadores más pequeños. Ésta es la idea principal de la construcción recursiva de redes Clos. Tomamos elementos con algún tipo de base y los conectamos para que lo que obtengamos pueda considerarse como un interruptor con una base más grande. Si necesita aún más, se puede repetir el procedimiento.
En los casos, por ejemplo, con Clos de dos niveles, cuando es posible identificar claramente los componentes que son verticales en mi diagrama, generalmente se los llama planos. Si tuviéramos que construir un Clos con tres niveles de interruptores de columna (todos los cuales no son interruptores de límite o ToR y se usan solo para tránsito), entonces los planos parecerían más complejos; los de dos niveles se verían exactamente así. Llamamos Pod a un bloque de ToR o interruptores de hoja y a los interruptores de columna de primer nivel asociados con ellos. Los interruptores de la columna vertebral del nivel de la columna vertebral 1 en la parte superior del Pod son la parte superior del Pod, la parte superior del Pod. Los interruptores que se encuentran en la parte superior de toda la fábrica son la capa superior de la fábrica, la parte superior de la tela.
Por supuesto, surge la pregunta: las redes Clos se construyen desde hace algún tiempo; la idea en sí proviene generalmente de los tiempos de la telefonía clásica, las redes TDM. ¿Quizás ha aparecido algo mejor, quizás se pueda hacer algo mejor? Si y no. En teoría sí, en la práctica, en un futuro próximo, definitivamente no. Debido a que existen varias topologías interesantes, algunas de ellas incluso se utilizan en producción; por ejemplo, Dragonfly se utiliza en aplicaciones HPC; También existen topologías interesantes como Xpander, FatClique, Jellyfish. Si observa informes recientes en conferencias como SIGCOMM o NSDI, puede encontrar una cantidad bastante grande de trabajos sobre topologías alternativas que tienen mejores propiedades (una u otra) que Clos.
Pero todas estas topologías tienen una propiedad interesante. Impide su implementación en redes de centros de datos, que estamos tratando de construir sobre hardware básico y que cuestan dinero bastante razonable. En todas estas topologías alternativas, lamentablemente no se puede acceder a la mayor parte del ancho de banda a través de los caminos más cortos. Por tanto, inmediatamente perdemos la oportunidad de utilizar el plano de control tradicional.
Teóricamente, se conoce la solución al problema. Estas son, por ejemplo, modificaciones del estado del enlace utilizando la ruta más corta k, pero, nuevamente, no existen protocolos de este tipo que se implementarían en producción y estarían ampliamente disponibles en los equipos.
Además, dado que no se puede acceder a la mayor parte de la capacidad a través de los caminos más cortos, necesitamos modificar algo más que el plano de control para seleccionar todos esos caminos (y, por cierto, esto es significativamente más estado en el plano de control). Todavía necesitamos modificar el plano de avance y, como regla general, se requieren al menos dos características adicionales. Esta es la capacidad de tomar todas las decisiones sobre el reenvío de paquetes una sola vez, por ejemplo, en el host. De hecho, esto es enrutamiento de origen; a veces en la literatura sobre redes de interconexión esto se denomina decisiones de reenvío todo a la vez. Y el enrutamiento adaptativo es una función que necesitamos en los elementos de la red, lo que se reduce, por ejemplo, al hecho de que seleccionamos el siguiente salto en función de la información sobre la menor carga en la cola. Por ejemplo, son posibles otras opciones.
Por tanto, la dirección es interesante, pero lamentablemente no podemos aplicarla en este momento.
Bien, nos decidimos por la topología lógica de Clos. ¿Cómo lo escalaremos? Veamos cómo funciona y qué se puede hacer.
En una red Clos hay dos parámetros principales que de alguna manera podemos variar y obtener resultados ciertos: la base de elementos y el número de niveles en la red. Tengo un diagrama esquemático de cómo ambos afectan el tamaño. Lo ideal es combinar ambos.
Se puede ver que el ancho final de la red Clos es el producto de todos los niveles de interruptores espinales de la base sur, cuántos enlaces tenemos hacia abajo, cómo se ramifica. Así es como escalamos el tamaño de la red.
En cuanto a la capacidad, especialmente en los conmutadores ToR, existen dos opciones de escalamiento. O podemos, manteniendo la topología general, utilizar enlaces más rápidos, o podemos agregar más planos.
Si miras la versión ampliada de la red Clos (en la esquina inferior derecha) y vuelves a esta imagen con la red Clos a continuación...
... entonces esta es exactamente la misma topología, pero en esta diapositiva está colapsada de manera más compacta y los planos de la fábrica se superponen entre sí. Es lo mismo.
¿Cómo es escalar una red Clos en números? Aquí proporciono datos sobre qué ancho máximo se puede obtener una red, qué número máximo de racks, conmutadores ToR o conmutadores de hoja, si no están en bastidores, podemos obtener dependiendo de qué base de conmutadores utilizamos para los niveles de columna, y ¿Cuántos niveles usamos?
He aquí cuántos racks podemos tener, cuántos servidores y aproximadamente cuánto puede consumir todo esto en base a 20 kW por rack. Un poco antes mencioné que nuestro objetivo es un tamaño de clúster de unos 100 servidores.
Se puede observar que en todo este diseño interesan dos opciones y media. Existe una opción con dos capas de espinas y conmutadores de 64 puertos, que se queda un poco corta. Luego están las opciones perfectas para interruptores de columna de 128 puertos (con base 128) con dos niveles, o interruptores con base 32 con tres niveles. Y en todos los casos, donde hay más raíces y más capas, se puede crear una red muy grande, pero si nos fijamos en el consumo esperado, normalmente hay gigavatios. Es posible tender un cable, pero es poco probable que consigamos tanta electricidad en un solo sitio. Si nos fijamos en las estadísticas y los datos públicos sobre los centros de datos, podemos encontrar muy pocos centros de datos con una capacidad estimada de más de 150 MW. Los más grandes suelen ser campus de centros de datos, varios centros de datos grandes ubicados bastante cerca unos de otros.
Hay otro parámetro importante. Si observa la columna de la izquierda, el ancho de banda utilizable aparece allí. Es fácil ver que en una red Clos una parte importante de los puertos se utilizan para conectar conmutadores entre sí. El ancho de banda utilizable, una franja útil, es algo que se puede dar fuera, hacia los servidores. Naturalmente, me refiero a puertos condicionales y específicamente a la banda. Como regla general, los enlaces dentro de la red son más rápidos que los enlaces hacia los servidores, pero por unidad de ancho de banda, por mucho que podamos enviarlo a nuestro equipo de servidor, todavía hay algo de ancho de banda dentro de la propia red. Y cuantos más niveles hagamos, mayor será el coste específico de dotar de esta franja al exterior.
Además, incluso esta banda adicional no es exactamente la misma. Si bien los tramos son cortos, podemos usar algo como DAC (cobre de conexión directa, es decir, cables twinax) u ópticas multimodo, que cuestan un dinero aún más o menos razonable. Tan pronto como pasamos a tramos más largos, por regla general, se trata de ópticas monomodo y el coste de este ancho de banda adicional aumenta notablemente.
Y nuevamente, volviendo a la diapositiva anterior, si creamos una red Clos sin sobresuscripción, entonces es fácil mirar el diagrama, ver cómo se construye la red: agregando cada nivel de interruptores de columna, repetimos toda la tira que estaba en el abajo. Nivel Plus: más la misma banda, la misma cantidad de puertos en los conmutadores que había en el nivel anterior y la misma cantidad de transceptores. Por lo tanto, es muy deseable minimizar el número de niveles de interruptores de columna.
Según esta imagen, está claro que realmente queremos construir sobre algo como interruptores con una base de 128.
Aquí, en principio, todo es igual a lo que acabo de decir, esta es una diapositiva para considerar más adelante.
¿Qué opciones hay que podemos elegir como tales interruptores? Es una noticia muy agradable para nosotros que ahora estas redes finalmente puedan construirse en conmutadores de un solo chip. Y esto es genial, tienen muchas características interesantes. Por ejemplo, casi no tienen estructura interna. Esto significa que se rompen más fácilmente. Se rompen de muchas maneras, pero afortunadamente se rompen por completo. En los dispositivos modulares hay una gran cantidad de fallas (muy desagradables), cuando desde el punto de vista de los vecinos y del plano de control parece estar funcionando, pero, por ejemplo, se ha perdido parte de la tela y no funciona. a plena capacidad. Y el tráfico hacia él se equilibra basándose en el hecho de que es completamente funcional y podemos sobrecargarnos.
O, por ejemplo, surgen problemas con la placa posterior, porque dentro del dispositivo modular también hay SerDes de alta velocidad; el interior es realmente complejo. O las señales entre elementos de reenvío están sincronizadas o no. En general, cualquier dispositivo modular productivo que consta de una gran cantidad de elementos, por regla general, contiene la misma red Clos en su interior, pero es muy difícil de diagnosticar. A menudo es difícil incluso para el propio vendedor realizar un diagnóstico.
Y tiene una gran cantidad de escenarios de falla en los que el dispositivo se degrada, pero no sale completamente de la topología. Dado que nuestra red es grande, se utiliza activamente el equilibrio entre elementos idénticos, la red es muy regular, es decir, un camino en el que todo está en orden no se diferencia del otro, es más rentable para nosotros simplemente perder parte de los dispositivos de la topología que terminar en una situación en la que algunos de ellos parecen funcionar, pero otros no.
La siguiente característica interesante de los dispositivos de un solo chip es que evolucionan mejor y más rápido. También suelen tener mejor capacidad. Si tomamos las grandes estructuras ensambladas que tenemos en un círculo, entonces la capacidad por unidad de rack para puertos de la misma velocidad es casi el doble que la de los dispositivos modulares. Los dispositivos construidos alrededor de un solo chip son notablemente más baratos que los modulares y consumen menos energía.
Pero, por supuesto, todo esto no se debe a nada, también hay desventajas. En primer lugar, la base es casi siempre más pequeña que la de los dispositivos modulares. Si podemos conseguir un dispositivo construido alrededor de un chip con 128 puertos, entonces podemos conseguir uno modular con varios cientos de puertos ahora sin ningún problema.
Se trata de un tamaño notablemente menor de las tablas de reenvío y, por regla general, de todo lo relacionado con la escalabilidad del plano de datos. Zonas de amortiguamiento poco profundas. Y, por regla general, una funcionalidad bastante limitada. Pero resulta que si conoces estas restricciones y te preocupas de eludirlas a tiempo o simplemente tenerlas en cuenta, entonces esto no da tanto miedo. El hecho de que la base sea más pequeña ya no es un problema en los dispositivos con una base de 128 que finalmente han aparecido recientemente; podemos construir dos capas de espinas. Pero todavía es imposible construir algo más pequeño que dos que sea interesante para nosotros. Con un nivel se obtienen racimos muy pequeños. Incluso nuestros diseños y requisitos anteriores los superaban.
De hecho, si de repente la solución está al borde del abismo, todavía hay una manera de ampliarla. Dado que el último (o primer) nivel más bajo donde se conectan los servidores son los conmutadores ToR o los conmutadores de hoja, no es necesario que les conectemos un bastidor. Por lo tanto, si la solución se queda corta a la mitad, puede pensar en simplemente usar un interruptor con una base grande en el nivel inferior y conectar, por ejemplo, dos o tres bastidores en un solo interruptor. Esta también es una opción, tiene sus costes, pero funciona bastante bien y puede ser una buena solución cuando necesitas alcanzar aproximadamente el doble de tamaño.
En resumen, estamos construyendo sobre una topología con dos niveles de columnas, con ocho capas de fábrica.
¿Qué pasará con la física? Cálculos muy simples. Si tenemos dos niveles de espinas, entonces solo tenemos tres niveles de conmutadores, y esperamos que haya tres segmentos de cable en la red: desde los servidores hasta los conmutadores de hoja, la columna 1 y la columna 2. Las opciones que podemos Los usos son: twinax, multimodo, monomodo. Y aquí debemos considerar qué tira está disponible, cuánto costará, cuáles son las dimensiones físicas, qué tramos podemos cubrir y cómo actualizaremos.
En términos de coste, todo se puede alinear. Los twinaxes son significativamente más baratos que la óptica activa, más baratos que los transceptores multimodo, si los tomamos por tramo desde el final, algo más baratos que un puerto de conmutador de 100 gigabits. Y tenga en cuenta que cuesta menos que la óptica monomodo, porque en vuelos donde se requiere modo monomodo, en los centros de datos, por varias razones, tiene sentido usar CWDM, mientras que el modo monomodo paralelo (PSM) no es muy conveniente para trabajar. Con ello se obtienen paquetes de fibras muy grandes, y si nos centramos en estas tecnologías, obtenemos aproximadamente la siguiente jerarquía de precios.
Una nota más: desafortunadamente, no es muy posible utilizar puertos multimodo de 100 a 4x25 desmontados. Debido a las características de diseño de los transceptores SFP28, no es mucho más económico que el QSFP28 de 100 Gbit. Y este desmontaje para multimodo no funciona muy bien.
Otra limitación es que, debido al tamaño de los clústeres informáticos y la cantidad de servidores, nuestros centros de datos resultan ser físicamente grandes. Esto significa que al menos un vuelo deberá realizarse con un solo mod. Nuevamente, debido al tamaño físico de los Pods, no será posible ejecutar dos tramos de twinax (cables de cobre).
Como resultado, si optimizamos el precio y tenemos en cuenta la geometría de este diseño, obtenemos un tramo de twinax, un tramo de multimodo y un tramo de monomodo usando CWDM. Esto tiene en cuenta posibles rutas de actualización.
Esto es lo que parece recientemente, hacia dónde nos dirigimos y lo que es posible. Está claro, al menos, cómo avanzar hacia SerDes de 50 Gigabit tanto para multimodo como para monomodo. Además, si observa lo que hay en los transceptores monomodo ahora y en el futuro para 400G, a menudo incluso cuando llegan SerDes de 50G desde el lado eléctrico, 100 Gbps por carril ya pueden ir a la óptica. Por lo tanto, es muy posible que en lugar de pasar a 50, haya una transición a 100 Gigabit SerDes y 100 Gbps por carril, porque según las promesas de muchos proveedores, se espera que estén disponibles bastante pronto. El período en el que los SerDes de 50G fueron los más rápidos, al parecer, no será muy largo, porque las primeras copias de SerDes de 100G se lanzarán casi el próximo año. Y después de un tiempo probablemente valdrán una cantidad razonable de dinero.
Un matiz más sobre la elección de la física. En principio ya podemos utilizar puertos de 400 o 200 Gigabit usando SerDes 50G. Pero resulta que esto no tiene mucho sentido porque, como dije antes, queremos una base bastante grande en los interruptores, dentro de lo razonable, por supuesto. Queremos 128. Y si tenemos una capacidad de chip limitada y aumentamos la velocidad del enlace, entonces la base naturalmente disminuye, no hay milagros.
Y podemos aumentar la capacidad total usando aviones, y no hay costos especiales; podemos agregar la cantidad de aviones. Y si perdemos la base, tendremos que introducir un nivel adicional, por lo que en la situación actual, con la capacidad máxima disponible actual por chip, resulta que es más eficiente usar puertos de 100 gigabits, porque te permiten para obtener una base más grande.
La siguiente pregunta es cómo se organiza la física, pero desde el punto de vista de la infraestructura de cables. Resulta que está organizado de una forma bastante divertida. Cableado entre los interruptores de hoja y las espinas del primer nivel: no hay muchos enlaces allí, todo está construido de manera relativamente simple. Pero si tomamos un plano, lo que sucede adentro es que necesitamos conectar todas las espinas del primer nivel con todas las espinas del segundo nivel.
Además, como regla general, existen algunos deseos sobre cómo debería verse el interior del centro de datos. Por ejemplo, realmente queríamos combinar cables en un paquete y tirarlos de modo que un panel de conexión de alta densidad encajara completamente en un solo panel de conexión, de modo que no hubiera ningún zoológico en términos de longitudes. Logramos resolver este problema. Si observa inicialmente la topología lógica, puede ver que los planos son independientes, cada plano se puede construir por sí solo. Pero cuando agregamos un paquete de este tipo y queremos arrastrar todo el panel de conexión a un panel de conexión, tenemos que mezclar diferentes planos dentro de un paquete e introducir una estructura intermedia en forma de conexiones cruzadas ópticas para volver a empaquetarlos desde cómo fueron ensamblados. en un segmento, en cómo se recolectarán en otro segmento. Gracias a esto, obtenemos una característica interesante: toda la conmutación compleja no va más allá de los bastidores. Cuando es necesario entrelazar algo con mucha fuerza, “desplegar los planos”, como a veces se le llama en las redes Clos, todo se concentra dentro de un estante. No tenemos enlaces altamente desmontados, hasta enlaces individuales, cambiando entre bastidores.
Así es desde el punto de vista de la organización lógica de la infraestructura de cable. En la imagen de la izquierda, los bloques multicolores representan bloques de interruptores de columna de primer nivel, ocho piezas cada uno, y cuatro haces de cables que salen de ellos, que van y se cruzan con los haces que provienen de los bloques de interruptores de columna 2. .
Los cuadrados pequeños indican intersecciones. En la parte superior izquierda hay un desglose de cada una de estas intersecciones; en realidad, se trata de un módulo de conexión cruzada de 512 por 512 puertos que vuelve a empaquetar los cables para que entren completamente en un bastidor, donde solo hay un plano de columna 2. Y a la derecha, un escaneo de esta imagen es un poco más detallado en relación con varios Pods en el nivel de la columna 1, y cómo se empaqueta en una conexión cruzada, cómo llega al nivel de la columna 2.
Esto es lo que parece. El soporte de la columna vertebral 2 aún no completamente ensamblado (a la izquierda) y el soporte de conexión cruzada. Desafortunadamente, no hay mucho que ver allí. Toda esta estructura se está implementando ahora mismo en uno de nuestros grandes centros de datos que se está ampliando. Este es un trabajo en progreso, se verá mejor y se completará mejor.
Una pregunta importante: elegimos la topología lógica y construimos la física. ¿Qué pasará con el avión de control? Es bien sabido por la experiencia operativa que hay varios informes de que los protocolos de estado de enlace son buenos, es un placer trabajar con ellos, pero, desafortunadamente, no se adaptan bien a una topología densamente conectada. Y hay un factor principal que lo impide: así es como funciona la inundación en los protocolos de estado de enlace. Si simplemente toma el algoritmo de inundación y observa cómo está estructurada nuestra red, puede ver que habrá una distribución muy grande en cada paso y simplemente inundará el plano de control con actualizaciones. Específicamente, dichas topologías se mezclan muy mal con el algoritmo de inundación tradicional en los protocolos de estado de enlace.
La opción es utilizar BGP. Cómo prepararlo correctamente se describe en el RFC 7938 sobre el uso de BGP en grandes centros de datos. Las ideas básicas son simples: número mínimo de prefijos por host y, en general, número mínimo de prefijos en la red, utilizar la agregación si es posible y suprimir la búsqueda de rutas. Queremos una distribución de actualizaciones muy cuidadosa y muy controlada, lo que se llama valle libre. Queremos que las actualizaciones se implementen exactamente una vez cuando pasan por la red. Si se originan en la parte inferior, suben, desplegándose no más de una vez. No debe haber zigzags. Los zigzags son muy malos.
Para hacer esto, utilizamos un diseño que es lo suficientemente simple como para utilizar los mecanismos BGP subyacentes. Es decir, utilizamos eBGP que se ejecuta en el enlace local y los sistemas autónomos se asignan de la siguiente manera: un sistema autónomo en ToR, un sistema autónomo en todo el bloque de conmutadores de columna 1 de un Pod y un sistema autónomo general en todo el Top de Tela. No es difícil mirar y ver que incluso el comportamiento normal de BGP nos proporciona la distribución de actualizaciones que queremos.
Naturalmente, el direccionamiento y la agregación de direcciones deben diseñarse de manera que sean compatibles con la forma en que se construye el enrutamiento, de modo que garantice la estabilidad del plano de control. El direccionamiento L3 en el transporte está ligado a la topología, porque sin ella es imposible lograr la agregación; sin esto, las direcciones individuales se infiltrarán en el sistema de enrutamiento. Y una cosa más es que la agregación, desafortunadamente, no combina muy bien con la ruta múltiple, porque cuando tenemos ruta múltiple y agregación, todo está bien, cuando toda la red está sana, no hay fallas en ella. Desafortunadamente, tan pronto como aparecen fallas en la red y se pierde la simetría de la topología, podemos llegar al punto desde el cual se anunció la unidad, desde donde no podemos ir más allá hasta donde necesitamos ir. Por lo tanto, es mejor agregar donde no hay más rutas múltiples; en nuestro caso, se trata de conmutadores ToR.
De hecho, es posible agregar, pero con cuidado. Si podemos hacer una desagregación controlada cuando ocurren fallas en la red. Pero esta es una tarea bastante difícil, incluso nos preguntamos si sería posible hacer esto, si sería posible agregar automatización adicional y máquinas de estados finitos que ejecutarían correctamente BGP para obtener el comportamiento deseado. Desafortunadamente, el procesamiento de casos extremos no es tan obvio y es complejo, y esta tarea no se resuelve bien adjuntando archivos adjuntos externos a BGP.
Se ha realizado un trabajo muy interesante a este respecto en el marco del protocolo RIFT, que se discutirá en el próximo informe.
Otra cosa importante es cómo los planos de datos escalan en topologías densas, donde tenemos una gran cantidad de rutas alternativas. En este caso, se utilizan varias estructuras de datos adicionales: grupos ECMP, que a su vez describen grupos de Next Hop.
En una red funcionando normalmente, sin fallos, cuando subimos a la topología Clos basta con utilizar un solo grupo, porque por defecto viene descrito todo lo que no es local, podemos subir. Cuando vamos de arriba a abajo hacia el sur, entonces no todas las rutas son ECMP, son rutas de ruta única. Todo esta bien. El problema es, y la peculiaridad de la topología clásica de Clos, que si miramos la parte superior de la tela, en cualquier elemento, solo hay un camino hacia cualquier elemento de abajo. Si se producen fallos en este camino, entonces este elemento en particular en la parte superior de la fábrica deja de ser válido precisamente para aquellos prefijos que se encuentran detrás del camino roto. Pero por lo demás es válido y tenemos que analizar los grupos ECMP e introducir un nuevo estado.
¿Cómo se ve la escalabilidad del plano de datos en los dispositivos modernos? Si hacemos LPM (coincidencia de prefijo más largo), todo está bastante bien, más de 100k prefijos. Si hablamos de grupos Next Hop, entonces todo es peor, 2-4 mil. Si estamos hablando de una tabla que contiene una descripción de los próximos saltos (o adyacencias), entonces está entre 16k y 64k. Y esto puede convertirse en un problema. Y aquí llegamos a una interesante digresión: ¿qué pasó con MPLS en los centros de datos? En principio queríamos hacerlo.
Sucedieron dos cosas. Hicimos microsegmentación en los hosts; ya no necesitábamos hacerlo en la red. No fue muy bueno con el soporte de diferentes proveedores, y más aún con implementaciones abiertas en cajas blancas con MPLS. Y MPLS, al menos sus implementaciones tradicionales, desafortunadamente, se combina muy mal con ECMP. Y es por eso.
Así es como se ve la estructura de reenvío ECMP para IP. Una gran cantidad de prefijos pueden usar el mismo grupo y el mismo bloque Next Hops (o adyacencias, esto puede denominarse de manera diferente en diferentes documentos para diferentes dispositivos). El punto es que esto se describe como el puerto de salida y en qué reescribir la dirección MAC para llegar al siguiente salto correcto. Para IP, todo parece simple, puede usar una gran cantidad de prefijos para el mismo grupo, el mismo bloque Next Hops.
La arquitectura MPLS clásica implica que, dependiendo de la interfaz saliente, la etiqueta se puede reescribir con diferentes valores. Por lo tanto, debemos mantener un grupo y un bloque Next Hops para cada etiqueta de entrada. Y esto, por desgracia, no escala.
Es fácil ver que en nuestro diseño necesitábamos alrededor de 4000 conmutadores ToR, el ancho máximo era 64 rutas ECMP, si nos alejamos de la columna 1 hacia la columna 2. Apenas entramos en una tabla de grupos ECMP, si solo desaparece un prefijo con ToR, y no entramos en la tabla Next Hops en absoluto.
No todo es inútil, porque arquitecturas como Segment Routing implican etiquetas globales. Formalmente, sería posible volver a colapsar todos estos bloques de Next Hops. Para hacer esto, necesita una operación de tipo comodín: tomar una etiqueta y reescribirla en la misma sin un valor específico. Pero lamentablemente esto no está muy presente en las implementaciones disponibles.
Y finalmente, necesitamos llevar tráfico externo al centro de datos. ¿Cómo hacerlo? Anteriormente, el tráfico se introducía en la red de Clos desde arriba. Es decir, había enrutadores de borde que se conectaban a todos los dispositivos en la parte superior de la estructura. Esta solución funciona bastante bien en tamaños pequeños y medianos. Desafortunadamente, para enviar tráfico simétricamente a toda la red de esta manera, necesitamos llegar simultáneamente a todos los elementos de la parte superior de la estructura, y cuando hay más de cien, resulta que también necesitamos una gran cantidad. radix en los enrutadores de borde. En general, esto cuesta dinero, porque los enrutadores de borde son más funcionales, los puertos en ellos serán más caros y el diseño no es muy hermoso.
Otra opción es iniciar dicho tráfico desde abajo. Es fácil verificar que la topología Clos está construida de tal manera que el tráfico que viene desde abajo, es decir, desde el lado ToR, se distribuye uniformemente entre los niveles a lo largo de toda la parte superior de la estructura en dos iteraciones, cargando toda la red. Por lo tanto, presentamos un tipo especial de Pod, Edge Pod, que proporciona conectividad externa.
Hay una opción más. Esto es lo que hace Facebook, por ejemplo. Lo llaman Fabric Aggregator o HGRID. Se está introduciendo un nivel de columna adicional para conectar múltiples centros de datos. Este diseño es posible si no tenemos funciones adicionales o cambios de encapsulación en las interfaces. Si son puntos de contacto adicionales, es difícil. Normalmente, hay más funciones y una especie de membrana que separa las diferentes partes del centro de datos. No tiene sentido agrandar dicha membrana, pero si realmente es necesaria por alguna razón, entonces tiene sentido considerar la posibilidad de quitarla, hacerla lo más ancha posible y transferirla a los huéspedes. Esto lo hacen, por ejemplo, muchos operadores de nube. Tienen superposiciones, parten de los anfitriones.
¿Qué oportunidades de desarrollo vemos? En primer lugar, mejorar el soporte para el proceso de CI/CD. Queremos volar como probamos y probar como volamos. Esto no funciona muy bien porque la infraestructura es grande y es imposible duplicarla para las pruebas. Debe comprender cómo introducir elementos de prueba en la infraestructura de producción sin abandonarla.
Una mejor instrumentación y un mejor seguimiento casi nunca son superfluos. Toda la cuestión es un equilibrio entre esfuerzo y retorno. Si puedes agregarlo con un esfuerzo razonable, muy bien.
Sistemas operativos abiertos para dispositivos de red. Mejores protocolos y mejores sistemas de enrutamiento, como RIFT. También se necesita investigación sobre el uso de mejores esquemas de control de la congestión y tal vez la introducción, al menos en algunos puntos, del soporte RDMA dentro del clúster.
Mirando hacia el futuro, necesitamos topologías avanzadas y posiblemente redes que utilicen menos gastos generales. Entre las novedades, recientemente ha habido publicaciones sobre la tecnología de tejido para HPC Cray Slingshot, que se basa en Ethernet básico, pero con la opción de usar encabezados mucho más cortos. Como resultado, se reducen los gastos generales.
Todo debe mantenerse lo más simple posible, pero no más simple. La complejidad es enemiga de la escalabilidad. La simplicidad y las estructuras regulares son nuestras amigas. Si puedes escalar en algún lugar, hazlo. Y, en general, es fantástico estar involucrado ahora en tecnologías de red. Están sucediendo muchas cosas interesantes. Gracias.
Fuente: habr.com