Os data centers modernos possuem centenas de dispositivos ativos cobertos por diferentes tipos de monitoramento. Mas mesmo um engenheiro perfeito com monitoramento perfeito em mãos será capaz de responder adequadamente a uma falha de rede em apenas alguns minutos. Em um relatório na conferência Next Hop 2020, apresentei uma metodologia de design de rede de data center que possui um recurso exclusivo - o data center se recupera em milissegundos. Mais precisamente, o engenheiro resolve o problema com calma, enquanto os serviços simplesmente não percebem.
Para muitos engenheiros de rede, a rede do data center começa, é claro, com ToR, com um switch no rack. ToR geralmente tem dois tipos de links. Os mais pequenos vão para os servidores, outros - são N vezes mais - vão para as espinhas de primeiro nível, ou seja, para os seus uplinks. Os uplinks geralmente são considerados iguais e o tráfego entre os uplinks é balanceado com base no hash de 5 tuplas, que inclui proto, src_ip, dst_ip, src_port, dst_port. Não há surpresas aqui.
Em seguida, como é a arquitetura dos aviões? Os espinhos do primeiro nível não estão conectados entre si, mas sim por meio de superspins. A letra X será responsável pelos superspins, é quase como um cross-connect.
E é claro que, por outro lado, os tori estão conectados a todas as espinhas do primeiro nível. O que é importante nesta imagem? Se tivermos interação dentro do rack, então a interação, claro, passa pelo ToR. Se a interação ocorrer dentro do módulo, a interação passará pelos espinhos do primeiro nível. Se a interação for intermodular - como aqui, ToR 1 e ToR 2 - então a interação passará pelas espinhas do primeiro e segundo níveis.
Teoricamente, tal arquitetura é facilmente escalável. Se tivermos capacidade de porta, uma reserva de espaço no datacenter e uma fibra pré-instalada, então o número de aviões pode sempre ser aumentado, aumentando assim a capacidade geral do sistema. No papel, isso é muito fácil de fazer. Seria assim na vida real. Mas a história de hoje não é sobre isso.
Eu quero que as conclusões certas sejam tiradas. Temos muitos caminhos dentro do data center. Eles são condicionalmente independentes. Uma maneira de entrar no data center só é possível dentro do ToR. Dentro do módulo, temos o mesmo número de caminhos que o número de planos. O número de caminhos entre os módulos é igual ao produto do número de planos e o número de superspins em cada plano. Para deixar mais claro, para sentir a escala, darei os números válidos para um dos data centers Yandex.
Existem oito aviões, cada avião tem 32 superspins. Como resultado, verifica-se que existem oito caminhos dentro do módulo e, com a interação entre módulos, já existem 256 deles.
Ou seja, se estivermos desenvolvendo um livro de receitas, tentando aprender como construir data centers tolerantes a falhas que se recuperem sozinhos, então a arquitetura planar é a escolha certa. Ele permite que você resolva o problema de dimensionamento e, teoricamente, é fácil. Existem muitos caminhos independentes. A questão permanece: como tal arquitetura sobrevive a falhas? Existem vários travamentos. E vamos discutir isso agora.
Deixe um dos nossos superspins ficar doente. Aqui retornei à arquitetura de dois planos. Vamos ficar com eles como exemplo porque simplesmente será mais fácil ver o que está acontecendo aqui com menos partes móveis. Deixe X11 ficar doente. Como isso afetará os serviços que residem nos data centers? Depende muito de como a falha realmente parece.
Se a falha for boa, ela for detectada no nível de automação do mesmo BFD, a automação felizmente coloca juntas problemáticas e isola o problema, então está tudo bem. Temos muitos caminhos, o tráfego é redirecionado instantaneamente para rotas alternativas e os serviços não notam nada. Este é um bom cenário.
Um cenário ruim é se tivermos perdas constantes e a automação não perceber o problema. Para entender como isso afeta o aplicativo, teremos que gastar um pouco de tempo discutindo como funciona o protocolo TCP.
Espero não chocar ninguém com esta informação: o TCP é um protocolo de handshake. Ou seja, no caso mais simples, o remetente envia dois pacotes e recebe um ACK cumulativo sobre eles: "Recebi dois pacotes".
Depois disso, ele enviará mais dois pacotes e a situação se repetirá. Peço desculpas antecipadamente por alguma simplificação. Este cenário está correto se a janela (número de pacotes em trânsito) for dois. Claro, isso não é necessariamente o caso em geral. Mas o contexto de encaminhamento de pacotes não é afetado pelo tamanho da janela.
O que acontece se perdermos o pacote 3? Nesse caso, o destinatário receberá os pacotes 1, 2 e 4. E ele informará explicitamente ao remetente usando a opção SACK: “Sabe, três vieram, mas o meio foi perdido”. Ele diz "Ack 2, SACK 4".
O remetente neste momento repete exatamente o pacote que foi perdido sem problemas.
Mas se o último pacote na janela for perdido, a situação parecerá muito diferente.
O destinatário recebe os três primeiros pacotes e antes de mais nada começa a esperar. Graças a algumas otimizações na pilha TCP do kernel do Linux, ele aguardará um pacote emparelhado, a menos que haja uma indicação explícita nos sinalizadores de que este é o último pacote ou algo parecido. Ele aguardará até que o tempo limite do ACK atrasado expire e, em seguida, enviará uma confirmação para os três primeiros pacotes. Mas agora o remetente estará esperando. Ele não sabe se o quarto pacote foi extraviado ou está para chegar. E para não sobrecarregar a rede, ele tentará aguardar a indicação explícita de que o pacote foi perdido ou o término do timeout do RTO.
O que é tempo limite de RTO? Este é o máximo do RTT calculado pela pilha TCP e alguma constante. O que é essa constante, discutiremos agora.
Mas é importante que, se tivermos azar novamente e o quarto pacote for perdido novamente, o RTO dobre. Ou seja, cada tentativa malsucedida é uma duplicação do tempo limite.
Agora vamos ver a que esta base é igual. Por padrão, o RTO mínimo é de 200ms. Este é o RTO mínimo para pacotes de dados. Para pacotes SYN, é diferente, 1 segundo. Como você pode ver, mesmo a primeira tentativa de reenviar pacotes levará 100 vezes mais do que o RTT dentro do data center.
Agora, de volta ao nosso cenário. O que está acontecendo com o serviço? O serviço começa a perder pacotes. Deixe o serviço inicialmente ter sorte e perder algo no meio da janela, então ele recebe um SACK, reenvia os pacotes perdidos.
Mas se o azar se repetir, então temos um RTO. O que é importante aqui? Sim, temos muitos caminhos na rede. Mas o tráfego TCP de uma conexão TCP específica continuará passando pela mesma pilha quebrada. A perda de pacotes, desde que nosso X11 mágico não saia sozinho, não faz com que o tráfego flua para áreas que não são problemáticas. Estamos tentando entregar um pacote através da mesma pilha quebrada. Isso leva a uma falha em cascata: um data center é um conjunto de aplicativos em interação e algumas das conexões TCP de todos esses aplicativos começam a se degradar - porque o superspin afeta todos os aplicativos que estão dentro do data center. Como no ditado: se você não ferrar um cavalo, o cavalo manca; o cavalo mancava - o relatório não foi entregue; a mensagem não foi entregue - eles perderam a guerra. Só aqui a contagem vai por segundos desde o momento em que ocorre o problema até a fase de degradação que os serviços começam a sentir. Isso significa que os usuários podem não receber algo em algum lugar.
Existem duas soluções clássicas que se complementam. O primeiro são os serviços que estão tentando colocar palhas e resolver o problema assim: “Vamos ajustar algo na pilha TCP. E vamos criar tempos limite no nível do aplicativo ou sessões TCP de longa duração com verificações internas de integridade. O problema é que tais soluções: a) não escalam; b) muito mal testado. Ou seja, mesmo que o serviço configure acidentalmente a pilha TCP para que fique melhor, em primeiro lugar, é improvável que seja aplicável a todos os aplicativos e todos os data centers e, em segundo lugar, provavelmente não entenderá o que foi feito corretamente e o que não. Ou seja, funciona, mas funciona mal e não escala. E se houver um problema de rede, de quem é a culpa? Claro NOC. O que o NOC faz?
Muitos serviços acreditam que no NOC o trabalho é mais ou menos assim. Mas para ser honesto, não só.
O NOC no esquema clássico está envolvido no desenvolvimento de muitos monitoramentos. Estes são monitoramento de caixa preta e monitoramento de caixa branca. Sobre o exemplo de monitoramento de caixa preta de espinhos Alexander Klimenko no passado Next Hop. A propósito, esse monitoramento funciona. Mas mesmo o monitoramento perfeito terá um intervalo de tempo. Normalmente são vários minutos. Depois que funciona, os engenheiros de plantão precisam de tempo para verificar novamente sua operação, localizar o problema e, em seguida, extinguir a área problemática. Ou seja, na melhor das hipóteses, o tratamento do problema leva 5 minutos, na pior das hipóteses 20 minutos, se não for imediatamente óbvio onde ocorrem as perdas. É claro que todo esse tempo - 5 ou 20 minutos - nossos serviços continuarão doendo, o que provavelmente não é bom.
O que você gostaria de receber? Temos tantos caminhos. E os problemas surgem justamente porque os fluxos TCP que não têm sorte continuam usando a mesma rota. Precisamos de algo que nos permita usar várias rotas em uma única conexão TCP. Parece que temos uma solução. Existe o TCP, que é chamado assim - TCP multipath, ou seja, TCP para muitos caminhos. É verdade que foi desenvolvido para uma tarefa completamente diferente - para smartphones que possuem vários dispositivos de rede. Para maximizar a transferência ou fazer o modo primário/backup, foi desenvolvido um mecanismo que cria de forma transparente vários threads (sessões) para a aplicação e permite alternar entre eles em caso de falha. Ou, como eu disse, maximize a largura de banda.
Mas há uma nuance aqui. Para entender o que é, teremos que ver como os fluxos são configurados.
Os encadeamentos são definidos sequencialmente. O primeiro fluxo é instalado primeiro. Os fluxos subseqüentes são definidos usando o cookie já acordado nesse encadeamento. E aqui está o problema.
O problema é que, se o primeiro thread não for instalado, o segundo e o terceiro threads nunca serão ativados. Ou seja, o multipath TCP não resolve a perda do pacote SYN no primeiro fluxo. E se o SYN for perdido, o multipath TCP torna-se o TCP normal. Portanto, em um ambiente de data center, não nos ajudará a resolver o problema de perdas na fábrica e aprender a usar vários caminhos em caso de falha.
O que pode nos ajudar? Alguns de vocês já adivinharam pelo nome que o campo de cabeçalho do rótulo de fluxo IPv6 será um campo importante em nossa próxima história. Aliás, esse é um campo que aparece na v6, não está na v4, leva 20 bits, e há muito tempo há polêmica sobre seu uso. Isso é muito interessante - houve disputas, algo foi corrigido na estrutura do RFC e, ao mesmo tempo, apareceu uma implementação no kernel do Linux que nunca foi documentada em nenhum lugar.
Eu sugiro que você se junte a mim em uma pequena investigação. Vamos dar uma olhada no que está acontecendo no kernel do Linux nos últimos anos.
ano de 2014. Um engenheiro de uma grande e conceituada empresa adiciona à funcionalidade do kernel do Linux a dependência do valor do rótulo do fluxo no hash do soquete. O que eles estão tentando consertar aqui? Isso está relacionado ao RFC 6438, que discutiu o seguinte problema. Dentro do data center, o IPv4 geralmente é encapsulado em pacotes IPv6, porque a fábrica em si é IPv6, mas o IPv4 deve ser distribuído de alguma forma. Por muito tempo, houve problemas com switches que não podiam procurar em dois cabeçalhos IP para chegar a TCP ou UDP e encontrar src_ports, dst_ports lá. Descobriu-se que o hash, se você observar os dois primeiros cabeçalhos IP, estava quase fixo. Para evitar isso, para que o balanceamento desse tráfego encapsulado funcione corretamente, foi proposto adicionar um hash do pacote encapsulado de 5 tuplas ao valor do campo do rótulo do fluxo. Aproximadamente o mesmo foi feito para outros esquemas de encapsulamento, para UDP, para GRE, neste último foi utilizado o campo GRE Key. De uma forma ou de outra, os objetivos aqui são claros. E pelo menos naquele momento eles foram úteis.
Em 2015, um novo patch vem do mesmo engenheiro respeitado. Ele é muito interessante. Ele diz o seguinte - vamos randomizar o hash no caso de um evento de roteamento negativo. O que é um evento de roteamento negativo? Esse é o RTO que discutimos anteriormente, ou seja, a perda da cauda da janela é um evento realmente negativo. É verdade que é relativamente difícil adivinhar o que é.
2016, outra empresa respeitada, também grande. Ele analisa as últimas muletas e faz com que o hash que tornamos aleatório anteriormente seja alterado a cada retransmissão SYN e após cada tempo limite de RTO. E nesta carta, pela primeira e última vez, soa o objetivo final - garantir que o tráfego em caso de perda ou sobrecarga de canais tenha a possibilidade de reencaminhamento suave, usando vários caminhos. Claro, depois disso houve muitas publicações, você pode encontrá-las facilmente.
Embora não, você não pode, porque não houve uma única publicação sobre este tópico. Mas nós sabemos!
E se você não entender completamente o que foi feito, vou lhe contar agora.
O que foi feito, que funcionalidade foi adicionada ao kernel do Linux? txhash muda para um valor aleatório após cada evento RTO. Este é o mesmo resultado de roteamento negativo. O hash depende desse txhash e o rótulo do fluxo depende do hash skb. Existem alguns cálculos sobre as funções aqui, todos os detalhes não podem ser colocados em um slide. Se alguém estiver curioso, você pode examinar o código do kernel e verificar.
O que é importante aqui? O valor do campo de rótulo de fluxo muda para um número aleatório após cada RTO. Como isso afeta nosso infeliz fluxo TCP?
No caso de um SACK, nada mudou porque estamos tentando reenviar um pacote perdido conhecido. Até agora tudo bem.
Mas no caso do RTO, desde que tenhamos adicionado um rótulo de fluxo à função hash no ToR, o tráfego pode seguir uma rota diferente. E quanto mais aviões, maior a probabilidade de encontrar um caminho que não seja afetado por uma falha em um determinado dispositivo.
Um problema permanece - RTO. Outra rota, é claro, é encontrada, mas muito tempo é gasto nela. 200ms é muito. Um segundo é geralmente selvageria. Anteriormente, falei sobre timeouts que configuram serviços. Então, um segundo é um timeout que normalmente configura um serviço no nível do aplicativo, e nisso o serviço até vai estar relativamente certo. Além disso, repito, o RTT real dentro de um data center moderno é de cerca de 1 milissegundo.
O que pode ser feito sobre os tempos limite de RTO? O tempo limite responsável pelo RTO em caso de perda de pacotes de dados pode ser configurado com relativa facilidade no espaço do usuário: existe um utilitário IP e um de seus parâmetros contém o mesmo rto_min. Considerando que, é claro, você precisa ativar o RTO não globalmente, mas para determinados prefixos, esse mecanismo parece bastante funcional.
É verdade que com SYN_RTO tudo é um pouco pior. É naturalmente pregado. O valor é fixado no núcleo - 1 segundo e pronto. Você não pode alcançá-lo do espaço do usuário. Há apenas um caminho.
eBPF vem para o resgate. Simplificando, esses são pequenos programas C. Eles podem ser inseridos em ganchos em diferentes locais na execução da pilha do kernel e da pilha TCP, com os quais você pode alterar um número muito grande de configurações. Em geral, o eBPF é uma tendência de longo prazo. Em vez de serrar dezenas de novos parâmetros sysctl e expandir o utilitário IP, o movimento é na direção do eBPF e expandir sua funcionalidade. Com o eBPF, você pode alterar dinamicamente os controles de congestionamento e várias outras configurações de TCP.
Mas é importante para nós que, com a ajuda dele, você possa distorcer os valores de SYN_RTO. E há um exemplo postado publicamente: . O que é feito aqui? O exemplo está funcionando, mas em si é muito difícil. Supõe-se aqui que dentro do data center comparamos os primeiros 44 bits, se forem iguais, então nos encontramos dentro do DC. E neste caso, alteramos o valor do timeout SYN_RTO para 4ms. A mesma tarefa pode ser realizada com muito mais elegância. Mas este exemplo simples mostra o que é a) possível; b) relativamente fácil.
O que já sabemos? O fato de a arquitetura planar permitir o dimensionamento acaba sendo extremamente útil para nós quando ativamos o rótulo de fluxo no ToR e temos a oportunidade de fluir em áreas problemáticas. A melhor maneira de diminuir os valores de RTO e SYN-RTO é usar programas eBPF. A questão permanece: é seguro usar o rótulo de fluxo para balanceamento? E há uma nuance aqui.
Suponha que você tenha um serviço na rede que resida em anycast. Infelizmente, não tenho tempo para entrar em detalhes sobre o anycast, mas é um serviço distribuído onde diferentes servidores físicos estão disponíveis no mesmo endereço IP. E aqui está um possível problema: o evento RTO pode ocorrer não apenas quando o tráfego passa pela fábrica. Também pode ocorrer no nível do buffer ToR: quando ocorre um evento incast, pode até ocorrer no host quando o host derrama algo. Quando ocorre um evento RTO e ele altera o rótulo do fluxo. Nesse caso, o tráfego pode ir para outra instância anycast. Suponha que este seja um anycast com estado, ele contém um estado de conexão - pode ser um balanceador L3 ou algum outro serviço. Aí surge um problema, pois após o RTO, a conexão TCP chega ao servidor, que nada sabe sobre essa conexão TCP. E se não tivermos compartilhamento de estado entre os servidores anycast, esse tráfego será descartado e a conexão TCP será interrompida.
O que pode ser feito aqui? Dentro de seu ambiente controlado, onde você habilita o balanceamento de rótulo de fluxo, você precisa corrigir o valor do rótulo de fluxo ao acessar os servidores anycast. A maneira mais fácil é fazê-lo através do mesmo programa eBPF. Mas aqui está um ponto muito importante - o que fazer se você não opera uma rede de data center, mas é uma operadora de telecomunicações? Este é o seu problema também: começando com certas versões do Juniper e Arista, eles incluem o rótulo de fluxo na função hash por padrão - para ser honesto, sem motivo, eu entendo. Isso pode fazer com que você descarte as conexões TCP dos usuários que passam pela sua rede. Portanto, eu recomendo verificar as configurações do roteador neste local.
De uma forma ou de outra, parece-me que estamos prontos para passar aos experimentos.
Quando ativamos o rótulo de fluxo no ToR, preparamos o eBPF do agente, que agora mora nos hosts, decidimos não esperar a próxima grande falha, mas realizar explosões controladas. Pegamos o ToR, que tem quatro uplinks, e fizemos drops em um deles. Eles traçaram uma regra, disseram - agora você está perdendo todos os pacotes. Como vocês podem ver à esquerda, temos o monitoramento por pacote, que caiu para 75%, ou seja, 25% dos pacotes são perdidos. À direita estão os gráficos dos serviços que estão por trás deste ToR. Na verdade, são gráficos de tráfego de juntas com servidores dentro do rack. Como você pode ver, eles afundaram ainda mais. Por que eles afundaram - não em 25%, mas em alguns casos em 3-4 vezes? Se a conexão TCP não tiver sorte, ela continuará tentando acessar a interface quebrada. Isso é exacerbado pelo comportamento típico do serviço dentro do DC - para uma solicitação do usuário, N solicitações para serviços internos são geradas e a resposta irá para o usuário, seja quando todas as fontes de dados responderem ou quando um tempo limite for acionado em o nível do aplicativo, que ainda precisa ser configurado. Ou seja, está tudo muito, muito ruim.
Agora o mesmo experimento, mas com o rótulo de fluxo ativado. Como você pode ver, à esquerda, nosso monitoramento de lote caiu nos mesmos 25%. Isso é absolutamente correto, porque ele não sabe nada sobre retransmissões, ele envia pacotes e simplesmente conta a proporção entre o número de pacotes entregues e perdidos.
E à direita está o cronograma de serviços. Você não encontrará aqui o efeito de uma junta problemática. O tráfego nesses mesmos milissegundos fluiu da área problemática para os três uplinks restantes que não foram afetados pelo problema. Temos uma rede que se cura sozinha.
Este é meu último slide, hora de fazer um balanço. Agora, espero que você saiba como construir uma rede de centro de dados de autorrecuperação. Você não precisará passar pelo arquivo do kernel Linux e procurar patches especiais lá, você sabe que o rótulo Flow resolve o problema neste caso, mas você precisa abordar esse mecanismo com cuidado. E volto a enfatizar que se você é portador, não deve usar o flow label como uma função hash, senão irá quebrar as sessões dos seus usuários.
Para os engenheiros de rede, uma mudança conceitual precisa ocorrer: a rede não começa com ToR, nem com um dispositivo de rede, mas com um host. Um exemplo bastante impressionante é como usamos o eBPF para alterar o RTO e corrigir o rótulo de fluxo para os serviços anycast.
A mecânica de rótulos de fluxo é certamente adequada para outros usos dentro do segmento administrativo controlado. Isso pode ser tráfego entre data centers ou você pode usar essa mecânica de uma maneira especial para controlar o tráfego de saída. Mas vou falar sobre isso, espero, na próxima vez. Muito obrigado pela sua atenção.
Fonte: habr.com