Legitimni promet na mreži DDoS-Guard nedavno je premašio sto gigabita u sekundi. Trenutačno 50% ukupnog našeg prometa generiraju klijentske web usluge. To su deseci tisuća domena, vrlo različitih iu većini slučajeva zahtijevaju individualan pristup.
Ispod presjeka je kako upravljamo prednjim čvorovima i izdajemo SSL certifikate za stotine tisuća stranica.
Postavljanje fronte za jedno mjesto, čak i vrlo veliko, jednostavno je. Uzimamo nginx ili haproxy ili lighttpd, konfiguriramo prema vodičima i zaboravimo na to. Ako trebamo nešto promijeniti, napravimo reload i opet zaboravimo.
Sve se mijenja kada obrađujete velike količine prometa u hodu, procjenjujete legitimnost zahtjeva, sažimate i predmemorišete korisnički sadržaj, a istovremeno mijenjate parametre nekoliko puta u sekundi. Korisnik želi vidjeti rezultat na svim vanjskim čvorovima odmah nakon što je promijenio postavke na svom osobnom računu. Korisnik također može preuzeti nekoliko tisuća (a ponekad i desetke tisuća) domena s pojedinačnim parametrima obrade prometa putem API-ja. Sve bi to trebalo odmah raditi iu Americi, iu Europi, iu Aziji - zadatak nije najtrivijalniji, s obzirom da samo u Moskvi postoji nekoliko fizički odvojenih filtracijskih čvorova.
Zašto postoji mnogo velikih pouzdanih čvorova diljem svijeta?
-
Kvaliteta usluge za klijentski promet - zahtjevi iz SAD-a moraju se obraditi u SAD-u (uključujući napade, parsiranje i druge anomalije), a ne povlačiti u Moskvu ili Europu, nepredvidivo povećavajući kašnjenje obrade.
-
Promet napada mora biti lokaliziran - operateri prijevoza mogu degradirati tijekom napada, čiji volumen često prelazi 1Tbps. Prijenos napadačkog prometa preko transatlantskih ili transazijskih veza nije dobra ideja. Imali smo stvarne slučajeve kada su Tier-1 operateri rekli: "Količina napada koje primate opasna je za nas." Zato prihvaćamo dolazne streamove što je moguće bliže njihovim izvorima.
-
Strogi zahtjevi za kontinuitetom usluge - centri za čišćenje ne bi trebali ovisiti jedni o drugima niti o lokalnim događanjima u našem svijetu koji se brzo mijenja. Jeste li isključili struju na svih 11 katova MMTS-9 na tjedan dana? - nema problema. Niti jedan klijent koji nema fizičku vezu na ovom određenom mjestu neće patiti, a ni web usluge neće trpjeti ni pod kojim okolnostima.
Kako upravljati svim tim?
Konfiguracije usluga treba distribuirati svim prednjim čvorovima što je brže moguće (idealno odmah). Ne možete samo uzeti i ponovno izgraditi tekstualne konfiguracije i ponovno pokrenuti demone pri svakoj promjeni - isti nginx zadržava procese koji se gase (radnik se gasi) još nekoliko minuta (ili možda sati ako postoje duge websocket sesije).
Prilikom ponovnog učitavanja nginx konfiguracije, sljedeća slika je sasvim normalna:
O korištenju memorije:
Stari radnici gutaju memoriju, uključujući memoriju koja ne ovisi linearno o broju veza - to je normalno. Kada se veze klijenta zatvore, ova memorija će se osloboditi.
Zašto to nije bio problem kada je nginx tek počinjao? Nije bilo HTTP/2, WebSocketa, masivnih dugih održavajućih veza. 70% našeg web prometa je HTTP/2, što znači vrlo duge veze.
Rješenje je jednostavno - nemojte koristiti nginx, nemojte upravljati frontovima na temelju tekstualnih datoteka i svakako nemojte slati komprimirane tekstualne konfiguracije preko transpacifičkih kanala. Kanali su, naravno, zajamčeni i rezervirani, ali to ih ne čini manje transkontinentalnima.
Imamo vlastiti prednji server-balanser, o čijem ću unutarnjem dijelu govoriti u sljedećim člancima. Glavna stvar koju može učiniti je primijeniti tisuće konfiguracijskih promjena u sekundi u hodu, bez ponovnog pokretanja, ponovnog učitavanja, naglog povećanja potrošnje memorije i svega toga. Ovo je vrlo slično Hot Code Reloadu, na primjer u Erlangu. Podaci se pohranjuju u geo-distribuiranu bazu podataka ključ-vrijednost i odmah ih čitaju prednji aktuatori. Oni. učitate SSL certifikat putem web sučelja ili API-ja u Moskvi i za nekoliko sekundi on je spreman za odlazak u naš centar za čišćenje u Los Angelesu. Ako se iznenada dogodi svjetski rat i internet nestane u cijelom svijetu, naši će čvorovi nastaviti raditi autonomno i popraviti podijeljeni mozak čim jedan od namjenskih kanala Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hong Kong- Los-Los postaje dostupan. Angeles ili barem jedno od GRE rezervnih slojeva.
Taj isti mehanizam omogućuje nam trenutačno izdavanje i obnavljanje Let's Encrypt certifikata. Vrlo jednostavno radi ovako:
-
Čim vidimo barem jedan HTTPS zahtjev za domenu našeg klijenta bez certifikata (ili s isteklim certifikatom), vanjski čvor koji je prihvatio zahtjev prijavljuje to internom certifikacijskom tijelu.
-
Ako korisnik nije zabranio izdavanje Let's Encrypt, certifikacijsko tijelo generira CSR, prima token potvrde od LE i šalje ga na sve strane preko šifriranog kanala. Sada bilo koji čvor može potvrditi zahtjev za provjeru valjanosti od LE.
-
Za nekoliko trenutaka ćemo dobiti ispravan certifikat i privatni ključ te ga na isti način poslati na frontove. Opet, bez ponovnog pokretanja demona
-
7 dana prije isteka roka valjanosti pokreće se postupak ponovnog preuzimanja certifikata
Upravo sada rotiramo 350 tisuća certifikata u stvarnom vremenu, potpuno transparentno za korisnike.
U sljedećim člancima iz serije govorit ću o drugim značajkama obrade velikog web prometa u stvarnom vremenu - na primjer, o analizi RTT-a korištenjem nepotpunih podataka za poboljšanje kvalitete usluge za tranzitne klijente i općenito o zaštiti tranzitnog prometa od terabit napade, o isporuci i agregaciji prometnih informacija, o WAF-u, gotovo neograničenom CDN-u i mnogim mehanizmima za optimizaciju isporuke sadržaja.
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Što biste prvo htjeli znati?
-
14,3%Algoritmi za klasteriranje i analizu kvalitete web prometa<3
-
33,3%Interno stanje DDoS-Guard7 balansera
-
9,5%Zaštita tranzitnog L3/L4 prometa2
-
0,0%Zaštita web stranica u tranzitnom prometu0
-
14,3%Vatrozid web aplikacije3
-
28,6%Zaštita od parsiranja i klikanja6
Glasovao je 21 korisnik. Suzdržano je bilo 6 korisnika.
Izvor: www.habr.com