Legitymny ruch w sieci DDoS-Guard niedawno przekroczył sto gigabitów na sekundę. Obecnie 50% całego naszego ruchu generują usługi internetowe klientów. To dziesiątki tysięcy domen, bardzo różnorodnych i w większości przypadków wymagających indywidualnego podejścia.
Poniżej przedstawiamy, jak zarządzamy węzłami frontowymi i wydajemy Certyfikaty SSL dla setek tysięcy stron internetowych.
Skonfigurowanie frontu dla jednej strony, nawet bardzo dużej, jest proste. Bierzemy nginx lub haproxy lub lighttpd, konfigurujemy zgodnie z przewodnikami i zapominamy. Jeśli trzeba coś zmienić — robimy reload i znowu zapominamy.
Wszystko zmienia się, gdy na bieżąco przetwarzasz duże ilości ruchu, oceniasz legitymację zapytań, kompresujesz i buforujesz treści użytkowników, a jednocześnie zmieniasz parametry kilka razy na sekundę. Użytkownik chce widzieć wyniki na wszystkich zewnętrznych węzłach natychmiast po tym, jak zmienił ustawienia w panelu sterowania. A ponadto użytkownik może przesłać przez API kilka tysięcy (a czasem nawet dziesiątki tysięcy) domen z indywidualnymi parametrami przetwarzania ruchu. Wszystko to również musi działać natychmiast, zarówno w Ameryce, w Europie, jak i w Azji — zadanie nie jest proste, mając na uwadze, że w samej Moskwie jest kilka fizycznie rozproszonych węzłów filtracyjnych.
Dlaczego potrzeba wielu dużych, niezawodnych węzłów na całym świecie?
- Jakość obsługi ruchu klientów — zapytania z USA muszą być przetwarzane właśnie w USA (w tym do obrony przed atakami, parsowaniem i innymi anomaliami), a nie wysyłane do Moskwy lub Europy, co nieprzewidywalnie zwiększa opóźnienie przetwarzania.
- Ruch atakujący musi być lokalizowany — operatorzy tranzytowi mogą ulegać degradacji podczas ataków, których objętość często przekracza 1 Tbps. Transportowanie ruchu atakującego przez transatlantyckie lub transazjatyckie łącza — to nie najlepszy pomysł. Mieliśmy rzeczywiste przypadki, kiedy operatorzy Tier-1 mówili: „Wielkości ataków, które przyjmujecie, są dla nas niebezpieczne”. Dlatego przyjmujemy przychodzące strumienie jak najbliżej ich źródeł.
- Surowe wymagania dotyczące ciągłości usług — centra danych nie powinny zależeć od siebie nawzajem ani od lokalnych wydarzeń w naszym szybko zmieniającym się świecie. Wyłączono wszystkie 11 pięter MMTS-9 na tydzień? — to nie problem. Żaden klient, który nie ma fizycznego połączenia w tej lokalizacji, nie ucierpi, a usługi internetowe nie zostaną w żaden sposób dotknięte.
Jak tym zarządzać?
Konfiguracje usług muszą jak najszybciej (idealnie natychmiast) rozprzestrzeniać się na wszystkich frontowych węzłach. Nie można po prostu edytować plików konfiguracyjnych i restartować demonów przy każdej zmianie — nginx utrzymuje działające procesy (worker shutting down) przez jeszcze kilka minut (a czasem i godzin, jeśli są długie sesje websocket).
Podczas restartu konfiguracji nginx często wygląda to następująco:
W zakresie wykorzystania pamięci:
Stare workery zużywają pamięć, która nie jest liniowo zależna od liczby połączeń — to normalne. Po zamknięciu połączeń klientów ta pamięć zostanie uwolniona.
Dlaczego to nie było problemem, gdy nginx dopiero zaczynał się rozwijać? Nie było ani HTTP/2, ani WebSocket, ani masowych długich połączeń keep-alive. 70% naszego ruchu internetowego to HTTP/2, a więc są to bardzo długie połączenia.
Rozwiązanie jest proste — nie używać nginx, nie zarządzać frontami na podstawie plików tekstowych, a tym bardziej nie przesyłać spakowanych plików konfiguracyjnych przez transoceaniczne łącza. Kanały są wprawdzie gwarantowane i zarezerwowane, ale nie zmienia to ich transkontynentalnego charakteru.
Mamy własny serwer frontowy-balonując, o wnętrzach którego opowiem w kolejnych artykułach. Najważniejsze, co potrafi — stosować tysiące zmian konfiguracji na sekundę w trybie on-the-fly, bez restartów, przeładowań, skokowego wzrostu zużycia pamięci i tym podobnych. To bardzo przypomina Hot Code Reload, na przykład w Erlang. Dane są przechowywane w geodystrybucyjnej bazie key-value i odczytywane od razu przez wykonawcze mechanizmy frontowe. Tzn. załadowałeś certyfikat SSL za pomocą interfejsu webowego lub API w Moskwie, a po kilku sekundach już jest gotowy do pracy w naszym centrum czyszczenia w Los Angeles. Jeśli nagle wybuchłaby wojna światowa i Internet zniknąłby na całym świecie, nasze węzły będą działać autonomicznie i naprawią problem split-brain, gdy tylko jeden z wydzielonych kanałów Los Angeles-Amsterdam-Moskwa, Moskwa-Amsterdam-Hongkong-Los Angeles lub chociaż jeden z rezerwowych kanałów GRE stanie się dostępny.
Ten sam mechanizm pozwala nam natychmiast wydawać i przedłużać certyfikaty Let’s Encrypt. Bardzo uproszczony sposób działania wygląda tak:
- Gdy tylko zauważymy jeden HTTPS-zapytanie dla domeny naszego klienta bez certyfikatu (lub z przestarzałym certyfikatem), zewnętrzny węzeł, który przyjął zapytanie, informuje o tym wewnętrzne centrum certyfikacji.
- Jeśli użytkownik nie zabronił wydawania Let’s Encrypt, centrum certyfikacji tworzy CSR, otrzymuje od LE token potwierdzający i rozsyła go do wszystkich frontów przez zaszyfrowany kanał. Teraz każdy węzeł może potwierdzić valicyzujące zapytanie od LE.
- Po kilku chwilach otrzymamy poprawny certyfikat i prywatny klucz, a w ten sam sposób rozsyłamy je do frontów. Ponownie bez restartowania demonów.
- Na 7 dni przed datą wygaśnięcia inicjowana jest procedura ponownej aktywacji certyfikatu.
W tej chwili w czasie rzeczywistym rotujemy 350k certyfikatów całkowicie przejrzysto dla użytkowników.
W kolejnych artykułach cyklu opowiem o innych szczegółach przetwarzania dużego ruchu webowego w czasie rzeczywistym — na przykład o analizie RTT na podstawie niepełnych danych w celu poprawy jakości usług klientów tranzytowych oraz ogólnie o ochronie ruchu tranzytowego przed atakami terabitowymi, o dostarczaniu i agregacji informacji o ruchu, o WAF, prawie nieograniczonym CDN i licznych mechanizmach optymalizacji dostarczania treści.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.
O czym chcielibyście się dowiedzieć w pierwszej kolejności?
- 14,3%Algorytmy klastrowania i analizy jakości ruchu sieciowego<3
- 33,3%Wnętrza balansujących DDoS-Guard7
- 9,5%Ochrona ruchu transitowego L3/L4 2
- 0,0%Ochrona stron internetowych przed ruchem tranzytowym 0
- 14,3%Zapora Aplikacji Webowych 3
- 28,6%Ochrona przed parsowaniem i klikaniem6
Głosowało 21 użytkowników. 6 użytkowników wstrzymało się.
Źródło: habr.com
