XDP та eBPF для високопродуктивної обробки пакетів

XDP (eXpress Data Path) та eBPF (extended Berkeley Packet Filter) дозволяють Linux обробляти мережеві пакети до того, як до справи долучається звичайний мережевий стек ядра. Замість того, щоб виділяти структури пам'яті для кожного вхідного пакета, XDP перехоплює трафік безпосередньо на рівні драйвера мережевої карти, вирішує, що з ним робити, і або відкидає, або пересилає, або перенаправляє його. Результатом є обробка мільйонів пакетів на секунду на ядро з часткою навантаження на процесор, що становить лише частку від навантаження традиційних інструментів, таких як iptables.

Як eBPF та XDP працюють разом

eBPF — це віртуальна машина всередині ядра Linux. Вона виконує спеціальний байт-код, який перевірено на безпеку (відсутність нескінченних циклів, відсутність несанкціонованого доступу до пам'яті), а потім компілюється за допомогою JIT у нативні інструкції процесора. Програми мають обмежену сферу дії. Вони не можуть викликати довільні функції ядра, а лише набір заздалегідь визначених допоміжних функцій для таких завдань, як пошук у мапах та перенаправлення пакетів.

Для управління станом eBPF використовує мапи — сховища ключів/значень (хеш-таблиці, масиви, LPM-дерева), які зберігаються між надходженнями пакетів. Мапи доступні для читання та запису з простору користувача, тому ви можете оновлювати списки блокування або правила маршрутизації без перезавантаження програми.

XDP — це точка підключення eBPF. Вона підключається до шляху прийому драйвера мережевої карти (NIC) перед тим, як ядро виділяє структуру sk_buff структуру (об'єкт метаданих розміром 200–300 байт на пакет, від якого залежить традиційний мережевий стек). Пропуск цього виділення і є джерелом підвищення продуктивності.

XDP працює у трьох режимах:

• Нативний режим: працює всередині драйвера мережевої карти. Найкраща продуктивність.
• Режим розвантаження: працює на ASIC мережевої карти. Повністю звільняє процесор.
• Загальний режим: працює після sk_buff виділення пам'яті. Корисний для тестування на непідтримуваному обладнанні, але не дає переваг у продуктивності.

Після обробки кожного пакета програма XDP повертає вердикт:

XDP проти iptables: тести продуктивності

Цифри вражають. iptables обробляє приблизно 200 000 пакетів на секунду на ядро. nftables покращує цей показник до приблизно 400 000 пакетів на секунду. XDP у нативному режимі обробляє від 10 до 40 мільйонів пакетів на секунду на ядро на тому самому обладнанні.

Причина проста: XDP_DROP вимагає однієї перевірки меж та значення повернення. iptables DROP вимагає sk_buff виділення пам'яті, обхід ланцюга netfilter, пошук відстеження з'єднання, саму дію DROP, а потім звільнення пам'яті. При швидкості 100 Гбіт/с з пакетами розміром 64 байти сервер обробляє 148 мільйонів пакетів на секунду, що залишає приблизно 100 наносекунд на пакет. У таких масштабах sk_buff виділення пам'яті стає вузьким місцем.

Економія ресурсів процесора є настільки ж значною. Перенесення списку блокування з iptables до XDP в одному тесті знизило використання процесора на програмні переривання з 28% до 3% при 1 мільйоні пакетів на секунду. Цей вивільнений ресурс дозволяє запускати процеси додатків, бази даних або віртуальні машини на тому ж сервері.

Захист від DDoS-атак та безпека

Найсильнішим аргументом на користь використання XDP у хостингу є захист від DDoS-атак. Оскільки він працює на рівні драйвера, шкідливі пакети відкидаються ще до того, як вони потрапляють у мережевий стек ядра. Один процесорний ядро, на якому працює XDP, може відкидати 26 мільйонів пакетів на секунду.

Cloudflare використовує систему на базі XDP під назвою L4Drop для захисту від об'ємних DDoS-атак принаймні з 2018 року. Система обробляє та відкидає трафік атак у контексті XDP, не даючи йому дістатися до рівня додатків. Katran від Meta, балансувальник навантаження XDP рівня 4 з відкритим кодом, обробляє трафік для Facebook та Instagram зі швидкістю понад 10 мільйонів пакетів на секунду на ядро.

Для динамічного фільтрування карти eBPF, такі як BPF_MAP_TYPE_LPM_TRIE дозволяють керувати списками заблокованих IP-адрес, що охоплюють окремі IP-адреси та підмережі CIDR, за допомогою одного запиту. Оновлення відбуваються з простору користувача в режимі реального часу, перезавантаження програми не потрібне. Під час активної атаки ви можете надсилати нові сигнатури за мілісекунди за допомогою bpftool:

bpftool map update id <MAP_ID> key <KEY_VALUE> value <VALUE>

Для спостережності eBPF збирає метрики за додатком, за IP та за потоком безпосередньо з шляху даних ядра. Контекст xdp_md контекст надає телеметрію, таку як ingress_ifindex та rx_queue_index, завдяки чому ви можете визначити, який інтерфейс або черга перебуває під навантаженням. Для довгострокового моніторингу такі інструменти, як ebpf_exporter перетворюють необроблені дані карти eBPF у метрики, сумісні з Prometheus, для візуалізації в Grafana.

Інструменти, розгортання та вимоги до апаратного забезпечення

Набір інструментів починається з Clang та LLVM для компіляції обмеженого C у байт-код eBPF. Далі вам знадобиться бібліотека завантажувача:

• libbpf: стандартна бібліотека C для виробничого використання. Підтримує CO-RE (Compile Once, Run Everywhere) для переносимості між ядрами.
• libxdp: специфічна для XDP, підтримує запуск декількох програм XDP на одному інтерфейсі.
• cilium/ebpf: чиста бібліотека Go для стеків на базі Go.

Для управління bpftool дозволяє перевіряти програми в режимі реального часу та відображати вміст. xdp-loader (з xdp-tools набору) обробляє завантаження та вивантаження. BCC корисний для створення прототипів з інтерфейсами Python/Lua, але libbpf з CO-RE — кращий вибір для виробництва.

Увімкніть компілятор BPF JIT перед розгортанням:

sysctl -w net.core.bpf_jit_enable=1

Для оновлень без простою використовуйте прапор XDP_FLAGS_REPLACE прапор, щоб атомарно замінити запущену програму. Закріпіть карти в /sys/fs/bpf/ , щоб вони зберігалися після завершення роботи завантажувача.

Сумісність з апаратним забезпеченням та ядром

XDP було впроваджено в ядрі 4.8, але для повного набору функцій рекомендується версія 5.x або пізніша. Перевірте своє ядро за допомогою uname -r та переконайтеся, що файлова система BPF існує за адресою /sys/fs/bpf/.

Ваш драйвер мережевої карти визначає, які функції XDP доступні:

Перевірте драйвер за допомогою ethtool -i <interface>. Якщо нативний режим не підтримується, система переходить у загальний режим, який запускається після sk_buff виділення пам'яті та не забезпечує жодних переваг у продуктивності.

Вимкніть GRO та LRO перед підключенням програми XDP, оскільки вони конфліктують:

ethtool -K <iface> gro off lro off

Стандартний XDP вимагає, щоб пакети вміщувалися в одну сторінку пам'яті розміром 4 096 байт. На i40e і ice драйверах обмеження MTU для x86 становить 3 046 байт.

Початок роботи з XDP

Почніть з оцінки вашого середовища. Запустіть uname -r , щоб підтвердити наявність ядра 4.8+ (бажано 5.x), та ethtool -i <interface> , щоб перевірити наявність вбудованої підтримки драйвера XDP.

Почніть з спостереження, а не з примусу. Використовуйте карти eBPF для класифікації та підрахунку трафіку, щоб мати базовий рівень нормальної активності. Як тільки ви зрозумієте свої шаблони трафіку, перейдіть до примусу: спочатку протестуйте в xdpgeneric режиму, а потім перейдіть до xdpdrv (нативний) для виробничого середовища.

Майте на увазі, що XDP обробляє фільтрацію на рівні пакетів, а не необроблену пропускну здатність. Для масштабних атак на рівні 100 Гбіт/с поєднуйте його з інфраструктурою «bare-metal» та BGP FlowSpec, щоб керувати вхідним трафіком до того, як він досягне сервера.

Якщо ви виконуєте робочі навантаження з високим трафіком, які потребують швидкого фільтрування пакетів, виділені сервери FDC забезпечують базову інфраструктуру для максимального використання XDP.