Den legitime trafikken på DDoS-Guard-nettverket overskred nylig hundre gigabit per sekund. Foreløpig genereres 50 % av all trafikken vår av klientnetttjenester. Dette er mange titusenvis av domener, svært forskjellige og krever i de fleste tilfeller en individuell tilnærming.
Under snittet er hvordan vi administrerer frontnoder og utsteder SSL-sertifikater for hundretusenvis av nettsteder.
Det er enkelt å sette opp en front for ett nettsted, selv et veldig stort. Vi tar nginx eller haproxy eller lighttpd, konfigurerer det i henhold til guidene og glemmer det. Hvis vi trenger å endre noe, laster vi på nytt og glemmer igjen.
Alt endres når du behandler store mengder trafikk i farten, evaluerer legitimiteten til forespørsler, komprimerer og hurtigbufrer brukerinnhold, og samtidig endrer parametere flere ganger per sekund. Brukeren ønsker å se resultatet på alle eksterne noder umiddelbart etter at han har endret innstillingene i sin personlige konto. En bruker kan også laste ned flere tusen (og noen ganger titusenvis) domener med individuelle trafikkbehandlingsparametere via API. Alt dette bør også fungere umiddelbart i Amerika, og i Europa, og i Asia - oppgaven er ikke den mest trivielle, med tanke på at i Moskva alene er det flere fysisk adskilte filtreringsnoder.
Hvorfor er det mange store pålitelige noder rundt om i verden?
-
Tjenestekvalitet for klienttrafikk - forespørsler fra USA må behandles i USA (inkludert for angrep, analysering og andre uregelmessigheter), og ikke trekkes til Moskva eller Europa, noe som øker behandlingsforsinkelsen uforutsigbart.
-
Angrepstrafikken må lokaliseres - transittoperatører kan forringes under angrep, hvis volumet ofte overstiger 1Tbps. Å transportere angrepstrafikk over transatlantiske eller transasiatiske forbindelser er ikke en god idé. Vi hadde virkelige tilfeller da Tier-1-operatører sa: "Angrepsvolumet du mottar er farlig for oss." Det er derfor vi aksepterer innkommende strømmer så nær kildene deres som mulig.
-
Strenge krav til kontinuitet i tjenesten – renholdssentraler skal ikke være avhengige verken av hverandre eller av lokale arrangementer i vår raskt skiftende verden. Kuttet du strømmen til alle de 11 etasjene i MMTS-9 i en uke? - ikke noe problem. Ikke en eneste klient som ikke har en fysisk forbindelse på dette bestemte stedet vil lide, og webtjenester vil ikke under noen omstendigheter lide.
Hvordan håndtere alt dette?
Tjenestekonfigurasjoner bør distribueres til alle frontnoder så raskt som mulig (ideelt sett umiddelbart). Du kan ikke bare ta og gjenoppbygge tekstkonfigurasjoner og starte demonene på nytt ved hver endring - den samme nginx holder prosessene stengt (arbeider stenger av) i noen minutter til (eller kanskje timer hvis det er lange websocket-økter).
Når du laster inn nginx-konfigurasjonen på nytt, er følgende bilde ganske normalt:
Om minneutnyttelse:
Gamle arbeidere spiser opp hukommelse, inkludert hukommelse som ikke er lineært avhengig av antall tilkoblinger – dette er normalt. Når klientforbindelser lukkes, vil dette minnet bli frigjort.
Hvorfor var ikke dette et problem da nginx akkurat startet? Det var ingen HTTP/2, ingen WebSocket, ingen massive lange keep-alive-forbindelser. 70 % av nettrafikken vår er HTTP/2, noe som betyr svært lange forbindelser.
Løsningen er enkel - ikke bruk nginx, administrer ikke fronter basert på tekstfiler, og send absolutt ikke zippede tekstkonfigurasjoner over transpacific-kanaler. Kanalene er selvfølgelig garantert og reservert, men det gjør dem ikke mindre transkontinentale.
Vi har vår egen frontserver-balanserer, den interne delen jeg vil snakke om i de følgende artiklene. Det viktigste den kan gjøre er å bruke tusenvis av konfigurasjonsendringer per sekund på flukt, uten omstarter, omlastinger, plutselige økninger i minneforbruk og alt det der. Dette ligner veldig på Hot Code Reload, for eksempel i Erlang. Dataene lagres i en geodistribuert nøkkelverdidatabase og leses umiddelbart av frontaktuatorene. De. du laster opp SSL-sertifikatet via nettgrensesnittet eller API i Moskva, og i løpet av få sekunder er det klart for å gå til vårt rengjøringssenter i Los Angeles. Hvis en verdenskrig plutselig skjer og Internett forsvinner over hele verden, vil nodene våre fortsette å jobbe autonomt og reparere den splittede hjernen så snart en av de dedikerte kanalene Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hong Kong- Los-Los blir tilgjengelig. Angeles eller minst ett av GRE-sikkerhetskopioverleggene.
Den samme mekanismen lar oss umiddelbart utstede og fornye Let's Encrypt-sertifikater. Veldig enkelt fungerer det slik:
-
Så snart vi ser minst én HTTPS-forespørsel for vår klients domene uten et sertifikat (eller med et utløpt sertifikat), rapporterer den eksterne noden som godtok forespørselen dette til den interne sertifiseringsmyndigheten.
-
Hvis brukeren ikke har forbudt utstedelse av Let's Encrypt, genererer sertifiseringsmyndigheten en CSR, mottar en bekreftelsestoken fra LE og sender den til alle fronter over en kryptert kanal. Nå kan enhver node bekrefte en validerende forespørsel fra LE.
-
Om noen få øyeblikk vil vi motta riktig sertifikat og privat nøkkel og sende det til frontene på samme måte. Igjen, uten å starte demonene på nytt
-
7 dager før utløpsdatoen igangsettes prosedyren for å motta sertifikatet på nytt
Akkurat nå roterer vi 350 XNUMX sertifikater i sanntid, helt gjennomsiktig for brukerne.
I de følgende artiklene i serien vil jeg snakke om andre funksjoner ved sanntidsbehandling av stor nettrafikk - for eksempel om å analysere RTT ved å bruke ufullstendige data for å forbedre kvaliteten på tjenesten for transittkunder og generelt om å beskytte transittrafikk fra terabit-angrep, om levering og aggregering av trafikkinformasjon, om WAF, nesten ubegrenset CDN og mange mekanismer for å optimalisere innholdslevering.
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Hva vil du vite først?
-
14,3%Algoritmer for gruppering og analyse av kvaliteten på nettrafikk<3
-
33,3%Internaler av DDoS-Guard7 balansere
-
9,5%Beskyttelse av transitt L3/L4 trafikk2
-
0,0%Beskytte nettsteder mot kollektivtrafikk0
-
14,3%Brannmur for nettapplikasjoner 3
-
28,6%Beskyttelse mot parsing og klikking6
21 brukere stemte. 6 brukere avsto.
Kilde: www.habr.com