Olá Habr! A seguir, é apresentada uma transcrição do relatório, por Evgeny
error2407 Bogomazov (engenheiro de P&D da rede) e Dmitry h8r Shemonaev (chefe do NOC) do UPTIMEDAY anterior. Vídeo no final da postagem.
Hoje, gostaríamos de falar sobre quais problemas surgem ao criar uma rede anycast. Por que entramos nisso e o que estamos fazendo lá?
No Qrator Labs, construímos nossa própria rede anycast para resolver problemas especiais que diferem dos das operadoras de telecomunicações "comuns". Assim, temos pontos de presença nessas regiões - esquecemos de adicionar a Rússia aqui. E isso significa que temos muitas histórias sobre como e não devemos fazer. Hoje vamos compartilhar com vocês alguns deles.
O que vamos contar, considerando que o tópico é inicialmente volumoso? No início, queríamos apenas fazer perguntas e respostas (perguntas e respostas), mas ainda éramos solicitados a ler o relatório. Portanto, se não contarmos algo, mas definitivamente não tivermos tempo, nos pegue depois, à margem.
Como parte do planejado, tentaremos falar sobre a diferença entre o balanceamento usando DNS e BGP. Como escolher novos sites e o que você precisa prestar atenção para evitar dores subsequentes. Como apoiar tudo isso e quanto essa difícil tarefa Dmitry dirá.
Para começar, vamos determinar o quanto você está familiarizado com o tópico.
- Quantos sabem o que é anycast e por que é necessário? (cerca de um terço das mãos sobe no corredor)
- E quem está familiarizado com o DNS e configurou o servidor? (aproximadamente o mesmo número de mãos)
- E BGP (duas mãos na moldura)
Ainda muito.
- Bem, a última pergunta - quem está familiarizado com o NOC? Quem teve problemas com os fornecedores e quem tentou resolvê-los? (a mão do administrador do sistema Habr está visível no quadro)
Ótimo. Nesse caso, espero que o que vamos lhe dizer venha à tona.
Antes de passar para o anycast, vamos ver por que é necessário. Você tem um aplicativo com o qual deseja processar solicitações de clientes. Você está hospedado em algum lugar - enquanto não está pensando particularmente sobre isso. Compre o nome DNS, resolva-o e assim por diante. Em seguida, assine o certificado, porque HTTPS. Sua aplicação está crescendo.
Primeiro, você tem que lidar com a carga. Se seu aplicativo "dispara" ao mesmo tempo - ou seja, se torna bastante popular, muito mais usuários o procuram. Você deve comprar ferro e equilibrar a carga nele.
Além disso, clientes especialmente exigentes podem surgir com as palavras: "Pessoal, você deve estar disponível sempre e em qualquer lugar por esse tipo de dinheiro!" O que leva ao fato de você estar redundando os recursos de computação não apenas para o processamento de cargas de pico, mas simplesmente como uma reserva.
Além disso, hoje já foi mencionado em outras aparências, você não pode colocar as glândulas em um data center - um desastre natural pode acontecer, o que significa que o aplicativo entrará em inatividade, o que causará perdas financeiras e outras. Portanto, se seu aplicativo tiver crescido o suficiente, você já deverá estar localizado em vários data centers; caso contrário, será ruim.
O problema tem um lado oposto - se seu aplicativo é sensível ao tempo, como em análises financeiras ou negociações, é importante que você envie solicitações aos seus usuários o mais rápido possível. A latência notória com a qual dois pontos estão conectados. A primeira - se você deseja fazer uma solicitação o mais rápido possível, para isso, o número de solicitações e respostas a elas deve ser o menor possível. Novamente, o fato é que, quando o usuário se conecta a você pela primeira vez - tudo não funciona e ele é forçado a passar por todos os círculos do inferno. O segundo ponto é a velocidade da luz. Um pacote da Europa Ocidental para a Rússia não pode ir mais rápido do que um certo número de milissegundos, não há nada a ser feito.
É necessário estar localizado em vários data centers, porque queremos redundância e precisamos estar mais próximos dos clientes em potencial. Se, por exemplo, sua principal região de clientes é a América, você colocará seu equipamento lá para que o tráfego não passe por outros países e partes do mundo.
Acontece que, a partir de algum ponto, você terá que estar presente em todas as partes do mundo em diferentes locais. E isso ainda não é anycast.
Então você precisa de alguns sites. De alguma forma, você precisa escolhê-los, ambos inicialmente novos, e entender sua capacidade de escalar - durante a sobrecarga, você terá que comprar hardware adicional.
Se você já possui vários sites, precisa aprender como distribuir usuários entre eles. Existem duas cadeiras: BGP e DNS.
A partir de dois pontos, começaremos com o último. E novamente duas abordagens principais. No primeiro, você tem sites diferentes, IPs diferentes e, portanto, quando um usuário solicita - ele obtém o IP de um site específico e o mapeia.
O que estamos decidindo aqui? Queremos que um usuário de uma determinada região acesse um site localizado na mesma região. A solução mais simples e burra é usar o GeoDNS. Você entende as regiões nas quais os prefixos estão localizados - você pega esses dados, envia-os ao servidor DNS, mapeia os usuários de acordo, se o IP de origem vier do prefixo certo, para o site certo. Mas há um problema - resolvedores. E cerca de 15 a 20% das solicitações vêm de resolvedores - ou seja, o IP de origem será 8.8.8.8. Onde colocar isso?
Para fazer isso, existe o EDNS, que permite, na estrutura da solicitação, transferir a sub-rede original do cliente da qual ela veio. Como você sabe, em 1 de fevereiro de 2019, o Dia da Bandeira do DNS aconteceu - a partir desse dia, todos os servidores DNS devem suportar esta extensão.
Neste exemplo, você pode ter um ou vários sites nos quais estão localizados servidores DNS que mapeiam os usuários - e os próprios servidores podem ser distribuídos pelo mundo. E já no âmbito do DNS há uma oportunidade de usar o anycast - falaremos sobre isso um pouco mais tarde.
No esquema geral, você mapeia o usuário para o site mais próximo dele, fornecendo o endereço desse site específico. É usado com menos frequência.
A terceira abordagem está relacionada ao fato de que, mesmo que o usuário tenha vindo da mesma região em que o site está localizado, isso não significa que o problema de atrasos foi resolvido. Pode ser ainda mais lucrativo transferir o usuário para outro site, pois a região pode ser sobrecarregada se rotas alternativas estiverem disponíveis. Seria bom usar isso? Infelizmente, quase não existem soluções atuais para fazer algo semelhante. O Facebook de alguma forma mostrou um relatório de que ele fez isso - mas não há caixa, tudo terá que ser feito com suas próprias mãos.
O que temos com o DNS?
As vantagens são que usuários diferentes podem receber endereços diferentes e um usuário específico pode ser enviado para um site estritamente definido - ou seja, você pode trabalhar com usuários individuais. Bem, o DNS é fácil de configurar.
Quais são as desvantagens? Se você fizer um ajuste granular, a configuração aumentará rapidamente, o que é impossível de suportar com as mãos. Precisa de automação. E se a automação for feita incorretamente, tudo irá falhar - se o DNS estiver, o aplicativo não estará disponível.
Por outro lado, se você fizer o balanceamento de DNS, o usuário mapeará para um site específico e seu IP ficará vulnerável. Esta é a razão pela qual não usamos o balanceamento de DNS em casa, pois nesse caso todo o tráfego do ataque pode fluir exatamente em um ponto, desativando-o.
E, como já mencionado, o DNS não suporta o balanceamento de latência pronto para uso. E fazer você mesmo é muito difícil.
Finalmente vamos ao que interessa, nomeadamente o BGP anycast.
Este é exatamente o nosso caso. Qual é o objetivo? Todos os sites têm o mesmo IP, ou melhor, anunciam o mesmo prefixo. O usuário mapeia para o site "mais próximo" dele. “Mais próximo” do ponto de vista do BGP - esse prefixo é anunciado usando várias rotas e, se o operador tiver várias rotas para o site anunciado, na maioria das vezes ele escolherá a mais curta. Novamente do ponto de vista do BGP. Em breve explicaremos por que isso é ruim.
O BGP também trabalha com a disponibilidade de prefixos; portanto, você sempre opera em uma sub-rede e não pode manipular IPs individuais.
Como resultado, como o mesmo prefixo é anunciado em todos os sites, todos os usuários da mesma região serão direcionados para o mesmo site. O invasor não tem como transferir a carga de uma região para outra, portanto, você precisa ganhar tanta energia em cada um dos lugares quanto o operador que escolheu essa rota quisesse. Mesmo se você não pontuar, ele ainda poderá ser protegido.
O mesmo prefixo é anunciado - o que poderia ser mais fácil? Mas também há problemas.
A primeira é que, devido à necessidade de anunciar o mesmo prefixo em todo o mundo, você é obrigado a comprar endereços independentes de provedor, que são várias vezes mais caros.
A segunda se resume ao fato de que usuários de uma região não podem ser simplesmente jogados em outra, se de repente alguns deles forem ilegítimos ou para diversificar o tráfego de ataque usando outros sites, porque alguns deles machucam. Não existem tais canetas.
O terceiro problema é que, dentro da estrutura do BGP, é muito fácil escolher o site "errado" e os fornecedores "errados". Parece que você tem redundância e disponibilidade, mas, na realidade, não haverá nem um nem outro.
Você tem vários sites entre os quais deseja dispersar os usuários. Quais são as formas de restringir uma determinada região, atraindo usuários para um site específico?
Há comunidade geográfica. Por que eles são? Deixe-me lembrá-lo - você escolhe a rota mais próxima do ponto de vista do BGP. E você tem um operador de Nível 1, por exemplo, Nível3, que possui seu próprio tronco em todo o mundo. O cliente Level3, se você estiver conectado diretamente a ele, está localizado em duas esperanças de você. E algum operador local - em três. Assim, um operador da América estará mais perto de você do que um operador da Rússia ou da Europa, porque, do ponto de vista do BGP, é assim.
Usando a Comunidade Geográfica, você pode limitar a região na qual um operador tão grande e internacional anunciará sua rota. O problema também é que eles nem sempre estão disponíveis (Comunidade Geográfica).
Temos vários casos quando se tratava de nós mesmos. Dim?
(Dmitry Shemonaev toma a palavra)
Pronto, muitas operadoras não fornecem isso e dizem que, dizem eles, não restringiremos nada pela neutralidade, liberdade e assim por diante da rede. Temos que explicar aos operadores por um longo tempo e quem somos, por que queremos e por que é tão importante para nós, e também para educar por que isso não se aplica à neutralidade que eles têm em mente. Às vezes isso funciona - e às vezes não, e simplesmente nos recusamos a cooperar com operadores potencialmente interessantes, porque essa cooperação levará a mais problemas na operação de nosso serviço.
Além disso, muitas vezes encontramos o fato de que Eugene já mencionou vários operadores - estes são de nível 1, que não compram tráfego de ninguém e apenas trocam tráfego entre eles. Mas, além deles, existem pelo menos dezenas de operadores que não são de nível 1 - eles compram tráfego, mas ao mesmo tempo também têm redes implantadas em todo o mundo. Você não precisa ir muito longe - do mais próximo a nós é Rostelecom ou ReTN, um pouco mais longe, existem maravilhosas telecomunicações de Taipei, China Unicom, Singtel e assim por diante.
E na Ásia, muitas vezes enfrentamos uma situação que, ao que parece, temos vários pontos de presença na Ásia, estamos conectados a vários operadores bastante grandes, do ponto de vista dessa região. No entanto, somos constantemente confrontados com o fato de que o tráfego da Ásia vai para o nosso site pela Europa ou faz uma viagem transatlântica. Do ponto de vista do BGP, isso é bastante normal para si, porque não leva em consideração a latência. Mas o aplicativo sofre nessas condições, também seus usuários - em geral, todo mundo sofre, mas do ponto de vista do BGP, está tudo bem.
E você precisa fazer algumas alterações com as mãos, fazer engenharia reversa de como o encaminhamento deste ou daquele operador é organizado, às vezes negociar, perguntar, implorar, ajoelhar-se. Em geral, faça qualquer coisa para resolver esses problemas. Com isso, nosso NOC é confrontado com regularidade invejável.
Como regra, os operadores atendem às suas necessidades e, em alguns casos, estão prontos para fornecer um determinado conjunto ... Mas, em geral, aqueles que trabalharam com o BGP no nível da comunidade levantam as mãos? (Sorrisos) Ótimo! Ou seja, os operadores estão prontos para fornecer algum conjunto de gerentes da comunidade para, por exemplo, diminuir o pref local em uma determinada região ou adicionar prefpend ou não anunciar bem ou qualquer outra coisa.
Consequentemente, existem duas maneiras de equilibrar a carga no BGP. O primeiro é como está escrito no slide, o chamado anexa. Podemos imaginar o caminho para o BGP como uma pequena linha listando sistemas autônomos pelos quais o caminho do pacote do remetente ao destinatário passa. Você pode adicionar um enésimo número de sistemas autônomos a esse caminho e, como resultado, o caminho será estendido e se tornará não muito prioritário. Este é um método frontal e não funciona para tudo - se você adicionar prefpend, não é granular, ou seja, todos verão no cone do operador no qual você está fazendo essa manipulação.
Por outro lado, há também a comunidade BGP, que está marcando uma, para entender de onde vem esse ou aquele prefixo, de quem é em relação ao operador - ou seja, um banquete, cliente ou montante, e também em que lugar é ocupado. assim por diante E há gerentes de comunidade que vão ao roteador para o operador e ele executa determinadas ações com esse prefixo.
A maioria dos operadores possui comunidades restritivas. Tomemos, por exemplo, o operador russo abstrato, que está conectado a vários operadores russos no vácuo. Alguns deles têm relacionamentos ponto a ponto, o que implica uma troca de paridade de tráfego, e alguns os compram. Dessa forma, eles fornecem comunidade para fazer prepends nessa direção, estendendo o caminho do AS ou para não anunciar ou alterar o pref local. Se você estiver operando com o BGP - observe a comunidade e saiba o que o candidato pode fazer para se tornar seu fornecedor. Às vezes, as comunidades estão ocultas e você precisa se comunicar com os gerentes de operadores ou com especialistas técnicos para nos mostrar um determinado conjunto suportado.
Por padrão, a comunidade, no caso da região europeia, é descrita no RIPE DB. Ou seja, você solicita a quem são os números do sistema autônomo e o campo Observações geralmente diz o que o operador possui em termos de marcação e gerenciamento da comunidade. Nem todo mundo tem isso, muitas vezes você tem que procurar lugares diferentes e interessantes.
Assim que você começa a operar o BGP, em essência, você diz que a rede faz parte do seu aplicativo e não algo abstrato, portanto, você deve considerar os riscos.
Por exemplo, tivemos um caso com uma instituição financeira letã, cujo prefixo, se incluído em nossa rede, ficou indisponível em cerca da metade da Letônia. Embora pareça que nada mudou - o mesmo prefixo que anunciamos nas operadoras de nível 1, na Europa, parece que tudo está lá, incluindo redundância. Mas não podíamos nem imaginar que aproximadamente metade dos operadores letões possuísse como dispositivos de fronteira que não pudessem digerir o volume total da visualização completa (toda a tabela de roteamento BGP), que na época era de cerca de 650 mil prefixos. Eles ficaram lá, bem, se alguém sabe o que é o Catalyst 3550, foi exatamente lá que estava, ele poderia ter apenas 12.000 prefixos. Bem, eles receberam uma certa quantidade de prefixos de IX'a, nos quais, é claro, não havia padrão. Junto com isso, de outro operador - a televisão letã, cujo prefixo no nono dia não era / 24, mas / 22 no qual esse / 24 estava.
Como resultado, ele foi para um lugar onde não sabia para onde encaminhar e tudo voou para dentro do cano. Para consertar isso, levamos cerca de dois dias e uma correspondência persistente com os operadores letões até que eles nos mostrassem a saída do dispositivo de fronteira e apenas notássemos o nome do host lá. Olá pessoal, às vezes é tão divertido.
Existem muitos operadores com ferro velho. Existem muitos operadores com um entendimento estranho de como a rede deve funcionar. E agora esse também é seu problema se você estiver jogando com o BGP. Bem, no final, muitos operadores são unipodal (um fornecedor superior de conectividade), portanto, eles têm seus próprios conjuntos de muletas.
(Evgeny Bogomazov continua)
Como você pode ver, mesmo este tópico pode ser desenvolvido por um longo tempo e é difícil mantê-lo em 40 minutos.
Então, você tem canetas com as quais deseja limitar a região. Agora, vamos descobrir o que você precisa analisar e o que é importante considerar quando você deseja se hospedar em um novo site.
O melhor caso não é comprar seu hardware, mas concordar com uma nuvem de hospedagem. Então, já será possível concordar com ele que você se conectará independentemente a determinados fornecedores.
Por outro lado, se você seguiu esse caminho, deve entender aproximadamente qual região, com ou sem alças, será reunida neste site. Para fazer isso, você precisa de modelagem, ou melhor, precisa entender que, se houver várias rotas de sites diferentes, qual será escolhido como o melhor. Para fazer isso, você deve ter uma idéia de como o BGP funciona e como as rotas circulam na situação atual.
Dois pontos principais são o comprimento do caminho, influenciado pelos prefixos e a preferência local, que afirma que as rotas dos clientes são preferíveis às rotas de outros lugares. Em princípio, esses dois pontos são suficientes para entender qual região será reunida e onde subir.
, , — , , (« ») Tier-1 , .
, IPv4 IPv6 , .
. : « ?» . — IX . , , , , , , IX' . , IX' , , — .
— , . — , , , IX'.
, , , ?
( )
. , . - , , , BGP anycast — .
, , RTT , . , , , , RTT , . — .
, , — .
, — «», . , , — , IGP , , . , — , , .
, «» , SDN , . . , SDN-, (CenturyLink) . - . NOC . - .
— .
, , — . — «», — «» ( ). , , «». , , . , , , -, , . - .
. community, NOC. , , , - - - DE-CIX . blackhole community.
, , . , , , - , - , . , . , — NOC , NOC , . . .
NOC'. Network Operations Center — , , , . , . ? - . . .
, « - » , . , — , . NOC' , . , , — RIPE Atlas . , . , .
community , . : , . , , . , , - community, . , - — community . community, . , , . community , . O que isso significa? latency — . - , , .
— 10 , , Ansible, Chef, Puppet, . ? BGP : « BGP-, ». .
, , , . — - . , . , , — , : « -!» — , ( ) — . , , . — .
, .
( )
. anycast' , , , .
, . , — , . , , , . RTT .
, , — . , anycast , — .
- — - , , . . anycast , — - , .
, - , , , . - , - - , , , — .
, — . — , — . , , BGP . , - , , .
, . — , DNS — . SDN' - , , , .
— DNS. Dyn — , 2016 , . DNS , . DNS- , , IETF , , DNS-.
, DNS. , , . RTT, , DNS- , , - . — DNS.
anycast DNS , DNS- .
? , latency, , .
, . - . , .
. , . - — , .
90% . 10% — . . «» ? , , . , , .
Portanto, é melhor delegar do que comprar seu próprio hardware. Mesmo parte da funcionalidade que descrevemos hoje na estrutura do anycast e os problemas que surgem são fáceis de resolver incorretamente. Portanto, se houver uma oportunidade de não resolver esses problemas e transferi-los para pessoas de fora, isso provavelmente vale a pena. Caso contrário, você precisará responder com precisão à pergunta de por que precisa implementar tudo isso.Bem, no caso de um ataque, recorra às nuvens especializadas em resolver esses problemas. Bem, ou você ainda pode conversar conosco.Obrigada
Perguntas?