Teisėtas srautas DDoS-Guard tinkle neseniai viršijo šimtą gigabitų per sekundę. Šiuo metu 50% viso mūsų srauto generuoja klientų žiniatinklio paslaugos. Tai yra daug dešimčių tūkstančių domenų, labai skirtingų ir daugeliu atvejų reikalaujančių individualaus požiūrio.
Žemiau nurodyta, kaip valdome priekinius mazgus ir išduodame SSL sertifikatus šimtams tūkstančių svetainių.
Vienos svetainės, net ir labai didelės, priekinę dalį lengva nustatyti. Paimame nginx arba haproxy arba lighttpd, sukonfigūruojame pagal vadovus ir pamirštame. Jei reikia ką nors pakeisti, perkrauname ir vėl pamirštame.
Viskas pasikeičia, kai apdorojate didelius srauto srautus, įvertinate užklausų teisėtumą, suspaudžiate ir talpinate vartotojo turinį, o tuo pačiu kelis kartus per sekundę keičiate parametrus. Vartotojas nori matyti rezultatą visuose išoriniuose mazguose iškart po to, kai pakeitė nustatymus savo asmeninėje paskyroje. Vartotojas taip pat gali atsisiųsti kelis tūkstančius (o kartais ir dešimtis tūkstančių) domenų su individualiais srauto apdorojimo parametrais per API. Visa tai taip pat turėtų iš karto veikti Amerikoje, Europoje ir Azijoje - užduotis nėra pati trivialiausia, turint omenyje, kad vien Maskvoje yra keli fiziškai atskirti filtravimo mazgai.
Kodėl visame pasaulyje yra daug didelių patikimų mazgų?
-
Klientų srauto paslaugų kokybė - užklausos iš JAV turi būti tvarkomos JAV (įskaitant atakas, analizavimą ir kitas anomalijas), o ne traukiamos į Maskvą ar Europą, nenuspėjamai padidinant apdorojimo delsą.
-
Atakos srautas turi būti lokalizuotas – tranzito operatoriai gali degraduoti atakų metu, kurių apimtis dažnai viršija 1Tbps. Atakų srauto perkėlimas transatlantinėmis ar transazinėmis jungtimis nėra gera idėja. Turėjome tikrų atvejų, kai 1 pakopos operatoriai pasakė: „Jūsų gaunamų atakų kiekis mums yra pavojingas“. Štai kodėl gauname srautus priimame kuo arčiau jų šaltinių.
-
Griežti paslaugų teikimo tęstinumo reikalavimai – valymo centrai neturėtų priklausyti nei vienas nuo kito, nei nuo vietinių įvykių mūsų sparčiai besikeičiančiame pasaulyje. Ar savaitei atjungėte maitinimą visuose 11 MMTS-9 aukštų? - jokiu problemu. Nenukentės nei vienas klientas, neturintis fizinio ryšio šioje konkrečioje vietoje, ir interneto paslaugos nenukentės jokiomis aplinkybėmis.
Kaip visa tai suvaldyti?
Paslaugų konfigūracijos turėtų būti kuo greičiau paskirstytos visiems priekiniams mazgams (idealiu atveju iš karto). Negalite tiesiog atstatyti teksto konfigūracijų ir iš naujo paleisti demonus kiekvieną kartą pakeitus – ta pati nginx dar kelias minutes (o gal valandas, jei yra ilgų žiniatinklio lizdo seansų) išjungia procesus (darbuotojas išsijungia).
Iš naujo įkeliant nginx konfigūraciją, toks vaizdas yra gana normalus:
Apie atminties naudojimą:
Seni darbuotojai suvalgo atmintį, įskaitant atmintį, kuri tiesiškai nepriklauso nuo jungčių skaičiaus – tai normalu. Uždarius kliento ryšius, ši atmintis bus atlaisvinta.
Kodėl tai nebuvo problema, kai nginx tik pradėjo veikti? Nebuvo nei HTTP/2, nei WebSocket, nei didžiulių ilgalaikių ryšių. 70 % mūsų žiniatinklio srauto sudaro HTTP/2, o tai reiškia labai ilgus ryšius.
Sprendimas paprastas – nenaudokite nginx, nevaldykite frontų pagal tekstinius failus ir tikrai nesiųskite supakuotų teksto konfigūracijų transpacific kanalais. Žinoma, kanalai yra garantuoti ir rezervuoti, tačiau dėl to jie nėra mažiau tarpkontinentiniai.
Turime savo priekinį serverį-balansuotoją, apie kurio vidinius elementus kalbėsiu kituose straipsniuose. Pagrindinis dalykas, kurį jis gali padaryti, yra pritaikyti tūkstančius konfigūracijos pakeitimų per sekundę be perkrovų, perkrovimų, staigaus atminties padidėjimo ir viso kito. Tai labai panašu į Hot Code Reload, pavyzdžiui, Erlang. Duomenys saugomi geografiškai paskirstytoje raktų reikšmių duomenų bazėje ir iš karto nuskaitomi priekinių pavarų. Tie. įkeliate SSL sertifikatą per žiniatinklio sąsają arba API Maskvoje ir po kelių sekundžių jis yra paruoštas keliauti į mūsų valymo centrą Los Andžele. Jei staiga kils pasaulinis karas ir visame pasaulyje išnyks internetas, mūsų mazgai ir toliau dirbs autonomiškai ir taisys suskaidytą smegenis, kai tik vienas iš tam skirtų kanalų Los Andželas-Amsterdamas-Maskva, Maskva-Amsterdamas-Honkongas- Los-Los tampa pasiekiamas. Andželas arba bent viena iš GRE atsarginių perdangų.
Tas pats mechanizmas leidžia mums akimirksniu išduoti ir atnaujinti Let's Encrypt sertifikatus. Labai paprastai tai veikia taip:
-
Kai tik matome bent vieną HTTPS užklausą mūsų kliento domenui be sertifikato (arba su pasibaigusio sertifikato galiojimu), išorinis mazgas, kuris priėmė užklausą, praneša apie tai vidinei sertifikavimo institucijai.
-
Jei vartotojas neuždraudė išduoti Let's Encrypt, sertifikavimo institucija sugeneruoja CSR, gauna patvirtinimo prieigos raktą iš LE ir siunčia jį visiems frontams šifruotu kanalu. Dabar bet kuris mazgas gali patvirtinti LE patvirtinimo užklausą.
-
Po kelių akimirkų gausime teisingą sertifikatą ir privatųjį raktą ir tuo pačiu būdu išsiųsime jį frontams. Vėlgi, neperkraunant demonų
-
Likus 7 dienoms iki galiojimo pabaigos, pradedama pakartotinio pažymėjimo gavimo procedūra
Šiuo metu mes keičiame 350 XNUMX sertifikatų realiuoju laiku, visiškai skaidriai vartotojams.
Tolesniuose serijos straipsniuose kalbėsiu apie kitas didelio žiniatinklio srauto apdorojimo realiuoju laiku ypatybes – pavyzdžiui, apie RTT analizę, naudojant nepilnus duomenis, siekiant pagerinti paslaugų kokybę tranzito klientams ir apskritai apie tranzito srauto apsaugą nuo terabitų atakų, apie srauto informacijos pateikimą ir kaupimą, apie WAF, beveik neribotą CDN ir daugybę turinio pateikimo optimizavimo mechanizmų.
Apklausoje gali dalyvauti tik registruoti vartotojai. , Prašau.
Ką pirmiausia norėtum sužinoti?
-
14,3%Žiniatinklio srauto grupavimo ir kokybės analizės algoritmai<3
-
33,3%DDoS-Guard7 balansierių vidinės dalys
-
9,5%Tranzitinio L3/L4 eismo apsauga2
-
0,0%Svetainių apsauga nuo tranzito srauto0
-
14,3%Žiniatinklio programų ugniasienė3
-
28,6%Apsauga nuo analizavimo ir spustelėjimo6
Balsavo 21 vartotojas. 6 vartotojai susilaikė.
Šaltinis: www.habr.com