ProHoster > Blogs > Administrācija > Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

LeÄ£itÄ«mā trafika DDoS-Guard tÄ«klā nesen pārsniedza simts gigabitus sekundē. PaÅ”laik 50% no visas mÅ«su trafika veido klientu tÄ«mekļa pakalpojumi. Tie ir daudzi desmiti tÅ«kstoÅ”u domēnu, kas ir ļoti atŔķirÄ«gi un vairumā gadÄ«jumu prasa individuālu pieeju.

Zemāk ir norādÄ«ts, kā mēs pārvaldām priekŔējos mezglus un izsniedzam SSL sertifikātus simtiem tÅ«kstoÅ”u vietņu.

Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

PriekÅ”puses iestatÄ«Å”ana vienai vietnei, pat ļoti lielai, ir vienkārÅ”a. Mēs ņemam nginx vai haproxy vai lighttpd, konfigurējam to saskaņā ar ceļvežiem un aizmirstam par to. Ja mums kaut kas jāmaina, mēs veicam pārlādÄ“Å”anu un atkal aizmirstam.

Viss mainās, kad lidojumā apstrādājat lielus trafika apjomus, novērtējat pieprasÄ«jumu likumÄ«bu, saspiežat un saglabājat lietotāja saturu keÅ”atmiņā un vienlaikus vairākas reizes sekundē maināt parametrus. Lietotājs vēlas redzēt rezultātu visos ārējos mezglos tÅ«lÄ«t pēc tam, kad viņŔ ir mainÄ«jis iestatÄ«jumus savā personÄ«gajā kontā. Lietotājs var arÄ« lejupielādēt vairākus tÅ«kstoÅ”us (dažreiz desmitiem tÅ«kstoÅ”u) domēnu ar atseviŔķiem trafika apstrādes parametriem, izmantojot API. Tam visam nekavējoties vajadzētu darboties arÄ« Amerikā, Eiropā un Āzijā - uzdevums nav pats triviālākais, ņemot vērā, ka Maskavā vien ir vairāki fiziski atdalÄ«ti filtrācijas mezgli.

Kāpēc visā pasaulē ir daudz lielu uzticamu mezglu?

  • Pakalpojuma kvalitāte klientu trafikam - pieprasÄ«jumi no ASV ir jāapstrādā ASV (tostarp par uzbrukumiem, parsÄ“Å”anu un citām anomālijām), nevis jāvelk uz Maskavu vai Eiropu, neprognozējami palielinot apstrādes aizkavi.

  • Uzbrukuma trafikam jābÅ«t lokalizētam ā€“ tranzÄ«ta operatori var degradēties uzbrukumu laikā, kuru apjoms bieži pārsniedz 1Tbps. Uzbrukuma satiksmes pārneÅ”ana pa transatlantiskajiem vai transāzijas savienojumiem nav laba ideja. Mums bija reāli gadÄ«jumi, kad 1. lÄ«meņa operatori teica: "JÅ«su saņemto uzbrukumu apjoms mums ir bÄ«stams." Tāpēc mēs pieņemam ienākoŔās straumes pēc iespējas tuvāk to avotiem.

  • Stingras prasÄ«bas pakalpojumu nepārtrauktÄ«bai ā€“ uzkopÅ”anas centriem nevajadzētu bÅ«t atkarÄ«giem ne viens no otra, ne vietējiem notikumiem mÅ«su strauji mainÄ«gajā pasaulē. Vai uz nedēļu atslēdzāt strāvu visiem MMTS-11 9 stāviem? - nekādu problēmu. NecietÄ«s neviens klients, kuram nav fiziska savienojuma Å”ajā konkrētajā vietā, un tÄ«mekļa pakalpojumi nekādā gadÄ«jumā necietÄ«s.

Kā to visu pārvaldīt?

Pakalpojumu konfigurācijas ir jāizplata visiem priekŔējiem mezgliem pēc iespējas ātrāk (ideālā gadÄ«jumā uzreiz). JÅ«s nevarat vienkārÅ”i pārbÅ«vēt teksta konfigurācijas un pārstartēt dēmonus katrā izmaiņā ā€” tas pats nginx aptur procesu slēgÅ”anu (darbinieka izslēgÅ”anu) vēl dažas minÅ«tes (vai varbÅ«t stundas, ja ir ilgas tÄ«mekļa ligzdas sesijas).

Pārlādējot nginx konfigurāciju, Ŕāds attēls ir diezgan normāls:

Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

Par atmiņas izmantoÅ”anu:

Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

Vecie strādnieki apēd atmiņu, tostarp atmiņu, kas nav lineāri atkarÄ«ga no savienojumu skaita - tas ir normāli. Kad klienta savienojumi tiek aizvērti, Ŕī atmiņa tiks atbrÄ«vota.

Kāpēc tā nebija problēma, kad nginx tikko sāka darboties? Nebija ne HTTP/2, ne WebSocket, ne masveida ilgi uzturētu savienojumu. 70% no mūsu tīmekļa trafika ir HTTP/2, kas nozīmē ļoti ilgus savienojumus.

