[Azamat]

Люди из стали, и не страшно ведь держать тысяч 22-25 голов на одном сервере ? :)  Хотя бы даже из соображений яиц и корзин имеет смысл раскидать трафик на 2-3 копеечных сервера ?

[John_obn]

@AzamatКто сказал, что сервер один? 🙂

[Azamat]

это само собой. Но если сервер нагружен например на 50 проц, он может подхватить нагрузку упавшего и выйти в свой пик на 37-38 гиг на время замены.

А если упадет плита в 40 гиг - нужно вообще пустой сервер держать в горячем резерве. Там же будут пылиться реальные IPv4.

[John_obn]

@AzamatВ этом плане вы правы.

Довод к тому, чтобы разобраться с загрузкой после замены на Мелланокс. Второй сервер менее нагружен, поэтому запас есть. Пока есть.

[Azamat]

Скажем, если у вас 55 гиг трафика, то нашей точки зрения, было бы логичнее держать 3 сервера по 18-20 гиг. Каждый из них должен быть готов принять нагрузку с любого из БРАС-ов, прописаны правила НАТ-а на все серые сети, которые водятся. Где-то по 128 IP адресов в нат-пул на каждом из НАТ серверов.

 

И со спокойной душой расти до 80 гиг

Изменено 18 декабря, 2023 пользователем Azamat

[Стич]

@Azamat А вам не страшно держать на самопальном и  не сертифицированном решении и копеечных серверах?

[Azamat]

Копеечные сервера не потому что самопальные :) Иные причины.

uptime по 2-3 года, нагружены в половину возможностей. Ростелеком (top-level) падает в разы чаще, чем у нас что-то.

[nixx]

В 18.12.2023 в 10:58, John_obn сказал:

Заметил, что после замены XL710 на Mellanox idle уменьшился в среднем на 5% (то есть загрузка возросла). Пока не критично, поэтому в причинах не разбирался.

сравните вывод ethtool --show-coalesce на интеле и мелланоксе, как возможность подвернется.

я так понимаю, что вы тайминги не крутили, всё дефолтное? возможно, в этом и разница (и самому интересны значения ))

[John_obn]

@nixxЭти тайминги я сделал такими же, какие были применены для Intel XL710:

Coalesce parameters for ens6:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 50
rx-frames: 128
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 50
tx-frames: 128
tx-usecs-irq: 0
tx-frames-irq: 0

rx-usecs-low: 0
rx-frames-low: 0
tx-usecs-low: 0
tx-frames-low: 0

rx-usecs-high: 0
rx-frames-high: 0
tx-usecs-high: 0
tx-frames-high: 0

 

[sirmax]

В 14.12.2023 в 10:17, nickD сказал:

Посоветуйте проверенную ethernet карту для роутера на linux , всё время использовали intel x520 все устраивало сейчас она снята с производства.

Нужна модель для 2x10G

и модель 40G.

Их тыщи на вторичном рынке, разве нет? В специфичном форм-факторе считай на вес отдают (делл мезанин вроде, мне 4 достались буквально даром с б/у сервером)

[_J_]

Всем привет.

Коллеги, поделитесь мнением, если бы вы сейчас собирали сервер на бордер bgp, чистый роутинг, порядка 30Гбит/с на вход и 5 на выход, то что бы поставили по железу и по софту?

Давно не собирал бордеры на серверах. В последний раз это был тогда ещё актуальный hp dl360 gen5 с интеловскими em картами, собранными в lacp на FreeBSD (помоему 7 или 8 версии) с пересобранным ядром. Пашет до сих пор, молотит гига 3 в пиках.

А сейчас как?

• По дистрибутиву это чисто вкусовщина, Debian/Ubuntu/Arch/Centos. Ставим что более привычнее?
• По CPU больше ядер и больше герц,  HT не нужен?
• Карты intel или melanox?
• 4 шт по 10Г в lacp или 1ш 40Г?
• dpdk и софт СКАТ/DANOS/TheRouter или всё на стандарном ядре, подтягиваем sysctl и драйвера сетевух?

[jffulcrum]

