O tráfego legítimo na rede DDoS-Guard ultrapassou recentemente cem gigabits por segundo. Atualmente, 50% de todo o nosso tráfego é gerado por serviços web de clientes. São muitas dezenas de milhares de domínios, muito diferentes e que, na maioria dos casos, exigem uma abordagem individual.
Abaixo está como gerenciamos nós frontais e emitimos certificados SSL para centenas de milhares de sites.
Configurar uma fachada para um site, mesmo que seja muito grande, é fácil. Pegamos nginx ou haproxy ou lighttpd, configuramos de acordo com os guias e esquecemos. Se precisarmos mudar alguma coisa, recarregamos e esquecemos novamente.
Tudo muda quando você processa grandes volumes de tráfego dinamicamente, avalia a legitimidade das solicitações, compacta e armazena em cache o conteúdo do usuário e, ao mesmo tempo, altera os parâmetros várias vezes por segundo. O usuário deseja ver o resultado em todos os nós externos imediatamente após alterar as configurações de sua conta pessoal. Um usuário também pode baixar vários milhares (e às vezes dezenas de milhares) de domínios com parâmetros individuais de processamento de tráfego por meio da API. Tudo isso também deve funcionar imediatamente na América, na Europa e na Ásia - a tarefa não é das mais triviais, considerando que só em Moscou existem vários nós de filtragem fisicamente separados.
Por que existem tantos nós grandes e confiáveis em todo o mundo?
-
Qualidade de serviço para tráfego de clientes - as solicitações dos EUA precisam ser processadas nos EUA (inclusive para ataques, análises e outras anomalias), e não puxadas para Moscou ou Europa, aumentando imprevisivelmente o atraso no processamento.
-
O tráfego de ataque deve ser localizado – os operadores de trânsito podem sofrer degradação durante os ataques, cujo volume geralmente excede 1 Tbps. Transportar o tráfego de ataque através de ligações transatlânticas ou transasiáticas não é uma boa ideia. Tivemos casos reais em que operadores de nível 1 disseram: “O volume de ataques que vocês recebem é perigoso para nós”. É por isso que aceitamos fluxos de entrada o mais próximo possível de suas fontes.
-
Requisitos rigorosos para a continuidade do serviço - os centros de limpeza não devem depender uns dos outros ou de eventos locais no nosso mundo em rápida mudança. Você cortou a energia de todos os 11 andares do MMTS-9 por uma semana? - sem problemas. Nem um único cliente que não tenha uma conexão física neste local específico sofrerá, e os serviços web não sofrerão em nenhuma circunstância.
Como gerenciar tudo isso?
As configurações de serviço devem ser distribuídas a todos os nós frontais o mais rápido possível (de preferência instantaneamente). Você não pode simplesmente reconstruir configurações de texto e reinicializar os daemons a cada alteração - o mesmo nginx mantém os processos desligados (desligamento do trabalhador) por mais alguns minutos (ou talvez horas se houver longas sessões de websocket).
Ao recarregar a configuração do nginx, a seguinte imagem é normal:
Sobre utilização de memória:
Os trabalhadores antigos consomem memória, incluindo memória que não depende linearmente do número de conexões - isso é normal. Quando as conexões do cliente forem fechadas, essa memória será liberada.
Por que isso não foi um problema quando o nginx estava apenas começando? Não havia HTTP/2, nem WebSocket, nem conexões massivas e longas para manter a atividade. 70% do nosso tráfego web é HTTP/2, o que significa conexões muito longas.
A solução é simples - não use nginx, não gerencie frentes baseadas em arquivos de texto e certamente não envie configurações de texto compactado por canais transpacíficos. Os canais são, claro, garantidos e reservados, mas isso não os torna menos transcontinentais.
Temos nosso próprio balanceador de servidor frontal, sobre os quais falarei nos próximos artigos. A principal coisa que ele pode fazer é aplicar milhares de alterações de configuração por segundo em tempo real, sem reinicializações, recarregamentos, aumentos repentinos no consumo de memória e tudo mais. Isso é muito semelhante ao Hot Code Reload, por exemplo, em Erlang. Os dados são armazenados em um banco de dados de valores-chave distribuídos geograficamente e são lidos imediatamente pelos atuadores frontais. Aqueles. você carrega o certificado SSL através da interface web ou API em Moscou e em poucos segundos ele está pronto para ir ao nosso centro de limpeza em Los Angeles. Se uma guerra mundial acontecer repentinamente e a Internet desaparecer em todo o mundo, nossos nós continuarão a trabalhar de forma autônoma e repararão o cérebro dividido assim que um dos canais dedicados Los Angeles-Amsterdã-Moscou, Moscou-Amsterdã-Hong Kong- Los-Los torna-se disponível.Angeles ou pelo menos uma das sobreposições de backup GRE.
Este mesmo mecanismo nos permite emitir e renovar instantaneamente certificados Let's Encrypt. Muito simplesmente funciona assim:
-
Assim que vemos pelo menos uma solicitação HTTPS para o domínio do nosso cliente sem certificado (ou com certificado expirado), o nó externo que aceitou a solicitação reporta isso à autoridade de certificação interna.
-
Caso o usuário não tenha proibido a emissão do Let's Encrypt, a autoridade certificadora gera um CSR, recebe um token de confirmação do LE e o envia para todas as frentes por meio de um canal criptografado. Agora qualquer nó pode confirmar uma solicitação de validação do LE.
-
Em alguns instantes receberemos o certificado correto e a chave privada e enviaremos para as frentes da mesma forma. Novamente, sem reiniciar os daemons
-
7 dias antes da data de vencimento, é iniciado o procedimento para re-recebimento do certificado
No momento, estamos rotacionando 350 mil certificados em tempo real, de forma totalmente transparente para os usuários.
Nos próximos artigos da série, falarei sobre outros recursos de processamento em tempo real de grande tráfego da web - por exemplo, sobre a análise de RTT usando dados incompletos para melhorar a qualidade do serviço para clientes de trânsito e, em geral, sobre como proteger o tráfego de trânsito de ataques terabit, sobre a entrega e agregação de informações de tráfego, sobre WAF, CDN quase ilimitado e muitos mecanismos para otimizar a entrega de conteúdo.
Apenas usuários registrados podem participar da pesquisa. por favor
O que você gostaria de saber primeiro?
-
14,3%Algoritmos para agrupamento e análise da qualidade do tráfego web<3
-
33,3%Internos dos balanceadores DDoS-Guard7
-
9,5%Proteção do tráfego de trânsito L3/L4
-
0,0%Protegendo sites no tráfego de trânsito0
-
14,3%Firewall de aplicativos da Web3
-
28,6%Proteção contra análise e cliques6
21 usuários votaram. 6 usuários se abstiveram.
Fonte: habr.com