Апаратні вимоги до системи захисту від DDoS: як підібрати сервер під DPDK

Впровадження системи захисту від DDoS-атак on-premise найчастіше зривається не на етапі вибору рішення, а на етапі підбору обладнання. Оператор купує ліцензію на програмне забезпечення anti-DDoS, отримує документацію, а потім виявляється, що сервер, якого мало б «із запасом» вистачити, задихається за першої більшої атаки. Винна не сама система, а нерозуміння того, що захист від DDoS на основі DPDK підпорядковується іншим законам, ніж типовий серверний застосунок.

Ця проблема стосується, по суті, кожного впровадження системи захисту від DDoS для телекомунікаційного оператора чи центру обробки даних: наскільки б хорошим не було саме програмне забезпечення, погано підібране обладнання під ним зведе нанівець його ефективність. Нижче ми описуємо, на що звернути увагу, щоб захист операторської мережі від DDoS-атак працював відповідно до задумів від першого дня.

Класичне мережеве програмне забезпечення користується мережевим стеком ядра операційної системи. Це зручно, але повільно: кожен пакет проходить кілька шарів копіювання даних і перемикань контексту, перш ніж застосунок його побачить. За трафіку порядку кількох, кільканадцяти Гб/с це не проблема. За аналізу трафіку пакет за пакетом у реальному часі, на рівні, потрібному для виявлення DDoS-атаки впродовж секунди, такі накладні витрати неприйнятні.

Тому ефективні системи захисту від DDoS, зокрема LiveShield, ґрунтуються на DPDK (Data Plane Development Kit), бібліотеці, що дозволяє застосунку приймати пакети безпосередньо з мережевої карти, оминаючи ядро системи. Підхід DPDK для anti-DDoS сьогодні є стандартом для рішень захисту від DDoS наступного покоління, які прагнуть працювати в реальному часі, а не із запізненням у кілька хвилин. Це розв'язує проблему продуктивності, але накладає конкретні, жорсткі вимоги на обладнання. Не кожен сервер і не кожна мережева карта для цього підходять.

LiveShield, як система захисту від DDoS для телекомунікаційного оператора та дата-центру, працює на основі трьох модулів: Manager, Analyser і Worker. Manager і Analyser це керувальні та аналітичні компоненти, вони можуть працювати на віртуальній машині, бо навантаження тут передбачуване. Worker це зовсім інша історія: саме він виконує обробку пакетів з використанням DPDK, тому потребує фізичного сервера. Віртуалізація вводить додатковий шар між мережевою картою та застосунком, що на практиці означає втрату переваг DPDK.

Наслідок для планування впровадження: якщо ви передбачаєте середовище all-in-one на одній машині, уся машина має бути фізичною. Якщо ви розділяєте модулі, лише Worker має стояти на фізичному обладнанні.

Кількість фізичних ядер CPU залежить від пропускної здатності трафіку, що має аналізуватися:

фізичні ядра = Гбіт/с ÷ 10 + 4

Приклад: для 40 Гб/с вхідного трафіку виходить 8 ядер на саму обробку плюс 4 базові ядра, тобто 12 фізичних ядер.

Два мінімальні пороги, про які слід пам'ятати незалежно від результату формули:

Це фізичні ядра, а не логічні потоки з Hyperthreading. За обробки пакетів у режимі poll-mode, яким користується DPDK, ядро зайняте на 100 % незалежно від того, чи є саме зараз пакети для обробки. Розрахунок на потоки HT дає хибну картину доступної потужності.

32 ГБ RAM або більше це відправна точка. DPDK використовує hugepages, тобто заздалегідь зарезервовані блоки пам'яті, тож потрібен запас понад те, чого «зазвичай вистачає» на подібному сервері без пакетної обробки. Під дисковий простір достатньо 60 ГБ на NVMe: система не зберігає повний трафік безперервно, тож тут немає вимог до місткості, типових для інструментів повного запису трафіку.

Це пункт, на якому найчастіше руйнується планування закупівлі. DPDK теоретично підтримує широкий перелік карт, але на практиці добре працюють конкретні моделі з відповідним драйвером PMD (Poll Mode Driver):

Onboard-карти (вбудовані в материнську плату) чи рішення типу SoC потребують окремої перевірки, чи виробник узагалі постачає для них драйвер PMD. Відсутність цього драйвера означає, що карта не зможе працювати в режимі DPDK, незалежно від того, наскільки хорошим є процесор чи обсяг пам'яті. Це часта помилка при підборі обладнання для серверів: закупівельні команди дивляться на пропускну здатність карти в Гб/с і оминають сумісність драйверів, яка в цьому випадку є необхідною умовою.

Практичне правило вибору виробника карти: нижче 40 Гб/с трафіку різниця між Intel і Mellanox/NVIDIA не має особливого значення, обидві родини добре себе зарекомендували. Понад цим порогом варто цілитися в NVIDIA ConnectX-5 або новішу модель.

Замість того щоб триматися лише теорії, варто показати, як ці настанови перетворюються на конкретне обладнання, яке вже рекомендувалося операторам на етапі підбору інфраструктури.

Варіант I, до бл. 40 Гб/с: сервер класу Dell R430 з процесором Intel Xeon E5-2680 v4, 32 ГБ RAM, у поєднанні з двопортовою карткою Intel XL710-QDA2 (QSFP+, 40G). Це обладнання, яке можна купити вживаним за відносно невеликі гроші і яке спокійно обслужить трафік на цьому рівні.

Варіант II, до 100 Гб/с: тут процесор мусить змінитися на Intel Xeon Gold серії 63xx, головно через підтримку PCIe 4.0.

Важливо: мережева карта Intel E8xx-cqda2 для цієї пропускної здатності фізично ділить шину PCIe навпіл між портами, тож якщо планується одночасне використання обох портів, материнська плата мусить підтримувати PCIe Bifurcation. Без цієї підтримки система побачить лише один порт карти. Без повного PCIe 4.0 карта обмежиться бл. 50G на порт, незалежно від кількості використовуваних портів.

Для оператора, що планує захист вхідного трафіку на рівні 20 Гб/с, мінімальна розумна специфікація під Worker виглядає так:

За 100 Гб/с вхідного трафіку це вже 14 фізичних ядер лише з формули, тож підбір CPU потрібно ще ретельніше планувати з огляду на архітектуру NUMA та кількість процесорних сокетів.

Сайзинг під систему захисту від DDoS на основі DPDK це не округлення вгору типової серверної специфікації. Це окрема категорія вимог: фізичний сервер для модуля обробки пакетів, фізичні ядра, обраховані за конкретною формулою, мережева карта, перевірена на драйвер PMD до того, як потрапить у специфікацію замовлення. Оминання будь-якого з цих пунктів на етапі планування зазвичай закінчується необхідністю докуповувати обладнання вже після тестів або, гірше, після першої реальної атаки.

Добре сплановний захист від DDoS для ISP чи дата-центру це такою самою мірою питання правильного програмного забезпечення, як і свідомого підбору інфраструктури, на якій це програмне забезпечення має працювати. Повна актуальна апаратна специфікація та список валідованих мережевих карт містяться в документації: docs.liveshield.net.

Уже маєте якесь обладнання? Проконсультуйте його з нами: office@liveshield.net