Свежерелизнутый OpenSSL-3.0.0 поменял подход к включению этой фичи. Сейчас надо в явном виде включать эти опции при инициализации SSL context, тогда как изначально фича была "default on" с возможностью выключения. Соответствующие правки в форк nginx планирую, но скорее всего сразу после того, как OpenSSL 3.0.0 будет официально поддержан в nginx - upstream.
да, остается. фактически создание NAT трансляции происходит в модуле nf_conntrack и абсолютно идентично тому, что происходит, если писать правила iptables. чтобы модуль ipt_NETFLOW логировал трансляции через natevents достаточно его просто загрузить
Насколько я знаю проект OpenWRT в своем веб-интерфейсе Luci разрешает задействовать механизм flow offload. Не совсем понятно, какого именно функционала вам не хватает, но если нужно что-то больше, чем роутинг/nat, то nftables тут не поможет
конечно работает. GSO разбирает пакет, перед отправкой в провода, ровно до того состояния, которое было до GRO. Из-за этого ограничения эффективность GRO ниже, чем LRO, но нет ограничения на роутинг
Не согласен, что это прям тупик. Несмотря на все оптимизации, сетевая часть ядра 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
Сервер старенький, поэтому ОС и ядро тех времён. Стоит ли пробовать более новое ядро под rhel 6 из elrepo? Или сразу думать о современной ОС?
Новая ОС — смотря что используется в user-space части этого сервера. Если всё сосредоточено в ядре/iptables и новые glibc/libc не принесут профита — можно оставить старую ОС, поменяв ядро и утилиты типа iproute2 и tcpdump, чтобы они соответствовали возможностям ядра. Я стараюсь использовать LTS ядра, и бэкпортировать в них что-то, что прям очень хорошее появилось в новых версиях, но это редко и скорее для теста производительности.
Интересный момент. На текущем ядре модуль igb имеет параметры (RSS, LRO и т.п.), а на новых ядрах этот модуль без параметров. Это как-то влияет на производительность?
По поводу драйвера — а вы пользуетесь этими параметрами? для роутинга нельзя использовать LRO, конфигурить RSS — ну так себе, профит изменения количества очередей не ясен, у сетевух в igb обычно не более 8 очередей — куда уж меньше. Но если хочется поиграться с настройками — лучше смотреть в сторону альтернативного драйвера — проект e1000 на sourceforge.
Начать надо с обновления ядра, потому что 2.6.39, да и 3.0 — это очень старые ядра. Со времен тех ядер в сетевую подсистему внесли огромное количество изменений, избавившись от глобального spinlock'a, оптимизировав conntrack до возможности добавления до 1 млн новых сессий в секунду. Правда, параллельная обработка пакетов на платформе E56xx приводит к тому, что разные процессоры начинают "сражаться" за общую шину PCIe, но, кажется, 4Гбит/с можно обрабатывать и одним процессором.
Как я и писал в статье — использование DPDK-based решений накладывает дополнительные требования на эксплуатацию. Как минимум, какие инструменты использовать для диагностики сетевой части (tcpdump, просмотр fib, динамическое изменение rib)? И второе — какие инструменты использовать для мониторинга? Счетчики байт и пакетов на интерфейсах внутри DPDK показывают только текущую сетевую нагрузку, но что мониторить, чтобы понимать запас производительности? DPDK использует CPU в режиме poll — нагрузка на задействованых ядрах всегда 100% вне зависимости от того, 0 пакетов обработано за цикл или миллионы — как понять, сколько CPU осталось и когда начнутся потери пакетов?
Слегка оптимизированная сборка ядра, отключение всех mitigation, отключение audit и выставление максимальной производительности CPU в ущерб энергопотреблению.
Распределение очередей сетевой карты по ядрам сейчас выполняется автоматически практически во всех драйверах сетевых карт. Отключение CRC ничего не дает — все высокоскоростные карты умеют делать это аппаратно. Отключение flow-control дает равномерное наполнение буферов карт. Ну и включение GRO+GSO даёт значительную экономию CPU.
Процессор в пике был до 50%, сессий около 1.6 млн. Экстраполирование чуть не срабатывает, потому что мы перешли на 40Gbps интерфейсы вместо 2х10Gbps в LAG, чем немного выиграли CPU. Нелинейный рост начинается после достаточно высокой загрузки CPU, когда в ядре набирается большое количество отложенных операций, например, удаление протухших сессий, или удаления старых данных после RCU grace period. Выглядит как резкий всплеск нагрузки на одно или нескольких ядрах. Поэтому лучше не доводить стабильную нагрузку на сервер больше 80% CPU.
Интересно было бы сравнить с этим модулем:
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
Сильно зависит от количества обслуживающих серверов в PoP. Речь же идет о том, чтобы максимально раздавать с одного сервера, а не закатывать полные стойки серверов в IX.
Популярным инструментом проброски пакетов был IPVS. Он выполнял задачи балансировки через тоннель и Direct Routing.
В первом случае, для каждого соединения устанавливался TCP-канал и пакет от пользователя шел на балансер, потом на миньон, а потом в обратном порядке.
Вот тут не совсем честно. У IPVS есть 3 метода доставки трафика до обслуживающих нод:
Gatewaying, он же Direct Routing — пересылка пакетов в пределах одного броадкаст сегмента.
Tunneling — туннелирование, работает в маршрутизируемых сетях, инкапсулирует пакеты в IPv4/IPv6.
Masquerading — классический DNAT.
Так вот обратный трафик идет через балансер только в случае Masquerading. В остальных двух случаях настройки на облуживающих нодах позволяют возвращать трафик клиенту без задействования балансировщика.
Да, точно. Но тут сравнение с Gnu TLS c малым размером TLS Record, который умещается в один TCP пакет. Такое поведение не самое распространенное, и не позволяет использовать механизмы GSO и TSO в ядре. Ну и версия kTLS там правда очень древняя. Была еще статья, в которой сравнивался OpenSSL (кажется 1.1.0) в более честных условиях, там были изменения в обратную сторону, но незначительные
и да, в той статье есть таблица, где у kTLS без аппаратного ускорения производительность оказалась ниже, чем в userspace (это я возвращаюсь к вопросу «будет ли выигрыш если исходные данные в userspace»)
Это одна из первых статей, после этого в ядре было несколько итераций оптимизации кода AES. Но я не берусь утверждать, что стало сильно лучше, вероятнее всего при проксировании действительно профита видно не будет
имелось в виду не «будет ли работать», а «будет ли профит в случае множества относительно медленных клиентов», очевидно, что хранить состояние всех сессий в сетевой карте невозможно, не убьёт ли производительность то, что контекст придётся постоянно передавать в сетевую карту/из сетевой (что-то вроде context switch в OS).
Конкретно у Mellanox в их Crypto-enabled BlueField воткнут «64-bit Armv8 A72» на 16 ядер и 16GB оперативки. Всё это с отдельным интерконнектом в собственно сетевой чип, поэтому вполне можно держать все сессии. Быстро перепрограммировать сетевой чип из BlueField точно умеют, а про передавать контекст в карту/из карты — это в общем случае надо делать только на старте сессии. Карта умеет трекать TCP Seq Number, и TLS Record Number. Соответственно от ядра нужно только получать данные на отправку.
Тут, кстати, нашел доку по картам Chelsio. У них указывается «The typical T6 adapter supports 32K simultaneous TLS/SSLsessions.» — вполне неплохая цифра одновременных TLS соединений.
в случае «nginx проксирует и обеспечивает tls» выигрыша, думаю, ждать не стоит.
По первым тестам использование шифрования в ядре без использования sendfile() давало несколько процентов производительности, но сейчас подтвердить или опровергнуть эти данные не могу — не получается быстро найти статью с картинками сравнения.
А можно ссылочку на статью, где производительность Kernel TLS просела относительно user-space?
Теоретически, выгоду могут получить любые проекты, использующие TLS. вот сразу в голову пришло — тот же Postfix MTA, всё пересылку ведет через файлы, умеет использовать sendfile, но в режиме TLS такое не поддерживает.
Но меня больше интересуют проекты, в которых уже была реализована поддержка. Правда, я больше искал в направлении WEB-серверов, возможно проекты в других направлениях используют.
Свежерелизнутый OpenSSL-3.0.0 поменял подход к включению этой фичи. Сейчас надо в явном виде включать эти опции при инициализации SSL context, тогда как изначально фича была "default on" с возможностью выключения. Соответствующие правки в форк nginx планирую, но скорее всего сразу после того, как OpenSSL 3.0.0 будет официально поддержан в nginx - upstream.
да, остается. фактически создание NAT трансляции происходит в модуле nf_conntrack и абсолютно идентично тому, что происходит, если писать правила iptables. чтобы модуль ipt_NETFLOW логировал трансляции через natevents достаточно его просто загрузить
Ответы просты:
Насколько я знаю проект OpenWRT в своем веб-интерфейсе Luci разрешает задействовать механизм flow offload. Не совсем понятно, какого именно функционала вам не хватает, но если нужно что-то больше, чем роутинг/nat, то nftables тут не поможет
конечно работает. GSO разбирает пакет, перед отправкой в провода, ровно до того состояния, которое было до GRO. Из-за этого ограничения эффективность GRO ниже, чем LRO, но нет ограничения на роутинг
Это было внутреннее тестирование, в Open Source проект не ушел. Решалась очень специфическая задача.
Не согласен, что это прям тупик. Несмотря на все оптимизации, сетевая часть ядра 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
Новая ОС — смотря что используется в user-space части этого сервера. Если всё сосредоточено в ядре/iptables и новые glibc/libc не принесут профита — можно оставить старую ОС, поменяв ядро и утилиты типа iproute2 и tcpdump, чтобы они соответствовали возможностям ядра. Я стараюсь использовать LTS ядра, и бэкпортировать в них что-то, что прям очень хорошее появилось в новых версиях, но это редко и скорее для теста производительности.
По поводу драйвера — а вы пользуетесь этими параметрами? для роутинга нельзя использовать LRO, конфигурить RSS — ну так себе, профит изменения количества очередей не ясен, у сетевух в igb обычно не более 8 очередей — куда уж меньше. Но если хочется поиграться с настройками — лучше смотреть в сторону альтернативного драйвера — проект e1000 на sourceforge.
Начать надо с обновления ядра, потому что 2.6.39, да и 3.0 — это очень старые ядра. Со времен тех ядер в сетевую подсистему внесли огромное количество изменений, избавившись от глобального spinlock'a, оптимизировав conntrack до возможности добавления до 1 млн новых сессий в секунду. Правда, параллельная обработка пакетов на платформе E56xx приводит к тому, что разные процессоры начинают "сражаться" за общую шину PCIe, но, кажется, 4Гбит/с можно обрабатывать и одним процессором.
Как я и писал в статье — использование DPDK-based решений накладывает дополнительные требования на эксплуатацию. Как минимум, какие инструменты использовать для диагностики сетевой части (tcpdump, просмотр fib, динамическое изменение rib)? И второе — какие инструменты использовать для мониторинга? Счетчики байт и пакетов на интерфейсах внутри DPDK показывают только текущую сетевую нагрузку, но что мониторить, чтобы понимать запас производительности? DPDK использует CPU в режиме poll — нагрузка на задействованых ядрах всегда 100% вне зависимости от того, 0 пакетов обработано за цикл или миллионы — как понять, сколько CPU осталось и когда начнутся потери пакетов?
Слегка оптимизированная сборка ядра, отключение всех mitigation, отключение audit и выставление максимальной производительности CPU в ущерб энергопотреблению.
Распределение очередей сетевой карты по ядрам сейчас выполняется автоматически практически во всех драйверах сетевых карт. Отключение CRC ничего не дает — все высокоскоростные карты умеют делать это аппаратно. Отключение flow-control дает равномерное наполнение буферов карт. Ну и включение GRO+GSO даёт значительную экономию CPU.
Процессор в пике был до 50%, сессий около 1.6 млн. Экстраполирование чуть не срабатывает, потому что мы перешли на 40Gbps интерфейсы вместо 2х10Gbps в LAG, чем немного выиграли CPU. Нелинейный рост начинается после достаточно высокой загрузки CPU, когда в ядре набирается большое количество отложенных операций, например, удаление протухших сессий, или удаления старых данных после RCU grace period. Выглядит как резкий всплеск нагрузки на одно или нескольких ядрах. Поэтому лучше не доводить стабильную нагрузку на сервер больше 80% CPU.
Предположу, что быстрее. Объясню почему. Это код модуля для iptables, соответственно, для этого должен работать iptables, который медленнее, чем nftables из-за иной организации правил и хуков в ядре. А в случае с flow offload в передаче пакетов в установленной сессии не участвует ни iptables, ни nftables. Поэтому даже чистый роутинг с помощью flow offload получается быстрее, чем использование пустых правил iptables без conntrack.
Да, любые доступные iptables-helpers можно использовать в этом случае. Пример конфига:
Offload в таком случае не будет работать для соединений, у которых настроен ALG и они свалятся в обычный conntrack
Сильно зависит от количества обслуживающих серверов в PoP. Речь же идет о том, чтобы максимально раздавать с одного сервера, а не закатывать полные стойки серверов в IX.
Вот тут не совсем честно. У IPVS есть 3 метода доставки трафика до обслуживающих нод:
Так вот обратный трафик идет через балансер только в случае Masquerading. В остальных двух случаях настройки на облуживающих нодах позволяют возвращать трафик клиенту без задействования балансировщика.
Да, точно. Но тут сравнение с Gnu TLS c малым размером TLS Record, который умещается в один TCP пакет. Такое поведение не самое распространенное, и не позволяет использовать механизмы GSO и TSO в ядре. Ну и версия kTLS там правда очень древняя. Была еще статья, в которой сравнивался OpenSSL (кажется 1.1.0) в более честных условиях, там были изменения в обратную сторону, но незначительные
Это одна из первых статей, после этого в ядре было несколько итераций оптимизации кода AES. Но я не берусь утверждать, что стало сильно лучше, вероятнее всего при проксировании действительно профита видно не будет
Конкретно у Mellanox в их Crypto-enabled BlueField воткнут «64-bit Armv8 A72» на 16 ядер и 16GB оперативки. Всё это с отдельным интерконнектом в собственно сетевой чип, поэтому вполне можно держать все сессии. Быстро перепрограммировать сетевой чип из BlueField точно умеют, а про передавать контекст в карту/из карты — это в общем случае надо делать только на старте сессии. Карта умеет трекать TCP Seq Number, и TLS Record Number. Соответственно от ядра нужно только получать данные на отправку.
Тут, кстати, нашел доку по картам Chelsio. У них указывается «The typical T6 adapter supports 32K simultaneous TLS/SSLsessions.» — вполне неплохая цифра одновременных TLS соединений.
По первым тестам использование шифрования в ядре без использования sendfile() давало несколько процентов производительности, но сейчас подтвердить или опровергнуть эти данные не могу — не получается быстро найти статью с картинками сравнения.
А можно ссылочку на статью, где производительность Kernel TLS просела относительно user-space?
Но меня больше интересуют проекты, в которых уже была реализована поддержка. Правда, я больше искал в направлении WEB-серверов, возможно проекты в других направлениях используют.