Ang lehitimong trapiko sa network ng DDoS-Guard ay lumampas kamakailan sa isang daang gigabit bawat segundo. Sa kasalukuyan, 50% ng lahat ng aming trapiko ay nabuo ng mga serbisyo sa web ng kliyente. Ang mga ito ay maraming libu-libong mga domain, ibang-iba at sa karamihan ng mga kaso ay nangangailangan ng isang indibidwal na diskarte.
Sa ibaba ng cut ay kung paano namin pinamamahalaan ang mga front node at nag-isyu ng mga SSL certificate para sa daan-daang libong mga site.
Ang pag-set up ng harap para sa isang site, kahit na napakalaki, ay madali. Kumuha kami ng nginx o haproxy o lighttpd, i-configure ito ayon sa mga gabay at kalimutan ang tungkol dito. Kung kailangan nating baguhin ang isang bagay, nagre-reload tayo at nakakalimutang muli.
Nagbabago ang lahat kapag mabilis kang nagproseso ng malalaking volume ng trapiko, sinusuri ang pagiging lehitimo ng mga kahilingan, i-compress at i-cache ang nilalaman ng user, at sabay na binago ang mga parameter nang ilang beses bawat segundo. Gusto ng user na makita kaagad ang resulta sa lahat ng panlabas na node pagkatapos niyang baguhin ang mga setting sa kanyang personal na account. Ang isang user ay maaari ding mag-download ng ilang libong (at kung minsan ay sampu-sampung libo) na mga domain na may indibidwal na mga parameter sa pagpoproseso ng trapiko sa pamamagitan ng API. Ang lahat ng ito ay dapat ding gumana kaagad sa Amerika, at sa Europa, at sa Asya - ang gawain ay hindi ang pinaka-walang halaga, isinasaalang-alang na sa Moscow lamang mayroong ilang mga pisikal na pinaghihiwalay na mga node ng pagsasala.
Bakit maraming malalaking maaasahang node sa buong mundo?
-
Ang kalidad ng serbisyo para sa trapiko ng kliyente - ang mga kahilingan mula sa USA ay kailangang iproseso sa USA (kabilang ang para sa mga pag-atake, pag-parse at iba pang mga anomalya), at hindi hinila sa Moscow o Europe, na hindi inaasahang tumataas ang pagkaantala sa pagproseso.
-
Ang trapiko ng pag-atake ay dapat na naisalokal - ang mga operator ng transit ay maaaring bumaba sa panahon ng mga pag-atake, ang dami nito ay kadalasang lumalampas sa 1Tbps. Ang pagdadala ng trapiko ng pag-atake sa mga transatlantic o transasian na link ay hindi magandang ideya. Nagkaroon kami ng mga totoong kaso nang sabihin ng mga operator ng Tier-1: "Ang dami ng mga pag-atake na natatanggap mo ay mapanganib para sa amin." Iyon ang dahilan kung bakit tinatanggap namin ang mga papasok na stream nang mas malapit sa kanilang mga mapagkukunan hangga't maaari.
-
Mga mahigpit na kinakailangan para sa pagpapatuloy ng serbisyo - ang mga sentro ng paglilinis ay hindi dapat umasa sa isa't isa o sa mga lokal na kaganapan sa ating mabilis na pagbabago sa mundo. Pinutol mo ba ang kuryente sa lahat ng 11 palapag ng MMTS-9 sa loob ng isang linggo? - walang problema. Walang sinumang kliyente na walang pisikal na koneksyon sa partikular na lokasyong ito ang magdurusa, at ang mga serbisyo sa web ay hindi magdurusa sa anumang sitwasyon.
Paano pamahalaan ang lahat ng ito?
Ang mga configuration ng serbisyo ay dapat na maipamahagi sa lahat ng mga front node sa lalong madaling panahon (mahusay na agad). Hindi mo maaaring kunin at muling buuin ang mga text config at i-reboot ang mga daemon sa bawat pagbabago - ang parehong nginx ay patuloy na nagsasara ng mga proseso (nagsasara ang manggagawa) sa loob ng ilang minuto pa (o maaaring mga oras kung may mahabang websocket session).
Kapag nire-reload ang configuration ng nginx, ang sumusunod na larawan ay medyo normal:
Sa paggamit ng memorya:
Ang mga matatandang manggagawa ay kumakain ng memorya, kabilang ang memorya na hindi linear na nakadepende sa bilang ng mga koneksyon - ito ay normal. Kapag ang mga koneksyon ng kliyente ay sarado, ang memorya na ito ay mapapalaya.
Bakit hindi ito isang isyu noong nagsisimula pa lang ang nginx? Walang HTTP/2, walang WebSocket, walang napakalaking long keep-alive na koneksyon. 70% ng aming trapiko sa web ay HTTP/2, na nangangahulugang napakahabang koneksyon.
Ang solusyon ay simple - huwag gumamit ng nginx, huwag pamahalaan ang mga front batay sa mga text file, at tiyak na huwag magpadala ng mga naka-zip na configuration ng teksto sa mga transpacific na channel. Ang mga channel ay, siyempre, garantisado at nakalaan, ngunit hindi nito ginagawang mas mababa ang transcontinental sa kanila.
Mayroon kaming sariling front server-balancer, ang mga internal na tatalakayin ko sa mga susunod na artikulo. Ang pangunahing bagay na magagawa nito ay maglapat ng libu-libong pagbabago ng configuration sa bawat segundo nang mabilisan, nang walang pag-restart, pag-reload, biglaang pagtaas sa pagkonsumo ng memorya, at lahat ng iyon. Ito ay halos kapareho sa Hot Code Reload, halimbawa sa Erlang. Ang data ay naka-imbak sa isang geo-distributed key-value database at binabasa kaagad ng mga front actuator. Yung. ia-upload mo ang SSL certificate sa pamamagitan ng web interface o API sa Moscow, at sa ilang segundo ay handa na itong pumunta sa aming cleaning center sa Los Angeles. Kung biglang mangyari ang isang digmaang pandaigdig at mawala ang Internet sa buong mundo, ang aming mga node ay patuloy na gagana nang awtonomiya at ayusin ang split-brain sa sandaling ang isa sa mga nakalaang channel na Los Angeles-Amsterdam-Moscow, Moscow-Amsterdam-Hong Kong- Nagiging available ang Los-Los. Angeles o hindi bababa sa isa sa mga GRE backup overlay.
Ang parehong mekanismong ito ay nagbibigay-daan sa amin na agad na mag-isyu at mag-renew ng mga sertipiko ng Let's Encrypt. Napakasimpleng gumagana tulad nito:
-
Sa sandaling makakita kami ng hindi bababa sa isang kahilingan sa HTTPS para sa domain ng aming kliyente na walang certificate (o may nag-expire na certificate), iuulat ito ng external node na tumanggap sa kahilingan sa internal na awtoridad sa certification.
-
Kung hindi ipinagbawal ng user ang pag-iisyu ng Let's Encrypt, ang awtoridad sa sertipikasyon ay bubuo ng CSR, makakatanggap ng confirmation token mula sa LE at ipapadala ito sa lahat ng larangan sa isang naka-encrypt na channel. Ngayon ang anumang node ay maaaring kumpirmahin ang isang pagpapatunay na kahilingan mula sa LE.
-
Sa ilang sandali, matatanggap namin ang tamang sertipiko at pribadong key at ipapadala ito sa mga harapan sa parehong paraan. Muli, nang hindi na-restart ang mga daemon
-
7 araw bago ang petsa ng pag-expire, ang pamamaraan para sa muling pagtanggap ng sertipiko ay sinisimulan
Sa ngayon ay nag-iikot kami ng 350k na certificate sa real time, ganap na transparent sa mga user.
Sa mga sumusunod na artikulo ng serye, magsasalita ako tungkol sa iba pang mga tampok ng real-time na pagpoproseso ng malaking trapiko sa web - halimbawa, tungkol sa pagsusuri sa RTT gamit ang hindi kumpletong data upang mapabuti ang kalidad ng serbisyo para sa mga kliyente ng transit at sa pangkalahatan tungkol sa pagprotekta sa trapiko ng transit mula sa terabit na pag-atake, tungkol sa paghahatid at pagsasama-sama ng impormasyon sa trapiko, tungkol sa WAF, halos walang limitasyong CDN at maraming mekanismo para sa pag-optimize ng paghahatid ng nilalaman.
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Ano ang una mong gustong malaman?
-
14,3%Algorithm para sa clustering at pagsusuri sa kalidad ng trapiko sa web<3
-
33,3%Mga panloob ng mga tagabalanse ng DDoS-Guard7
-
9,5%Proteksyon ng sasakyang L3/L4 trapiko2
-
0,0%Pagprotekta sa mga website sa trapiko ng transit0
-
14,3%Web Application Firewall3
-
28,6%Proteksyon laban sa pag-parse at pag-click6
21 user ang bumoto. 6 na user ang umiwas.
Pinagmulan: www.habr.com