[trksergey]

Коллеги, помогите с выборам железа под Freeradius + MariaDB (база только для radius) + Debian 12. Пользователей до 50000. Авторизация PPPoE и DHCP.

Предлагают:

Сервер HP DL360 Gen9 4LFF. 
Процессор Intel Xeon E5-2690v4 2.6GHz 14 Core - 1
128 GB DDR4 PC4-19200 2400MHz ECC RDIMM 
Аппаратный RAID-контроллер HP Smart Array P440ar 2GB Cache
SSD Intel 480GB SATA Ref - под систему
HDD 4TB SAS 3.5" 12Gbps 7.2K Ref - под базу

Есть сомнения по дискам для базы, по скорости. Что порекомедуете?

[sdy_moscow]

Рекомендуется настраивать модель БД под себя.  А это не хухры-мухры для такой абон. базы. Штатная модель - дно. Может возникнуть масса проблем при сбоях и перезагрузке БД, скорость работы и "простота" настроек абонентов и пулов тоже не фонтан в штатной схеме. Я  как раз сейчас вожусь с подобной задачей. Результат есть и неплохой, НО пока в сырцах, и вряд-ли отдам бесплатно. МОЁ МНЕНИЕ: Штатные схема SQL не для задач операторского уровня, и не рабочие.

[jffulcrum]

Железке поди лет 10 уже, и REFURBISHED наверняка - так себе для mission critical. База на SAS HDD - ну, работало так когда-то, но не на одном, а все же на массиве хотя бы из 4-х шпинделей. Нет смысла в 2025 году связываться с HDD вообще в данной задаче, ну разве что для бекапов один диск воткнуть. RAID контроллер нафиг не нужен, лишний передаст, для отказоустойчивости второй сервер заведите + репликация. Про схему БД выше правильно сказали, пример, насколько штатное  - говно:

 

, уже на 100 юзерах складывалось. Вот только это и запросы в скриптах переписывать, и уже не обновишь пакеты штатно = не посадишь обезьянку на сопровождение. А если всё равно костылить, то тут по соседству есть: 

 написано специально для провайдеров. Правда, надо знать древний запретный язык Perl хоть базово.

[Urs_ak]

Цитата

RAID контроллер нафиг не нужен, лишний передаст

 

Недавно сервер под DPI купили, нам поставщик так сделал:

 

RAID-контроллер LSI 9361-8i, 12Gb/s SAS/SATA 8-port int, cache 1Gb
1 шт.
Накопитель SSD Phison SC-ESM1720 480GB, SATA, 3D TLC 2,5"
2 шт.

 

будет RAID 1

 

Плохо что-ли? 

Я правда (тьфу*3) не разу не сталкивался как SSD серверные дохнут

 

[sirmax]

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

Железке поди лет 10 уже, и REFURBISHED наверняка - так себе для mission critical. База на SAS HDD - ну, работало так когда-то, но не на одном, а все же на массиве хотя бы из 4-х шпинделей. Нет смысла в 2025 году связываться с HDD вообще в данной задаче, ну разве что для бекапов один диск воткнуть. RAID контроллер нафиг не нужен, лишний передаст, для отказоустойчивости второй сервер заведите + репликация. Про схему БД выше правильно сказали, пример, насколько штатное  - говно:

 

, уже на 100 юзерах складывалось. Вот только это и запросы в скриптах переписывать, и уже не обновишь пакеты штатно = не посадишь обезьянку на сопровождение. А если всё равно костылить, то тут по соседству есть: 

 написано специально для провайдеров. Правда, надо знать древний запретный язык Perl хоть базово.

Там вопрос про ppp или dhcp? 
так то я б сначала метод тестирования разработал, что б не на живых абонах тестить, и что б четко понимать что лучше и насколько лучше  в цифрах.

 

при желании то и свой модуль написать на первый взгляд не сложно, перл или питон - но мне с моими нанонагрузками хватает питона даже без попыток оптимизировать код

[sdy_moscow]

