Het legitieme verkeer op het DDoS-Guard-netwerk overschreed onlangs de honderd gigabits per seconde. Momenteel wordt 50% van al ons verkeer gegenereerd door webservices van klanten. Het gaat om vele tienduizenden domeinen, heel verschillend en die in de meeste gevallen een individuele aanpak vergen.
Hieronder ziet u hoe we front-nodes beheren en SSL-certificaten uitgeven voor honderdduizenden sites.
Het opzetten van een front voor één site, zelfs een hele grote, is eenvoudig. We nemen nginx of haproxy of lighttpd, configureren het volgens de handleidingen en vergeten het. Als we iets moeten veranderen, herladen we het en vergeten we het weer.
Alles verandert wanneer u grote hoeveelheden verkeer on-the-fly verwerkt, de legitimiteit van verzoeken evalueert, gebruikersinhoud comprimeert en in de cache opslaat, en tegelijkertijd parameters meerdere keren per seconde wijzigt. De gebruiker wil het resultaat direct op alle externe knooppunten zien nadat hij de instellingen in zijn persoonlijke account heeft gewijzigd. Via de API kan een gebruiker ook enkele duizenden (en soms tienduizenden) domeinen downloaden met individuele verkeersverwerkingsparameters. Dit alles zou ook onmiddellijk moeten werken in Amerika, en in Europa, en in AziΓ« - de taak is niet de meest triviale, aangezien er alleen al in Moskou verschillende fysiek gescheiden filtratieknooppunten zijn.
Waarom zijn er veel grote, betrouwbare knooppunten over de hele wereld?
-
Kwaliteit van de dienstverlening voor klantverkeer - verzoeken uit de VS moeten in de VS worden verwerkt (inclusief voor aanvallen, parsing en andere afwijkingen) en niet naar Moskou of Europa worden getrokken, waardoor de verwerkingsvertraging onvoorspelbaar toeneemt.
-
Aanvalsverkeer moet worden gelokaliseerd. Transitoperators kunnen slechter worden tijdens aanvallen, waarvan het volume vaak groter is dan 1 Tbps. Het transporteren van aanvalsverkeer over trans-Atlantische of trans-Aziatische verbindingen is geen goed idee. We hadden echte gevallen waarin Tier-1-operators zeiden: βHet aantal aanvallen dat u ontvangt is gevaarlijk voor ons.β Daarom accepteren wij inkomende streams zo dicht mogelijk bij hun bron.
-
Strenge eisen voor de continuΓ―teit van de dienstverlening β schoonmaakcentra mogen niet afhankelijk zijn van elkaar of van lokale gebeurtenissen in onze snel veranderende wereld. Hebt u de stroom naar alle 11 verdiepingen van MMTS-9 een week lang afgesloten? - Geen probleem. Geen enkele klant die op deze specifieke locatie geen fysieke verbinding heeft, zal eronder lijden, en webdiensten zullen onder geen enkele omstandigheid lijden.
Hoe dit allemaal te beheren?
Serviceconfiguraties moeten zo snel mogelijk (idealiter onmiddellijk) naar alle frontknooppunten worden gedistribueerd. Je kunt niet zomaar tekstconfiguraties nemen en opnieuw opbouwen en de daemons bij elke wijziging opnieuw opstarten - dezelfde nginx zorgt ervoor dat processen nog een paar minuten worden afgesloten (of misschien wel uren als er lange websocket-sessies zijn).
Bij het herladen van de nginx-configuratie is het volgende beeld heel normaal:
Over geheugengebruik:
Oude werknemers vreten geheugen op, inclusief geheugen dat niet lineair afhankelijk is van het aantal verbindingen - dit is normaal. Wanneer clientverbindingen worden gesloten, wordt dit geheugen vrijgemaakt.
Waarom was dit geen probleem toen nginx net begon? Er was geen HTTP/2, geen WebSocket, geen enorme, lang houdbare verbindingen. 70% van ons webverkeer is HTTP/2, wat zeer lange verbindingen betekent.
De oplossing is eenvoudig: gebruik geen nginx, beheer geen fronten op basis van tekstbestanden en stuur zeker geen gecomprimeerde tekstconfiguraties via transpacific kanalen. De kanalen zijn uiteraard gegarandeerd en gereserveerd, maar dat maakt ze niet minder transcontinentaal.
We hebben onze eigen frontserver-balancer, waarvan ik de interne werking in de volgende artikelen zal bespreken. Het belangrijkste dat het kan doen, is duizenden configuratiewijzigingen per seconde direct toepassen, zonder herstarten, herladen, plotselinge toename van het geheugengebruik en dergelijke. Dit lijkt erg op Hot Code Reload, bijvoorbeeld in Erlang. De gegevens worden opgeslagen in een geografisch gedistribueerde sleutelwaardedatabase en worden onmiddellijk gelezen door de frontactuators. Die. u uploadt het SSL-certificaat via de webinterface of API in Moskou en binnen enkele seconden is het klaar om naar ons schoonmaakcentrum in Los Angeles te gaan. Als er plotseling een wereldoorlog uitbreekt en het internet over de hele wereld verdwijnt, zullen onze knooppunten autonoom blijven werken en het gespleten brein herstellen zodra een van de speciale kanalen Los Angeles-Amsterdam-Moskou, Moskou-Amsterdam-Hong Kong- Los-Los komt beschikbaar in Angeles of ten minste één van de GRE-back-upoverlays.
Ditzelfde mechanisme stelt ons in staat om direct Let's Encrypt-certificaten uit te geven en te vernieuwen. Heel eenvoudig werkt het als volgt:
-
Zodra wij minimaal één HTTPS-verzoek zien voor het domein van onze klant zonder certificaat (of met een verlopen certificaat), meldt de externe node die het verzoek heeft geaccepteerd dit aan de interne certificeringsinstantie.
-
Als de gebruiker de uitgifte van Let's Encrypt niet heeft verboden, genereert de certificeringsinstantie een CSR, ontvangt een bevestigingstoken van LE en stuurt deze via een gecodeerd kanaal naar alle fronten. Nu kan elk knooppunt een valideringsverzoek van LE bevestigen.
-
Binnen enkele ogenblikken ontvangen wij het juiste certificaat en de private sleutel en sturen deze op dezelfde manier naar de fronten. Nogmaals, zonder de daemons opnieuw te starten
-
7 dagen vΓ³Γ³r de vervaldatum wordt de procedure voor het opnieuw ontvangen van het certificaat gestart
Op dit moment rouleren we 350 certificaten in realtime, volledig transparant voor gebruikers.
In de volgende artikelen van de serie zal ik het hebben over andere kenmerken van de realtime verwerking van groot webverkeer, bijvoorbeeld over het analyseren van RTT met behulp van onvolledige gegevens om de kwaliteit van de dienstverlening voor transitklanten te verbeteren en in het algemeen over het beschermen van transitverkeer tegen terabit-aanvallen, over de levering en aggregatie van verkeersinformatie, over WAF, vrijwel onbeperkte CDN en vele mechanismen voor het optimaliseren van de levering van inhoud.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Wat wil je eerst weten?
-
14,3%Algoritmen voor het clusteren en analyseren van de kwaliteit van webverkeer<3
-
33,3%Interne onderdelen van DDoS-Guard7-balancers
-
9,5%Bescherming van het transitoverkeer L3/L4
-
0,0%Websites beschermen tegen transitverkeer0
-
14,3%Firewall voor webapplicaties3
-
28,6%Bescherming tegen parseren en klikken6
21 gebruikers hebben gestemd. 6 gebruikers onthielden zich van stemming.
Bron: www.habr.com