DDoS-Guard sareko trafiko legitimoak ehun gigabit segundoko gainditu ditu duela gutxi. Gaur egun, gure trafiko guztiaren %50 bezeroen web zerbitzuek sortzen dute. Hamarnaka milaka domeinu dira hauek, oso desberdinak eta kasu gehienetan banakako ikuspegia eskatzen dutenak.
Ebakiaren azpian aurrealdeko nodoak nola kudeatzen ditugun eta ehunka milaka gunetarako SSL ziurtagiriak igortzen ditugu.
Gune baterako frontea ezartzea, nahiz eta oso handia izan, erraza da. Nginx edo haproxy edo lighttpd hartzen dugu, giden arabera konfiguratzen dugu eta ahaztu egiten dugu. Zerbait aldatu behar badugu, berriro kargatu eta berriro ahazten dugu.
Dena aldatzen da trafiko-bolumen handiak hegan prozesatzen dituzunean, eskaeren zilegitasuna ebaluatzen duzunean, erabiltzaileen edukia konprimitzen eta katxeatzen duzunean eta, aldi berean, parametroak segundoko hainbat aldiz aldatzen dituzunean. Erabiltzaileak emaitza kanpoko nodo guztietan ikusi nahi du bere kontu pertsonaleko ezarpenak aldatu eta berehala. Erabiltzaile batek hainbat milaka (eta batzuetan dozenaka milaka) domeinu deskarga ditzake trafikoa prozesatzeko parametro indibidualekin APIaren bidez. Horrek guztiak berehala funtzionatu beharko luke Amerikan, eta Europan eta Asian - zeregina ez da hutsala, kontuan hartuta Moskun bakarrik fisikoki bereizita dauden hainbat iragazketa-nodo daudela.
Zergatik daude munduan zehar nodo fidagarri handi asko?
-
Bezeroen trafikoaren zerbitzuaren kalitatea - AEBetako eskaerak AEBetan prozesatu behar dira (eraso, analisia eta bestelako anomaliak barne), eta ez Moskura edo Europara eraman, prozesatzeko atzerapena ezusteko handituz.
-
Erasoen trafikoa lokalizatu egin behar da - garraio-operadoreek erasoetan degradatu dezakete, eta horien bolumena 1 Tbps gainditzen du askotan. Eraso-trafikoa transatlantiko edo transasiar loturen bidez garraiatzea ez da ideia ona. Benetako kasuak izan genituen Tier-1 operadoreek esan zutenean: "Jasotzen dituzun erasoen bolumena arriskutsua da guretzat". Horregatik, sarrerako korronteak beren iturrietatik ahalik eta hurbilen onartzen ditugu.
-
Zerbitzuaren jarraipenerako baldintza zorrotzak - garbiketa zentroek ez lukete ez bata bestearen edo tokiko gertaeren araberakoa izan behar azkar aldatzen ari den gure munduan. Astebetez MMTS-11ko 9 solairuei argindarra eten al diezu? - arazorik ez. Kokapen zehatz honetan konexio fisikorik ez duen bezero bakar batek ere ez du sufrituko, eta web-zerbitzuek ez dute inola ere jasango.
Nola kudeatu hau guztia?
Zerbitzuaren konfigurazioak aurrealdeko nodo guztietan banatu behar dira ahalik eta azkarren (egokiena berehala). Ezin dituzu testu-konfigurazioak hartu eta berreraiki eta deabruak berrabiarazi aldaketa bakoitzean - nginx berak prozesuak itzaltzen ditu (langilea itzaltzen) minutu batzuk gehiagoz (edo agian orduak websocket saio luzeak badira).
Nginx konfigurazioa berriro kargatzean, argazki hau nahiko normala da:
Memoriaren erabilerari buruz:
Langile zaharrek memoria jaten dute, konexio kopuruaren arabera linealki ez den memoria barne - hau normala da. Bezeroaren konexioak ixten direnean, memoria hau askatuko da.
Zergatik ez zen hau arazo bat nginx hasi berria zenean? Ez zegoen HTTP/2, ez WebSocket, ez mantentze-biziko konexio luze masiboak. Gure web trafikoaren % 70 HTTP/2 da, hau da, konexio oso luzeak esan nahi du.
Irtenbidea sinplea da: ez erabili nginx, ez kudeatu testu-fitxategietan oinarritutako fronteak eta, zalantzarik gabe, ez bidali konprimatutako testu-konfigurazioak opazifikoen bidez. Kanalak, noski, bermatuak eta erreserbatuak dira, baina horrek ez ditu transkontinental gutxiago bihurtzen.
Gure aurrealdeko zerbitzari-orekatzailea dugu, zeinaren barnekoak hurrengo artikuluetan hitz egingo dudana. Egin dezakeen gauza nagusia segundoko milaka konfigurazio-aldaketa hegan aplikatzea da, berrabiarazi, birkargatu, memoria-kontsumoaren bat-bateko igoerarik gabe eta hori guztia. Hot Code Reload-en oso antzekoa da, adibidez Erlang-en. Datuak geo-banatutako gako-balioen datu-base batean gordetzen dira eta berehala irakurtzen dituzte aurreko eragileek. Horiek. Moskuko web interfazearen edo APIaren bidez igotzen duzu SSL ziurtagiria, eta segundo gutxitan Los Angeleseko gure garbiketa zentrora joateko prest dago. Mundu gerra bat bat-batean gertatzen bada eta Internet mundu osoan desagertzen bada, gure nodoek modu autonomoan lanean jarraituko dute eta zatitutako garuna konponduko dute Los Angeles-Amsterdam-Mosku, Mosku-Amsterdam-Hong Kong- kate dedikatuetako bat bezain laster. Los-Los eskuragarri egongo da. Angeles edo GREren babeskopia gainjarrietako bat gutxienez.
Mekanismo honek Let's Encrypt ziurtagiriak berehala eman eta berritzeko aukera ematen digu. Oso sinplea da honela funtzionatzen du:
-
Gure bezeroaren domeinurako gutxienez HTTPS eskaera bat ziurtagiririk gabe (edo iraungitako ziurtagiri batekin) ikusten dugun bezain laster, eskaera onartu duen kanpoko nodoak horren berri ematen dio barne ziurtagiri-agintaritzari.
-
Erabiltzaileak ez badu debekatu Let's Encrypt igortzea, ziurtapen-agintaritzak CSR bat sortzen du, LE-tik berrespen-token bat jasotzen du eta fronte guztietara bidaltzen du enkriptatutako kanal baten bidez. Orain edozein nodok LE-ren baliozkotze eskaera berretsi dezake.
-
Momentu gutxiren buruan, ziurtagiri eta gako pribatu egokiak jasoko ditugu eta frontoietara bidaliko ditugu era berean. Berriz ere, deabruak berrabiarazi gabe
-
Iraungitze-data baino 7 egun lehenago, ziurtagiria berriro jasotzeko prozedura hasten da
Oraintxe bertan 350 ziurtagiri txandakatzen ari gara denbora errealean, erabiltzaileentzat guztiz gardenak.
Serieko hurrengo artikuluetan, web trafiko handiaren denbora errealean prozesatzeko beste ezaugarri batzuei buruz hitz egingo dut; adibidez, RTT datu osatugabeak erabiliz aztertzeaz, garraio-bezeroen zerbitzuaren kalitatea hobetzeko eta, oro har, garraio-trafikoa babesteari buruz. terabit erasoak, trafikoaren informazioa emateari eta batzeari buruzkoak, WAFari buruz, CDN ia mugagabeari eta edukien banaketa optimizatzeko mekanismo asko.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Zer jakin nahiko zenuke lehenik?
-
14,3%Web trafikoaren kalitatea multzokatzeko eta aztertzeko algoritmoak<3
-
33,3%DDoS-Guard7 orekatzaileen barnekoak
-
9,5%L3/L4 trafikoaren babesa2
-
0,0%Garraio-trafikoan webguneak babestea0
-
14,3%Web Aplikazioen Firewall3
-
28,6%Analisiaren eta klikaren aurkako babesa6
21 erabiltzailek eman dute botoa. 6 erabiltzaile abstenitu ziren.
Iturria: www.habr.com