ProHoster > Blog > Administrimi > Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

Trafici legjitim në rrjetin DDoS-Guard kohët e fundit e kaloi njëqind gigabit në sekondë. Tani 50% e gjithë trafikut tonë gjenerohet nga shërbimet në ueb të klientëve. Këto janë shumë dhjetëra mijëra domain-e, shumë të ndryshme dhe në shumicën e rasteve që kërkojnë një qasje të veçantë.

Më poshtë - si menaxhojmë front-nodet dhe i ofrojmë Certifikatat SSL për qindra mijëra faqe.

Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

Të konfigurosh frontin për një faqe, edhe nëse është shumë e madhe, është e lehtë. Marrim nginx, haproxy ose lighttpd, e konfiguroni sipas udhëzimeve dhe harrojmë. Nëse nevojitet të ndryshojmë diçka - bëjmë një rifreskim dhe sërish harrojmë.

Të gjitha ndryshon kur përpunoni në kohë reale volume të mëdha trafiku, vlerësoni legjitimitetin e kërkesave, kompresoni dhe kesoni përmbajtjen e përdoruesve, dhe gjatë kësaj ndërroni parametrat disa herë në sekondë. Përdoruesi dëshiron të shohë rezultatin në të gjitha nodet e jashtme menjëherë pasi të ndryshojë parametrat në kabinetin e tij. Gjithashtu, përdoruesi mund të ngarkojë përmes API-t disa mijëra (ndonjëherë edhe dhjetëra mijëra) domain-e me parametra të veçantë për përpunimin e trafikut. Të gjitha këto gjithashtu duhet të funksionojnë menjëherë në Amerikë, Evropë dhe Azi - një detyrë jo aq triviale, duke pasur parasysh se vetëm në Moskë ka disa njësitë fizike të ndara të filtrimit.

Pse ka shumë njësive të mëdha dhe të besueshme 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 (pĂ«rfshirĂ« pĂ«r sulme, parsing dhe anomali tĂ« tjera), dhe jo tĂ« tĂ«rhiqen nĂ« MoskĂ« ose EvropĂ«, duke rritur nĂ« mĂ«nyrĂ« tĂ« paparashikueshme vonesĂ«n e pĂ«rpunimit.
  • Trafiku sulmues duhet tĂ« lokalizohet - operatorĂ«t e kalimit mund tĂ« degradojnĂ« gjatĂ« sulmeve, volumi i tĂ« cilave shpesh kalon 1Tbps. Transportimi i trafikut sulmues pĂ«rmes linjave transatlantike ose transaziatike - nuk Ă«shtĂ« ide e mirĂ«. Ne kemi pasur raste reale kur operatorĂ«t Tier-1 thanĂ«: "Volumet e sulmeve qĂ« po pranoni janĂ« tĂ« rrezikshme pĂ«r ne". PikĂ«risht pĂ«r kĂ«tĂ« arsye, ne pranojmĂ« rrjedhat hyrĂ«se sa mĂ« afĂ«r burimeve tĂ« tyre.
  • KĂ«rkesat e ashpra pĂ«r vazhdimĂ«sinĂ« e shĂ«rbimit - qendrat e filtrimit nuk duhet tĂ« varen nga njĂ«ra-tjetra, as nga ngjarjet lokale tĂ« botĂ«s sonĂ« nĂ« ndryshim tĂ« shpejtĂ«. U shkĂ«putĂ«n tĂ« gjitha 11 katet e MMT-9 pĂ«r njĂ« javĂ«? - nuk ka problem. Nuk do tĂ« dĂ«mtohet asnjĂ« klient, qĂ« nuk ka njĂ« lidhje fizike nĂ« kĂ«tĂ« lokacion, dhe shĂ«rbimet nĂ« ueb nuk do tĂ« dĂ«mtohen nĂ«n asnjĂ« rrethanĂ«.

Si ta menaxhojmë të gjitha këto?

Konfigurimet e shërbimeve duhet të shpërndahen sa më shpejt (në mënyrë ideale menjëherë) në të gjitha front-nodet. Nuk mund të merrni dhe ristrukturoni konfigurimet tekstuale dhe të bëni rifillime demonësh për çdo ndryshim - i njëjti nginx mban proceset që përfundojnë (worker shutting down) për disa minuta (ose ndoshta edhe orë nëse ka sesi të gjatë websocket).

Kur rikonfigurohet, kjo është pamja e zakonshme:

Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

PĂ«r riciklimin e memories:

Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

Përpunuesit e vjetër konsumojnë memory, përfshirë atë që nuk varet në mënyrë lineare nga numri i lidhjeve - kjo është normale. Kur lidhjet e klientëve të mbyllen, kjo memory do të lirohet.