По ОС - в свете тенденций по сдаче узлов и списка железа в РКН - можно начинать изучать РЕД ОС.

По CPU высокая частота в целом выгоднее числа ядер, хотя бывают конфигурации, где лучше ядер запасти. И конечно CPU один, не надо вам NUMA.

Сетевые карты  - зависит от того, что конкретно система будет делать. С Intel в целом жить проще.

Порты - зависит от активки и устройства СОРМ. В целом лучше пара толще, чем куча мелких, как с тз управления, распределения прерываний, так и с тз что LACP полной утилизации всех портов не даст, и на полку выйдете раньше.

По реализации - ответ тоже зависит от требований СОРМ, Netflow, биллинга и прочего.  

[Стич]

В 07.01.2024 в 18:58, jffulcrum сказал:

По ОС - в свете тенденций по сдаче узлов и списка железа в РКН - можно начинать изучать РЕД ОС.

У вас есть опыт сдачи самосборного бордера/bras на базе сервера? Поделитесь плиз. Нужен ведь ССС на сервер и ОС.

[Стич]

В 07.01.2024 в 18:58, jffulcrum сказал:

И конечно CPU один, не надо вам NUMA.

Можно отключить в параметрах ядра numa=off

Больше процов больше ядер больше прерываний можно использовать.

А вот про отключение HT самому интересно вроде бы с HT можно столкнуться с вымыванием кэша, но так ли это. Иногда с включённым HT сталкивался с аномальной загрузкой одного двух thread'ов

[taf_321]

20 часов назад, Стич сказал:

У вас есть опыт сдачи самосборного бордера/bras на базе сервера? Поделитесь плиз. Нужен ведь ССС на сервер и ОС.

В связи с прикрытием халявы от RH, судьба деривативов от RHEL сейчас туманна. Пересобирать чужое с нескучными обоями и гордится "совместимостью вплоть до воспроизведения ошибок" это одно, а заниматься реально разработкой дистра это уже совсем другое.

16 часов назад, Стич сказал:

Можно отключить в параметрах ядра numa=off

Больше процов больше ядер больше прерываний можно использовать.

А вот про отключение HT самому интересно вроде бы с HT можно столкнуться с вымыванием кэша, но так ли это. Иногда с включённым HT сталкивался с аномальной загрузкой одного двух thread'ов

Аномалия возникает, когда система решает, что вот это ядро и это ядро это разные ядра и на них навешивает тяжелые задачи, но в физике это оказывается одно и то же ядро. И да, HT на роутинге все же надо выключать.

[Phantom]

Осторожно поинтересуюсь, о чем давно хотел спросить то же. А, что все-таки лучше из всего многообразия ОС лучше на бордере использовать?  Как то давно установил RockyLinux 8. Вроде бы и работает всё, но, чуйствую, что надо, наверное, в сторону Debian`а смотреть. Сервер только занимается NAT`ом и NetFLOW льёт в сорм. 

Ядро, только старое - 4.18.0-348.20.1.el8_5.x86_64 - вот и думаю, обновить или "работает - не трогай" ? 

В общем, буду рад советам всем 🙂

[Стич]

4 часа назад, taf_321 сказал:

Аномалия возникает, когда система решает, что вот это ядро и это ядро это разные ядра и на них навешивает тяжелые задачи,

К сожалению не так у меня прерывания жёстко прибиты к threads и система ни чем более не занимается. Проблема возникает токо с включенным HT, как токо от потока отвязывал прерывание с карты загрузка 0%, подвешиваю другое опять аномалия. Ну в принципе не важно уже.

 

4 часа назад, taf_321 сказал:

И да, HT на роутинге все же надо выключать.

А вот обоснование какое интересно. А для NAT как HT нужно?

1 час назад, Phantom сказал:

. А, что все-таки лучше из всего многообразия ОС лучше на бордере использовать? 

Ту которую можно контролировать чего она делает в заданный момент времени. И достаточно консервативную что бы не рвать на себе волосы что вдруг выпилили iptables и system v, и не собирается ipt_netflow и прочие.

Мы например slackware довольны.

[taf_321]

