Traficul legitim pe rețeaua DDoS-Guard a depășit recent o sută de gigabiți pe secundă. În prezent, 50% din tot traficul nostru este generat de serviciile web ale clienților. Acestea sunt multe zeci de mii de domenii, foarte diferite și, în majoritatea cazurilor, necesită o abordare individuală.
Mai jos este modul în care gestionăm nodurile frontale și emitem certificate SSL pentru sute de mii de site-uri.
Configurarea unui front pentru un site, chiar și unul foarte mare, este ușor. Luăm nginx sau haproxy sau lighttpd, îl configuram conform ghidurilor și uităm de el. Dacă trebuie să schimbăm ceva, facem o reîncărcare și uităm din nou.
Totul se schimbă atunci când procesați volume mari de trafic din mers, evaluați legitimitatea solicitărilor, comprimați și stocați în cache conținutul utilizatorului și, în același timp, modificați parametrii de câteva ori pe secundă. Utilizatorul dorește să vadă rezultatul pe toate nodurile externe imediat după ce a schimbat setările din contul personal. De asemenea, un utilizator poate descărca câteva mii (și uneori zeci de mii) de domenii cu parametri individuali de procesare a traficului prin intermediul API-ului. Toate acestea ar trebui să funcționeze imediat și în America, și în Europa și în Asia - sarcina nu este cea mai banală, având în vedere că numai în Moscova există mai multe noduri de filtrare separate fizic.
De ce există multe noduri mari de încredere în întreaga lume?
-
Calitatea serviciului pentru traficul clienților - cererile din SUA trebuie procesate în SUA (inclusiv pentru atacuri, analize și alte anomalii) și nu trase la Moscova sau Europa, crescând în mod imprevizibil întârzierea procesării.
-
Traficul de atac trebuie localizat - operatorii de tranzit se pot degrada în timpul atacurilor, al căror volum depășește adesea 1 Tbps. Transportul traficului de atac prin legături transatlantice sau transasiatice nu este o idee bună. Am avut cazuri reale când operatorii de nivel 1 au spus: „Volumul de atacuri pe care le primiți este periculos pentru noi”. De aceea, acceptăm fluxurile primite cât mai aproape de sursele lor.
-
Cerințe stricte pentru continuitatea serviciului - centrele de curățare nu ar trebui să depindă nici unul de celălalt, nici de evenimentele locale din lumea noastră în schimbare rapidă. Ați întrerupt curentul la toate cele 11 etaje ale MMTS-9 timp de o săptămână? - nici o problemă. Niciun client care nu are o conexiune fizică în această locație anume nu va avea de suferit, iar serviciile web nu vor avea de suferit în nicio circumstanță.
Cum să gestionezi toate acestea?
Configurațiile serviciului ar trebui să fie distribuite tuturor nodurilor frontale cât mai repede posibil (ideal, instantaneu). Nu puteți pur și simplu să luați și să reconstruiți configurațiile de text și să reporniți demonii la fiecare modificare - același nginx menține procesele închidere (închiderea lucrătorului) pentru încă câteva minute (sau poate ore dacă există sesiuni lungi de websocket).
Când reîncărcați configurația nginx, următoarea imagine este destul de normală:
Despre utilizarea memoriei:
Lucrătorii vechi consumă memorie, inclusiv memorie care nu depinde liniar de numărul de conexiuni - acest lucru este normal. Când conexiunile clientului sunt închise, această memorie va fi eliberată.
De ce nu a fost aceasta o problemă când nginx tocmai începea? Nu exista HTTP/2, nici WebSocket, nici conexiuni masive de lungă durată. 70% din traficul nostru web este HTTP/2, ceea ce înseamnă conexiuni foarte lungi.
Soluția este simplă - nu utilizați nginx, nu gestionați fronturi bazate pe fișiere text și, cu siguranță, nu trimiteți configurații de text arhivat pe canale transpacific. Canalele sunt, desigur, garantate și rezervate, dar asta nu le face mai puțin transcontinentale.
Avem propriul nostru server-balancer frontal, despre ale cărui elemente interne voi vorbi în articolele următoare. Principalul lucru pe care îl poate face este să aplice mii de modificări de configurare pe secundă din mers, fără reporniri, reîncărcări, creșteri bruște ale consumului de memorie și toate astea. Acest lucru este foarte asemănător cu Hot Code Reload, de exemplu în Erlang. Datele sunt stocate într-o bază de date cheie-valoare geodistribuită și sunt citite imediat de actuatoarele frontale. Acestea. încarci certificatul SSL prin interfața web sau API din Moscova și în câteva secunde este gata să meargă la centrul nostru de curățare din Los Angeles. Dacă se va întâmpla brusc un război mondial și internetul va dispărea în toată lumea, nodurile noastre vor continua să funcționeze autonom și să repare creierul divizat de îndată ce unul dintre canalele dedicate Los Angeles-Amsterdam-Moscova, Moscova-Amsterdam-Hong Kong- Los-Los devine disponibil. Angeles sau cel puțin una dintre suprapunerile de rezervă GRE.
Același mecanism ne permite să emitem și să reînnoim instantaneu certificate Let's Encrypt. Foarte simplu funcționează așa:
-
De îndată ce vedem cel puțin o solicitare HTTPS pentru domeniul clientului nostru fără certificat (sau cu un certificat expirat), nodul extern care a acceptat cererea raportează acest lucru autorității interne de certificare.
-
Dacă utilizatorul nu a interzis emiterea Let's Encrypt, autoritatea de certificare generează un CSR, primește un token de confirmare de la LE și îl trimite pe toate fronturile printr-un canal criptat. Acum orice nod poate confirma o cerere de validare de la LE.
-
În câteva momente, vom primi certificatul corect și cheia privată și le vom trimite pe fronturi în același mod. Din nou, fără a reporni demonii
-
Cu 7 zile înainte de data expirării se inițiază procedura de reprimire a certificatului
În acest moment, rotim certificate de 350 în timp real, complet transparente pentru utilizatori.
În următoarele articole ale seriei, voi vorbi despre alte caracteristici ale procesării în timp real a traficului web mare - de exemplu, despre analiza RTT folosind date incomplete pentru a îmbunătăți calitatea serviciului pentru clienții de tranzit și, în general, despre protejarea traficului de tranzit împotriva atacuri terabit, despre livrarea și agregarea informațiilor de trafic, despre WAF, CDN aproape nelimitat și multe mecanisme de optimizare a livrării de conținut.
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Ce ai vrea să știi mai întâi?
-
14,3%Algoritmi pentru gruparea și analiza calității traficului web<3
-
33,3%Interne ale echilibratoarelor DDoS-Guard7
-
9,5%Protecția traficului de tranzit L3/L4
-
0,0%Protejarea site-urilor web în traficul de tranzit0
-
14,3%Firewall aplicație web3
-
28,6%Protecție împotriva parsării și clicurilor6
Au votat 21 de utilizatori. 6 utilizatori s-au abținut.
Sursa: www.habr.com