Desenvolvemos um projeto de rede de data center que permite a implantação de clusters de computação maiores que 100 mil servidores com largura de banda de pico de mais de um petabyte por segundo.
Com o relatório de Dmitry Afanasyev, você aprenderá sobre os princípios básicos do novo design, dimensionamento de topologias, problemas que surgem com isso, opções para resolvê-los, recursos de roteamento e dimensionamento das funções do plano de encaminhamento de dispositivos de rede modernos em “densamente conectados” topologias com um grande número de rotas ECMP. Além disso, Dima falou brevemente sobre a organização da conectividade externa, a camada física, o sistema de cabeamento e formas de aumentar ainda mais a capacidade.
- Boa tarde a todos! Meu nome é Dmitry Afanasyev, sou arquiteto de redes na Yandex e principalmente projeto redes de data centers.
Minha história será sobre a rede atualizada de data centers Yandex. É uma evolução do design que tínhamos, mas ao mesmo tempo existem alguns elementos novos. Esta é uma apresentação geral porque havia muita informação a ser reunida em um curto período de tempo. Começaremos escolhendo uma topologia lógica. Em seguida, haverá uma visão geral do plano de controle e dos problemas de escalabilidade do plano de dados, uma escolha do que acontecerá no nível físico e veremos alguns recursos dos dispositivos. Vamos falar um pouco sobre o que está acontecendo em um data center com MPLS, do qual falamos há algum tempo.
Então, o que é Yandex em termos de cargas e serviços? Yandex é um hiperescalador típico. Se olharmos para os usuários, processamos principalmente as solicitações dos usuários. Também vários serviços de streaming e transferência de dados, porque também temos serviços de armazenamento. Se estiver mais próximo do back-end, aí aparecem cargas e serviços de infraestrutura, como armazenamento distribuído de objetos, replicação de dados e, claro, filas persistentes. Um dos principais tipos de cargas de trabalho é MapReduce e sistemas similares, processamento de fluxo, aprendizado de máquina, etc.
Como está a infraestrutura em cima da qual tudo isso acontece? Novamente, somos um hiperescalador bastante típico, embora talvez estejamos um pouco mais próximos do lado menor do hiperescalador do espectro. Mas temos todos os atributos. Usamos hardware comum e escalabilidade horizontal sempre que possível. Temos pooling completo de recursos: não trabalhamos com máquinas individuais, racks individuais, mas os combinamos em um grande pool de recursos intercambiáveis com alguns serviços adicionais que tratam de planejamento e alocação, e trabalhamos com todo esse pool.
Portanto, temos o próximo nível - o sistema operacional no nível do cluster de computação. É muito importante controlarmos totalmente a pilha de tecnologia que utilizamos. Controlamos os endpoints (hosts), rede e pilha de software.
Temos vários grandes data centers na Rússia e no exterior. Eles estão unidos por um backbone que utiliza tecnologia MPLS. Nossa infraestrutura interna é quase inteiramente construída em IPv6, mas como precisamos atender o tráfego externo que ainda vem principalmente por IPv4, devemos de alguma forma entregar as solicitações que chegam por IPv4 aos servidores frontend, e um pouco mais ir para IPv4 externo - Internet - para por exemplo, para indexação.
As últimas iterações de projetos de rede de data center usaram topologias Clos multicamadas e são apenas L3. Saímos do L2 há um tempo e respiramos aliviados. Finalmente, nossa infraestrutura inclui centenas de milhares de instâncias de computação (servidor). O tamanho máximo do cluster há algum tempo era de cerca de 10 mil servidores. Isso se deve em grande parte à forma como esses mesmos sistemas operacionais em nível de cluster, agendadores, alocação de recursos etc. podem funcionar. Como o progresso ocorreu no lado do software de infraestrutura, o tamanho alvo é agora de cerca de 100 mil servidores em um cluster de computação, e Temos uma tarefa: ser capaz de construir fábricas de rede que permitam o agrupamento eficiente de recursos em tal cluster.
O que queremos de uma rede de data center? Em primeiro lugar, há muita largura de banda barata e distribuída de maneira bastante uniforme. Porque a rede é a espinha dorsal através da qual podemos reunir recursos. O novo tamanho alvo é de cerca de 100 mil servidores em um cluster.
É claro que também queremos um plano de controle escalável e estável, porque em uma infraestrutura tão grande surgem muitas dores de cabeça, mesmo de eventos simplesmente aleatórios, e não queremos que o plano de controle também nos traga dores de cabeça. Ao mesmo tempo, queremos minimizar o estado nele. Quanto menor a condição, melhor e mais estável tudo funciona e mais fácil é diagnosticar.
É claro que precisamos de automação, porque é impossível gerenciar manualmente essa infraestrutura, e isso já é impossível há algum tempo. Precisamos de apoio operacional tanto quanto possível e de apoio CI/CD na medida em que possa ser fornecido.
Com esses tamanhos de data centers e clusters, a tarefa de dar suporte à implantação e expansão incrementais sem interrupção do serviço tornou-se bastante difícil. Se em clusters com um tamanho de mil máquinas, talvez perto de dez mil máquinas, eles ainda pudessem ser implementados como uma operação - isto é, estamos planejando uma expansão da infra-estrutura, e vários milhares de máquinas são adicionadas como uma operação, então um cluster do tamanho de cem mil máquinas não surge imediatamente assim, ele é construído ao longo de um período de tempo. E é desejável que durante todo esse tempo o que já foi bombeado, a infraestrutura que foi implantada, esteja disponível.
E um requisito que tínhamos e saímos: suporte para multilocação, ou seja, virtualização ou segmentação de rede. Agora não precisamos fazer isso no nível da estrutura da rede, porque o sharding foi para os hosts, e isso tornou o dimensionamento muito fácil para nós. Graças ao IPv6 e a um grande espaço de endereçamento, não precisávamos usar endereços duplicados na infraestrutura interna; todo endereçamento já era único. E graças ao fato de termos levado a filtragem e a segmentação de rede aos hosts, não precisamos criar nenhuma entidade de rede virtual nas redes de data centers.
Uma coisa muito importante é o que não precisamos. Se algumas funções puderem ser retiradas da rede, isso facilita muito a vida e, via de regra, amplia a escolha de equipamentos e softwares disponíveis, tornando o diagnóstico muito simples.
Então, do que não precisamos, do que conseguimos abrir mão, nem sempre com alegria no momento em que aconteceu, mas com grande alívio quando o processo se completa?
Em primeiro lugar, abandonar L2. Não precisamos de L2, nem real nem emulado. Não utilizado em grande parte devido ao fato de controlarmos a pilha de aplicativos. Nossas aplicações são escaláveis horizontalmente, trabalham com endereçamento L3, não ficam muito preocupados com a saída de alguma instância individual, simplesmente lançam uma nova, não precisa ser implantada no endereço antigo, pois existe um nível separado de descoberta de serviço e monitoramento de máquinas localizadas no cluster. Não delegamos esta tarefa à rede. A função da rede é entregar pacotes do ponto A ao ponto B.
Também não temos situações em que os endereços se movam dentro da rede e isso precisa ser monitorado. Em muitos projetos, isso normalmente é necessário para dar suporte à mobilidade de VMs. Não utilizamos a mobilidade de máquinas virtuais na infraestrutura interna do grande Yandex e, além disso, acreditamos que mesmo que isso seja feito, não deverá acontecer com suporte de rede. Se você realmente precisa fazer isso, você precisa fazê-lo no nível do host e enviar endereços que podem migrar para sobreposições, de modo a não tocar ou fazer muitas alterações dinâmicas no sistema de roteamento do próprio underlay (rede de transporte) .
Outra tecnologia que não utilizamos é o multicast. Se você quiser, posso lhe contar em detalhes o porquê. Isso torna a vida muito mais fácil, porque se alguém tiver lidado com isso e observado exatamente como é o plano de controle multicast, em todas as instalações, exceto nas mais simples, isso será uma grande dor de cabeça. E mais, é difícil encontrar uma implementação de código aberto que funcione bem, por exemplo.
Finalmente, projetamos nossas redes para que não mudem muito. Podemos contar com o fato de que o fluxo de eventos externos no sistema de roteamento é pequeno.
Que problemas surgem e que restrições devem ser tidas em conta quando desenvolvemos uma rede de data centers? Custo, é claro. Escalabilidade, o nível em que queremos crescer. A necessidade de expandir sem parar o serviço. Largura de banda, disponibilidade. Visibilidade do que está acontecendo na rede para sistemas de monitoramento, para equipes operacionais. Suporte de automação - novamente, tanto quanto possível, uma vez que diferentes tarefas podem ser resolvidas em diferentes níveis, incluindo a introdução de camadas adicionais. Bem, não [possivelmente] dependente de fornecedores. Embora em diferentes períodos históricos, dependendo da secção que se olha, esta independência foi mais fácil ou mais difícil de alcançar. Se considerarmos um corte transversal de chips de dispositivos de rede, até recentemente era muito condicional falar sobre independência de fornecedores, se também quiséssemos chips com alto rendimento.
Que topologia lógica usaremos para construir nossa rede? Este será um Clos multinível. Na verdade, não existem alternativas reais neste momento. E a topologia Clos é muito boa, mesmo quando comparada a várias topologias avançadas que estão mais na área de interesse acadêmico agora, se tivermos switches de raiz grandes.
Como uma rede Clos multinível é estruturada aproximadamente e quais são os diferentes elementos nela chamados? Em primeiro lugar, a rosa dos ventos, para se orientar onde é norte, onde é sul, onde é leste, onde é oeste. Redes desse tipo são geralmente construídas por quem tem um tráfego oeste-leste muito grande. Quanto aos demais elementos, no topo está um switch virtual montado a partir de switches menores. Esta é a ideia principal da construção recursiva de redes Clos. Pegamos elementos com algum tipo de base e os conectamos para que o que obtemos possa ser considerado como uma chave com uma base maior. Se precisar de ainda mais, o procedimento pode ser repetido.
Nos casos, por exemplo, de Clos de dois níveis, quando é possível identificar claramente os componentes verticais em meu diagrama, eles geralmente são chamados de planos. Se construíssemos um Clos com três níveis de switches de coluna (todos os quais não são switches de limite ou ToR e são usados apenas para trânsito), então os planos pareceriam mais complexos; os de dois níveis seriam exatamente assim. Chamamos um bloco de ToR ou switches leaf e os switches de coluna de primeiro nível associados a eles de Pod. Os interruptores da coluna do nível da coluna 1 no topo do Pod são o topo do Pod, o topo do Pod. Os interruptores localizados na parte superior de toda a fábrica são a camada superior da fábrica, a parte superior do tecido.
Naturalmente, surge a questão: as redes Clos já são construídas há algum tempo; a ideia em si geralmente vem dos tempos da telefonia clássica, das redes TDM. Talvez algo melhor tenha aparecido, talvez algo possa ser feito melhor? Sim e não. Teoricamente sim, na prática num futuro próximo definitivamente não. Por haver uma série de topologias interessantes, algumas delas são até utilizadas em produção, por exemplo, Dragonfly é utilizado em aplicações HPC; Existem também topologias interessantes como Xpander, FatClique, Jellyfish. Se você olhar relatórios em conferências como SIGCOMM ou NSDI recentemente, poderá encontrar um número bastante grande de trabalhos sobre topologias alternativas que possuem propriedades melhores (uma ou outra) do que Clos.
Mas todas essas topologias possuem uma propriedade interessante. Impede a sua implementação em redes de centros de dados, que estamos a tentar construir em hardware comum e que custam dinheiro bastante razoável. Em todas essas topologias alternativas, infelizmente, a maior parte da largura de banda não é acessível através dos caminhos mais curtos. Portanto, perdemos imediatamente a oportunidade de utilizar o plano de controle tradicional.
Teoricamente, a solução para o problema é conhecida. Estas são, por exemplo, modificações do estado do link usando k-caminho mais curto, mas, novamente, não existem tais protocolos que seriam implementados na produção e amplamente disponíveis nos equipamentos.
Além disso, como a maior parte da capacidade não é acessível através dos caminhos mais curtos, precisamos modificar mais do que apenas o plano de controle para selecionar todos esses caminhos (e, a propósito, isso representa significativamente mais estado no plano de controle). Ainda precisamos modificar o plano de encaminhamento e, via de regra, são necessários pelo menos dois recursos adicionais. Esta é a capacidade de tomar todas as decisões sobre o encaminhamento de pacotes de uma só vez, por exemplo, no host. Na verdade, este é o roteamento de origem, às vezes na literatura sobre redes de interconexão isso é chamado de decisões de encaminhamento all-at-once. E o roteamento adaptativo é uma função que precisamos nos elementos da rede, que se resume, por exemplo, ao fato de selecionarmos o próximo salto com base nas informações sobre a menor carga na fila. Por exemplo, outras opções são possíveis.
Assim, a direção é interessante, mas, infelizmente, não podemos aplicá-la neste momento.
Ok, decidimos pela topologia lógica Clos. Como vamos dimensioná-lo? Vamos ver como funciona e o que pode ser feito.
Numa rede Clos existem dois parâmetros principais que podemos variar de alguma forma e obter determinados resultados: a base dos elementos e o número de níveis na rede. Eu tenho um diagrama esquemático de como ambos afetam o tamanho. Idealmente, combinamos ambos.
Pode-se observar que a largura final da rede Clos é o produto de todos os níveis de switches espinhais da raiz sul, quantos links temos abaixo, como ela se ramifica. É assim que dimensionamos o tamanho da rede.
Em relação à capacidade, especialmente em switches ToR, existem duas opções de escalonamento. Podemos, mantendo a topologia geral, usar links mais rápidos, ou podemos adicionar mais planos.
Se você olhar a versão expandida da rede Clos (no canto inferior direito) e retornar a esta imagem com a rede Clos abaixo...
... então esta é exatamente a mesma topologia, mas neste slide ela é recolhida de forma mais compacta e os planos da fábrica ficam sobrepostos uns aos outros. É o mesmo.
Como é o dimensionamento de uma rede Clos em números? Aqui forneço dados sobre qual largura máxima uma rede pode ser obtida, qual número máximo de racks, switches ToR ou switches leaf, se não estiverem em racks, podemos obter dependendo de qual raiz de switches usamos para níveis de coluna, e quantos níveis usamos.
Veja quantos racks podemos ter, quantos servidores e aproximadamente quanto tudo isso pode consumir com base em 20 kW por rack. Mencionei um pouco antes que pretendemos um tamanho de cluster de cerca de 100 mil servidores.
Percebe-se que em todo esse design interessam duas opções e meia. Existe uma opção com duas camadas de espinhos e switches de 64 portas, o que fica um pouco aquém. Depois, há opções perfeitamente adequadas para switches de coluna de 128 portas (com base 128) com dois níveis ou switches com base 32 com três níveis. E em todos os casos, onde há mais bases e mais camadas, você pode fazer uma rede muito grande, mas se você olhar o consumo esperado, normalmente são gigawatts. É possível instalar um cabo, mas é pouco provável que consigamos tanta electricidade num só local. Se você olhar as estatísticas e os dados públicos sobre data centers, poderá encontrar muito poucos data centers com capacidade estimada em mais de 150 MW. Os maiores geralmente são campi de data centers, vários grandes data centers localizados bem próximos uns dos outros.
Existe outro parâmetro importante. Se você olhar para a coluna da esquerda, a largura de banda utilizável está listada lá. É fácil ver que em uma rede Clos uma parte significativa das portas é usada para conectar switches entre si. Largura de banda utilizável, uma faixa útil, é algo que pode ser fornecido externamente, em direção aos servidores. Naturalmente, estou falando de portas condicionais e especificamente de banda. Via de regra, os links dentro da rede são mais rápidos do que os links para servidores, mas por unidade de largura de banda, por mais que possamos enviá-la para nosso equipamento de servidor, ainda há alguma largura de banda dentro da própria rede. E quanto mais níveis fizermos, maior será o custo específico de fornecer essa faixa para o exterior.
Além disso, mesmo esta banda adicional não é exactamente a mesma. Embora os vãos sejam curtos, podemos usar algo como DAC (cobre de conexão direta, ou seja, cabos twinax) ou óptica multimodo, que custam ainda mais ou menos dinheiro razoável. Assim que passamos para vãos mais longos - como regra, são ópticas de modo único, e o custo dessa largura de banda adicional aumenta visivelmente.
E novamente, voltando ao slide anterior, se criarmos uma rede Clos sem excesso de assinaturas, então é fácil olhar o diagrama, ver como a rede é construída - somando cada nível de switches de coluna, repetimos toda a faixa que estava no fundo. Nível Plus - mais a mesma banda, o mesmo número de portas nos switches que havia no nível anterior e o mesmo número de transceptores. Portanto, é altamente desejável minimizar o número de níveis de interruptores de coluna.
Com base nesta imagem, fica claro que realmente queremos construir algo como switches com base 128.
Aqui, em princípio, tudo é igual ao que acabei de dizer, este é um slide para consideração mais tarde.
Que opções existem que podemos escolher como opções? É uma notícia muito agradável para nós que agora essas redes possam finalmente ser construídas em switches de chip único. E isso é muito legal, eles têm muitos recursos interessantes. Por exemplo, eles quase não têm estrutura interna. Isso significa que eles quebram com mais facilidade. Eles quebram de todas as maneiras, mas felizmente quebram completamente. Nos dispositivos modulares há um grande número de falhas (muito desagradáveis), quando do ponto de vista dos vizinhos e do plano de controle parece estar funcionando, mas, por exemplo, parte da malha foi perdida e não está funcionando em plena capacidade. E o tráfego para ele é equilibrado pelo fato de estar totalmente funcional e podemos ficar sobrecarregados.
Ou, por exemplo, surgem problemas com o backplane, porque dentro do dispositivo modular também existem SerDes de alta velocidade - é realmente complexo por dentro. Os sinais entre os elementos de encaminhamento estão sincronizados ou não sincronizados. Em geral, qualquer dispositivo modular produtivo composto por um grande número de elementos, via de regra, contém dentro de si a mesma rede Clos, mas é muito difícil de diagnosticar. Muitas vezes é difícil até mesmo para o próprio fornecedor diagnosticar.
E tem um grande número de cenários de falha em que o dispositivo se degrada, mas não sai completamente da topologia. Como nossa rede é grande, o equilíbrio entre elementos idênticos é utilizado ativamente, a rede é muito regular, ou seja, um caminho em que tudo está em ordem não difere do outro caminho, é mais lucrativo para nós simplesmente perdermos alguns dos os dispositivos da topologia do que acabar em uma situação em que alguns deles parecem funcionar, mas outros não.
A próxima característica interessante dos dispositivos de chip único é que eles evoluem melhor e mais rápido. Eles também tendem a ter melhor capacidade. Se considerarmos as grandes estruturas montadas que temos em círculo, então a capacidade por unidade de rack para portas da mesma velocidade é quase duas vezes melhor que a dos dispositivos modulares. Dispositivos construídos em torno de um único chip são visivelmente mais baratos que os modulares e consomem menos energia.
Mas, claro, tudo isso tem uma razão, também existem desvantagens. Em primeiro lugar, a base é quase sempre menor que a dos dispositivos modulares. Se conseguirmos um dispositivo construído em torno de um chip com 128 portas, então poderemos obter um dispositivo modular com várias centenas de portas agora sem problemas.
Este é um tamanho visivelmente menor de tabelas de encaminhamento e, como regra, tudo relacionado à escalabilidade do plano de dados. Buffers rasos. E, via de regra, funcionalidade bastante limitada. Mas acontece que se você conhece essas restrições e toma cuidado para contorná-las a tempo ou simplesmente levá-las em consideração, então isso não é tão assustador. O fato da raiz ser menor não é mais um problema em dispositivos com raiz de 128 que finalmente apareceram recentemente; podemos construir em duas camadas de espinhas. Mas ainda é impossível construir algo menor que dois que seja interessante para nós. Com um nível, são obtidos clusters muito pequenos. Mesmo nossos projetos e requisitos anteriores ainda os excediam.
Na verdade, se de repente a solução estiver em algum lugar no limite, ainda há uma maneira de escalar. Como o último (ou primeiro) nível mais baixo onde os servidores estão conectados são switches ToR ou switches leaf, não somos obrigados a conectar um rack a eles. Portanto, se a solução ficar aquém da metade, você pode pensar em simplesmente usar um switch com uma base grande no nível inferior e conectar, por exemplo, dois ou três racks em um switch. Essa também é uma opção, tem seus custos, mas funciona muito bem e pode ser uma boa solução quando você precisa atingir cerca do dobro do tamanho.
Resumindo, estamos construindo uma topologia com dois níveis de espinhas, com oito camadas de fábrica.
O que acontecerá com a física? Cálculos muito simples. Se tivermos dois níveis de espinhos, então teremos apenas três níveis de switches, e esperamos que haja três segmentos de cabos na rede: dos servidores aos switches leaf, para a espinha 1, para a espinha 2. As opções que podemos uso são - estes são twinax, multimodo, modo único. E aqui precisamos considerar qual faixa está disponível, quanto custará, quais são as dimensões físicas, quais vãos podemos cobrir e como iremos atualizar.
Em termos de custo, tudo pode ser alinhado. Os Twinaxes são significativamente mais baratos que a óptica ativa, mais baratos que os transceptores multimodo, se você fizer isso por voo a partir do final, um pouco mais barato que uma porta de switch de 100 gigabit. E, observe, custa menos do que a óptica monomodo, porque em voos onde o modo único é necessário, em data centers, por uma série de razões, faz sentido usar CWDM, enquanto o modo único paralelo (PSM) não é muito conveniente para trabalhar com, obtêm-se embalagens muito grandes de fibras, e se focarmos nessas tecnologias, obtemos aproximadamente a seguinte hierarquia de preços.
Mais uma observação: infelizmente não é muito possível utilizar portas multimodo 100 a 4x25 desmontadas. Devido aos recursos de design dos transceptores SFP28, não é muito mais barato que o QSFP28 de 100 Gbit. E essa desmontagem para multimodo não funciona muito bem.
Outra limitação é que devido ao tamanho dos clusters de computação e ao número de servidores, nossos data centers acabam sendo fisicamente grandes. Isso significa que pelo menos um voo deverá ser feito com um singlemod. Novamente, devido ao tamanho físico dos Pods, não será possível passar dois vãos de twinax (cabos de cobre).
Como resultado, se otimizarmos o preço e levarmos em conta a geometria deste projeto, obteremos um intervalo de twinax, um intervalo de multimodo e um intervalo de monomodo usando CWDM. Isso leva em consideração possíveis caminhos de atualização.
Isto é o que parece recentemente, para onde estamos indo e o que é possível. Está claro, pelo menos, como avançar em direção ao SerDes de 50 Gigabit para multimodo e monomodo. Além disso, se você observar o que está nos transceptores monomodo agora e no futuro para 400G, muitas vezes, mesmo quando o SerDes 50G chega do lado elétrico, 100 Gbps por pista já podem ir para a óptica. Portanto, é bem possível que em vez de passar para 50, haja uma transição para 100 Gigabit SerDes e 100 Gbps por via, pois de acordo com as promessas de muitos fornecedores, sua disponibilidade é esperada para muito em breve. O período em que o SerDes 50G foi o mais rápido, ao que parece, não será muito longo, porque as primeiras cópias do SerDes 100G serão lançadas quase no ano que vem. E depois de algum tempo, provavelmente valerão um dinheiro razoável.
Mais uma nuance sobre a escolha da física. Em princípio, já podemos usar portas de 400 ou 200 Gigabit usando 50G SerDes. Mas acontece que isso não faz muito sentido, porque, como eu disse anteriormente, queremos uma base bastante grande nos switches, dentro do razoável, é claro. Queremos 128. E se tivermos capacidade limitada de chip e aumentarmos a velocidade do link, então a raiz diminui naturalmente, não há milagres.
E podemos aumentar a capacidade total usando aviões, e não há custos especiais, podemos somar o número de aviões. E se perdermos a raiz, teremos que introduzir um nível adicional, então na situação atual, com a atual capacidade máxima disponível por chip, verifica-se que é mais eficiente usar portas de 100 gigabits, porque elas permitem você para obter uma raiz maior.
A próxima questão é como a física está organizada, mas do ponto de vista da infraestrutura de cabos. Acontece que está organizado de uma forma bastante engraçada. Cabeamento entre leaf-switches e espinhos de primeiro nível - não há muitos links lá, tudo é construído de forma relativamente simples. Mas se pegarmos um plano, o que acontece lá dentro é que precisamos conectar todos os espinhos do primeiro nível com todos os espinhos do segundo nível.
Além disso, como regra, há alguns desejos sobre como deveria ser a aparência dentro do data center. Por exemplo, queríamos realmente combinar os cabos em um feixe e puxá-los de forma que um patch panel de alta densidade fosse inteiramente em um patch panel, de modo que não houvesse zoológico em termos de comprimento. Conseguimos resolver esse problema. Se você observar inicialmente a topologia lógica, verá que os planos são independentes, cada plano pode ser construído por conta própria. Mas quando adicionamos tal pacote e queremos arrastar todo o patch panel para um patch panel, temos que misturar diferentes planos dentro de um pacote e introduzir uma estrutura intermediária na forma de conexões cruzadas ópticas para reembalá-los de como foram montados em um segmento, em como serão coletados em outro segmento. Graças a isso, obtemos um recurso interessante: toda a comutação complexa não vai além dos racks. Quando você precisa entrelaçar algo com muita força, “desdobrar os planos”, como às vezes é chamado nas redes Clos, tudo fica concentrado dentro de um rack. Não desmontamos altamente, até links individuais, alternando entre racks.
É assim que parece do ponto de vista da organização lógica da infraestrutura de cabos. Na imagem à esquerda, os blocos multicoloridos representam blocos de interruptores de coluna de primeiro nível, oito peças cada, e quatro feixes de cabos provenientes deles, que vão e se cruzam com os feixes provenientes dos blocos de interruptores de coluna 2 .
Pequenos quadrados indicam interseções. No canto superior esquerdo há um detalhamento de cada interseção; na verdade, é um módulo de conexão cruzada de 512 por 512 portas que reembala os cabos para que eles fiquem completamente em um rack, onde há apenas um plano de coluna 2. E à direita, uma varredura desta imagem é um pouco mais detalhada em relação a vários Pods no nível da lombada 1, e como eles são empacotados em uma conexão cruzada, como chegam ao nível da lombada 2.
Isto é o que parece. O suporte Spine-2 ainda não totalmente montado (à esquerda) e o suporte de conexão cruzada. Infelizmente, não há muito para ver lá. Toda essa estrutura está sendo implantada neste momento em um dos nossos grandes data centers que está em expansão. Este é um trabalho em andamento, ficará mais bonito, será melhor preenchido.
Uma questão importante: escolhemos a topologia lógica e construímos a física. O que acontecerá com o plano de controle? É bem sabido pela experiência operacional que há vários relatos de que os protocolos de estado de link são bons, é um prazer trabalhar com eles, mas, infelizmente, eles não se adaptam bem em uma topologia densamente conectada. E há um fator principal que impede isso: é assim que funciona a inundação em protocolos de estado de link. Se você apenas pegar o algoritmo de inundação e observar como nossa rede está estruturada, verá que haverá um fanout muito grande em cada etapa e simplesmente inundará o plano de controle com atualizações. Especificamente, tais topologias combinam muito pouco com o algoritmo de inundação tradicional em protocolos de estado de link.
A escolha é usar BGP. Como prepará-lo corretamente está descrito na RFC 7938 sobre o uso do BGP em grandes data centers. As ideias básicas são simples: número mínimo de prefixos por host e geralmente número mínimo de prefixos na rede, usar agregação se possível e suprimir a busca de caminhos. Queremos uma distribuição de atualizações muito cuidadosa e controlada, o que é chamado de vale grátis. Queremos que as atualizações sejam implantadas exatamente uma vez ao passarem pela rede. Se originam-se na parte inferior, sobem, desdobrando-se no máximo uma vez. Não deve haver ziguezagues. Ziguezagues são muito ruins.
Para fazer isso, usamos um design simples o suficiente para usar os mecanismos BGP subjacentes. Ou seja, usamos eBGP rodando no link local, e os sistemas autônomos são atribuídos da seguinte forma: um sistema autônomo no ToR, um sistema autônomo em todo o bloco de switches Spine-1 de um Pod e um sistema autônomo geral em todo o Top de Tecido. Não é difícil olhar e ver que mesmo o comportamento normal do BGP nos dá a distribuição de atualizações que desejamos.
Naturalmente, o endereçamento e a agregação de endereços devem ser projetados de forma que sejam compatíveis com a forma como o roteamento é construído, de modo que garantam a estabilidade do plano de controle. O endereçamento L3 no transporte está vinculado à topologia, porque sem isso é impossível obter agregação; sem isso, endereços individuais entrarão no sistema de roteamento. E mais uma coisa é que agregação, infelizmente, não combina muito bem com multicaminho, porque quando temos multicaminho e temos agregação, está tudo bem, quando toda a rede está saudável, não há falhas nela. Infelizmente, assim que surgirem falhas na rede e se perder a simetria da topologia, podemos chegar ao ponto a partir do qual a unidade foi anunciada, a partir do qual não podemos ir mais longe para onde precisamos ir. Portanto, é melhor agregar onde não há mais multicaminhos; no nosso caso, são switches ToR.
Na verdade é possível agregar, mas com cuidado. Se pudermos fazer desagregação controlada quando ocorrerem falhas na rede. Mas esta é uma tarefa bastante difícil, até nos perguntamos se seria possível fazer isso, se seria possível adicionar automação adicional e máquinas de estado finito que ativassem corretamente o BGP para obter o comportamento desejado. Infelizmente, o processamento de casos extremos é pouco óbvio e complexo, e essa tarefa não é bem resolvida anexando anexos externos ao BGP.
Um trabalho muito interessante a este respeito foi realizado no âmbito do protocolo RIFT, que será discutido no próximo relatório.
Outra coisa importante é como os planos de dados são dimensionados em topologias densas, onde temos um grande número de caminhos alternativos. Neste caso, são utilizadas diversas estruturas de dados adicionais: grupos ECMP, que por sua vez descrevem grupos Next Hop.
Em uma rede funcionando normalmente, sem falhas, quando subimos a topologia Clos, basta usar apenas um grupo, pois tudo que não é local é descrito por padrão, podemos subir. Quando vamos de cima para baixo para o sul, então todos os caminhos não são ECMP, são caminhos de caminho único. Tudo está bem. O problema é que a peculiaridade da topologia Clos clássica é que se olharmos para o topo do tecido, para qualquer elemento, existe apenas um caminho para qualquer elemento abaixo. Se ocorrerem falhas ao longo desse caminho, esse elemento específico no topo da fábrica se tornará inválido precisamente para os prefixos que estão por trás do caminho quebrado. Mas de resto é válido, e temos que analisar os grupos ECMP e introduzir um novo estado.
Como é a escalabilidade do plano de dados em dispositivos modernos? Se fizermos LPM (correspondência de prefixo mais longa), tudo ficará muito bom, mais de 100 mil prefixos. Se falamos de grupos Next Hop, então tudo é pior, 2 a 4 mil. Se estamos falando de uma tabela que contém uma descrição dos próximos saltos (ou adjacências), então isso está entre 16k e 64k. E isso pode se tornar um problema. E aqui chegamos a uma digressão interessante: o que aconteceu com o MPLS nos data centers? Em princípio, queríamos fazer isso.
Duas coisas aconteceram. Fizemos microssegmentação nos hosts, não precisávamos mais fazer isso na rede. Não foi muito bom com suporte de diferentes fornecedores, e mais ainda com implementações abertas em caixas brancas com MPLS. E o MPLS, pelo menos suas implementações tradicionais, infelizmente, combina muito mal com o ECMP. E é por causa disso.
Esta é a aparência da estrutura de encaminhamento do ECMP para IP. Um grande número de prefixos pode usar o mesmo grupo e o mesmo bloco Next Hops (ou adjacências, isso pode ser chamado de forma diferente em documentação diferente para dispositivos diferentes). A questão é que esta é descrita como a porta de saída e onde reescrever o endereço MAC para chegar ao próximo salto correto. Para IP tudo parece simples, você pode usar um número muito grande de prefixos para o mesmo grupo, o mesmo bloco Next Hops.
A arquitetura MPLS clássica implica que, dependendo da interface de saída, o rótulo pode ser reescrito com valores diferentes. Portanto, precisamos manter um grupo e um bloco Next Hops para cada rótulo de entrada. E isso, infelizmente, não escala.
É fácil ver que em nosso projeto precisávamos de cerca de 4000 switches ToR, a largura máxima era de 64 caminhos ECMP, se nos afastarmos da coluna 1 em direção à coluna 2. Mal entramos em uma tabela de grupos ECMP, se apenas um prefixo com ToR desaparecer, e não entramos na tabela Next Hops.
Nem tudo é impossível, porque arquiteturas como o Segment Routing envolvem rótulos globais. Formalmente, seria possível recolher novamente todos esses blocos Next Hops. Para fazer isso, você precisa de uma operação do tipo curinga: pegue um rótulo e reescreva-o no mesmo sem um valor específico. Mas infelizmente isso não está muito presente nas implementações disponíveis.
E, finalmente, precisamos trazer o tráfego externo para o data center. Como fazer isso? Anteriormente, o tráfego era introduzido na rede Clos por cima. Ou seja, havia roteadores de borda que se conectavam a todos os dispositivos na parte superior da malha. Esta solução funciona muito bem em tamanhos pequenos e médios. Infelizmente, para enviar tráfego simetricamente para toda a rede desta forma, precisamos chegar simultaneamente a todos os elementos do Top of fabric, e quando há mais de cem deles, verifica-se que também precisamos de um grande raiz nos roteadores de borda. Em geral, isso custa dinheiro, porque os roteadores de borda são mais funcionais, as portas neles serão mais caras e o design não é muito bonito.
Outra opção é iniciar esse tráfego por baixo. É fácil verificar que a topologia Clos é construída de forma que o tráfego vindo de baixo, ou seja, do lado ToR, seja distribuído uniformemente entre os níveis ao longo de todo o Top of fabric em duas iterações, carregando toda a rede. Portanto, apresentamos um tipo especial de Pod, Edge Pod, que fornece conectividade externa.
Existe mais uma opção. É isso que o Facebook faz, por exemplo. Eles o chamam de Fabric Aggregator ou HGRID. Um nível de coluna adicional está sendo introduzido para conectar vários data centers. Este design é possível se não tivermos funções adicionais ou alterações de encapsulamento nas interfaces. Se forem pontos de contato adicionais, é difícil. Normalmente, existem mais funções e uma espécie de membrana que separa as diferentes partes do data center. Não adianta aumentar essa membrana, mas se ela for realmente necessária por algum motivo, faz sentido considerar a possibilidade de retirá-la, torná-la o mais larga possível e transferi-la para os hospedeiros. Isto é feito, por exemplo, por muitos operadores de nuvem. Eles têm sobreposições, começam pelos anfitriões.
Que oportunidades de desenvolvimento vemos? Em primeiro lugar, melhorar o suporte ao pipeline de CI/CD. Queremos voar da forma como testamos e testar a forma como voamos. Isso não funciona muito bem, porque a infraestrutura é grande e é impossível duplicá-la para testes. Você precisa entender como introduzir elementos de teste na infraestrutura de produção sem abandoná-la.
Melhor instrumentação e melhor monitoramento quase nunca são supérfluos. A questão toda é um equilíbrio entre esforço e retorno. Se você puder adicioná-lo com um esforço razoável, muito bom.
Sistemas operacionais abertos para dispositivos de rede. Melhores protocolos e melhores sistemas de roteamento, como o RIFT. Também é necessária investigação sobre a utilização de melhores esquemas de controlo de congestionamento e talvez a introdução, pelo menos em alguns pontos, do apoio RDMA dentro do cluster.
Olhando mais adiante, precisamos de topologias avançadas e possivelmente de redes que utilizem menos sobrecarga. Das novidades, recentemente houve publicações sobre a tecnologia de malha para HPC Cray Slingshot, que é baseada em Ethernet comum, mas com a opção de usar cabeçalhos muito mais curtos. Como resultado, a sobrecarga é reduzida.
Tudo deve ser o mais simples possível, mas não mais simples. A complexidade é inimiga da escalabilidade. Simplicidade e estruturas regulares são nossas amigas. Se você puder expandir em algum lugar, faça-o. E, em geral, é ótimo estar envolvido em tecnologias de rede agora. Há muitas coisas interessantes acontecendo. Obrigado.
Fonte: habr.com