Pse kjo nuk ishte një problem kur nginx filloi të zhvillohet? Nuk kishte as HTTP/2, as WebSocket, as lidhje të gjata të zakonshme me mbajtje të gjata. 70% e trafikut tonë në web është HTTP/2, dhe këto janë lidhje shumë të gjata.

Zgjidhja është e thjeshtë - mos e përdorni nginx, mos e menaxhoni frontet përmes skedarëve tekstualë, dhe për më tepër, mos i dërgoni konfigurimet e zipezuara tekstuale përmes kanaleve trans-paqësore. Kanalet, sigurisht, janë të garantuara dhe të rezervuara, por kjo nuk i bën më pak transkontinentale.

Ne kemi një front-server-balancer të vetin, për të cilin do të flas në artikujt e tjerë. E rëndësishme është se ai di të aplikojë mijëra ndryshime konfigurimesh në sekondë në mënyrë të menjëhershme, pa rifillime, pa rifreskime, pa rritje të papritur të konsumit të memories dhe gjithçka tjetër. Kjo është shumë e ngjashme me Hot Code Reload, për shembull në Erlang. Të dhënat ruhen në një bazë të shpërndarë gjeografikisht key-value dhe lexohet menjëherë nga mekanizmat ekzekutues të frontit. Pra, ju ngarkuat një certifikat SSL përmes ndërfaqes në web apo API në Moskë, dhe pas disa sekondash është gati për punë në qendrën tonë të filtrimit në Los Angeles. Nëse ndonjëherë ndodh një luftë botërore dhe interneti humbet në të gjithë botën, nodet tona do të vazhdojnë të punojnë autonomisht dhe do të rikthejnë 'split-brain', sa herë që një nga kanalet e dedikuara Los Angeles-Amsterdam-Moskë, Moskë-Amsterdam-Hong-Kong-Los Angeles, ose ndonjë nga mbështetje rezervë GRE bëhet e qasshme.

Ky mekanizĂ«m gjithashtu na lejon tĂ« lĂ«shojmĂ« dhe zgjatim certifikatat Let’s Encrypt. NĂ« mĂ«nyrĂ« tĂ« thjeshtĂ«, funksionon kĂ«shtu:

  1. Sa herë që shohim të paktën një kërkesë HTTPS për domenin e klientit tonë pa certifikatë (ose me certifikatë të skaduar), nodi i jashtëm që pranon kërkesën e raporton këtij qendre të brendshme të certificimit.

    Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

  2. NĂ«se pĂ«rdoruesi nuk e ka ndaluar lĂ«shimin e Let’s Encrypt, qendra e certificimit formon CSR, merr nga LE njĂ« token konfirmimi 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.

    Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

  3. Pas disa çastesh do tĂ« marrim njĂ« certifikatĂ« tĂ« saktĂ« dhe njĂ« çelĂ«s privat dhe po ashtu do t’i shpĂ«rndajmĂ« frontet. PĂ«rsĂ«ri pa rinisur demonĂ«t.

    Web-HighLoad — si menaxhojmĂ« trafikun e dhjetĂ«ra mijĂ«ra domeineve

  4. 7 ditë para datës së skadencës, niset procedura për ripërfitimin e certifikatës.

Tani për tani rrotullojmë në kohë reale 350,000 certifikata plotësisht në mënyrë transparente për përdoruesit.

Në artikujt e ardhshëm të ciklit do të flas për tipare të tjera të përpunimit në kohë reale të trafikut të madh në internet - për shembull, për analizimin e RTT sipas të dhënave të paplota për të përmirësuar cilësinë e shërbimit për klientët e transitit dhe në përgjithësi për mbrojtjen e trafikut të transitit nga sulmet terabit, për shpërndarjen dhe agregimin e informacionit mbi trafikun, për WAF, një CDN pothuajse të pakufizuar dhe shumë mekanizma optimizimi të dorëzimit të përmbajtjes.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutemi.

Për çfarë do të dëshironit të dinit së pari?

  • 14,3%Algoritmet e klastrimit dhe analizĂ«s sĂ« cilĂ«sisĂ« sĂ« trafikut tĂ« internetit<3
  • 33,3%BrendĂ«sitĂ« e balancuesve DDoS-Guard7
  • 9,5%Mbrojtja e trafikut L3/L4 tĂ« transitit2
  • 0,0%Mbrojtja e faqeve tĂ« internetit mbi trafikun e transitit0
  • 14,3%Firewall pĂ«r Aplikacionin Web3
  • 28,6%Mbrojtja nga parsing dhe klikim6

Votuan 21 përdorues. Abstenuan 6 përdorues.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster