Wymagania sprzętowe dla systemu anty-DDoS: jak dobrać serwer pod DPDK

Wdrożenie systemu ochrony przed atakami DDoS on-premise najczęściej upada nie na etapie wyboru rozwiązania, tylko na etapie doboru sprzętu. Operator kupuje licencję na oprogramowanie anty-DDoS, dostaje dokumentację, a potem okazuje się, że serwer, który miał "z zapasem" wystarczyć, dławi się przy pierwszym większym ataku. Winny nie jest sam system - winny jest brak zrozumienia, że ochrona DDoS oparta o DPDK rządzi się innymi prawami niż typowa aplikacja serwerowa.

Ten problem dotyczy w zasadzie każdego wdrożenia systemu anty-DDoS dla operatora telekomunikacyjnego czy centrum danych - niezależnie od tego, jak dobre jest samo oprogramowanie, źle dobrany sprzęt pod spodem zniweczy jego skuteczność. Poniżej opisujemy, na co zwrócić uwagę, żeby ochrona sieci operatorskiej przed atakami DDoS działała zgodnie z założeniami od pierwszego dnia.

Klasyczne oprogramowanie sieciowe korzysta ze stosu sieciowego jądra systemu operacyjnego. To wygodne, ale wolne - każdy pakiet przechodzi przez kilka warstw kopiowania danych i przełączeń kontekstu, zanim aplikacja go zobaczy. Przy ruchu rzędu kilku, kilkunastu Gb/s to nie problem. Przy analizie ruchu pakiet po pakiecie w czasie rzeczywistym, na poziomie wymaganym do wykrycia ataku DDoS w ciągu sekundy, taki narzut jest nie do zaakceptowania.

Dlatego skuteczne systemy anty-DDoS, w tym LiveShield, opierają się na DPDK (Data Plane Development Kit) - bibliotece, która pozwala aplikacji odbierać pakiety bezpośrednio z karty sieciowej, z pominięciem jądra systemu. Podejście DPDK anty-DDoS to dziś standard dla rozwiązań next-gen DDoS protection, które mają ambicję działać w czasie rzeczywistym, a nie z opóźnieniem rzędu minut. To rozwiązuje problem wydajności, ale nakłada konkretne, sztywne wymagania na sprzęt. Nie każdy serwer i nie każda karta sieciowa się do tego nadają.

LiveShield, jako system anty-DDoS dla operatora telekomunikacyjnego i data center, działa w oparciu o trzy moduły: Manager, Analyser i Worker. Manager i Analyser to komponenty zarządzające i analityczne - mogą działać na maszynie wirtualnej, obciążenie jest tu przewidywalne. Worker to zupełnie inna historia: to on wykonuje przetwarzanie pakietów z użyciem DPDK, więc wymaga fizycznego serwera. Wirtualizacja wprowadza dodatkową warstwę między kartą sieciową a aplikacją, co w praktyce oznacza utratę korzyści z DPDK.

Konsekwencja dla planowania wdrożenia: jeśli zakładacie środowisko all-in-one na jednej maszynie, cała maszyna musi być fizyczna. Jeśli rozdzielacie moduły, tylko Worker musi stać na fizycznym sprzęcie.

Liczba fizycznych rdzeni CPU zależy od przepustowości ruchu, który ma być analizowany:

Przykład: dla 40 Gb/s ruchu wejściowego wychodzi 8 rdzeni na samo przetwarzanie plus 4 rdzenie bazowe, czyli 12 rdzeni fizycznych.

Dwa progi minimalne, o których trzeba pamiętać niezależnie od wyniku formuły:

To rdzenie fizyczne, nie wątki logiczne z Hyperthreadingu - przy przetwarzaniu pakietów w trybie poll-mode, jakim posługuje się DPDK, rdzeń jest zajęty w 100% niezależnie od tego, czy akurat są pakiety do obróbki. Liczenie na wątki HT daje fałszywy obraz dostępnej mocy.

