Leĝa trafiko en la reto DDoS-Guard lastatempe superis cent gigabitojn por sekundo. Nuntempe, 50% de nia tuta trafiko estas generita de klientaj retservoj. Ĉi tiuj estas multaj dekoj da miloj da domajnoj, tre malsamaj kaj plejofte postulantaj individuan aliron.
Sub la tranĉo estas kiel ni administras antaŭajn nodojn kaj eldonas SSL-atestilojn por centoj da miloj da retejoj.
Agordi fronton por unu retejo, eĉ tre granda, estas facila. Ni prenas nginx aŭ haproxy aŭ lighttpd, agordas ĝin laŭ la gvidiloj kaj forgesas pri ĝi. Se ni bezonas ŝanĝi ion, ni faras reŝargi kaj denove forgesas.
Ĉio ŝanĝiĝas kiam vi prilaboras grandajn volumojn de trafiko sur la flugo, taksas la legitimecon de petoj, kunpremas kaj konservas uzantenhavon, kaj samtempe ŝanĝas parametrojn plurfoje por sekundo. La uzanto volas vidi la rezulton sur ĉiuj eksteraj nodoj tuj post kiam li ŝanĝis la agordojn en sia persona konto. Uzanto ankaŭ povas elŝuti plurajn milojn (kaj foje dekojn da miloj) domajnoj kun individuaj trafikaj prilaboraj parametroj per la API. Ĉio ĉi devus funkcii tuj en Ameriko, kaj en Eŭropo, kaj en Azio - la tasko ne estas la plej bagatela, konsiderante, ke nur en Moskvo ekzistas pluraj fizike apartigitaj filtraj nodoj.
Kial ekzistas multaj grandaj fidindaj nodoj tra la mondo?
-
Kvalito de servo por klienta trafiko - petoj de Usono devas esti procesitaj en Usono (inkluzive por atakoj, analizado kaj aliaj anomalioj), kaj ne tiritaj al Moskvo aŭ Eŭropo, neantaŭvideble pliigante la prokrastan prokraston.
-
Ataktrafiko devas esti lokalizita - transitaj funkciigistoj povas degradi dum atakoj, kies volumo ofte superas 1Tbps. Transporti ataktrafikon tra transatlantikaj aŭ transaziaj ligoj ne estas bona ideo. Ni havis realajn kazojn kiam Tier-1-funkciigistoj diris: "La kvanto de atakoj, kiujn vi ricevas, estas danĝera por ni." Tial ni akceptas alvenantajn fluojn kiel eble plej proksime al iliaj fontoj.
-
Striktaj postuloj por kontinueco de servo - purigadcentroj ne dependu unu de la alia aŭ de lokaj eventoj en nia rapide ŝanĝiĝanta mondo. Ĉu vi ĉesis elektron al ĉiuj 11 etaĝoj de MMTS-9 dum semajno? - Nedankinde. Ne unu kliento, kiu ne havas fizikan konekton en ĉi tiu aparta loko, suferos, kaj retservoj ne suferos sub neniu cirkonstanco.
Kiel administri ĉion ĉi?
Servaj agordoj devas esti distribuitaj al ĉiuj antaŭaj nodoj kiel eble plej rapide (idee tuj). Vi ne povas simple preni kaj rekonstrui tekstajn agordojn kaj rekomenci la demonojn ĉe ĉiu ŝanĝo - la sama nginx daŭrigas la procezojn malŝalti (laboristo malŝaltas) dum kelkaj pliaj minutoj (aŭ eble horoj se estas longaj websocket-sesioj).
Reŝargante la agordon nginx, la sekva bildo estas sufiĉe normala:
Pri memoruzo:
Maljunaj laboristoj manĝas memoron, inkluzive de memoro, kiu ne lineare dependas de la nombro da konektoj - tio estas normala. Kiam klientkonektoj estas fermitaj, ĉi tiu memoro estos liberigita.
Kial ĉi tio ne estis problemo kiam nginx ĵus komencis? Ekzistis neniu HTTP/2, neniu WebSocket, neniuj masivaj longaj vivkonektoj. 70% de nia rettrafiko estas HTTP/2, kio signifas tre longajn konektojn.
La solvo estas simpla - ne uzu nginx, ne administru frontojn bazitajn sur tekstaj dosieroj, kaj certe ne sendu zipitajn tekstajn agordojn tra transpacifikaj kanaloj. La kanaloj estas, kompreneble, garantiitaj kaj rezervitaj, sed tio ne igas ilin malpli transkontinentaj.
Ni havas nian antaŭan servilon-balancilon, pri kies interno mi parolos en la sekvaj artikoloj. La ĉefa afero, kiun ĝi povas fari, estas apliki milojn da agordaj ŝanĝoj je sekundo sur la flugo, sen rekomencoj, reŝargiĝoj, subitaj pliiĝoj de memorkonsumo kaj ĉio tio. Ĉi tio tre similas al Hot Code Reload, ekzemple en Erlang. La datumoj estas konservitaj en geo-distribuita ŝlosil-valora datumbazo kaj estas tuj legataj de la antaŭaj aktuarioj. Tiuj. vi alŝutas la SSL-atestilon per la retinterfaco aŭ API en Moskvo, kaj post kelkaj sekundoj ĝi pretas iri al nia purigadcentro en Los-Anĝeleso. Se mondmilito subite okazos kaj la Interreto malaperas tra la tuta mondo, niaj nodoj daŭre funkcios aŭtonome kaj riparos la disigitan cerbon tuj kiam unu el la dediĉitaj kanaloj Los-Anĝeleso-Amsterdamo-Moskvo, Moskvo-Amsterdamo-Honkongo- Los-Los iĝas haveblaj Anĝeloj aŭ almenaŭ unu el la GRE-rezervkovraĵoj.
Ĉi tiu sama mekanismo permesas al ni tuj elsendi kaj renovigi atestojn de Let's Encrypt. Tre simple ĝi funkcias tiel:
-
Tuj kiam ni vidas almenaŭ unu HTTPS-peton por la domajno de nia kliento sen atestilo (aŭ kun eksvalidiĝinta atestilo), la ekstera nodo kiu akceptis la peton raportas tion al la interna atestadaŭtoritato.
-
Se la uzanto ne malpermesis la emision de Let's Encrypt, la atestila aŭtoritato generas CSR, ricevas konfirman signon de LE kaj sendas ĝin al ĉiuj frontoj per ĉifrita kanalo. Nun ĉiu nodo povas konfirmi validan peton de LE.
-
Post kelkaj momentoj, ni ricevos la ĝustan atestilon kaj privatan ŝlosilon kaj sendos ĝin al la frontoj en la sama maniero. Denove, sen rekomenci la demonojn
-
7 tagojn antaŭ la limdato, la proceduro por rericevo de la atestilo estas komencita
Ĝuste nun ni turnas 350k atestiloj en reala tempo, tute travideblaj por uzantoj.
En la sekvaj artikoloj de la serio, mi parolos pri aliaj funkcioj de realtempa prilaborado de granda rettrafiko - ekzemple pri analizado de RTT uzante nekompletajn datumojn por plibonigi la kvaliton de servo por transitklientoj kaj ĝenerale pri protektado de transittrafiko kontraŭ terabit-atakoj, pri la livero kaj agregado de trafikaj informoj, pri WAF, preskaŭ senlima CDN kaj multaj mekanismoj por optimumigi enhavliveron.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Kion vi ŝatus scii unue?
-
14,3%Algoritmoj por grupigi kaj analizi la kvaliton de interreta trafiko<3
-
33,3%Internoj de DDoS-Guard7-balanciloj
-
9,5%Protekto de trafiko L3/L4
-
0,0%Protektante retejojn pri trafika trafiko0
-
14,3%TTT-aplika fajroŝirmilo3
-
28,6%Protekto kontraŭ analizado kaj klakado6
21 uzantoj voĉdonis. 6 uzantoj sindetenis.
fonto: www.habr.com