Портирование в mainstream мы отложили на неопрелеленное время.
Конечно видел. И как раз сильно расстроило то, что закончилось это ничем. Хотя patchset был воспринят очень позитивно в community. Я как раз обсуждал его с Jakub Kicinski в то время, и он был настроен очень оптимистично...
Я не хотел никого обидеть или принизить чьи-то заслуги. Я просто хотел отметить, что эта работа от имени сотрудников Tempesta так и не появилась в ядре Linux. Ускорения TLS мы, кажется, уже обсуждали в offline как раз после NetDev Conf, я ни в коем случае не говорю (и не говорил), что вы не занимаетесь улучшением этих алгоритмов.
Именно эту работу в ядре я имел ввиду в предыдущем своем комментарии про производительность TLS в ядре - она не уступает user-space реализациям
коллеги, как и все нормальные/простые люди, у которых нет ресурсов Facebook для поддержки mainline ядер в продакшене, работают на longterm ядрах.
А вот тут можно немного подробнее? Например, с каким минорных версий LTS ядер ты считаешь имеет смысл использовать в проде? И почему поддержка LTS ядер требует меньше ресурсов? Мне кажется, что в community сформировалось некорректное предубеждение к Stable версиям, или отсутствует понимание зачем поддерживаются LTS ядра.
Фактически при норме ответа в 100–200ms мы можем деградировать до 1-й, а в ряде случаев 2-х секунд без ухудшений для пользователя
Ох, вот тут я бы поспорил насчет "без ухудшений для пользователя". Трансляция чемпионата мира по футболу в 2018 показала очень "интересную" реакцию пользователей, когда деградирующий до 2х секунд Live приводил к тому, что по всему городу было минимум 2 волны реакции на забитый мяч - первая волна от зрителей классического ТВ, а вторая - как раз от деградирующего Live, когда чанки не отдавались вовремя. С того времени я крайне настороженно отношусь к заявлениям о возможности деградации Live трансляций... Что действительно помогает лучше раздавать и Live, и VOD - это корректно выполненый pacing на стороне сервера. Судя по тому, что в статье это не упоминается совершенно - вы в эту сторону не копали, и чудный мир честного распределения канала между пользователями откроется вам в (вероятно скором) будущем :)
P. S. Если скорость kTLS — это прямо блокер для вас, то можно пообщаться с @krizhanovsky и ребятами из Tempesta, они занимаются TLS в ядре (в том числе хендшейками).
Ну я не совсем понимаю метрику "заниматься TLS в ядре", но:
Говорить, что шифрование в ядре заметно медленнее, чем в OpenSSL - некорректно, особенно если речь идет про свежие ", где Eric Biggers сильно оптимизировал всю линейку AES шифров. Под "понятными причинами" я имел ввиду скорость проверки подписи, сделанной на основе EC-сертификата, на клиенте. Это самый большой известный trade off - сервер выигрывает, клиент страдает, тратя больше времени и батарейки в случае мобильного клиента. И вторая причина увеличения этого самого TTFB в случае kTLS - необходимость выполнять дополнительный syscall с передачей TLS контекста в ядро перед передачей первых данных. Вы автоматически лишаетесь возможности передавать зашифрованные данные в одном TCP сегменте вместе с TLS Finished сообщением. Вероятно, для передачи потокового видео это и правда не сильно критично, однако, в случае general CDN может случиться так, что userspace-only вариант успеет положить все нужные данные в сетевой стек быстрее, чем kTLS успеет настроить все необходимое для начала шифрования данных. Ну и да, TTFB имеет смысл сравнивать на одном клиенте с одним подключением, конечно же, чтобы понять влияние именно изменений в TLS на эту метрику.
Мне вот интересно, а был ли проводен анализ клиентских метрик после перехода на kTLS и на сертификаты с EC? Я имею ввиду в первую очередь Time-to-first-byte? Обычно они знатно проседают по понятным причинам. Или вам не важно, что в итоге клиент получает?
Свежерелизнутый 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.
Ok, но я почему уверен, что если бы занимались этим, то обязательно упомянули бы в выступлении...
Поговорить всегда рад. От предложения работать вынужден, увы, отказаться :)
Конечно видел. И как раз сильно расстроило то, что закончилось это ничем. Хотя patchset был воспринят очень позитивно в community. Я как раз обсуждал его с Jakub Kicinski в то время, и он был настроен очень оптимистично...
Я не хотел никого обидеть или принизить чьи-то заслуги. Я просто хотел отметить, что эта работа от имени сотрудников Tempesta так и не появилась в ядре Linux. Ускорения TLS мы, кажется, уже обсуждали в offline как раз после NetDev Conf, я ни в коем случае не говорю (и не говорил), что вы не занимаетесь улучшением этих алгоритмов.
Именно эту работу в ядре я имел ввиду в предыдущем своем комментарии про производительность TLS в ядре - она не уступает user-space реализациям
А вот тут можно немного подробнее? Например, с каким минорных версий LTS ядер ты считаешь имеет смысл использовать в проде? И почему поддержка LTS ядер требует меньше ресурсов? Мне кажется, что в community сформировалось некорректное предубеждение к Stable версиям, или отсутствует понимание зачем поддерживаются LTS ядра.
Ох, вот тут я бы поспорил насчет "без ухудшений для пользователя". Трансляция чемпионата мира по футболу в 2018 показала очень "интересную" реакцию пользователей, когда деградирующий до 2х секунд Live приводил к тому, что по всему городу было минимум 2 волны реакции на забитый мяч - первая волна от зрителей классического ТВ, а вторая - как раз от деградирующего Live, когда чанки не отдавались вовремя. С того времени я крайне настороженно отношусь к заявлениям о возможности деградации Live трансляций...
Что действительно помогает лучше раздавать и Live, и VOD - это корректно выполненый pacing на стороне сервера. Судя по тому, что в статье это не упоминается совершенно - вы в эту сторону не копали, и чудный мир честного распределения канала между пользователями откроется вам в (вероятно скором) будущем :)
Ну я не совсем понимаю метрику "заниматься TLS в ядре", но:
Говорить, что шифрование в ядре заметно медленнее, чем в OpenSSL - некорректно, особенно если речь идет про свежие ", где Eric Biggers сильно оптимизировал всю линейку AES шифров. Под "понятными причинами" я имел ввиду скорость проверки подписи, сделанной на основе EC-сертификата, на клиенте. Это самый большой известный trade off - сервер выигрывает, клиент страдает, тратя больше времени и батарейки в случае мобильного клиента. И вторая причина увеличения этого самого TTFB в случае kTLS - необходимость выполнять дополнительный syscall с передачей TLS контекста в ядро перед передачей первых данных. Вы автоматически лишаетесь возможности передавать зашифрованные данные в одном TCP сегменте вместе с TLS Finished сообщением. Вероятно, для передачи потокового видео это и правда не сильно критично, однако, в случае general CDN может случиться так, что userspace-only вариант успеет положить все нужные данные в сетевой стек быстрее, чем kTLS успеет настроить все необходимое для начала шифрования данных.
Ну и да, TTFB имеет смысл сравнивать на одном клиенте с одним подключением, конечно же, чтобы понять влияние именно изменений в TLS на эту метрику.
Мне вот интересно, а был ли проводен анализ клиентских метрик после перехода на kTLS и на сертификаты с EC? Я имею ввиду в первую очередь Time-to-first-byte? Обычно они знатно проседают по понятным причинам. Или вам не важно, что в итоге клиент получает?
Свежерелизнутый 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.