Traffiku legjitim në rrjetin DDoS-Guard së fundmi ka tejkaluar njëqind gigabit në sekondë. Tani 50% e gjithë trafikut tonë gjenerohet nga shërbimet web të klientëve. Këto janë shumë dhjetëra mijëra domene, shumë të ndryshme dhe në shumicën e rasteve kërkojnë një qasje individuale.
Poshtë - si menaxhojmë nodet para dhe ofrojmë Certifikatat SSL për qindra mijëra faqesh.
Të konfigurosh një front për një faqe, madje edhe për një të shumë të madhe, është e thjeshtë. Marrim nginx, haproxy ose lighttpd, e konfigurojmë sipas udhëzimeve dhe harrojmë. Nëse na nevojitet të ndryshojmë diçka - bëjmë reload dhe sërish harrojmë.
Të gjitha ndryshon kur përpunoni në lëvizje sasi të mëdha trafiku, vlerësoni legjitimitetin e kërkesave, kompresoni dhe cache-oni përmbajtjen e përdoruesit, dhe në të njëjtën kohë ndryshoni parametrat disa herë në sekondë. Përdoruesi dëshiron të shohë rezultatin në të gjitha nodet e jashtme menjëherë pas ndryshimit të cilësimeve në llogarinë e tij. Dhe gjithashtu, përdoruesi mund të ngarkojë përmes API disa mijëra (dhe ndonjëherë dhjetëra mijëra) domene me parametra të veçantë për përpunimin e trafikut. Të gjitha këto gjithashtu duhet të funksionojnë menjëherë dhe në Amerikë, dhe në Evropë, dhe në Azinë - një detyrë jo shumë triviale, duke marrë parasysh se vetëm në Moskë ka disa nyje filtrimi të shpërndara fizikisht.
Pse ka kaq shumë nodë të mëdha besuese në të gjithë botën?
- Cilësia e shërbimit të trafikut të klientëve - kërkesat nga SHBA duhet të përpunohen pikërisht në SHBA (duke përfshirë për sulme, parsing dhe anomalitë e tjera), dhe jo të tërhiqen në Moskë apo Evropë, duke rritur papërcaktueshëm vonesën e përpunimit.
- Trafiku sulmues duhet lokalizuar - operatorët e tranzitit mund të degradohen gjatë sulmeve, sasia e të cilave shpesh tejkalon 1Tbps. Të transportosh trafikun sulmues përmes linjave transatlantike ose transaziatike - nuk është ide e mirë. Kemi pasur raste reale, kur operatorët Tier-1 thonin: "Sasia e sulmeve që po pranoni është e rrezikshme për ne". Pikërisht për këtë arsye ne pranojmë rrjedhat e ardhshme sa më afër burimeve të tyre.
- KĂ«rkesat e rrepta pĂ«r vazhdimĂ«sinĂ« e shĂ«rbimit â qendrat e pastrimit nuk duhet tĂ« varen nga njĂ«ra-tjetra, as nga ngjarjet lokale tĂ« botĂ«s sonĂ« qĂ« po ndryshon me shpejtĂ«si. U ndĂ«rpre energjia pĂ«r njĂ« javĂ« nĂ« tĂ« gjithĂ« 11 katet e MMT-9? â nuk Ă«shtĂ« aspak problem. AsnjĂ« klient nuk do tĂ« dĂ«mtohet, pĂ«rveç atyre qĂ« kanĂ« lidhje fizike nĂ« kĂ«tĂ« lokacion, dhe shĂ«rbimet nĂ« internet nuk do tĂ« preken nĂ« asnjĂ« rast.
Si mund të menaxhohet gjithçka kjo?
Konfigurimet e shĂ«rbimeve duhet tĂ« shpĂ«rndahen sa mĂ« shpejt (idealisht menjĂ«herĂ«) nĂ« tĂ« gjithĂ« front-nodet. Nuk mund tĂ« merrni dhe tĂ« rindĂ«rtoni konfigurimet tekstuale dhe tĂ« bĂ«ni rindezje demonĂ«sh pĂ«r çdo ndryshim â nginx mban proceset qĂ« po mbyllen (worker shutting down) pĂ«r disa minuta (apo ndoshta edhe orĂ« nĂ«se ka seanca tĂ« gjatĂ« websocket).
Kur rindez konfigurimin, pamja e mëposhtme është plotësisht normale:
Për sa i përket riciklimit të memories:
VorkerĂ«t e vjetĂ«r hanĂ« memorie, pĂ«rfshirĂ« edhe atĂ« qĂ« nuk varet linearisht nga numri i lidhjeve, â kjo Ă«shtĂ« normale. Kur lidhjet e klientĂ«ve mbyllen, kjo memorie do tĂ« lirohet.
Pse kjo nuk ishte një problem kur nginx sapo fillonte të zhvillohej? Nuk kishte as HTTP/2, as WebSocket, as lidhje të gjata dhe masive keep-alive. 70% e trafikut tonë të internetit është HTTP/2, dhe këto janë lidhje shumë të gjata.
Zgjidhja Ă«shtĂ« e thjeshtĂ« â mos pĂ«rdorni nginx, mos menaxhoni frontet mbi baza tĂ« skedarĂ«ve tekstualĂ«, dhe pĂ«r mĂ« tepĂ«r, mos dĂ«rgoni konfigurimet tekstuale tĂ« zipoara pĂ«rmes kanaleve transatlantike. Kanalet, sigurisht, janĂ« tĂ« garantuara dhe tĂ« rezervuara, por kjo nuk i bĂ«n mĂ« pak transkontinentale.
Ne kemi një server balancer front-end tonin, për të cilin do flas në artikujt e ardhshëm. Gjëja kryesore që ai bën është të aplikojë mijëra ndryshime konfigurimi në sekondë në flukse, pa restartime, reloadime, rritje të papritur të konsumit të memories dhe gjithçka tjetër. Kjo është shumë e ngjashme me Hot Code Reload, p.sh. në Erlang. Të dhënat ruhen në një bazë të shpërndarë gjeografikisht key-value dhe lexohen menjëherë nga mekanizmat ekzekutivë të frontit. Kështu që, keni ngarkuar një certifikat SSL përmes ndërfaqes së uebit ose API në Moskë, dhe brenda disa sekondash ai është gati për t'u përdorur në qendrën tonë të pastrimit në Los Anxhelos. Nëse ndodhi një luftë botërore dhe interneti zhduket në të gjithë botën, nodat tona do të vazhdojnë të punojnë autonomisht dhe do të riparojnë split-brain sapo të bëhet e disponueshme një nga kanalet e dedikuara Los Anxhelos-Amsterdam-Moskë, Moskë-Amsterdam-Hon Kong-Los Anxhelos, ose të paktën një nga GRE rezervuese.
Ky mekanizĂ«m po ashtu na lejon tĂ« lĂ«shojmĂ« dhe rinovojmĂ« menjĂ«herĂ« certifikatat Letâs Encrypt. NĂ« mĂ«nyrĂ« shumĂ« tĂ« thjeshtĂ«, kjo funksionon kĂ«shtu:
- Sa herë që shohim edhe një kërkesë HTTPS për domenin e klientit tonë pa certifikatë (ose me certifikatë të skaduar), nodi i jashtëm që pranonte kërkesën, e njofton këtë qendrën e brendshme të certifikimit.
- NĂ«se pĂ«rdoruesi nuk e ka ndaluar lĂ«shimin e Letâs Encrypt, qendra e certifikimit formon CSR, merr njĂ« token konfirmimi nga LE dhe e shpĂ«rndan atĂ« nĂ« tĂ« gjitha frontet pĂ«rmes njĂ« kanali tĂ« enkriptuar. Tani çdo nod mund tĂ« konfirmojĂ« kĂ«rkesĂ«n validuese nga LE.
- PĂ«r disa momente, do tĂ« marrim njĂ« certifikatĂ« tĂ« saktĂ« dhe çelĂ«sin privat dhe nĂ« po tĂ« njĂ«jtĂ«n mĂ«nyrĂ« do tâi shpĂ«rndajmĂ« frontet. Edhe njĂ«herĂ« pa rinisje demonĂ«sh.
- 7 ditë para datës së skadencës, fillon procedura e riparimit të certifikatës.
Për momentin, ne në kohë reale po rrotullojmë 350,000 certifikata plotësisht transparente për përdoruesit.
Në artikujt e ardhshëm të ciklit do flas për veçori të tjera të trajtimit në kohë reale të trafikut të madh në ueb - për shembull, rreth analizës së RTT sipas të dhënave të pa plota për përmirësimin e cilësisë së shërbimit për klientët transit dhe për mbrojtjen e trafikët të transit nga sulmet terabits, për dërgimin dhe agregimin e informacionit mbi trafik, për WAF, një CDN gati pa kufizime dhe shumë mekanizma optimizimi të dorëzimit të përmbajtjes.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.
Për çfarë do donit të dinit së pari?
- 14,3%Algoritmet e klasterizimit dhe analizës së cilësisë së trafikut në internet<3
- 33,3%Brendësia e balancuesve DDoS-Guard7
- 9,5%Mbrojtja e trafikshëm L3/L42
- 0,0%Mbrojtja e faqeve të internetit ndaj trafikshmeve të transmisionit0
- 14,3%Firewalla për Aplikacionin Web3
- 28,6%Mbrojtja nga parserët dhe klikimet6
Votuan 21 përdorues. I abstenuan 6 përdorues.
Burimi: habr.com
