O tráfico lexítimo na rede DDoS-Guard superou recentemente os cen gigabits por segundo. Actualmente, o 50% de todo o noso tráfico é xerado polos servizos web do cliente. Trátase de moitas decenas de miles de dominios, moi diferentes e que na maioría dos casos requiren un enfoque individual.
Debaixo do corte está como xestionamos os nodos frontais e emitimos certificados SSL para centos de miles de sitios.
Configurar unha fronte para un sitio, incluso un moi grande, é doado. Collemos nginx ou haproxy ou lighttpd, configúrao segundo as guías e esquécenos. Se necesitamos cambiar algo, facemos unha recarga e esquecemos de novo.
Todo cambia cando procesas grandes volumes de tráfico sobre a marcha, avalías a lexitimidade das solicitudes, comprimes e almacenas en caché o contido dos usuarios e, ao mesmo tempo, cambias os parámetros varias veces por segundo. O usuario quere ver o resultado en todos os nodos externos inmediatamente despois de cambiar a configuración da súa conta persoal. Un usuario tamén pode descargar varios miles (e ás veces decenas de miles) de dominios con parámetros individuais de procesamento de tráfico a través da API. Todo isto tamén debería funcionar inmediatamente en América, en Europa e en Asia: a tarefa non é a máis trivial, tendo en conta que só en Moscova hai varios nodos de filtración separados fisicamente.
Por que hai moitos nodos fiables en todo o mundo?
-
Calidade do servizo para o tráfico de clientes: as solicitudes dos EUA deben procesarse nos EE. UU. (incluíndo ataques, análises e outras anomalías) e non levar a Moscova ou Europa, o que aumenta de forma imprevisible o atraso de procesamento.
-
O tráfico de ataque debe ser localizado: os operadores de transporte poden degradarse durante os ataques, cuxo volume adoita superar 1 Tbps. Transportar tráfico de ataque por enlaces transatlánticos ou transasiáticos non é unha boa idea. Tivemos casos reais nos que os operadores de nivel 1 dixeron: "O volume de ataques que recibe é perigoso para nós". É por iso que aceptamos emisións entrantes o máis preto posible das súas fontes.
-
Requisitos estritos para a continuidade do servizo: os centros de limpeza non deben depender nin uns dos outros nin dos eventos locais no noso mundo en rápido cambio. Cortaches a luz aos 11 pisos do MMTS-9 durante unha semana? - sen problema. Nin un só cliente que non teña unha conexión física nesta localización concreta sufrirá, e os servizos web non sufrirán baixo ningún concepto.
Como xestionar todo isto?
As configuracións do servizo deben distribuírse a todos os nodos fronte o máis rápido posible (idealmente ao instante). Non podes simplemente coller e reconstruír as configuracións de texto e reiniciar os daemons en cada cambio: o mesmo nginx mantén os procesos apagados (apagando o traballador) durante uns minutos máis (ou quizais horas se hai longas sesións de websocket).
Ao volver cargar a configuración de nginx, a seguinte imaxe é bastante normal:
Sobre o uso da memoria:
Os vellos traballadores comen memoria, incluída a memoria que non depende linealmente do número de conexións, isto é normal. Cando se pechen as conexións do cliente, esta memoria liberarase.
Por que non era un problema cando nginx estaba a comezar? Non había HTTP/2, nin WebSocket, nin conexións masivas de longa duración. O 70% do noso tráfico web é HTTP/2, o que significa conexións moi longas.
A solución é sinxela: non use nginx, non xestione frontes baseadas en ficheiros de texto e, por suposto, non envíe configuracións de texto comprimido por canles transpacíficos. As canles están, por suposto, garantidas e reservadas, pero iso non as fai menos transcontinentais.
Temos o noso propio equilibrador de servidor frontal, cuxos elementos internos falarei nos seguintes artigos. O principal que pode facer é aplicar miles de cambios de configuración por segundo sobre a marcha, sen reinicios, recargas, aumentos repentinos no consumo de memoria e todo iso. Isto é moi semellante ao Hot Code Reload, por exemplo en Erlang. Os datos gárdanse nunha base de datos de valores-clave xeodistribuídas e son lidos inmediatamente polos actuadores frontales. Eses. cargas o certificado SSL a través da interface web ou da API en Moscova e, en poucos segundos, está listo para ir ao noso centro de limpeza en Los Ángeles. Se de súpeto ocorre unha guerra mundial e Internet desaparece en todo o mundo, os nosos nodos seguirán traballando de forma autónoma e repararán o cerebro dividido en canto unha das canles dedicadas Los Ángeles-Amsterdam-Moscova, Moscova-Amsterdam-Hong Kong- Los-Los está dispoñible. Angeles ou polo menos unha das superposicións de copia de seguranza GRE.
Este mesmo mecanismo permítenos emitir e renovar instantáneamente os certificados de Let's Encrypt. Moi sinxelamente funciona así:
-
En canto vemos polo menos unha solicitude HTTPS para o dominio do noso cliente sen certificado (ou cun certificado caducado), o nodo externo que aceptou a solicitude infórmao á autoridade de certificación interna.
-
Se o usuario non prohibiu a emisión de Let's Encrypt, a autoridade de certificación xera un CSR, recibe un token de confirmación de LE e envíao a todas as frontes a través dunha canle cifrada. Agora calquera nodo pode confirmar unha solicitude de validación de LE.
-
En poucos momentos, recibiremos o certificado e a clave privada correctos e enviarémolos ás frontes do mesmo xeito. De novo, sen reiniciar os daemons
-
7 días antes da data de caducidade, iníciase o procedemento para volver recibir o certificado
Nestes momentos estamos rotando certificados de 350 en tempo real, totalmente transparentes para os usuarios.
Nos seguintes artigos da serie, falarei doutras características do procesamento en tempo real de gran tráfico web; por exemplo, sobre a análise de RTT utilizando datos incompletos para mellorar a calidade do servizo dos clientes de transporte público e, en xeral, sobre a protección do tráfico de tránsito de ataques terabit, sobre a entrega e agregación de información de tráfico, sobre WAF, CDN case ilimitado e moitos mecanismos para optimizar a entrega de contidos.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Que che gustaría saber primeiro?
-
14,3%Algoritmos para agrupar e analizar a calidade do tráfico web<3
-
33,3%Internos dos equilibradores DDoS-Guard7
-
9,5%Protección do tráfico de tránsito L3/L4
-
0,0%Protexer sitios web no tráfico de tránsito0
-
14,3%Firewall de aplicacións web 3
-
28,6%Protección contra análise e clic6
Votaron 21 usuarios. 6 usuarios abstivéronse.
Fonte: www.habr.com