Uprawniony ruch w sieci DDoS-Guard przekroczył ostatnio sto gigabitów na sekundę. Obecnie 50% całego naszego ruchu generowane jest przez usługi sieciowe klientów. To wiele dziesiątek tysięcy domen, bardzo różnych i w większości przypadków wymagających indywidualnego podejścia.
Poniżej znajduje się opis sposobu, w jaki zarządzamy węzłami czołowymi i wydajemy certyfikaty SSL dla setek tysięcy witryn.
Konfiguracja frontu dla jednej witryny, nawet bardzo dużej, jest łatwa. Bierzemy nginx, haproxy lub lighttpd, konfigurujemy według poradników i zapominamy o tym. Jeśli musimy coś zmienić, ładujemy ponownie i ponownie zapominamy.
Wszystko się zmienia, gdy przetwarzasz na bieżąco duże wolumeny ruchu, oceniasz zasadność żądań, kompresujesz i buforujesz treści użytkowników, a jednocześnie zmieniasz parametry kilka razy na sekundę. Użytkownik chce zobaczyć wynik na wszystkich węzłach zewnętrznych natychmiast po zmianie ustawień na swoim koncie osobistym. Użytkownik może także poprzez API pobrać kilka tysięcy (a czasem i dziesiątki tysięcy) domen z indywidualnymi parametrami przetwarzania ruchu. Wszystko to powinno od razu zadziałać także w Ameryce, Europie i Azji – zadanie nie jest trywialne, biorąc pod uwagę, że w samej Moskwie znajduje się kilka fizycznie oddzielonych węzłów filtracyjnych.
Dlaczego na świecie jest wiele dużych i niezawodnych węzłów?
-
Jakość obsługi ruchu klienckiego - żądania z USA muszą być przetwarzane w USA (w tym w przypadku ataków, analizowania i innych anomalii), a nie przeciągane do Moskwy lub Europy, co w nieprzewidywalny sposób zwiększa opóźnienie przetwarzania.
-
Ruch ataków musi być zlokalizowany – operatorzy tranzytowi mogą ulec degradacji podczas ataków, których wolumen często przekracza 1 Tb/s. Transportowanie ruchu ataków łączami transatlantyckimi lub transazjatyckimi nie jest dobrym pomysłem. Mieliśmy prawdziwe przypadki, gdy operatorzy poziomu 1 powiedzieli: „Ilość ataków, które otrzymujecie, jest dla nas niebezpieczna”. Dlatego akceptujemy przychodzące strumienie jak najbliżej ich źródeł.
-
Rygorystyczne wymagania dotyczące ciągłości świadczenia usług – centra sprzątające nie powinny być zależne ani od siebie nawzajem, ani od lokalnych wydarzeń w naszym szybko zmieniającym się świecie. Czy odciąłeś zasilanie na wszystkich 11 piętrach MMTS-9 na tydzień? - Nie ma problemu. Żaden klient, który nie ma fizycznego połączenia w tej konkretnej lokalizacji, nie ucierpi, a usługi sieciowe w żadnym wypadku nie ucierpią.
Jak tym wszystkim zarządzać?
Konfiguracje usług powinny zostać rozesłane do wszystkich węzłów czołowych tak szybko, jak to możliwe (najlepiej natychmiast). Nie możesz po prostu pobrać i przebudować konfiguracji tekstowych i ponownie uruchomić demony przy każdej zmianie - ten sam nginx powoduje zamknięcie procesów (zamknięcie procesu roboczego) jeszcze przez kilka minut (lub może godzin, jeśli są długie sesje websocket).
Podczas ponownego ładowania konfiguracji Nginx następujący obraz jest całkiem normalny:
O wykorzystaniu pamięci:
Starzy pracownicy zjadają pamięć, w tym pamięć, która nie zależy liniowo od liczby połączeń - jest to normalne. Po zamknięciu połączeń klientów pamięć ta zostanie zwolniona.
Dlaczego nie stanowiło to problemu, gdy Nginx dopiero zaczynał? Nie było protokołu HTTP/2, protokołu WebSocket ani masowych, długo utrzymujących się połączeń. 70% naszego ruchu internetowego to HTTP/2, co oznacza bardzo długie połączenia.
Rozwiązanie jest proste - nie używaj nginxa, nie zarządzaj frontami w oparciu o pliki tekstowe, a już na pewno nie wysyłaj spakowanych konfiguracji tekstowych kanałami transpacyficznym. Kanały są oczywiście gwarantowane i zarezerwowane, ale to nie czyni ich mniej transkontynentalnymi.
Mamy własny front-balancer serwerów, o którego wnętrzu opowiem w kolejnych artykułach. Najważniejsze, co może zrobić, to zastosować tysiące zmian konfiguracyjnych na sekundę w locie, bez ponownego uruchamiania, przeładowywania, nagłego wzrostu zużycia pamięci i tak dalej. Jest to bardzo podobne do Hot Code Reload, na przykład w Erlangu. Dane są przechowywane w rozproszonej geograficznie bazie danych klucz-wartość i są natychmiast odczytywane przez przednie siłowniki. Te. przesyłasz certyfikat SSL przez interfejs sieciowy lub API w Moskwie i za kilka sekund jest on gotowy do wyjazdu do naszego centrum sprzątania w Los Angeles. Jeśli nagle wybuchnie wojna światowa i Internet zniknie na całym świecie, nasze węzły będą nadal działać autonomicznie i naprawiać rozszczepiony mózg, gdy tylko jeden z dedykowanych kanałów Los Angeles-Amsterdam-Moskwa, Moskwa-Amsterdam-Hongkong- Los-Los staje się dostępny.Angele lub przynajmniej jedna z nakładek zapasowych GRE.
Ten sam mechanizm pozwala nam na błyskawiczne wydawanie i odnawianie certyfikatów Let's Encrypt. Działa to bardzo prosto:
-
Gdy tylko zobaczymy przynajmniej jedno żądanie HTTPS dla domeny naszego klienta bez certyfikatu (lub z certyfikatem, który wygasł), węzeł zewnętrzny, który przyjął żądanie, zgłasza to wewnętrznemu urzędowi certyfikacji.
-
Jeśli użytkownik nie zabronił wydania Let's Encrypt, urząd certyfikacji generuje CSR, otrzymuje token potwierdzający od LE i wysyła go na wszystkie fronty zaszyfrowanym kanałem. Teraz każdy węzeł może potwierdzić żądanie sprawdzające od LE.
-
Za kilka chwil otrzymamy prawidłowy certyfikat i klucz prywatny i w ten sam sposób wyślemy go na fronty. Ponownie, bez ponownego uruchamiania demonów
-
Na 7 dni przed upływem ważności certyfikatu rozpoczynana jest procedura ponownego odbioru certyfikatu
W tej chwili obracamy 350 tys. certyfikatów w czasie rzeczywistym, całkowicie niezauważalnie dla użytkowników.
W kolejnych artykułach z tej serii będę mówił o innych cechach przetwarzania w czasie rzeczywistym dużego ruchu sieciowego - na przykład o analizie RTT na podstawie niekompletnych danych w celu poprawy jakości obsługi klientów tranzytowych i ogólnie o zabezpieczeniu ruchu tranzytowego przed terabitowych ataków, o dostarczaniu i agregacji informacji o ruchu, o WAF, prawie nieograniczonym CDN i wielu mechanizmach optymalizacji dostarczania treści.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Co chciałbyś wiedzieć jako pierwsze?
-
14,3%Algorytmy klastrowania i analizy jakości ruchu internetowego<3
-
33,3%Elementy wewnętrzne balanserów DDoS-Guard7
-
9,5%Ochrona ruchu tranzytowego L3/L4
-
0,0%Ochrona stron internetowych w ruchu tranzytowym0
-
14,3%Zapora sieciowa aplikacji internetowych 3
-
28,6%Ochrona przed analizowaniem i klikaniem6
Głosowało 21 użytkowników. 6 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com