Не важно какое железо, на моем стенде я в итоге добился >10000 авторизаций в БД с выделением IP, регистрацией и ведением сессий, логами ошибок и т.п. за 5-10 сек на обычном любимом мной I7 c MySQL 5.7 в одном потоке - но это больше 40 хранимых процедур, несколько тысяч строк кода и своя БД под эту задачу.

На штатной схеме (я думаю) в лучшем случае будет 1000 авторизаций в минуту, прикиньте как будет весело когда у вас будет ребут в каком-то районе. Штатные схемы SQL и сам rlm_SQL - по мне не рабочая схема для хоть сколько-то значимого числа абонентов. А дальше у вас начнётся хардкор с погружением в SQL, модули фрирадиуса и unlang.

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

 

 

29 минут назад, sirmax сказал:

при желании то и свой модуль написать на первый взгляд не сложно, перл или питон - но мне с моими нанонагрузками хватает питона даже без попыток оптимизировать код

 

Это так только кажется, когда начинаешь погружаться в проблемы рассинхрона сессий,  ребутов, параллельных потоков, необходимости хоть как-то взаимодействовать с внешним миром - всё становится ГОРАЗДО сложнее, не случайно за биллинги люди денеК просят. Модули (методы) в фрирадиусе нужные уже все есть, но плохо документированы или вообще не описаны. Как сделать быстро - надо самому доходить и ковырять.

 

[sdy_moscow]

50 минут назад, Urs_ak сказал:

Я правда (тьфу*3) не разу не сталкивался как SSD серверные дохнут