3 часа назад, Стич сказал:

К сожалению не так у меня прерывания жёстко прибиты к threads и система ни чем более не занимается. Проблема возникает токо с включенным HT, как токо от потока отвязывал прерывание с карты загрузка 0%, подвешиваю другое опять аномалия. Ну в принципе не важно уже.

Продвигали HT как технологию, которая позволяет более полно утилизировать процессоры, ибо при выполнении команд, процессор использует только некоторые блоки, и типа можно еще накинуть задачи, которые будут выполняться на других блоках. Возникновение ситуации, когда за ресурсы процессора будут конкурировать такие задачи, которым нужны те же самые блоки это вопрос статистики. А уж на роутере как раз и будут те задачи, которым требуется исполнять на процессоре идентичный набор инструкций. Собственно, по perf top можно посмотреть самые часто исполняемые команды процессора на самых прожорливых процессах.

[QWE]

"Можно отключить в параметрах ядра numa=off "   

как это работает?   Память подключенная к одному процессору, становиться недоступной другому процессору?

 

"Ядро, только старое - 4.18.0-348.20.1.el8_5.x86_64 - вот и думаю, обновить или "работает - не трогай" ? "   чего больше хочется, то и делайте, для самопознания.

 

у самого   4.12.0-1.el6.elrepo.x86_64

[jffulcrum]

6 часов назад, QWE сказал:

как это работает?   Память подключенная к одному процессору, становиться недоступной другому процессору?

Нет. Просто формируется одна NUMA-область на всю память сервера. Для программ, не использующих NUMA-awareness, не меняется ничего - они и так вольны лезть куда угодно, ядро, конечно, пытается их как-то распределять, но уж как получится. Программы с NUMA-awareness же мы просто обманываем, сообщая, что область памяти у нас одна. Иногда это бывает нужно, когда, например, софт не дает использовать область памяти больше размера одной области NUMA, а кровь из носу надо. Например, хост виртуализации, и одну машину надо откормить до предела. На аппаратном уровне всё по-прежнему, и обращение в чужую память имеет соответствующие штрафы. Но иногда с ними смиряешься, пока новые плашки или новый сервер не приедут.

[jffulcrum]

11 часов назад, Стич сказал:

А вот обоснование какое интересно. А для NAT как HT нужно?

Ситуация примерно такая. Включение HT само по себе вкидывает в систему ресурсы - пачку регистров CPU, LocalAPIC, блоки управления кешем и очередью команд, а с т.з. ОС - еще одну очередь к CPU, шедулеру ОС сразу легче. А вот дальше уже начинается внутренняя магия, и про эту магию в точности знают избранные личности внутри Intel и AMD. Общественностью же считается, что некий шедулер внутри процессора смотрит, какие исполняющие блоки заняты, а какие-нет, и, если основная очередь микроопераций по какой-то причине встала, например по причине cache miss, или неправильного предсказания ветвления, то, если это возможно, шедулер вкинет на свободные исполняющие блоки операции из второй очереди. Дальше начинаются тысячи "НО", выливающиеся в итоге во что-то такое:

 

Скрытый текст

- Элементарно, Ватсон: если девушка сосёт в публичном доме, вооружённых дедуктивным методом разум может сделать вывод что перед нами проститутка.
Я почувствовал обиду за своё поколение.
-Почему обязательно проститутка? А может это белошвейка. Которая только вчера приехала из деревни. И влюбилась в водопроводчика, ремонтирующего в публичном доме душ. А водопроводчик взял её с собой на работу, потому что ей временно негде жить. И у них там выдалась свободная минутка.
Самарцев поднял палец:
-Вот на этом невысказанном предположении и держится весь хрупкий механизм нашего молодого народовластия.

 

Разумеется, недостатки схемы тоже очевидны - усиливается нагрузка на контроллеры памяти и кеша, которых в процессоре не прибавляется, плюс в кеше начинают лежать данные второй очереди, которые, возможно, понадобятся очень нескоро. Ну и вероятность конфликтов, когда обе очереди встанут...

 