32 GB RAM lub więcej to punkt wyjścia - DPDK korzysta z hugepages, czyli zarezerwowanych z góry bloków pamięci, więc trzeba mieć zapas ponad to, co "zwykle wystarcza" na podobnym serwerze bez przetwarzania pakietowego. Pod przestrzeń dyskową wystarczy 60 GB na NVMe - system nie przechowuje pełnego ruchu w sposób ciągły, więc nie ma tu wymogów pojemnościowych typowych dla narzędzi do pełnego nagrywania ruchu.

To jest punkt, na którym najczęściej się przewraca planowanie zakupu. DPDK teoretycznie wspiera szeroką listę kart, ale w praktyce sprawdzają się konkretne modele z odpowiednim sterownikiem PMD (Poll Mode Driver):

Karty onboardowe (wbudowane w płytę główną) albo rozwiązania typu SoC wymagają osobnego sprawdzenia, czy producent w ogóle dostarcza dla nich sterownik PMD. Brak tego sterownika oznacza, że karta nie będzie w stanie pracować w trybie DPDK, niezależnie od tego, jak dobry jest procesor czy ilość pamięci. To częsty błąd przy doborze sprzętu do serwerów - zespoły zakupowe patrzą na przepustowość karty w Gb/s, a pomijają zgodność sterownikową, która w tym przypadku jest warunkiem koniecznym.

Praktyczna zasada wyboru producenta karty: poniżej 40 Gb/s ruchu różnica między Intelem a Mellanox/NVIDIA nie ma większego znaczenia - obie rodziny sprawdzają się dobrze. Powyżej tego progu warto celować w NVIDIA ConnectX-5 lub nowszy model.

Zamiast trzymać się wyłącznie teorii, warto pokazać, jak te wytyczne przekładają się na konkretny sprzęt, który był już rekomendowany operatorom na etapie doboru infrastruktury.

Wariant I, do ok. 40 Gb/s Serwer klasy Dell R430 z procesorem Intel Xeon E5-2680 v4, 32 GB RAM, w połączeniu z dwuportową kartą Intel XL710-QDA2 (QSFP+, 40G). To sprzęt, który da się kupić używany za relatywnie niewielkie pieniądze i który spokojnie obsłuży ruch na tym poziomie. 

Wariant II, do 100 Gb/s Tutaj procesor musi się zmienić na Intel Xeon Gold serii 63xx - głównie ze względu na wsparcie PCIe 4.0. 

Istotne: Karta sieciowa Intela E8xx-cqda2 dla tej przepustowości dzieli fizycznie szynę PCIe na pół między porty, więc jeśli planowane jest wykorzystanie obu portów jednocześnie, płyta główna musi obsługiwać PCIe Bifurcation. Bez tego wsparcia system zobaczy tylko jeden port karty. Bez pełnego PCIe 4.0 karta ograniczy się do ok. 50G na port, niezależnie od liczby wykorzystywanych portów.

Dla operatora planującego ochronę ruchu wejściowego na poziomie 20 Gb/s, minimalna sensowna specyfikacja pod Worker wygląda tak:

Przy 100 Gb/s ruchu wejściowego robi się to już 14 rdzeni fizycznych z samej formuły, więc dobór CPU trzeba jeszcze bardziej zaplanować pod kątem architektury NUMA i liczby gniazd procesorowych.

Sizing pod system anty-DDoS oparty o DPDK to nie jest zaokrąglanie w górę typowej specyfikacji serwerowej. To osobna kategoria wymagań: fizyczny serwer dla modułu przetwarzającego pakiety, rdzenie fizyczne liczone według konkretnej formuły, karta sieciowa zweryfikowana pod kątem sterownika PMD zanim trafi do specyfikacji zamówienia. Pominięcie któregokolwiek z tych punktów na etapie planowania zwykle kończy się koniecznością dokupienia sprzętu już po testach lub, gorzej, po pierwszym realnym ataku.

Dobrze zaplanowana ochrona przed DDoS dla ISP czy data center to w równym stopniu kwestia właściwego oprogramowania, co świadomego doboru infrastruktury, na której to oprogramowanie ma pracować. Pełna, aktualna specyfikacja sprzętowa oraz lista zwalidowanych kart sieciowych znajduje się w dokumentacji: docs.liveshield.net.

Posiadasz już jakiś sprzęt? Skonsultuj go z nami: office@liveshield.net