Den lovlige trafik på DDoS-Guard-netværket oversteg for nylig hundrede gigabit pr. sekund. I øjeblikket genereres 50 % af al vores trafik af klientwebtjenester. Det er mange titusindvis af domæner, meget forskellige og kræver i de fleste tilfælde en individuel tilgang.
Nedenfor snittet er, hvordan vi administrerer frontnoder og udsteder SSL-certifikater til hundredtusindvis af websteder.
Det er nemt at konfigurere en front for ét websted, selv et meget stort,. Vi tager nginx eller haproxy eller lighttpd, konfigurerer det i henhold til guiderne og glemmer det. Hvis vi skal ændre noget, laver vi en genindlæsning og glemmer igen.
Alt ændrer sig, når du behandler store mængder trafik på farten, vurderer legitimiteten af anmodninger, komprimerer og cacher brugerindhold og samtidig ændrer parametre flere gange i sekundet. Brugeren ønsker at se resultatet på alle eksterne noder umiddelbart efter at han har ændret indstillingerne på sin personlige konto. En bruger kan også downloade flere tusinde (og nogle gange titusinder) domæner med individuelle trafikbehandlingsparametre via API'et. Alt dette burde også virke umiddelbart i Amerika, og i Europa og i Asien - opgaven er ikke den mest trivielle, i betragtning af at der alene i Moskva er flere fysisk adskilte filtreringsknuder.
Hvorfor er der mange store pålidelige noder rundt om i verden?
-
Servicekvalitet for klienttrafik - anmodninger fra USA skal behandles i USA (inklusive for angreb, parsing og andre uregelmæssigheder) og ikke trækkes til Moskva eller Europa, hvilket uforudsigeligt øger behandlingsforsinkelsen.
-
Angrebstrafik skal være lokaliseret - transitoperatører kan forringes under angreb, hvis volumen ofte overstiger 1 Tbps. Transport af angrebstrafik over transatlantiske eller transasiatiske forbindelser er ikke en god idé. Vi havde virkelige tilfælde, da Tier-1-operatører sagde: "Mængden af angreb, du modtager, er farlige for os." Det er derfor, vi accepterer indgående streams så tæt på deres kilder som muligt.
-
Strenge krav til kontinuitet i servicen - rengøringscentre bør ikke være afhængige af hverken hinanden eller af lokale begivenheder i vores hastigt skiftende verden. Afbrød du strømmen til alle 11 etager i MMTS-9 i en uge? - intet problem. Ikke en eneste klient, der ikke har en fysisk forbindelse på dette særlige sted, vil lide, og webtjenester vil under ingen omstændigheder lide.
Hvordan klarer man alt dette?
Tjenestekonfigurationer bør distribueres til alle frontnoder så hurtigt som muligt (ideelt set øjeblikkeligt). Du kan ikke bare tage og genopbygge tekstkonfigurationer og genstarte dæmonerne ved hver ændring - den samme nginx holder processer lukket ned (arbejder lukker ned) i et par minutter mere (eller måske timer, hvis der er lange websocketsessioner).
Når du genindlæser nginx-konfigurationen, er følgende billede ganske normalt:
Om hukommelsesudnyttelse:
Gamle arbejdere æder hukommelsen, inklusive hukommelse, der ikke lineært afhænger af antallet af forbindelser - det er normalt. Når klientforbindelser lukkes, frigøres denne hukommelse.
Hvorfor var dette ikke et problem, da nginx lige var begyndt? Der var ingen HTTP/2, ingen WebSocket, ingen massive lange keep-alive-forbindelser. 70 % af vores webtrafik er HTTP/2, hvilket betyder meget lange forbindelser.
Løsningen er enkel - brug ikke nginx, administrer ikke fronter baseret på tekstfiler, og send bestemt ikke zippede tekstkonfigurationer over transpacific-kanaler. Kanalerne er selvfølgelig garanterede og reserverede, men det gør dem ikke mindre transkontinentale.
Vi har vores egen frontserver-balancer, hvis interne elementer jeg vil tale om i de følgende artikler. Det vigtigste, det kan gøre, er at anvende tusindvis af konfigurationsændringer i sekundet på farten, uden genstart, genindlæsninger, pludselige stigninger i hukommelsesforbrug og alt det der. Dette minder meget om Hot Code Reload, for eksempel i Erlang. Dataene lagres i en geo-distribueret nøgleværdi-database og læses straks af frontaktuatorerne. De der. du uploader SSL-certifikatet via webgrænsefladen eller API i Moskva, og på få sekunder er det klar til at gå til vores rengøringscenter i Los Angeles. Hvis der pludselig sker en verdenskrig, og internettet forsvinder over hele verden, vil vores noder fortsætte med at arbejde selvstændigt og reparere den splittede hjerne, så snart en af de dedikerede kanaler Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hong Kong- Los-Los bliver tilgængelig. Angeles eller mindst et af GRE backup overlays.
Den samme mekanisme giver os mulighed for øjeblikkeligt at udstede og forny Let's Encrypt-certifikater. Meget enkelt fungerer det sådan her:
-
Så snart vi ser mindst én HTTPS-anmodning for vores klients domæne uden et certifikat (eller med et udløbet certifikat), rapporterer den eksterne node, der accepterede anmodningen, dette til den interne certificeringsmyndighed.
-
Hvis brugeren ikke har forbudt udstedelsen af Let's Encrypt, genererer certificeringsmyndigheden en CSR, modtager en bekræftelsestoken fra LE og sender den til alle fronter over en krypteret kanal. Nu kan enhver node bekræfte en validerende anmodning fra LE.
-
Om få øjeblikke vil vi modtage det korrekte certifikat og private nøgle og sende det til fronterne på samme måde. Igen, uden at genstarte dæmonerne
-
7 dage før udløbsdatoen påbegyndes proceduren for genmodtagelse af certifikatet
Lige nu roterer vi 350 certifikater i realtid, fuldstændig gennemsigtige for brugerne.
I de følgende artikler i serien vil jeg tale om andre funktioner i realtidsbehandling af stor webtrafik – for eksempel om at analysere RTT ved hjælp af ufuldstændige data til at forbedre servicekvaliteten for transitkunder og generelt om at beskytte transittrafik fra terabit-angreb, om levering og aggregering af trafikinformation, om WAF, næsten ubegrænset CDN og mange mekanismer til optimering af indholdslevering.
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Hvad vil du gerne vide først?
-
14,3 %Algoritmer til klyngedannelse og analyse af kvaliteten af webtrafik<3
-
33,3 %Internal af DDoS-Guard7 balancere
-
9,5 %Beskyttelse af transit L3/L4 trafik2
-
0,0 %Beskyttelse af websteder mod transittrafik0
-
14,3 %Webapplikations firewall3
-
28,6 %Beskyttelse mod parsing og klik6
21 brugere stemte. 6 brugere undlod at stemme.
Kilde: www.habr.com