Risinājums ir vienkārÅ”s - neizmantojiet nginx, nepārvaldiet frontes, pamatojoties uz teksta failiem, un noteikti nesÅ«tiet zip teksta konfigurācijas pa transpacific kanāliem. Kanāli, protams, ir garantēti un rezervēti, taču tas nepadara tos mazāk transkontinentālus.

Mums ir savs priekŔējais serveris-balansētājs, par kura iekŔējiem elementiem es runāŔu turpmākajos rakstos. Galvenais, ko tas var darÄ«t, ir lidojuma laikā piemērot tÅ«kstoÅ”iem konfigurācijas izmaiņu sekundē, bez restartÄ“Å”anas, pārlādÄ“Å”anas, pēkŔņa atmiņas patēriņa pieauguma un tā visa. Tas ir ļoti lÄ«dzÄ«gs Hot Code Reload, piemēram, Erlang. Dati tiek glabāti Ä£eogrāfiski sadalÄ«tā atslēgu vērtÄ«bu datu bāzē, un tos nekavējoties nolasa priekŔējie izpildmehānismi. Tie. jÅ«s augÅ”upielādējat SSL sertifikātu, izmantojot tÄ«mekļa saskarni vai API Maskavā, un pēc dažām sekundēm tas ir gatavs doties uz mÅ«su tÄ«rÄ«Å”anas centru Losandželosā. Ja pēkŔņi notiks pasaules karÅ” un visā pasaulē pazudÄ«s internets, mÅ«su mezgli turpinās darboties autonomi un labos sadalÄ«tās smadzenes, tiklÄ«dz viens no specializētajiem kanāliem Losandželosa-Amsterdama-Maskava, Maskava-Amsterdama-Honkonga Los-Los kļūst pieejams. Angeles vai vismaz viens no GRE rezerves pārklājumiem.

Å is pats mehānisms ļauj mums nekavējoties izsniegt un atjaunot Let's Encrypt sertifikātus. Ä»oti vienkārÅ”i tas darbojas Ŕādi:

  1. TiklÄ«dz mēs redzam vismaz vienu HTTPS pieprasÄ«jumu mÅ«su klienta domēnam bez sertifikāta (vai ar sertifikātu, kuram beidzies derÄ«guma termiņŔ), ārējais mezgls, kas pieņēma pieprasÄ«jumu, ziņo par to iekŔējai sertifikācijas iestādei.

    Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

  2. Ja lietotājs nav aizliedzis Encrypt izdoÅ”anu, sertifikācijas iestāde Ä£enerē CSR, saņem apstiprinājuma marÄ·ieri no LE un nosÅ«ta to visām frontēm pa Å”ifrētu kanālu. Tagad jebkurÅ” mezgls var apstiprināt apstiprināŔanas pieprasÄ«jumu no LE.

    Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

  3. Pēc dažiem mirkļiem mēs saņemsim pareizo sertifikātu un privāto atslēgu un nosÅ«tÄ«sim to frontēm tādā paŔā veidā. Atkal, bez dēmonu restartÄ“Å”anas

    Web HighLoad ā€” kā mēs pārvaldām datplÅ«smu desmitiem tÅ«kstoÅ”u domēnu

  4. 7 dienas pirms derÄ«guma termiņa beigām tiek uzsākta sertifikāta atkārtotas saņemÅ”anas procedÅ«ra

PaÅ”laik mēs rotējam 350 XNUMX sertifikātu reāllaikā, kas lietotājiem ir pilnÄ«bā pārredzams.

Nākamajos sērijas rakstos es runāŔu par citām lielas tÄ«mekļa trafika apstrādes reāllaika funkcijām - piemēram, par RTT analÄ«zi, izmantojot nepilnÄ«gus datus, lai uzlabotu tranzÄ«ta klientu pakalpojumu kvalitāti, un kopumā par tranzÄ«ta trafika aizsardzÄ«bu no terabitu uzbrukumi, par satiksmes informācijas piegādi un apkopoÅ”anu, par WAF, gandrÄ«z neierobežotu CDN un daudziem mehānismiem satura piegādes optimizÄ“Å”anai.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Ko jūs vēlētos uzzināt vispirms?

  • 14,3%Algoritmi klasterÄ“Å”anai un tÄ«mekļa trafika kvalitātes analÄ«zei<3

  • 33,3%DDoS-Guard7 balansētāju iekŔējie elementi

  • 9,5%TranzÄ«ta L3/L4 satiksmes aizsardzÄ«ba2

  • 0,0%Vietņu aizsardzÄ«ba tranzÄ«ta satiksmē0

  • 14,3%TÄ«mekļa lietojumprogrammu ugunsmÅ«ris3

  • 28,6%AizsardzÄ«ba pret parsÄ“Å”anu un noklikŔķināŔanu6

Nobalsoja 21 lietotājs. 6 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru