El tráfico legítimo en la red DDoS-Guard superó recientemente los cien gigabits por segundo. Actualmente, el 50% de todo nuestro tráfico lo generan los servicios web de los clientes. Se trata de decenas de miles de dominios, muy diferentes y que en la mayoría de los casos requieren un enfoque individual.
Debajo del corte se muestra cómo administramos los nodos frontales y emitimos certificados SSL para cientos de miles de sitios.
Configurar un frente para un sitio, incluso uno muy grande, es fácil. Tomamos nginx o haproxy o lighttpd, lo configuramos según las guías y nos olvidamos de él. Si necesitamos cambiar algo, hacemos una recarga y volvemos a olvidar.
Todo cambia cuando procesa grandes volúmenes de tráfico sobre la marcha, evalúa la legitimidad de las solicitudes, comprime y almacena en caché el contenido del usuario y, al mismo tiempo, cambia los parámetros varias veces por segundo. El usuario quiere ver el resultado en todos los nodos externos inmediatamente después de cambiar la configuración en su cuenta personal. Un usuario también puede descargar varios miles (y a veces decenas de miles) de dominios con parámetros de procesamiento de tráfico individuales a través de la API. Todo esto también debería funcionar inmediatamente en América, Europa y Asia; la tarea no es la más trivial, considerando que solo en Moscú hay varios nodos de filtración físicamente separados.
¿Por qué hay tantos nodos grandes y confiables en todo el mundo?
-
Calidad de servicio para el tráfico de clientes: las solicitudes de EE. UU. deben procesarse en EE. UU. (incluidos ataques, análisis y otras anomalías) y no enviarse a Moscú o Europa, lo que aumenta de manera impredecible la demora en el procesamiento.
-
El tráfico de ataque debe estar localizado: los operadores de tránsito pueden degradarse durante los ataques, cuyo volumen a menudo supera 1 Tbps. Transportar tráfico de ataque a través de enlaces transatlánticos o transasiáticos no es una buena idea. Tuvimos casos reales en los que los operadores de nivel 1 dijeron: "El volumen de ataques que reciben es peligroso para nosotros". Es por eso que aceptamos transmisiones entrantes lo más cerca posible de sus fuentes.
-
Requisitos estrictos para la continuidad del servicio: los centros de limpieza no deben depender ni unos de otros ni de eventos locales en nuestro mundo que cambia rápidamente. ¿Cortaste la electricidad a los 11 pisos de MMTS-9 durante una semana? - ningún problema. Ni un solo cliente que no tenga una conexión física en esta ubicación en particular se verá afectado, y los servicios web no se verán afectados bajo ninguna circunstancia.
¿Cómo gestionar todo esto?
Las configuraciones de servicio deben distribuirse a todos los nodos frontales lo más rápido posible (idealmente al instante). No puede simplemente tomar y reconstruir configuraciones de texto y reiniciar los demonios con cada cambio: el mismo nginx mantiene los procesos apagándose (el trabajador apagándose) durante unos minutos más (o tal vez horas si hay largas sesiones de websocket).
Al recargar la configuración de nginx, la siguiente imagen es bastante normal:
Sobre la utilización de la memoria:
Los trabajadores antiguos consumen memoria, incluida la que no depende linealmente del número de conexiones; esto es normal. Cuando se cierren las conexiones del cliente, esta memoria se liberará.
¿Por qué esto no fue un problema cuando nginx apenas estaba comenzando? No había HTTP/2, ni WebSocket, ni conexiones masivas de mantenimiento prolongado. El 70% de nuestro tráfico web es HTTP/2, lo que significa conexiones muy largas.
La solución es simple: no use nginx, no administre frentes basados en archivos de texto y, ciertamente, no envíe configuraciones de texto comprimido a través de canales transpacíficos. Los canales, por supuesto, están garantizados y reservados, pero eso no los hace menos transcontinentales.
Tenemos nuestro propio equilibrador de servidor frontal, de cuyos aspectos internos hablaré en los siguientes artículos. Lo principal que puede hacer es aplicar miles de cambios de configuración por segundo sobre la marcha, sin reinicios, recargas, aumentos repentinos en el consumo de memoria y todo eso. Esto es muy similar a Hot Code Reload, por ejemplo en Erlang. Los datos se almacenan en una base de datos de valores clave distribuida geográficamente y los actuadores frontales los leen inmediatamente. Aquellos. carga el certificado SSL a través de la interfaz web o API en Moscú y en unos segundos estará listo para ir a nuestro centro de limpieza en Los Ángeles. Si de repente se produce una guerra mundial y Internet desaparece en todo el mundo, nuestros nodos seguirán funcionando de forma autónoma y repararán el cerebro dividido tan pronto como uno de los canales dedicados Los Ángeles-Ámsterdam-Moscú, Moscú-Ámsterdam-Hong Kong- Está disponible Los-Los Ángeles o al menos una de las superposiciones de respaldo de GRE.
Este mismo mecanismo nos permite emitir y renovar instantáneamente certificados Let's Encrypt. De manera muy simple funciona así:
-
Tan pronto como vemos al menos una solicitud HTTPS para el dominio de nuestro cliente sin certificado (o con un certificado caducado), el nodo externo que aceptó la solicitud informa esto a la autoridad de certificación interna.
-
Si el usuario no ha prohibido la emisión de Let's Encrypt, la autoridad de certificación genera una CSR, recibe un token de confirmación de LE y lo envía a todos los frentes a través de un canal cifrado. Ahora cualquier nodo puede confirmar una solicitud de validación de LE.
-
En unos instantes recibiremos el certificado correcto y la clave privada y lo enviaremos a los frentes de la misma forma. De nuevo, sin reiniciar los demonios.
-
7 días antes de la fecha de vencimiento, se inicia el trámite para volver a recibir el certificado.
Ahora mismo estamos rotando 350k certificados en tiempo real, de forma totalmente transparente para los usuarios.
En los siguientes artículos de la serie, hablaré sobre otras características del procesamiento en tiempo real de un gran tráfico web, por ejemplo, sobre el análisis de RTT utilizando datos incompletos para mejorar la calidad del servicio para los clientes de tránsito y, en general, sobre la protección del tráfico de tránsito. ataques de terabit, sobre la entrega y agregación de información de tráfico, sobre WAF, CDN casi ilimitado y muchos mecanismos para optimizar la entrega de contenido.
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Qué te gustaría saber primero?
-
14,3%Algoritmos para agrupar y analizar la calidad del tráfico web<3
-
33,3%Partes internas de los balanceadores DDoS-Guard7
-
9,5%Protección del tráfico en tránsito L3/L4
-
0,0%Protección de sitios web en el tráfico de tránsito0
-
14,3%Cortafuegos de aplicaciones web3
-
28,6%Protección contra análisis y clic6
21 usuarios votaron. 6 usuarios se abstuvieron.
Fuente: habr.com