Den legitima trafiken på DDoS-Guard-nätverket översteg nyligen hundra gigabit per sekund. För närvarande genereras 50 % av all vår trafik av klientwebbtjänster. Det handlar om många tiotusentals domäner, väldigt olika och i de flesta fall kräver ett individuellt tillvägagångssätt.
Nedanför snittet är hur vi hanterar frontnoder och utfärdar SSL-certifikat för hundratusentals sajter.
Det är enkelt att skapa en front för en webbplats, även en mycket stor. Vi tar nginx eller haproxy eller lighttpd, konfigurerar det enligt guiderna och glömmer det. Om vi behöver ändra något, laddar vi om och glömmer igen.
Allt förändras när du bearbetar stora trafikvolymer i farten, utvärderar legitimiteten hos förfrågningar, komprimerar och cachelagrar användarinnehåll och samtidigt ändrar parametrar flera gånger per sekund. Användaren vill se resultatet på alla externa noder direkt efter att han har ändrat inställningarna i sitt personliga konto. En användare kan också ladda ner flera tusen (och ibland tiotusentals) domäner med individuella trafikbearbetningsparametrar via API:et. Allt detta borde också fungera omedelbart i Amerika, och i Europa och i Asien - uppgiften är inte den mest triviala, med tanke på att det bara i Moskva finns flera fysiskt åtskilda filtreringsnoder.
Varför finns det många stora pålitliga noder runt om i världen?
-
Servicekvalitet för klienttrafik - förfrågningar från USA måste behandlas i USA (inklusive för attacker, analys och andra anomalier), och inte dras till Moskva eller Europa, vilket oförutsägbart ökar bearbetningsfördröjningen.
-
Attacktrafik måste vara lokaliserad - transitoperatörer kan försämras under attacker, vars volym ofta överstiger 1 Tbps. Att transportera attacktrafik över transatlantiska eller transasiatiska länkar är inte en bra idé. Vi hade verkliga fall när Tier-1-operatörer sa: "Mängden attacker du får är farliga för oss." Det är därför vi accepterar inkommande strömmar så nära deras källor som möjligt.
-
Strikta krav på kontinuitet i servicen – städcentraler ska inte vara beroende av vare sig varandra eller lokala evenemang i vår snabbt föränderliga värld. Stängde du av strömmen till alla 11 våningarna i MMTS-9 under en vecka? - inga problem. Inte en enda klient som inte har en fysisk anslutning på just den här platsen kommer att drabbas, och webbtjänster kommer inte att drabbas under några omständigheter.
Hur ska man hantera allt detta?
Tjänstekonfigurationer bör distribueras till alla frontnoder så snabbt som möjligt (helst omedelbart). Du kan inte bara ta och bygga om textkonfigurationer och starta om demonerna vid varje förändring - samma nginx håller processer avstängda (arbetaren stänger av) i några minuter till (eller kanske timmar om det finns långa webbsocketsessioner).
När du laddar om nginx-konfigurationen är följande bild ganska normal:
Om minnesanvändning:
Gamla arbetare äter upp minne, inklusive minne som inte är linjärt beroende av antalet anslutningar - detta är normalt. När klientanslutningar stängs kommer detta minne att frigöras.
Varför var inte detta ett problem när nginx precis började? Det fanns ingen HTTP/2, ingen WebSocket, inga massiva långa keep-alive-anslutningar. 70 % av vår webbtrafik är HTTP/2, vilket innebär mycket långa anslutningar.
Lösningen är enkel - använd inte nginx, hantera inte fronter baserat på textfiler, och skicka absolut inte zippade textkonfigurationer över transpacific-kanaler. Kanalerna är naturligtvis garanterade och reserverade, men det gör dem inte mindre transkontinentala.
Vi har vår egen frontserver-balanserare, vars interna delar jag kommer att prata om i följande artiklar. Det viktigaste som den kan göra är att tillämpa tusentals konfigurationsändringar per sekund i farten, utan omstarter, omladdningar, plötsliga ökningar i minnesförbrukning och allt det där. Detta är väldigt likt Hot Code Reload, till exempel i Erlang. Data lagras i en geodistribuerad nyckel-värdesdatabas och läses omedelbart av de främre ställdonen. De där. du laddar upp SSL-certifikatet via webbgränssnittet eller API i Moskva, och på några sekunder är det klart att åka till vårt städcenter i Los Angeles. Om ett världskrig plötsligt inträffar och internet försvinner över hela världen, kommer våra noder att fortsätta arbeta autonomt och reparera den splittrade hjärnan så fort en av de dedikerade kanalerna Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hong Kong- Los-Los blir tillgängligt. Angeles eller åtminstone en av GRE-backup-överläggen.
Samma mekanism tillåter oss att omedelbart utfärda och förnya Let's Encrypt-certifikat. Mycket enkelt fungerar det så här:
-
Så snart vi ser minst en HTTPS-begäran för vår klients domän utan ett certifikat (eller med ett utgånget certifikat), rapporterar den externa noden som accepterade begäran detta till den interna certifieringsmyndigheten.
-
Om användaren inte har förbjudit utfärdandet av Let's Encrypt, genererar certifieringsmyndigheten en CSR, tar emot en bekräftelsetoken från LE och skickar den till alla fronter över en krypterad kanal. Nu kan vilken nod som helst bekräfta en validerande begäran från LE.
-
Om några ögonblick kommer vi att få rätt certifikat och privat nyckel och skicka det till fronterna på samma sätt. Återigen, utan att starta om demonerna
-
7 dagar före utgångsdatumet inleds förfarandet för att återta certifikatet
Just nu roterar vi 350 XNUMX certifikat i realtid, helt transparenta för användarna.
I de följande artiklarna i serien kommer jag att prata om andra funktioner i realtidsbehandling av stor webbtrafik - till exempel om att analysera RTT med ofullständig data för att förbättra servicekvaliteten för transitkunder och i allmänhet om att skydda transittrafik från terabitattacker, om leverans och aggregering av trafikinformation, om WAF, nästan obegränsad CDN och många mekanismer för att optimera innehållsleverans.
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Vad skulle du vilja veta först?
-
14,3%Algoritmer för klustring och analys av kvaliteten på webbtrafik<3
-
33,3%Interner i DDoS-Guard7-balanserare
-
9,5%Skydd av transittrafik L3/L4
-
0,0%Skydda webbplatser för kollektivtrafik0
-
14,3%Webbapplikationsbrandvägg3
-
28,6%Skydd mot att analysera och klicka6
21 användare röstade. 6 användare avstod från att rösta.
Källa: will.com