Comments 33
github.com/andrsharaev/xt_NAT
И вопрос, в случае NFTables ALG популярных протоколов работает?
Интересно было бы сравнить с этим модулем:
github.com/andrsharaev/xt_NAT
Предположу, что быстрее. Объясню почему. Это код модуля для iptables, соответственно, для этого должен работать iptables, который медленнее, чем nftables из-за иной организации правил и хуков в ядре. А в случае с flow offload в передаче пакетов в установленной сессии не участвует ни iptables, ни nftables. Поэтому даже чистый роутинг с помощью flow offload получается быстрее, чем использование пустых правил iptables без conntrack.
И вопрос, в случае NFTables ALG популярных протоколов работает?
Да, любые доступные iptables-helpers можно использовать в этом случае. Пример конфига:
table raw {
ct helper pptp-gre {
type "pptp" protocol tcp;
}
chain prerouting {
type filter hook prerouting priority -300;
tcp dport 1723 ct helper set "pptp-gre"
}
}Offload в таком случае не будет работать для соединений, у которых настроен ALG и они свалятся в обычный conntrack
Не поделитесь, какой еще тюнинг сетевого стека применяете?
Делаете ли распределение очередей сетевой карты по ядрам, отключение каких-либо затратных фич, типа, проверки CRC, etc?
Слегка оптимизированная сборка ядра, отключение всех mitigation, отключение audit и выставление максимальной производительности CPU в ущерб энергопотреблению.
Распределение очередей сетевой карты по ядрам сейчас выполняется автоматически практически во всех драйверах сетевых карт. Отключение CRC ничего не дает — все высокоскоростные карты умеют делать это аппаратно. Отключение flow-control дает равномерное наполнение буферов карт. Ну и включение GRO+GSO даёт значительную экономию CPU.
А насколько утилизируется процессор при ваших 30 гигабитах и сколько при этом сессий? Если не секрет конечно же.
Спрашиваю, а не экстраполирую данные из графика в статье потому что оно может очень нелинейно расти при увеличении pps и числа сессий.
Процессор в пике был до 50%, сессий около 1.6 млн. Экстраполирование чуть не срабатывает, потому что мы перешли на 40Gbps интерфейсы вместо 2х10Gbps в LAG, чем немного выиграли CPU. Нелинейный рост начинается после достаточно высокой загрузки CPU, когда в ядре набирается большое количество отложенных операций, например, удаление протухших сессий, или удаления старых данных после RCU grace period. Выглядит как резкий всплеск нагрузки на одно или нескольких ядрах. Поэтому лучше не доводить стабильную нагрузку на сервер больше 80% CPU.
vigor-nf.github.io?
Как я и писал в статье — использование DPDK-based решений накладывает дополнительные требования на эксплуатацию. Как минимум, какие инструменты использовать для диагностики сетевой части (tcpdump, просмотр fib, динамическое изменение rib)? И второе — какие инструменты использовать для мониторинга? Счетчики байт и пакетов на интерфейсах внутри DPDK показывают только текущую сетевую нагрузку, но что мониторить, чтобы понимать запас производительности? DPDK использует CPU в режиме poll — нагрузка на задействованых ядрах всегда 100% вне зависимости от того, 0 пакетов обработано за цикл или миллионы — как понять, сколько CPU осталось и когда начнутся потери пакетов?
Здравствуйте коллеги! Требуется помощь знатоков.
Есть немолодой NAT сервер. 2 xeon 56xx по 4 ядра/8 потоков. 4 intel gigabit ethernet собраных в bond. Потоки серевых карт равномерно распределены по всем ядрам. Oracle Linux 6 с UEK ядром 2.6.39 (которое на базе 3.0). Используются iptables (NAT, ipt-netflow, ipt-ratelimit), ipset.
В нормальных условиях без проблем прокачивает все 4 гигабита. Загрузка процессоров в пределе 10%. LA — в пределах 1. Conntrack count около 150 тыс.
Но бывает активизируются вирусы/ботнеты, которые со страшной силой начинают перебирать IP-адреса, этим создавая сверхвысокую нагрузку на сервер. При этом загрузка всех ядер достигает 100% (в основном si), LA — десатки единиц, conntrack резко возрастает, трафик и pps резко падают практически до нуля. Зачастую один такой абонент способен поставить сервер колом.
На сколько я понимаю — сервер не способен обработать такое количество новых соединений. Что можно сделать в подобной ситуации, что-бы улучшить состояние сервера?
Начать надо с обновления ядра, потому что 2.6.39, да и 3.0 — это очень старые ядра. Со времен тех ядер в сетевую подсистему внесли огромное количество изменений, избавившись от глобального spinlock'a, оптимизировав conntrack до возможности добавления до 1 млн новых сессий в секунду. Правда, параллельная обработка пакетов на платформе E56xx приводит к тому, что разные процессоры начинают "сражаться" за общую шину PCIe, но, кажется, 4Гбит/с можно обрабатывать и одним процессором.
У вас лимиты на сессии для абонентов настроены? Это должно спасти от проблемных абонентов.
Лимиты сессий настроены с помощью iptables connlim, но это не спасает от огромного потока новых соединений.
Пробовали отключать HT, кардинальным образом ничего не изменило (при нормальной нагрузке), решили оставить.
Сервер старенький, поэтому ОС и ядро тех времён. Стоит ли пробовать более новое ядро под rhel 6 из elrepo? Или сразу думать о современной ОС? Тогда какое ядро лучше использовать под rhel, стандартное, oracle uek или elrepo?
Интересный момент. На текущем ядре модуль igb имеет параметры (RSS, LRO и т.п.), а на новых ядрах этот модуль без параметров. Это как-то влияет на производительность?
Сервер старенький, поэтому ОС и ядро тех времён. Стоит ли пробовать более новое ядро под rhel 6 из elrepo? Или сразу думать о современной ОС?
Новая ОС — смотря что используется в user-space части этого сервера. Если всё сосредоточено в ядре/iptables и новые glibc/libc не принесут профита — можно оставить старую ОС, поменяв ядро и утилиты типа iproute2 и tcpdump, чтобы они соответствовали возможностям ядра. Я стараюсь использовать LTS ядра, и бэкпортировать в них что-то, что прям очень хорошее появилось в новых версиях, но это редко и скорее для теста производительности.
Интересный момент. На текущем ядре модуль igb имеет параметры (RSS, LRO и т.п.), а на новых ядрах этот модуль без параметров. Это как-то влияет на производительность?
По поводу драйвера — а вы пользуетесь этими параметрами? для роутинга нельзя использовать LRO, конфигурить RSS — ну так себе, профит изменения количества очередей не ясен, у сетевух в igb обычно не более 8 очередей — куда уж меньше. Но если хочется поиграться с настройками — лучше смотреть в сторону альтернативного драйвера — проект e1000 на sourceforge.
В разрезе Centos 6 пробовали ядра от Oracle.
R2 (2.6.39) лучший результат, самая маленькая нагрузка на процессор.
R3 (3.2.13) нагрузка явно выше в разы, особенно в час пик.
R4 (4.1.12) то-же какие-то проблемы были. Подробностей не помню.
Поэтому пока остались на Uek-R2
На текущий момент у Оракла самое свежее ядро R6 5.4.17, но только с 7й версии rhel.
Правила nftables описываются совсем не так, как в iptables.
Ну вот зачем менять правила описания? Есть гибкий iptables, синтаксис которого схож ещё ipchains, он был описан в куче мануалов (как и логика работы файровола). А теперь плодятся ufw, firewalld с новыми инструкциями…
Сейчас модным направлением в программном «перекладывании пакетиков» является использование DPDK и XDP. На эту тему написана куча статей, сделано много разных выступлений, появляются коммерческие продукты (например, СКАТ от VasExperts). Но в условиях ограниченных ресурсов программистов в операторах связи, пилить самостоятельно какое-нибудь «поделие» на базе этих фреймворков довольно проблематично. Эксплуатировать такое решение в дальнейшем будет намного сложнее, в частности, придется разрабатывать инструменты диагностики. Например, штатный tcpdump с DPDK просто так не заработает, да и пакеты, отправленные назад в провода с помощью XDP, он не «увидит».
ИМХО DPDK — тупиковый путь.
фактически это ещё один сетевой стек (притом весьма «специфический»). да, сегодня он актуален, но по мере роста производительности CPU и оптимизации сетевого стека в ядре, он потеряет свою привлекательность.
Не согласен, что это прям тупик. Несмотря на все оптимизации, сетевая часть ядра Linux — это монстр, который не может работать очень быстро из-за своей универсальности. А зависимостей между модулями столько, что не всегда получается оставить только то, что действительно необходимо. При этом на DPDK можно сделать очень производительное решение под конкретную частную задачу. Например, я не представляю, какое железо должно быть под задачу firewall ipv6 трафика с большим количеством правил (миллионы, например). При этом решение на DPDK вполне справлялось с задаче на 100Gbps line-rate, не забывая потом еще маршрутизировать этот трафик, и всё на 8 ядрах 2Ghz. Поэтому, правильнее сравнивать решения на DPDK с решениями от производителей сетевого оборудования. Например, Juniper MX204, позиционируется как бордер, P/PE маршрутизатор. Стоит сейчас больше 3 млн рублей. Сервис контракт на год на него стоит еще минимум шестизначную сумму. При этом фактически нужен для быстрого RMA, потому что time to market новых фич или багфиксов (если вообще получилось продавить тех поддержку) — минимум 6 месяцев. В качестве альтернативы — сервер на Supermicro X10, карты Mellanox ConnectX5 c такими же 100G интерфейсами. Цена выходит около 500 тыс. Если таких устройств нужно больше 4х, то ценой сервис контракта вполне можно закрыть годовую зарплату разработчика для DPDK. При этом time-to-market новых фич будет 1 спринт в agile. Решить эту же задачу в похожих объемах на чистом Linux скорее всего не выйдет, или выйдет дороже, и time-to-market будет сопоставим с Juniper
Решить эту же задачу в похожих объемах на чистом Linux скорее всего не выйдет, или выйдет дороже, и time-to-market будет сопоставим с Juniper
речь шла о перспективе, а не о сегодняшнем положении дел.
то, что сегодня использование DPDK в некоторых задачах оправдано — несомненно. но, я думаю, со временем (речь о годах и даже десятилетиях) таких задач будет всё меньше и меньше.
Можете поделиться инфой, где почитать про 100G на 8-ми ядрах?
А есть какие инструменты для управления nftables через веб? Ищем решение для малого офиса с постоянным трафиком 800мбит/с от камер видеонаблюдения. Сейчас есть kerio control, но он иногда дико лагает и функционала недостает.
Насколько я знаю проект OpenWRT в своем веб-интерфейсе Luci разрешает задействовать механизм flow offload. Не совсем понятно, какого именно функционала вам не хватает, но если нужно что-то больше, чем роутинг/nat, то nftables тут не поможет
1. А есть ли параллельно графикам загрузки процессоров график с количеством rx_dropped?
2. Какая сетевая карта использовалась?
Небольшой лайвхак как разгрузить NAT: нужно внедрить IPv6. Тогда огромный объём трафика, как минимум с Youtube, уйдёт с NAT на IPv6. А по сути надо стимулировать включать IPv6 на серверах и у клиентов. Это же позволит снизить нагрузку за провайдерский NAT и, в перспективе, полностью уйти от него. В текущих реалиях без IPv4 тяжело только с торрентами и всё, что на битторренте основано, потому что пиров мало или может совсем не быть. У Steam тоже были проблемы, но они решались костылём на клиентской машине. Т.е. вполне реально жить только на IPv6!!! Но вот для дома есть сложные случаи.
Можно и вообще построить сеть доступа только на IPv6, но это только если провайдер может позволить себе заказать свои CPE, например, с MAP-T. В РФ о таком пока не слышал, а в Европе и США уже есть. В РФ вообще всё глухо... мне доступно 1,5 провайдера, везде выдают IPv6 криво: Ростелеком режет в мою сторону все соединения и хоронит сквозную прозрачность, а Дом.ру, вроде, выдаёт только /64. А из сотовых первым был МТС, сейчас к нему подключился Мегафон. Про Мегафон точно могу сказать, что работает, сам пользуюсь.
Быстрый роутинг и NAT в Linux