Desenvolvemos un deseño de rede de centros de datos que permite o despregamento de clústeres de computación de máis de 100 mil servidores cun ancho de banda máximo de bisección superior a un petabyte por segundo.
No informe de Dmitry Afanasyev aprenderá sobre os principios básicos do novo deseño, escalando topoloxías, os problemas que xorden con isto, as opcións para resolvelos, as características de enrutamento e escalado das funcións do plano de reenvío dos dispositivos de rede modernos en "densamente conectados". topoloxías cunha gran cantidade de rutas ECMP . Ademais, Dima falou brevemente sobre a organización da conectividade externa, a capa física, o sistema de cableado e as formas de aumentar aínda máis a capacidade.
- Boas tardes a todos! Chámome Dmitry Afanasyev, son arquitecto de redes en Yandex e deseño principalmente redes de centros de datos.
A miña historia versará sobre a rede actualizada de centros de datos Yandex. É en gran medida unha evolución do deseño que tiñamos, pero ao mesmo tempo hai algúns elementos novos. Esta é unha presentación xeral porque había moita información para empaquetar nun pequeno período de tempo. Comezaremos escollendo unha topoloxía lóxica. Despois haberá unha visión xeral do plano de control e problemas coa escalabilidade do plano de datos, unha elección do que ocorrerá a nivel físico e analizaremos algunhas características dos dispositivos. Tocamos un pouco o que está a suceder nun centro de datos con MPLS, do que falamos hai tempo.
Entón, que é Yandex en termos de cargas e servizos? Yandex é un hiperescalador típico. Se miramos aos usuarios, procesamos principalmente as solicitudes dos usuarios. Tamén varios servizos de streaming e transferencia de datos, porque tamén temos servizos de almacenamento. Se está máis preto do backend, alí aparecen cargas de infraestrutura e servizos, como o almacenamento de obxectos distribuídos, a replicación de datos e, por suposto, as colas persistentes. Un dos principais tipos de cargas de traballo é MapReduce e sistemas similares, procesamento de fluxos, aprendizaxe automática, etc.
Como é a infraestrutura sobre a que sucede todo isto? De novo, somos un hiperescalador bastante típico, aínda que quizais esteamos un pouco máis preto do lado do hiperescalador menor do espectro. Pero temos todos os atributos. Usamos hardware común e escala horizontal sempre que sexa posible. Temos unha posta en común de recursos: non traballamos con máquinas individuais, bastidores individuais, senón que os combinamos nun gran conxunto de recursos intercambiables con algúns servizos adicionais que se ocupan da planificación e asignación e traballamos con todo este grupo.
Polo tanto, temos o seguinte nivel: o sistema operativo no nivel de clúster de computación. É moi importante que controlemos totalmente a pila de tecnoloxía que usamos. Controlamos os puntos finais (hosts), a rede e a pila de software.
Temos varios grandes centros de datos en Rusia e no estranxeiro. Están unidos por unha columna vertebral que utiliza tecnoloxía MPLS. A nosa infraestrutura interna está construída case na súa totalidade en IPv6, pero dado que necesitamos atender o tráfico externo que aínda chega principalmente a través de IPv4, debemos, dalgún xeito, entregar as solicitudes que chegan a través de IPv4 aos servidores frontend e un pouco máis ir a IPv4 externo - Internet - para exemplo, para indexar.
As últimas iteracións dos deseños de redes de centros de datos utilizaron topoloxías Clos multicapa e só son L3. Saímos da L2 hai un tempo e respiramos aliviados. Finalmente, a nosa infraestrutura inclúe centos de miles de instancias informáticas (servidores). O tamaño máximo do clúster hai algún tempo era duns 10 mil servidores. Isto débese en gran medida a como poden funcionar eses mesmos sistemas operativos a nivel de clúster, programadores, asignación de recursos, etc. Dado que se produciu un progreso no lado do software de infraestrutura, o tamaño obxectivo é agora uns 100 mil servidores nun clúster informático e Temos unha tarefa: poder construír fábricas de rede que permitan unha posta en común de recursos eficiente nun clúster deste tipo.
Que queremos dunha rede de centros de datos? En primeiro lugar, hai moito ancho de banda barato e distribuído de forma bastante uniforme. Porque a rede é a columna vertebral a través da cal podemos xuntar recursos. O novo tamaño obxectivo é duns 100 mil servidores nun clúster.
Tamén, por suposto, queremos un plano de control escalable e estable, porque nunha infraestrutura tan grande xorden moitos dores de cabeza incluso de eventos simplemente aleatorios, e non queremos que o plano de control tamén nos traia dores de cabeza. Ao mesmo tempo, queremos minimizar o estado nel. Canto menor sexa a condición, mellor e máis estable funciona todo, e máis fácil é diagnosticar.
Por suposto, necesitamos automatización, porque é imposible xestionar manualmente unha infraestrutura deste tipo, e hai tempo que é imposible. Necesitamos apoio operativo na medida do posible e apoio CI/CD na medida en que se poida proporcionar.
Con tales tamaños de centros de datos e clústeres, a tarefa de soportar a implantación e expansión incrementais sen interrupción do servizo fíxose bastante aguda. Se en clústeres dun tamaño de mil máquinas, quizais preto de dez mil máquinas, aínda poderían implementarse como unha soa operación, é dicir, estamos planeando unha expansión da infraestrutura e engádense varios miles de máquinas como unha soa operación, entón un clúster dun tamaño de cen mil máquinas non xorde inmediatamente así, constrúese durante un período de tempo. E é desexable que todo este tempo o que xa se bombeou, a infraestrutura que se despregou, estea dispoñible.
E un requisito que tiñamos e deixamos: soporte para multitenencia, é dicir, virtualización ou segmentación da rede. Agora non necesitamos facelo a nivel de tecido de rede, porque a fragmentación foi para os anfitrións, e isto facilitounos moito a escala. Grazas a IPv6 e un gran espazo de enderezos, non necesitabamos utilizar enderezos duplicados na infraestrutura interna, xa que todos os enderezos eran únicos. E grazas a que levamos o filtrado e a segmentación da rede aos hosts, non necesitamos crear ningunha entidade de rede virtual nas redes de centros de datos.
Unha cousa moi importante é o que non necesitamos. Se algunhas funcións poden ser eliminadas da rede, isto facilita moito a vida e, por regra xeral, amplía a elección de equipos e software dispoñibles, facendo que o diagnóstico sexa moi sinxelo.
Entón, que é o que non necesitamos, a que puidemos renunciar, non sempre con alegría no momento en que pasou, senón con gran alivio cando se completa o proceso?
En primeiro lugar, abandonar a L2. Non necesitamos L2, nin real nin emulado. Non se usa en gran parte debido ao feito de que controlamos a pila de aplicacións. As nosas aplicacións son escalables horizontalmente, funcionan con direccionamento L3, non lles preocupa moito que se extinga algunha instancia individual, simplemente lanzan unha nova, non é necesario que estea no enderezo antigo, porque hai un nivel separado de descubrimento de servizo e seguimento das máquinas situadas no clúster. Non delegamos esta tarefa na rede. O traballo da rede é entregar paquetes desde o punto A ata o punto B.
Tampouco temos situacións nas que os enderezos se movan dentro da rede, e isto hai que supervisalo. En moitos deseños, isto é normalmente necesario para soportar a mobilidade de VM. Non utilizamos a mobilidade das máquinas virtuais na infraestrutura interna do gran Yandex e, ademais, cremos que aínda que se faga isto non debería ocorrer co soporte de rede. Se realmente necesitas facelo, cómpre facelo a nivel de host e empurrar os enderezos que poidan migrar a superposicións, para non tocar nin facer demasiados cambios dinámicos no sistema de enrutamento do subxacente (rede de transporte). .
Outra tecnoloxía que non usamos é a multidifusión. Se queres, podo dicirche detalladamente por que. Isto fai a vida moito máis fácil, porque se alguén se enfrontou a iso e mirou exactamente como é o plano de control de multidifusión, en todas as instalacións, excepto nas máis simples, isto é un gran quebradizo de cabeza. E ademais, é difícil atopar unha implementación de código aberto que funcione ben, por exemplo.
Por último, deseñamos as nosas redes para que non cambien demasiado. Podemos contar co feito de que o fluxo de eventos externos no sistema de enrutamento é pequeno.
Que problemas xorden e que restricións hai que ter en conta cando desenvolvemos unha rede de centros de datos? Custo, claro. Escalabilidade, o nivel ao que queremos crecer. A necesidade de ampliar sen parar o servizo. Ancho de banda, dispoñibilidade. Visibilidade do que acontece na rede para sistemas de monitorización, para equipos operativos. Soporte de automatización - de novo, na medida do posible, xa que se poden resolver diferentes tarefas en diferentes niveis, incluída a introdución de capas adicionais. Ben, non [posiblemente] dependente dos provedores. Aínda que en diferentes períodos históricos, segundo o apartado que se mire, esta independencia foi máis fácil ou máis difícil de conseguir. Se tomamos unha sección transversal dos chips de dispositivos de rede, ata hai pouco era moi condicionado falar de independencia dos provedores, se tamén queríamos chips con alto rendemento.
Que topoloxía lóxica usaremos para construír a nosa rede? Este será un Clos de varios niveis. De feito, non hai alternativas reais polo momento. E a topoloxía Clos é bastante boa, mesmo se se compara con varias topoloxías avanzadas que agora están máis na área de interese académico, se temos grandes interruptores de base.
Como se estrutura aproximadamente unha rede Clos de varios niveis e como se chaman os diferentes elementos nela? En primeiro lugar, a rosa dos ventos, para orientarse onde está o norte, onde está o sur, onde está o leste, onde está o oeste. As redes deste tipo adoitan ser construídas por aqueles que teñen un tráfico oeste-leste moi grande. En canto aos elementos restantes, na parte superior hai un interruptor virtual montado a partir de interruptores máis pequenos. Esta é a idea principal da construción recursiva das redes Clos. Collemos elementos con algún tipo de radix e conectámolos para que o que obtemos poida considerarse como un interruptor cunha radix maior. Se precisa aínda máis, o procedemento pódese repetir.
Nos casos, por exemplo, de Clos de dous niveis, cando é posible identificar claramente os compoñentes verticais no meu diagrama, adoitan chamarse planos. Se construímos un Clos con tres niveis de interruptores de columna (que non son interruptores de límite ou ToR e que se usan só para o tránsito), entón os avións pareceríanse máis complexos; os de dous niveis parecen exactamente así. Chamamos Pod a un bloque de ToR ou interruptores de folla e aos interruptores de columna de primeiro nivel asociados a eles. Os interruptores da columna vertebral do nivel de columna 1 na parte superior do Pod son a parte superior do Pod, a parte superior do Pod. Os interruptores que están situados na parte superior de toda a fábrica son a capa superior da fábrica, Top of fabric.
Por suposto, xorde a pregunta: as redes Clos constrúense dende hai tempo; a idea en si xorde xeralmente dos tempos da telefonía clásica, as redes TDM. Quizais apareceu algo mellor, quizais se poida facer algo mellor? Si e non. Teoricamente si, na práctica nun futuro próximo definitivamente non. Debido a que hai unha serie de topoloxías interesantes, algunhas delas incluso úsanse na produción, por exemplo, Dragonfly úsase en aplicacións HPC; Tamén hai topoloxías interesantes como Xpander, FatClique, Jellyfish. Se observas os informes en congresos como SIGCOMM ou NSDI recentemente, podes atopar un número bastante grande de traballos sobre topoloxías alternativas que teñen mellores propiedades (unha ou outra) que Clos.
Pero todas estas topoloxías teñen unha propiedade interesante. Impide a súa implementación en redes de centros de datos, que estamos tentando construír en hardware común e que custa un diñeiro bastante razoable. En todas estas topoloxías alternativas, a maior parte do ancho de banda, desafortunadamente, non é accesible a través dos camiños máis curtos. Polo tanto, perdemos inmediatamente a oportunidade de usar o plano de control tradicional.
Teoricamente, a solución do problema é coñecida. Trátase, por exemplo, de modificacións do estado da ligazón usando o camiño máis curto de k, pero, de novo, non hai protocolos deste tipo que se implementen en produción e estean amplamente dispoñibles nos equipos.
Ademais, dado que a maior parte da capacidade non é accesible a través dos camiños máis curtos, necesitamos modificar algo máis que o plano de control para seleccionar todos eses camiños (e, por certo, isto é significativamente máis estado no plano de control). Aínda necesitamos modificar o plano de reenvío e, por regra xeral, son necesarias polo menos dúas funcións adicionais. Esta é a capacidade de tomar todas as decisións sobre o reenvío de paquetes dunha soa vez, por exemplo, no host. De feito, trátase de enrutamento de orixe, ás veces na literatura sobre redes de interconexión chámase decisións de reenvío todo á vez. E o enrutamento adaptativo é unha función que necesitamos nos elementos da rede, que se reduce, por exemplo, a que seleccionamos o seguinte salto en función da información sobre a menor carga da cola. Por exemplo, outras opcións son posibles.
Así, a dirección é interesante, pero, por desgraza, non podemos aplicala agora mesmo.
Está ben, decidimos a topoloxía lóxica Clos. Como o escalaremos? A ver como funciona e que se pode facer.
Nunha rede Clos hai dous parámetros principais que dalgún xeito podemos variar e obter certos resultados: a base de elementos e o número de niveis da rede. Teño un diagrama esquemático de como ambos afectan o tamaño. O ideal é combinar ambos.
Pódese ver que a anchura final da rede de Clos é o produto de todos os niveis de conmutadores de columna vertebral da base sur, de cantos enlaces temos abaixo, de como se ramifica. Así é como escalamos o tamaño da rede.
En canto á capacidade, especialmente nos interruptores ToR, hai dúas opcións de escala. Ou podemos, mantendo a topoloxía xeral, usar ligazóns máis rápidas, ou podemos engadir máis planos.
Se miras a versión ampliada da rede Clos (na esquina inferior dereita) e volves a esta imaxe coa rede Clos a continuación...
... entón esta é exactamente a mesma topoloxía, pero nesta diapositiva colapsase de forma máis compacta e os planos da fábrica superpoñense uns a outros. É o mesmo.
Como é o escalado dunha rede Clos en números? Aquí ofrezo datos sobre que ancho máximo se pode obter unha rede, que número máximo de bastidores, conmutadores ToR ou conmutadores de folla, se non están en bastidores, podemos obter dependendo da base de conmutadores que usemos para os niveis de columna, e cantos niveis usamos.
Velaquí cantos racks podemos ter, cantos servidores e canto pode consumir todo isto aproximadamente en función de 20 kW por rack. Un pouco antes mencionei que pretendemos un tamaño de clúster duns 100 mil servidores.
Pódese ver que en todo este deseño interesan dúas opcións e media. Hai unha opción con dúas capas de espiñas e interruptores de 64 portos, que queda un pouco curto. Despois, hai opcións que se adaptan perfectamente aos interruptores de columna vertebral de 128 portos (con radix 128) con dous niveis ou interruptores con radix 32 con tres niveis. E en todos os casos, onde hai máis radixes e máis capas, pódese facer unha rede moi grande, pero se se mira o consumo esperado, normalmente hai gigavatios. É posible colocar un cable, pero é improbable que teñamos tanta electricidade nun sitio. Se miras as estatísticas e os datos públicos dos centros de datos, podes atopar moi poucos centros de datos cunha capacidade estimada de máis de 150 MW. Os máis grandes adoitan ser campus de centros de datos, varios centros de datos grandes situados bastante preto uns dos outros.
Hai outro parámetro importante. Se miras a columna da esquerda, aparece o ancho de banda útil alí. É doado ver que nunha rede Clos unha parte importante dos portos utilízanse para conectar conmutadores entre si. O ancho de banda útil, unha tira útil, é algo que se pode dar fóra, cara aos servidores. Por suposto, falo de portos condicionais e concretamente da banda. Como regra xeral, as ligazóns dentro da rede son máis rápidas que as conexións cara aos servidores, pero por unidade de ancho de banda, por moito que poidamos envialo ao noso equipo servidor, aínda hai algo de ancho de banda dentro da propia rede. E cantos máis niveis fagamos, maior será o custo específico de proporcionar esta franxa ao exterior.
Ademais, mesmo esta banda adicional non é exactamente a mesma. Aínda que os tramos son curtos, podemos usar algo como DAC (cobre de conexión directa, é dicir, cables twinax) ou ópticas multimodo, que custan aínda máis ou menos cartos razoables. En canto nos movemos a intervalos máis longos, por regra xeral, estas son ópticas monomodo e o custo deste ancho de banda adicional aumenta notablemente.
E de novo, volvendo á diapositiva anterior, se creamos unha rede Clos sen subscrición excesiva, é fácil ver o diagrama, ver como está construída a rede - engadindo cada nivel de conmutadores de columna, repetimos toda a franxa que estaba no fondo. Nivel máis: máis a mesma banda, o mesmo número de portos nos interruptores que había no nivel anterior e o mesmo número de transceptores. Polo tanto, é moi desexable minimizar o número de niveis de interruptores da columna vertebral.
Con base nesta imaxe, está claro que realmente queremos construír algo así como interruptores cunha base de 128.
Aquí, en principio, todo é o mesmo que acabo de dicir; esta é unha diapositiva para considerala máis tarde.
Que opcións hai que podemos escoller como tales interruptores? É unha noticia moi agradable para nós que agora este tipo de redes poden finalmente construírse en conmutadores dun só chip. E isto é moi chulo, teñen moitas características agradables. Por exemplo, case non teñen estrutura interna. Isto significa que rompen máis facilmente. Rompen de todo tipo, pero afortunadamente rompen por completo. Nos dispositivos modulares hai unha gran cantidade de avarías (moi desagradables), cando dende o punto de vista dos veciños e do plano de control parece que funciona, pero, por exemplo, perdeuse parte do tecido e non funciona. a pleno rendemento. E o tráfico cara a ela está equilibrado en función do feito de que é totalmente funcional e podemos sobrecargarnos.
Ou, por exemplo, xorden problemas co backplane, porque dentro do dispositivo modular tamén hai SerDes de alta velocidade: é realmente complexo por dentro. Ou os sinais entre os elementos de reenvío están sincronizados ou non están sincronizados. En xeral, calquera dispositivo modular produtivo composto por un gran número de elementos, por regra xeral, contén a mesma rede Clos no seu interior, pero é moi difícil de diagnosticar. Moitas veces é difícil incluso para o propio vendedor diagnosticar.
E ten un gran número de escenarios de fallo nos que o dispositivo se degrada, pero non cae completamente da topoloxía. Dado que a nosa rede é grande, utilízase activamente o equilibrio entre elementos idénticos, a rede é moi regular, é dicir, un camiño no que todo está en orde non é diferente do outro, é máis rendible para nós simplemente perder algo de os dispositivos da topoloxía que para acabar nunha situación na que algúns deles parecen funcionar, pero algúns deles non.
A seguinte característica agradable dos dispositivos dun só chip é que evolucionan mellor e máis rápido. Tamén tenden a ter mellor capacidade. Se tomamos as grandes estruturas ensambladas que temos nun círculo, entón a capacidade por unidade de rack para portos da mesma velocidade é case o dobre que a dos dispositivos modulares. Os dispositivos construídos arredor dun só chip son notablemente máis baratos que os modulares e consomen menos enerxía.
Pero, por suposto, todo isto é por unha razón, tamén hai desvantaxes. En primeiro lugar, a base é case sempre máis pequena que a dos dispositivos modulares. Se podemos conseguir un dispositivo construído arredor dun chip con 128 portos, entón podemos obter un modular con varios centos de portos agora sen ningún problema.
Este é un tamaño notablemente menor das táboas de reenvío e, por regra xeral, todo o relacionado coa escalabilidade do plano de datos. Tampóns pouco profundos. E, por regra xeral, unha funcionalidade bastante limitada. Pero resulta que se coñeces estas restricións e tes coidado a tempo de evitalas ou simplemente tes en conta, isto non é tan asustado. O feito de que a base sexa máis pequena xa non é un problema nos dispositivos cunha base de 128 que finalmente apareceron recentemente; podemos construír dúas capas de espiñas. Pero aínda é imposible construír algo máis pequeno que dous que sexa interesante para nós. Cun nivel, obtéñense clusters moi pequenos. Mesmo os nosos deseños e requisitos anteriores aínda os superaban.
De feito, se de súpeto a solución está nalgún lugar ao bordo, aínda hai un xeito de escalar. Dado que o último (ou primeiro) nivel máis baixo onde están conectados os servidores son os interruptores ToR ou os interruptores de folla, non estamos obrigados a conectar un rack a eles. Polo tanto, se a solución queda preto da metade, pode pensar simplemente en usar un interruptor cunha gran base no nivel inferior e conectar, por exemplo, dous ou tres bastidores nun interruptor. Esta tamén é unha opción, ten os seus custos, pero funciona bastante ben e pode ser unha boa solución cando hai que acadar aproximadamente o dobre de tamaño.
Para resumir, estamos construíndo unha topoloxía con dous niveis de espiñas, con oito capas de fábrica.
Que pasará coa física? Cálculos moi sinxelos. Se temos dous niveis de espiñas, entón temos só tres niveis de conmutadores, e esperamos que haxa tres segmentos de cable na rede: desde servidores ata conmutadores de folla, pasando polo lombo 1, ata o lombo 2. As opcións que podemos use are - estes son twinax, multimode, single mode. E aquí temos que considerar que tira está dispoñible, canto custará, cales son as dimensións físicas, que espazos podemos cubrir e como actualizaremos.
En canto ao custo, todo se pode aliñar. Os Twinaxes son significativamente máis baratos que as ópticas activas, máis baratos que os transceptores multimodo, se o tomas por voo desde o final, algo máis barato que un porto de conmutación de 100 gigabits. E, por favor, teña en conta que custa menos que a óptica monomodo, porque nos voos onde se require o modo único, nos centros de datos ten sentido usar CWDM por varias razóns, mentres que o modo único paralelo (PSM) non é moi cómodo de traballar. con, obtéñense envases moi grandes de fibras, e se nos centramos nestas tecnoloxías, obtemos aproximadamente a seguinte xerarquía de prezos.
Unha nota máis: desafortunadamente, non é moi posible usar portos multimodo desmontados de 100 a 4x25. Debido ás características de deseño dos transceptores SFP28, non é moito máis barato que 28 Gbit QSFP100. E esta desmontaxe para multimodo non funciona moi ben.
Outra limitación é que debido ao tamaño dos clústeres informáticos e ao número de servidores, os nosos centros de datos resultan ser fisicamente grandes. Isto significa que polo menos un voo terá que facerse cun único mod. De novo, debido ao tamaño físico dos Pods, non será posible executar dous tramos de twinax (cables de cobre).
Como resultado, se optimizamos o prezo e temos en conta a xeometría deste deseño, obtemos un intervalo de twinax, un intervalo de multimodo e un intervalo de modo único usando CWDM. Isto ten en conta posibles rutas de actualización.
Así se ve recentemente, cara a onde imos e o que é posible. Está claro, polo menos, como avanzar cara a SerDes de 50 Gigabit tanto para modo multimodo como para modo único. Ademais, se miras o que hai nos transceptores monomodo agora e no futuro para 400G, moitas veces mesmo cando chegan 50G SerDes do lado eléctrico, 100 Gbps por carril xa poden ir á óptica. Polo tanto, é moi posible que en lugar de pasar a 50, haxa unha transición a 100 Gigabit SerDes e 100 Gbps por carril, porque segundo as promesas de moitos provedores, espérase a súa dispoñibilidade bastante pronto. O período no que 50G SerDes foron os máis rápidos, ao parecer, non será moi longo, porque as primeiras copias de 100G SerDes lanzaranse case o próximo ano. E despois dun tempo despois diso, probablemente valerán un diñeiro razoable.
Un matiz máis sobre a elección da física. En principio, xa podemos usar portos de 400 ou 200 Gigabit usando 50G SerDes. Pero resulta que isto non ten moito sentido, porque, como dixen antes, queremos unha base bastante grande nos interruptores, dentro do razonable, claro. Queremos 128. E se temos unha capacidade de chip limitada e aumentamos a velocidade da ligazón, entón a base diminúe naturalmente, non hai milagres.
E podemos aumentar a capacidade total usando avións, e non hai custos especiais; podemos engadir o número de avións. E se perdemos o radix, teremos que introducir un nivel adicional, polo que na situación actual, coa capacidade máxima dispoñible actual por chip, resulta que é máis eficiente empregar portos de 100 gigabits, porque che permiten para obter unha base máis grande.
A seguinte pregunta é como se organiza a física, pero desde o punto de vista da infraestrutura de cable. Resulta que está organizado dun xeito bastante divertido. Cableado entre interruptores de follas e espiñas de primeiro nivel: non hai moitas ligazóns alí, todo está construído de forma relativamente sinxela. Pero se tomamos un plano, o que pasa dentro é que necesitamos conectar todas as espiñas do primeiro nivel con todas as do segundo nivel.
Ademais, como regra xeral, hai algúns desexos de como debería verse dentro do centro de datos. Por exemplo, realmente queriamos combinar os cables nun paquete e tiralos para que un panel de conexión de alta densidade entrase completamente nun panel de conexión, para que non houbese zoolóxico en termos de lonxitude. Conseguimos resolver este problema. Se observas inicialmente a topoloxía lóxica, podes ver que os planos son independentes, cada plano pode construírse por si mesmo. Pero cando engadimos tal agrupación e queremos arrastrar todo o panel de parches a un panel de parches, temos que mesturar diferentes planos dentro dun paquete e introducir unha estrutura intermedia en forma de conexións cruzadas ópticas para reempaquelas desde como foron ensambladas. nun segmento, en como se recollerán noutro segmento. Grazas a isto, obtemos unha característica agradable: toda a conmutación complexa non vai máis aló dos racks. Cando hai que entrelazar algo con moita forza, "desdobrar os planos", como ás veces se lle chama nas redes Clos, todo concéntrase nun só rack. Non temos moi desmontado, ata enlaces individuais, cambiar entre bastidores.
Así se ve dende o punto de vista da organización lóxica da infraestrutura de cable. Na imaxe da esquerda, os bloques multicolores representan bloques de interruptores de columna vertebral de primeiro nivel, oito pezas cada un, e catro feixes de cables procedentes deles, que van e se cruzan cos paquetes procedentes dos bloques dos interruptores de columna vertebral-2. .
Os cadrados pequenos indican interseccións. Na parte superior esquerda hai un desglose de cada unha destas interseccións, este é en realidade un módulo de conexión cruzada de portos 512 por 512 que reempaque os cables para que entren completamente nun rack, onde só hai un plano de columna vertebral 2. E á dereita, unha exploración desta imaxe é un pouco máis detallada en relación con varios Pods no nivel da columna vertebral-1, e como se empaqueta nunha conexión cruzada, como se chega ao nivel da columna vertebral-2.
Isto é o que parece. O soporte Spine-2 aínda non totalmente montado (á esquerda) e o soporte de conexión cruzada. Por desgraza, non hai moito que ver alí. Toda esta estrutura estase a implementar agora mesmo nun dos nosos grandes centros de datos que se está a ampliar. Este é un traballo en proceso, quedará mellor, cubrirase mellor.
Unha pregunta importante: escollemos a topoloxía lóxica e construímos a física. Que pasará co avión de control? É bastante coñecido pola experiencia operativa, hai unha serie de informes que indican que os protocolos de estado de enlace son bos, é un pracer traballar con eles, pero, por desgraza, non se escalan ben nunha topoloxía densamente conectada. E hai un factor principal que o impide: así funcionan as inundacións nos protocolos de estado de enlace. Se simplemente tomas o algoritmo de inundación e miras como está estruturada a nosa rede, podes ver que haberá un fanout moi grande en cada paso, e simplemente inundará o plano de control con actualizacións. En concreto, tales topoloxías mestúranse moi mal co algoritmo de inundación tradicional nos protocolos de estado de enlace.
A opción é usar BGP. Como preparalo correctamente descríbese na RFC 7938 sobre o uso de BGP en grandes centros de datos. As ideas básicas son sinxelas: número mínimo de prefixos por host e xeralmente número mínimo de prefixos na rede, usar a agregación se é posible e suprimir a busca de camiños. Queremos unha distribución de actualizacións moi coidada, moi controlada, o que se chama valle libre. Queremos que as actualizacións se despreguen exactamente unha vez mentres pasan pola rede. Se se orixinan na parte inferior, soben, desdobrándose non máis dunha vez. Non debería haber zigzags. Os zigzags son moi malos.
Para iso, usamos un deseño que é o suficientemente sinxelo como para usar os mecanismos BGP subxacentes. É dicir, usamos eBGP que se executa en enlace local, e os sistemas autónomos están asignados do seguinte xeito: un sistema autónomo en ToR, un sistema autónomo en todo o bloque de conmutadores da columna vertebral-1 dun Pod e un sistema autónomo xeral en todo o Top de Tecido. Non é difícil mirar e ver que mesmo o comportamento normal de BGP nos dá a distribución de actualizacións que queremos.
Naturalmente, o direccionamento e a agregación de enderezos teñen que ser deseñados de xeito que sexan compatibles coa forma en que se constrúe o enrutamento, para que garanta a estabilidade do plano de control. O direccionamento L3 no transporte está ligado á topoloxía, porque sen iso é imposible lograr a agregación; sen iso, as direccións individuais introduciranse no sistema de enrutamento. E unha cousa máis é que a agregación, por desgraza, non se mestura moi ben coa multiruta, porque cando temos multiruta e temos agregación, todo está ben, cando toda a rede está sa, non hai fallos nela. Desafortunadamente, en canto aparecen fallos na rede e se perde a simetría da topoloxía, podemos chegar ao punto desde o que se anunciou a unidade, desde o que non podemos ir máis lonxe ata onde temos que ir. Polo tanto, o mellor é agregar onde non hai máis rutas múltiples, no noso caso son conmutadores ToR.
De feito, é posible agregar, pero con coidado. Se podemos facer unha desagregación controlada cando se produzan fallos na rede. Pero esta é unha tarefa bastante difícil, ata nos preguntamos se sería posible facelo, se sería posible engadir automatización adicional e máquinas de estado finito que activasen correctamente BGP para obter o comportamento desexado. Desafortunadamente, o procesamento de casos de esquina non é moi obvio e complexo, e esta tarefa non se resolve ben ao conectar anexos externos a BGP.
A este respecto realizouse un traballo moi interesante no marco do protocolo RIFT, do que se tratará no próximo informe.
Outra cousa importante é como escalan os planos de datos en topoloxías densas, onde temos un gran número de camiños alternativos. Neste caso, utilízanse varias estruturas de datos adicionais: grupos ECMP, que á súa vez describen grupos Next Hop.
Nunha rede que funcione normalmente, sen fallos, cando subimos a topoloxía Clos abonda con usar só un grupo, porque todo o que non é local está descrito por defecto, podemos subir. Cando imos de arriba abaixo cara ao sur, entón todos os camiños non son ECMP, son camiños únicos. Todo está ben. O problema é que, e a peculiaridade da topoloxía Clos clásica é que se miramos a parte superior do tecido, en calquera elemento, só hai un camiño para calquera elemento abaixo. Se se producen fallos neste camiño, este elemento en particular na parte superior da fábrica non é válido precisamente para aqueles prefixos que se atopan detrás do camiño roto. Pero para o resto vale, e temos que analizar os grupos ECMP e introducir un novo estado.
Como é a escalabilidade do plano de datos nos dispositivos modernos? Se facemos LPM (concordancia de prefixo máis longa), todo é bastante bo, máis de 100k prefixos. Se estamos a falar de grupos Next Hop, todo é peor, 2-4 mil. Se estamos a falar dunha táboa que contén unha descrición de Next Hops (ou adxacencias), entón esta é de 16k a 64k. E isto pode converterse nun problema. E aquí chegamos a unha digresión interesante: que pasou co MPLS nos centros de datos? En principio, queriamos facelo.
Pasaron dúas cousas. Fixemos microsegmentación nos hosts; xa non necesitabamos facelo na rede. Non foi moi bo co apoio de diferentes provedores, e máis aínda con implementacións abertas en caixas brancas con MPLS. E MPLS, polo menos as súas implementacións tradicionais, por desgraza, combinan moi mal con ECMP. E por iso.
Este é o aspecto da estrutura de reenvío ECMP para IP. Un gran número de prefixos poden usar o mesmo grupo e o mesmo bloque Next Hops (ou adxacencias, isto pode chamarse de forma diferente en documentación diferente para diferentes dispositivos). A cuestión é que este descríbese como o porto de saída e no que reescribir o enderezo MAC para chegar ao seguinte salto correcto. Para IP todo parece sinxelo, podes usar un número moi grande de prefixos para o mesmo grupo, o mesmo bloque Next Hops.
A arquitectura MPLS clásica implica que, dependendo da interface de saída, a etiqueta pode ser reescrita a diferentes valores. Polo tanto, necesitamos manter un grupo e un bloque Next Hops para cada etiqueta de entrada. E isto, por desgraza, non escala.
É fácil ver que no noso deseño necesitábamos uns 4000 interruptores ToR, o ancho máximo era de 64 camiños ECMP, se nos afastamos da columna vertebral-1 cara á columna vertebral-2. Apenas entramos nunha táboa de grupos ECMP, se só desaparece un prefixo con ToR e non entramos en absoluto na táboa Next Hops.
Non todo é irremediable, porque arquitecturas como Segment Routing implican etiquetas globais. Formalmente, sería posible colapsar de novo todos estes bloques de Next Hops. Para iso, necesitas unha operación de tipo comodín: colle unha etiqueta e reescribínaa na mesma sen un valor específico. Pero, por desgraza, isto non está moi presente nas implementacións dispoñibles.
E, finalmente, necesitamos levar tráfico externo ao centro de datos. Como facelo? Anteriormente, o tráfico introducíase na rede de Clos desde arriba. É dicir, había enrutadores de borde que se conectaban a todos os dispositivos na parte superior do tecido. Esta solución funciona bastante ben en tamaños pequenos e medianos. Desafortunadamente, para enviar o tráfico de forma simétrica a toda a rede deste xeito, necesitamos chegar a todos os elementos Top of fabric simultaneamente, e cando hai máis de cen, resulta que tamén necesitamos un gran radix en os enrutadores de borde. En xeral, isto custa diñeiro, porque os enrutadores de borde son máis funcionais, os portos neles serán máis caros e o deseño non é moi bonito.
Outra opción é iniciar ese tráfico desde abaixo. É doado verificar que a topoloxía Clos está construída de forma que o tráfico procedente de abaixo, é dicir, do lado do ToR, se distribúa uniformemente entre os niveis en toda a parte superior do tecido en dúas iteracións, cargando toda a rede. Polo tanto, presentamos un tipo especial de Pod, Edge Pod, que proporciona conectividade externa.
Hai unha opción máis. Isto é o que fai Facebook, por exemplo. Chámanlle Fabric Aggregator ou HGRID. Está introducindo un nivel de columna adicional para conectar varios centros de datos. Este deseño é posible se non temos funcións adicionais ou cambios de encapsulación nas interfaces. Se son puntos de contacto adicionais, é difícil. Normalmente, hai máis funcións e unha especie de membrana que separa diferentes partes do centro de datos. Non ten sentido facer unha membrana tan grande, pero se realmente é necesaria por algún motivo, ten sentido considerar a posibilidade de quitala, facéndoa o máis ancha posible e traspasala aos anfitrións. Isto faise, por exemplo, por moitos operadores na nube. Teñen superposicións, parten dos anfitrións.
Que oportunidades de desenvolvemento vemos? En primeiro lugar, mellorar o soporte para o pipeline CI/CD. Queremos voar como probamos e probamos como voamos. Isto non funciona moi ben, porque a infraestrutura é grande e é imposible duplicala para probas. Debe comprender como introducir elementos de proba na infraestrutura de produción sen deixalos caer.
Unha mellor instrumentación e un mellor seguimento case nunca son superfluos. Toda a cuestión é un equilibrio entre esforzo e retorno. Se podes engadilo cun esforzo razoable, moi ben.
Sistemas operativos abertos para dispositivos de rede. Mellores protocolos e mellores sistemas de enrutamento, como RIFT. Tamén é necesaria a investigación sobre o uso de mellores esquemas de control da conxestión e quizais a introdución, polo menos nalgúns puntos, do soporte RDMA dentro do clúster.
Mirando máis cara ao futuro, necesitamos topoloxías avanzadas e posiblemente redes que usen menos sobrecarga. Das cousas novas, recentemente houbo publicacións sobre a tecnoloxía de tecido para HPC Cray Slingshot, que se basea en Ethernet de mercadorías, pero coa opción de usar cabeceiras moito máis curtas. Como resultado, a sobrecarga redúcese.
Todo debe ser o máis sinxelo posible, pero non máis sinxelo. A complexidade é o inimigo da escalabilidade. A simplicidade e as estruturas regulares son os nosos amigos. Se podes escalar nalgún lugar, faino. E, en xeral, é xenial estar agora implicado en tecnoloxías de rede. Hai moitas cousas interesantes a suceder. Grazas.
Fonte: www.habr.com