Но еще до этого свое слово говорят разработчики операционных систем. Они HT не любят изначально, а особенно после всех десятков "Спектров" и прочего. Потому шедулер ОС очень наврядли выдаст на два логических CPU одного физического ядра разные процессы, судя по срачам в Linux Kernel DEV это к 6-й версии ядра стало в принципе невозможным.

 

Итак, для пользы от HT нам надо иметь:

1. многопоточное приложение

2. оперирующее независимыми кусками данных

3. желательно, сильно зависимое от какого-то еще железа, в разы медленнее CPU - то есть CPU большую часть времени ждет данные "оттуда" (ну или ответы, что "туда" дошло.

 

Большинство провайдерского хозяйства не удовлетворяет критерию 2. Потому что оперирует последовательностями, и пока все обещанные магии от разработчиков сетевых контроллеров по отдаче в систему уже готовых потоков остаются мракетингом (потому как сами системы нихера к такому не готовы), от HT будет скорее проигрыш, хотя, за счет вкидывания ресурсов из начала поста и критерия 3 может получаться и выигрыш. Еще неприятнее тенденция, что порой и критерию 1 не соответствует (порождая кучу полуавтономных процессов вместо одного процесса с кучей тредов - так проще писать). Да, есть DPDK, решающий в какой-то степени проблему 2, но это если вы FAANG ВСРАТОСЛАВ и готовы писать весь сетевой стек под себя. Так что стоит тестировать, ну или принять, что для роутера HT/SMT бесполезен или даже вреден.

[Стич]

@jffulcrum Спасибо за развернутый ответ. А что вы думаете по numa включать его для роутеров без nat, и с nat.

[jffulcrum]

В 10.01.2024 в 09:28, Стич сказал:

У вас есть опыт сдачи самосборного бордера/bras на базе сервера

Софт-роутеры в сведения по приказам указывают, и даже устанавливают взаимодействие с ЦМУ ССОП. Серты нужны для первой сдачи узла, РКН сейчас не до того, чтобы майнить свою БигДату из загруженных в ЛК XMLек (но когда-нибудь начнут!). Вот с КИИ грести начнут уже скоро.

 

5 часов назад, Стич сказал:

А что вы думаете по numa включать его для роутеров без nat, и с nat.

 

Для чего нужна NUMA? NUMA нужна, чтобы сообщить приложению: псс, у нас тут памяти столько, но вот столько из неё - тебе будет таки больно использовать. А что мы имеем в случае роутера с данными - да водопад. Сетевка вытащила какую-то датаграмму/фрейм, поклала в память. Стек ОС вытащил эту датаграмму из памяти, превратил в пакет, поклал в память. Приложение забрало пакет из памяти, и что-то с ним сделало. В худшем случае, у нас еще и на L5-6 какая-то херня происходит с перекладыванием данных, типа из TCP в HTTP. А что дальше? А дальше надо все провернуть в обратном направлении. Нигде в этой цепочке нам не всралось пересекать границу NUMA с конскими штрафами на межпроцессорный обмен, ибо у нас задача бассейна с двумя трубами и вода должна литься без задержек. Потому делать NUMA архитектуру для роутера - это сюр. Ну разве что у нас на каждом CPU висят свои сетевухи на вход и выход, и сделан VRF, чтобы потоки не пересекались. Тогда да, второй проц себя покажет, хотя все равно в ОС есть ресурсы в единственном числе, на CPU0, и эти ресурсы и могут оказаться узким местом, убивая всё хорошее. Так что лучше один проц, да почастотнее, потому что эти ресурсы на CPU0 никуда не деваются, и продолжают оставаться узким местом.

[alibek]

Цитата

Потому делать NUMA архитектуру для роутера - это сюр.

Ну зачастую под словом "роутер" что-то более широкое, например BRAS.

Хотя в общем случае производительность одного процессора будет важнее, чем число процессоров.

[Стич]

В 12.01.2024 в 15:13, jffulcrum сказал:

Так что лучше один проц, да почастотнее

Ну не знаю, имею два роутера с двумя физическими процессорами, прерывания карт прибиты к ядрам, numa=off,

34gbps туда и обратно проблем не имею.