Legitime ferkear op it DDoS-Guard-netwurk hat koartlyn mear as hûndert gigabits per sekonde. Op it stuit wurdt 50% fan al ús ferkear generearre troch klantwebtsjinsten. Dit binne in protte tsientûzenen domeinen, hiel oars en yn 'e measte gefallen fereaskje in yndividuele oanpak.
Under de besuniging is hoe't wy frontknooppunten beheare en SSL-sertifikaten útjaan foar hûnderttûzenen siden.
It opsetten fan in front foar ien side, sels in heul grutte, is maklik. Wy nimme nginx as haproxy of lighttpd, konfigurearje it neffens de gidsen en ferjitte it. As wy moatte feroarje wat, wy dogge in reload en ferjitte wer.
Alles feroaret as jo grutte folumes ferkear op 'e flecht ferwurkje, de legitimiteit fan oanfragen evaluearje, brûkersynhâld komprimearje en cache, en tagelyk parameters ferskate kearen per sekonde feroarje. De brûker wol it resultaat sjen op alle eksterne knooppunten fuortendaliks nei't hy de ynstellings yn syn persoanlike akkount feroare hat. In brûker kin ek ferskate tûzen (en soms tsientûzenen) domeinen downloade mei yndividuele ferkearferwurkingsparameters fia de API. Dit alles moat ek fuortendaliks wurkje yn Amearika, en yn Jeropa, en yn Azië - de taak is net de meast triviale, sjoen dat yn Moskou allinich d'r ferskate fysyk skieden filtraasjeknooppunten binne.
Wêrom binne d'r in protte grutte betroubere knopen om 'e wrâld?
-
Kwaliteit fan tsjinst foar klantferkear - oanfragen fan 'e FS moatte wurde ferwurke yn' e FS (ynklusyf foar oanfallen, parsearjen en oare anomalies), en net nei Moskou of Jeropa lutsen, wat de ferwurkingsfertraging ûnfoarspelber fergruttet.
-
Oanfalferkear moat lokalisearre wurde - transitoperators kinne degradearje by oanfallen, wêrfan it folume faak mear as 1Tbps is. It ferfier fan oanfalferkear oer transatlantyske of transasyske keppelings is gjin goed idee. Wy hiene echte gefallen doe't Tier-1-operators seine: "It folume fan oanfallen dat jo ûntfange is gefaarlik foar ús." Dêrom akseptearje wy ynkommende streamen sa ticht mooglik by har boarnen.
-
Strikte easken foar kontinuïteit fan tsjinstferliening - skjinmaksintra moatte net ôfhinklik wêze fan elkoar of fan lokale eveneminten yn ús rap feroarjende wrâld. Hawwe jo in wike stroom ôfsnien nei alle 11 ferdjippings fan MMTS-9? - gjin probleem. Net ien kliïnt dy't gjin fysike ferbining hat op dizze bepaalde lokaasje sil lije, en webtsjinsten sille ûnder gjin omstannichheden lije.
Hoe kinne jo dit alles beheare?
Tsjinstkonfiguraasjes moatte sa gau mooglik ferspraat wurde oan alle frontknooppunten (ideaal direkt). Jo kinne net gewoan tekstkonfiguraasjes nimme en opnij opbouwe en de daemons opnij opstarte by elke feroaring - deselde nginx hâldt prosessen foar in pear minuten langer ôfsluten (of miskien oeren as d'r lange websocket-sesjes binne).
By it opnij laden fan de nginx-konfiguraasje is de folgjende ôfbylding frij normaal:
Op ûnthâldgebrûk:
Alde arbeiders ite ûnthâld op, ynklusyf ûnthâld dat net lineêr ôfhinklik is fan it oantal ferbiningen - dit is normaal. As client ferbinings wurde sluten, dit ûnthâld wurdt befrijd.
Wêrom wie dit gjin probleem doe't nginx krekt begon? D'r wie gjin HTTP/2, gjin WebSocket, gjin massale lange keep-alive-ferbiningen. 70% fan ús webferkear is HTTP/2, wat tige lange ferbiningen betsjut.
De oplossing is ienfâldich - brûk gjin nginx, beheare gjin fronten basearre op tekstbestannen, en ferstjoere wis gjin zipped tekstkonfiguraasjes oer transpasyske kanalen. De kanalen binne fansels garandearre en reservearre, mar dat makket se net minder transkontinintaal.
Wy hawwe ús eigen front-server-balancer, de ynterne wêrfan ik sil prate oer yn 'e folgjende artikels. It wichtichste ding dat it kin dwaan is tûzenen konfiguraasjewizigingen per sekonde op 'e flecht tapasse, sûnder opnij starte, opnij laden, hommelse ferheging fan ûnthâldferbrûk, en dat alles. Dit is heul gelyk oan Hot Code Reload, bygelyks yn Erlang. De gegevens wurde opslein yn in geo-ferspraat kaai-wearde databank en wurdt lêzen fuortendaliks troch de front actuators. Dy. jo uploade it SSL-sertifikaat fia de webynterface of API yn Moskou, en yn in pear sekonden is it klear om nei ús skjinmaksintrum yn Los Angeles te gean. As der ynienen in wrâldoarloch bart en it ynternet oer de hiele wrâld ferdwynt, sille ús knooppunten autonoom wurkje en it split-brain reparearje sa gau as ien fan 'e tawijde kanalen Los Angeles-Amsterdam-Moskou, Moskou-Amsterdam-Hong Kong- Los-Los wurdt beskikber. Angeles of op syn minst ien fan de GRE backup overlays.
Ditselde meganisme lit ús Let's Encrypt-sertifikaten direkt útjaan en fernije. Hiel ienfâldich wurket it sa:
-
Sadree't wy op syn minst ien HTTPS-fersyk foar it domein fan ús kliïnt sjogge sûnder in sertifikaat (of mei in ferrûn sertifikaat), rapporteart de eksterne knooppunt dy't it fersyk akseptearre dit oan 'e ynterne sertifisearingsautoriteit.
-
As de brûker de útjefte fan Let's Encrypt net ferbean hat, genereart de sertifisearringsautoriteit in CSR, ûntfangt in befêstigingstoken fan LE en stjoert it nei alle fronten oer in fersifere kanaal. No kin elke knooppunt in validearjend fersyk fan LE befêstigje.
-
Yn in pear momint krije wy it juste sertifikaat en privee kaai en stjoere it op deselde wize nei de fronten. Nochris, sûnder de daemons opnij te starten
-
7 dagen foar de ferfaldatum wurdt de proseduere foar it opnij ûntfangen fan it sertifikaat inisjearre
Op it stuit draaie wy 350k sertifikaten yn echte tiid, folslein transparant foar brûkers.
Yn 'e folgjende artikels fan' e searje sil ik prate oer oare funksjes fan real-time ferwurking fan grut webferkear - bygelyks oer it analysearjen fan RTT mei ûnfolsleine gegevens om de kwaliteit fan tsjinst foar transitkliïnten te ferbetterjen en yn 't algemien oer it beskermjen fan transitferkear fan terabit oanfallen, oer de levering en aggregaasje fan ferkear ynformaasje, oer WAF, hast ûnbeheinde CDN en in protte meganismen foar it optimalisearjen fan ynhâld levering.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Wat wolle jo earst witte?
-
14,3%Algoritmen foar clustering en analysearjen fan de kwaliteit fan webferkear <3
-
33,3%Internals fan DDoS-Guard7 balancers
-
9,5%Beskerming fan transit L3 / L4 ferkear2
-
0,0%Beskermje fan websiden op transitferkear0
-
14,3%Firewall foar webapplikaasje 3
-
28,6%Beskerming tsjin parsearjen en klikken6
21 brûkers stimden. 6 brûkers ûntholden har.
Boarne: www.habr.com