Legitimní provoz v síti DDoS-Guard nedávno přesáhl sto gigabitů za sekundu. V současné době je 50 % veškeré naší návštěvnosti generováno klientskými webovými službami. Jedná se o mnoho desítek tisíc domén, velmi odlišných a ve většině případů vyžadujících individuální přístup.
Níže je uvedeno, jak spravujeme přední uzly a vydáváme certifikáty SSL pro stovky tisíc webů.
Nastavení fronty pro jeden web, dokonce i velmi velký, je snadné. Vezmeme nginx nebo haproxy nebo lighttpd, nakonfigurujeme to podle průvodců a zapomeneme na to. Pokud potřebujeme něco změnit, provedeme reload a znovu zapomeneme.
Vše se mění, když zpracováváte velké objemy provozu za chodu, vyhodnocujete oprávněnost požadavků, komprimujete a ukládáte uživatelský obsah do mezipaměti a zároveň měníte parametry několikrát za sekundu. Uživatel chce vidět výsledek na všech externích uzlech ihned poté, co změnil nastavení ve svém osobním účtu. Uživatel si také může přes API stáhnout několik tisíc (někdy i desítky tisíc) domén s individuálními parametry zpracování provozu. To vše by mělo okamžitě fungovat také v Americe, v Evropě a v Asii - úkol není nejtriviálnější, vezmeme-li v úvahu, že v samotné Moskvě je několik fyzicky oddělených filtračních uzlů.
Proč je na světě mnoho velkých spolehlivých uzlů?
-
Kvalita služeb pro klientský provoz – požadavky z USA musí být zpracovány v USA (včetně útoků, analýzy a jiných anomálií) a ne stahovány do Moskvy nebo Evropy, což nepředvídatelně zvyšuje zpoždění zpracování.
-
Útočný provoz musí být lokalizován – tranzitní operátoři mohou degradovat při útocích, jejichž objem často přesahuje 1 Tbps. Přenášet útočný provoz přes transatlantická nebo transasijská spojení není dobrý nápad. Měli jsme skutečné případy, kdy operátoři Tier-1 řekli: "Objem útoků, které dostáváte, je pro nás nebezpečný." Proto přijímáme příchozí streamy co nejblíže jejich zdrojům.
-
Přísné požadavky na kontinuitu služeb – úklidová centra by v našem rychle se měnícím světě neměla záviset ani na sobě, ani na lokálním dění. Vypnuli jste na týden napájení všech 11 pater MMTS-9? - žádný problém. Netrpí tím ani jeden klient, který nemá fyzické připojení v tomto konkrétním místě, a za žádných okolností neutrpí ani webové služby.
Jak tohle všechno zvládnout?
Konfigurace služeb by měla být distribuována do všech předních uzlů co nejrychleji (ideálně okamžitě). Nemůžete jen vzít a znovu sestavit textové konfigurace a restartovat démony při každé změně - stejný nginx udržuje procesy vypínání (vypínání pracovníka) ještě několik minut (nebo možná hodin, pokud jsou dlouhé relace webového soketu).
Při opětovném načítání konfigurace nginx je následující obrázek zcela normální:
O využití paměti:
Staří pracovníci zabírají paměť, včetně paměti, která lineárně nezávisí na počtu připojení - to je normální. Po uzavření klientských připojení se tato paměť uvolní.
Proč to nebyl problém, když nginx teprve začínal? Neexistoval žádný HTTP/2, žádný WebSocket, žádná masivní dlouhá udržovaná připojení. 70 % našeho webového provozu je HTTP/2, což znamená velmi dlouhá připojení.
Řešení je jednoduché – nepoužívejte nginx, nespravujte fronty založené na textových souborech a rozhodně neposílejte zazipované textové konfigurace přes transpacifické kanály. Kanály jsou samozřejmě garantované a rezervované, ale to je nečiní méně transkontinentálními.
Máme vlastní front server-balancer, o jehož vnitřnostech budu hovořit v následujících článcích. Hlavní věc, kterou umí, je aplikovat tisíce konfiguračních změn za sekundu za běhu, bez restartů, opětovného načítání, náhlého zvýšení spotřeby paměti a tak dále. To je velmi podobné Hot Code Reload, například v Erlangu. Data jsou uložena v geograficky distribuované databázi klíč-hodnota a jsou okamžitě čtena předními akčními členy. Tito. nahrajete SSL certifikát přes webové rozhraní nebo API v Moskvě a za pár sekund je připraven vyrazit do našeho úklidového centra v Los Angeles. Pokud se náhle stane světová válka a internet zmizí po celém světě, naše uzly budou nadále pracovat autonomně a opraví rozdělený mozek, jakmile jeden z vyhrazených kanálů Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hong Kong- Los-Los bude k dispozici. Angeles nebo alespoň jedno ze záložních překryvů GRE.
Stejný mechanismus nám umožňuje okamžitě vydávat a obnovovat certifikáty Let's Encrypt. Velmi jednoduše to funguje takto:
-
Jakmile uvidíme alespoň jeden HTTPS požadavek na doménu našeho klienta bez certifikátu (nebo s prošlým certifikátem), externí uzel, který požadavek přijal, to oznámí interní certifikační autoritě.
-
Pokud uživatel vydání Let's Encrypt nezakázal, certifikační autorita vygeneruje CSR, obdrží od LE potvrzovací token a odešle jej na všechna fronta přes šifrovaný kanál. Nyní může kterýkoli uzel potvrdit ověřovací požadavek od LE.
-
Za pár okamžiků obdržíme správný certifikát a soukromý klíč a stejným způsobem jej pošleme na fronty. Opět bez restartování démonů
-
7 dní před datem vypršení platnosti je zahájena procedura pro opětovné obdržení certifikátu
Právě teď rotujeme 350 XNUMX certifikátů v reálném čase, zcela transparentně pro uživatele.
V následujících článcích seriálu budu hovořit o dalších funkcích zpracování velkého webového provozu v reálném čase – například o analýze RTT pomocí neúplných dat ke zlepšení kvality služeb pro tranzitní klienty a obecně o ochraně tranzitního provozu před terabitové útoky, o doručování a agregaci dopravních informací, o WAF, téměř neomezeném CDN a mnoha mechanismech pro optimalizaci doručování obsahu.
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
Co byste chtěli vědět jako první?
-
14,3%Algoritmy pro shlukování a analýzu kvality webového provozu<3
-
33,3%Vnitřní části balancerů DDoS-Guard7
-
9,5%Ochrana tranzitního provozu L3/L4
-
0,0%Ochrana webových stránek před tranzitním provozem0
-
14,3%Firewall webových aplikací3
-
28,6%Ochrana proti analýze a kliknutí6
Hlasovalo 21 uživatelů. 6 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com