Как обычно, когда в рэйде дохнут диски, начинается или тупняк, или просто отваливается 1 диск. Регулярный мониторинг - залог спасения от проблем. С SSD та же проблема что и с HDD, если в рэйде диски одного производителя или еще хуже из одной партии - то они имеют привычку дохнуть почти одновременно :-(.

[sirmax]

30 минут назад, sdy_moscow сказал:

Это так только кажется, когда начинаешь погружаться в проблемы рассинхрона сессий,  ребутов, параллельных потоков, необходимости хоть как-то взаимодействовать с внешним миром - всё становится ГОРАЗДО сложнее, не случайно за биллинги люди денеК просят. Модули (методы) в фрирадиусе нужные уже все есть, но плохо документированы или вообще не описаны. Как сделать быстро - надо самому доходить и ковырять.

У меня сейчас масштаб не сопоставим.
 

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

на тот момент когда я хоть как то погружался- у конторы было 16к абонентов 

 

в целом я с вами более чем согласен, если что, но повторю топикстартеру - без внятной методики тестирования я бы и не начинал.

 

[Ivan_83]

Вы для начала определитесь: нахрена вам нужна БД.

Если оно только для авторизаций/привязки адресов - это одна нагрузка, если туда ещё и аккаунтинг писать будет - другая.

И вроде как аккаунтинг можно и в другое место писать, в другую базу на другом сервере.

 

Вам уже дали ссылки, там где то я лет 10+ делился опытом сколько у меня запросов/сек отрабатывало на тогда уже отсосном дуалкоре E5300.

Сразу скажу что: "Пользователей до 50000" не означает даже близко что надо уметь 50к/сек запросов держать.

Скорее всего обычный рейт для авторизаций будет довольно низким, менее 1к/сек, и пики возможны когда после аварии сегмент подключили и все ринулись в авторизацию.

Но и при этом никакой проблемы нет если у вас сервер не будет тянуть больше условно 1к/сек, просто не все подключатся в первую секунду после восстановления связности, ну повисят минуту, ведь в минуте 60 секунд * 1к/сек = те уже в теории хватит на 60к юзеров.

Нюанс в том, чтобы запросы в очередь не ставить нигде, иначе оно однажды захлебнувшись уже не всплывёт.

В общем смотрите как там у вас в реале и сами прикидывайте.

 

 

6 hours ago, jffulcrum said:

Правда, надо знать древний запретный язык Perl хоть базово.

Врёшь ты всё.

Я когда его писал никого perl не знал, ни до ни во время ни после 🙂

 

 

4 hours ago, sdy_moscow said:

Не важно какое железо, на моем стенде я в итоге добился >10000 авторизаций в БД с выделением IP, регистрацией и ведением сессий, логами ошибок и т.п. за 5-10 сек на обычном любимом мной I7 c MySQL 5.7 в одном потоке - но это больше 40 хранимых процедур, несколько тысяч строк кода и своя БД под эту задачу.

Выглядит оверинженеред.

 

4 hours ago, sdy_moscow said:

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

Надо написать нечто на замену freeraduis на C+LUA с вменяемой логикой.

Но как всегда вопрос в деньгах 🙂

 

Я когда в freeraduis копался - там подходы ко всему сильно далёкие от того что в компьютерной индустрии, даже софт ISC хоть и жуткое легаси кажется не таким инопланетным как это поделие телефонистов.

[sdy_moscow]

3 часа назад, Ivan_83 сказал:

Надо написать нечто на замену freeraduis на C+LUA с вменяемой логикой.

Зачем? Там СИшная часть - вполне себе: и многопоточность, и конвейеры соединений, и тебе словари,  и unlang, и SOA реализовано, и буферизация запросов, и ещё куча фишек готовых. Сам по себе фрирадиус вполне неплох. Вся хитрость в схемах и настройках - дефолт это витрина, красиво, многообещающе, но не для продакшн. И логика настроек там вполне себе понятная + средств отладки более чем! Вот ДОКУМЕНТАЦИЯ у фрирадиуса - гуано и дефолтные конфиги объемные (т.к. функционал широкий), опять-же с прокси (не особо кому нужным) куча наворотов, но если выкинуть всё лишнее, то очень даже неплохо. Немного сложен только механизм вложений и вызовов модулей с их ответами, выходами и секциями, но и с этим можно разобраться. Зато опенсурс.

 

3 часа назад, Ivan_83 сказал:

Выглядит оверинженеред.

Оно так и есть - фактически получилось своё ядро авторизаций биллинга написанное на SQL. И подходы для SQL прям совсем (по мне) нестандартные использовались. Собственно оно в итоге и есть ядро авторизаций и аккаунтинга биллинга, ибо штатный старый ланбиллинг "утомил". А покупать очередных "котов в мешке" и потом ловить глюки годами с невнятной тех. поддержкой и без доступа к коду я больше не хочу.

[jffulcrum]

9 часов назад, Urs_ak сказал:

будет RAID 1

 

Плохо что-ли? 

Я правда (тьфу*3) не разу не сталкивался как SSD серверные дохнут

А я сталкивался неоднократно. В RAID1 ресурс с обоих носителей стачивается одновременно, и кончается тоже одновременно. Да, запас прочности там большой, в вашем случае DWPD 3, но всё можно уработать. RAID1 не для SSD точно.

 

В плане задержек для SATA дисков контроллер как отд.плата может и в плюс, если подключать его в слот PCIE от CPU. Набортные порты, да и даже контроллеры, обычно от южного моста идут. Но это если контроллер умеет отдавать диски как RAW, работая по-сути как HBA.

[tcup]

11 minutes ago, jffulcrum said:

В RAID1 ресурс с обоих носителей стачивается одновременно, и кончается тоже одновременно. Да, запас прочности там большой, в вашем случае DWPD 3, но всё можно уработать. RAID1 не для SSD точно.

Может просто счётчик байтов записанных одинаков, да контроллеры диска выставляют ошибку конца ресурса, а райд выплёвывает для замены, да сразу оба?

[jffulcrum]

В 3 лично исследованных случаях из 4-х никаких явных предупреждений не поступало, просто контроллеры внутри SSD +/- одновременно уходили в нирвану и диски пропадали из системы, возможно сталкиваясь с массовым отвалом областей под нагрузкой. Существуют инженерные утилиты, позволяющие в теории сбросить такой зависший диск, но данным в любом случае конец. Смарт у SSD вообще имеет два реальных показателя - NAND Writes bytes и PowerOn hours, дальше с учётом TBW считать в Excel, "кукушка кукушка, сколько мне осталось", и при исчерпании примерно 75% ресурса можно идти за новыми, т.к. во-первых, контроллеры дисков начинают беречь ресурс, вводя менее производительный профиль записи, во-вторых, ввиду оценочности показаний smart, ресурса могло остаться уже ещё меньше, и есть риск до замены не дотянуть. В четвёртом случае "кончились" DRAM-буферы в дисках, они тоже имеют ресурс, как оказалось, выяснилось это уже в гарантии, вероятно с помощью упомянутых утилит. Диски из системы не пропали, но записать на них уже ничего было нельзя.

[Ivan_83]

3 hours ago, sdy_moscow said:

Там СИшная часть - вполне себе: и многопоточность

Да не по человечьи всё там.

Ну вот что такое радиус: разобрать запрос авторизации, чего то дёрнуть и вернуть ответ, возможно с атрибутами.

Там же конфиг для этого какой то малость запутанный.

Анланг - вообще херня на постном масле: как язык весьма куцый и неудобный, больше его нигде нет. Практически латынь.

Аккаунтинг по идее ещё проще: получил, разобрал - закинул в базу. Но тоже там всё как то пососно сделано.

Ну типа да, оно как то там работает, но это знание вообще оторвано от всего что есть вокруг и практически никак и ни с чем не пересекается.

 

3 hours ago, sdy_moscow said:

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

Я к тому, что такое придётся либо сильно документировать либо оно умрёт или от того что автор свалит или автор сам забудет как оно устроено через пару лет.

 

[sdy_moscow]

37 минут назад, Ivan_83 сказал:

...

Там же конфиг для этого какой то малость запутанный.

Анланг - вообще херня на постном масле: как язык весьма куцый и неудобный, больше его нигде нет. Практически латынь.

 

Аккаунтинг по идее ещё проще: получил, разобрал - закинул в базу. Но тоже там всё как то пососно сделано.

 

Я к тому, что такое придётся либо сильно документировать либо оно умрёт или от того что автор свалит или автор сам забудет как оно устроено через пару лет.

 

Ценность фрирадиуса - это готовые механизмы работы  между сетевым уровнем и БД с полным фаршем. Нет смысла это переписывать, если оно  работает.

Конфиг  и анлэнг просты и понятны, если разобраться. Там сам подход не совсем очевидный.

 

Аккаунтинг как раз не так просто, если предположить, что могут быть потери пакетов START STOP и ребуты как на стороне NAS так и RADIUS.

 

Да, без документации это не продукт, но я его пока и не планирую никуда. Так, просто в тему пришлось.

[trksergey]

Цитата

 

Не важно какое железо, на моем стенде я в итоге добился >10000 авторизаций в БД с выделением IP, регистрацией и ведением сессий, логами ошибок и т.п. за 5-10 сек на обычном любимом мной I7 c MySQL 5.7 в одном потоке - но это больше 40 хранимых процедур, несколько тысяч строк кода и своя БД под эту задачу.

На штатной схеме (я думаю) в лучшем случае будет 1000 авторизаций в минуту, прикиньте как будет весело когда у вас будет ребут в каком-то районе. Штатные схемы SQL и сам rlm_SQL - по мне не рабочая схема для хоть сколько-то значимого числа абонентов. А дальше у вас начнётся хардкор с погружением в SQL, модули фрирадиуса и unlang.

 

Так какие характеристики у железа?

 

Поделитесь, опытом, что стоит и сколько висит клиентов. 

 

Цитата

Вы для начала определитесь: нахрена вам нужна БД.

Если оно только для авторизаций/привязки адресов - это одна нагрузка, если туда ещё и аккаунтинг писать будет - другая.

Сначало планируем PPPoE. В основном авторизация. Аккаунтинг  - start-stop для СОРМ.

[sdy_moscow]

3 часа назад, trksergey сказал:

Так какие характеристики у железа?

 

Поделитесь, опытом, что стоит и сколько висит клиентов. 

 

Сначало планируем PPPoE. В основном авторизация. Аккаунтинг  - start-stop для СОРМ.

Стоит на стенде I7 12700 c 16Гб памяти и SSD 512 raid1. Планируется под 20К с запасом до 50К абоннетов. Сейчас трудится Ланбиллинг на древней железке - любой ребут  - тупняк минут на 20, периодически виснет их софт.

Для СОРМ - мы просто зеркалируем им RADIUS трафик

[trksergey]

Спасибо.