Legitimni promet v omrežju DDoS-Guard je nedavno presegel sto gigabitov na sekundo. Trenutno 50 % vsega našega prometa ustvarijo spletne storitve strank. Gre za več deset tisoč domen, ki so zelo različne in v večini primerov zahtevajo individualen pristop.
Spodaj je prikazano, kako upravljamo sprednja vozlišča in izdajamo potrdila SSL za več sto tisoč spletnih mest.
Postavitev fronte za eno spletno mesto, tudi zelo veliko, je enostavno. Vzamemo nginx ali haproxy ali lighttpd, ga konfiguriramo po navodilih in pozabimo nanj. Če moramo kaj spremeniti, naredimo ponovno nalaganje in spet pozabimo.
Vse se spremeni, ko sproti obdelujete velike količine prometa, ocenjujete legitimnost zahtev, stiskate in predpomnite uporabniško vsebino ter hkrati večkrat na sekundo spreminjate parametre. Uporabnik želi videti rezultat na vseh zunanjih vozliščih takoj po tem, ko je spremenil nastavitve v osebnem računu. Preko API-ja lahko uporabnik prenese tudi več tisoč (in včasih tudi več deset tisoč) domen s posameznimi parametri obdelave prometa. Vse to bi moralo takoj delovati tudi v Ameriki, v Evropi in v Aziji - naloga ni najbolj trivialna, glede na to, da je samo v Moskvi več fizično ločenih filtrirnih vozlišč.
Zakaj je po svetu veliko velikih zanesljivih vozlišč?
-
Kakovost storitev za promet strank – zahteve iz ZDA je treba obdelati v ZDA (vključno z napadi, razčlenjevanjem in drugimi anomalijami) in jih ne potegniti v Moskvo ali Evropo, kar nepredvidljivo poveča zamudo pri obdelavi.
-
Promet napadov mora biti lokaliziran - operaterji tranzita se lahko poslabšajo med napadi, katerih obseg pogosto presega 1Tbps. Prenos napadalnega prometa prek čezatlantskih ali transazijskih povezav ni dobra ideja. Imeli smo resnične primere, ko so operaterji stopnje 1 rekli: "Količina napadov, ki jih prejemate, je nevarna za nas." Zato sprejemamo dohodne tokove čim bližje njihovim virom.
-
Stroge zahteve glede kontinuitete storitev – čistilni centri v našem hitro spreminjajočem se svetu ne bi smeli biti odvisni niti drug od drugega niti od lokalnih dogodkov. Ste za en teden izklopili elektriko v vseh 11 nadstropjih MMTS-9? - ni problema. Noben odjemalec, ki nima fizične povezave na tej lokaciji, ne bo trpel, spletne storitve pa ne bodo trpele v nobenem primeru.
Kako vse to obvladati?
Konfiguracije storitev je treba čim hitreje razdeliti na vsa sprednja vozlišča (v idealnem primeru takoj). Ne morete preprosto vzeti in znova zgraditi besedilnih konfiguracij in znova zagnati demonov ob vsaki spremembi - isti nginx poskrbi za zaustavitev procesov (zapiranje delavca) še nekaj minut (ali morda ur, če so dolge seje spletne vtičnice).
Pri ponovnem nalaganju konfiguracije nginx je naslednja slika povsem običajna:
Glede uporabe pomnilnika:
Stari delavci jedo pomnilnik, vključno s pomnilnikom, ki ni linearno odvisen od števila povezav - to je normalno. Ko se odjemalske povezave zaprejo, se ta pomnilnik sprosti.
Zakaj to ni bila težava, ko se je nginx šele začel? Ni bilo HTTP/2, ni WebSocket, ni bilo velikih dolgotrajnih vzdrževalnih povezav. 70 % našega spletnega prometa je HTTP/2, kar pomeni zelo dolge povezave.
Rešitev je preprosta - ne uporabljajte nginx, ne upravljajte front na podlagi besedilnih datotek in vsekakor ne pošiljajte stisnjenih besedilnih konfiguracij po transpacifiških kanalih. Kanali so seveda zagotovljeni in rezervirani, a zaradi tega niso nič manj transkontinentalni.
Imamo svoj sprednji strežnik za uravnoteženje, o notranjosti katerega bom govoril v naslednjih člankih. Glavna stvar, ki jo lahko naredi, je, da sproti uporablja na tisoče konfiguracijskih sprememb na sekundo, brez ponovnih zagonov, ponovnih nalaganj, nenadnih povečanj porabe pomnilnika in vsega tega. To je zelo podobno Hot Code Reload, na primer v Erlangu. Podatki so shranjeni v geografsko porazdeljeni zbirki podatkov o ključih in vrednostih in jih takoj preberejo sprednji aktuatorji. Tisti. SSL certifikat naložite prek spletnega vmesnika ali API-ja v Moskvi in v nekaj sekundah je pripravljen za odhod v naš čistilni center v Los Angelesu. Če se nenadoma zgodi svetovna vojna in internet izgine po vsem svetu, bodo naša vozlišča še naprej delovala avtonomno in popravila razcepljene možgane takoj, ko bo eden od namenskih kanalov Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hong Kong- Los-Los postane na voljo. Angeles ali vsaj ena od varnostnih kopij GRE.
Ta isti mehanizem nam omogoča takojšnjo izdajo in obnovitev potrdil Let's Encrypt. Zelo preprosto deluje takole:
-
Takoj, ko opazimo vsaj eno zahtevo HTTPS za domeno našega odjemalca brez certifikata (ali s potečenim certifikatom), zunanje vozlišče, ki je zahtevo sprejelo, to sporoči notranjemu overitelju.
-
Če uporabnik ni prepovedal izdaje Let's Encrypt, certifikacijski organ ustvari CSR, prejme potrditveni žeton od LE in ga pošlje vsem frontam po šifriranem kanalu. Zdaj lahko katero koli vozlišče potrdi zahtevo za preverjanje od LE.
-
Čez nekaj trenutkov bomo prejeli pravilno potrdilo in zasebni ključ ter ga na enak način poslali na fronte. Spet brez ponovnega zagona demonov
-
7 dni pred iztekom veljavnosti se začne postopek za ponovni prevzem potrdila
Trenutno rotiramo 350 potrdil v realnem času, popolnoma pregledno za uporabnike.
V naslednjih člankih iz serije bom govoril o drugih funkcijah obdelave velikega spletnega prometa v realnem času – na primer o analizi RTT z uporabo nepopolnih podatkov za izboljšanje kakovosti storitev za tranzitne stranke in na splošno o zaščiti tranzitnega prometa pred terabitnih napadih, o dostavi in združevanju prometnih informacij, o WAF, skoraj neomejenem CDN in številnih mehanizmih za optimizacijo dostave vsebin.
V anketi lahko sodelujejo samo registrirani uporabniki. , prosim.
Kaj bi radi najprej izvedeli?
-
14,3%Algoritmi za združevanje in analiziranje kakovosti spletnega prometa<3
-
33,3%Notranjost balansirnih elementov DDoS-Guard7
-
9,5%Varovanje tranzitnega prometa L3/L4
-
0,0%Zaščita spletnih mest pri tranzitnem prometu0
-
14,3%Požarni zid spletne aplikacije 3
-
28,6%Zaščita pred razčlenjevanjem in klikanjem6
Glasovalo je 21 uporabnikov. 6 uporabnikov se je vzdržalo.
Vir: www.habr.com