NiTr0

Да-да, 40А от зарядника на аккумы выдавать...

Упсы с нормальным ВЧ инвертором внутри вместо 50Гц трансформатора. Если у вас цель питать микротик с медиком - скорее всего микроваттовских с головой хватит. Если не требуется мониторинг и т.п. Или вообще минвел взять, с 12В или 24В выходом, + понижающие преобразователи навешать...

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

Дедлок не должен появляться. Ибо лок вызывается только в auth.pm, в одном месте кода, и сразу на всю таблицу сессий. А дедлок вылезает в acct.pm - где нет ни локов, ни транзакций, ибо нет сложных операций.

А не подумывали ли что-то более адекватное чем МТ, заюзать? Ну хотя бы линь какой, или бздю на крайняк... Чтобы с подземными стуками тика не бороться методом перебора опций конфига...

Ну мускул всяко надежнее для хранения, чем таблица в памяти, умирающая вместе с процессом. А критичность статуса ип адресов (свободен/занят) - вроде как и невысокая, но и не нулевая. Потому как если двум клиентам выдается один и тот же ип - начинаются проблемы у клиентов, и много возмущений.

Сохранение статуса при каждом изменении объекта - да, это нормально. Для критичных данных. И получение статуса из базы каждый раз - это тоже нормально для критичных данных. Особенно - если планируется когда-нибудь строить отказоустойчивый кластер, или балансировать нагрузку. А делать заведомо немасштабируемую систему, которая допускает возможность утери важных данных при краше - это ненормально. Дедлок таки проскакивает в аккаунтинге, если радиус собран с поддержкой потоков (как в дебиане). Но откуда он вылазить может - я не представляю, негде ему там взяться вроде бы... 2014-10-2

Ну я ж и грю - как минимум переписывать mysqlclient библиотеку...

А кроме фильтров - еще в райпе прописать ассет, и пнуть аплинка на всякий чтобы обновил...

Покажи мне асинхронный MySQL запрос Я что-то не припомню таковой реализации в мускуле, как и в других СУБД. Опять же, другой работой заняться не получится особо - потому как ничего читать-писать из таблицы сессий/ип адресов не выйдет в это время, придется ждать.

Не в производительности счастье. Тазики еще производительнее. Но их что-то в энтерпрайзе на роутинг не ставят.

Логика и так в отдельном процессе. А вы предлагаете вынести из СУБД именно хранение текущего актуального состояния в отдельный процесс. Из которого запихивать данные в СУБД раз в N времени и надеяться, что процесс не упадет и сохраненные данные о состоянии не потеряются. Что есть бредом. Не, понятно, оно будет работать быстрее - но кому нужна скорость в ущерб надежности? Куда гоняли? SQL - это не обращение к дисковой подсистеме в общем-то, уже давным-давно СУБД обзавелась кешами, из которых все и читается. А сохраняется на диск только статус. Но - да, при каждой его смене, а не ра

Дык а кто вам сказал, что SQL - это I/O? А главное - как вы SQL асинхронным-то сделаете, если это даже I/O? Свой SQL сервер напишете, с асинхроннстью и однопоточностью? Итоги подведем: никакого i/o активного нет и в помине (запрос в 5 секунд) - значит, асинхронность в один поток есть бред. Для сети в 300-500 человек - да, пофиг какой говнокод А если радиус будет обрабатывать эдак 500+ запросов в секунду? С чего бы это не прижились? Вполне себе прижились, и активно используются. В том же rlm_perl

http://www.ebay.com/itm/Cisco-WS-C6506-E-Switch-Bundle-W-WS-C6506-E-FAN-2-WS-SUP720-WS-CAC-3000W-DD-/231284457867?pt=US_Network_Switches&hash=item35d9a0c18b к примеру - нищебродский железный бордер/ядро для тех, кто не любит готовить тазики. Хоть и фулл целиком не влезет, и жрет как калорифер - но в первом придлижении вполне юзабельна.

Ну разве что )))) Только аплинков-то 2, а значит дефолт не катит.

А с чего вы взяли, что все упирается в i/o, а не в CPU? А главное - как предлагаете с SQL запросами быть? Мускул клиент вроде как не предлагает асинхронный обработчик. А главное - в итоге получится стремная солянка, которая крутится на одном ядре, и распараллелить которую невозможно без полного переписывания с нуля... К слову, перловые потоки таки нормальные потоки. http://letsgetdugg.com/2009/04/19/fun-perl-benchmark/ в помощь если не верите. То на питоне из-за GIL с потоками грусть-печаль

А в чем годнота? В отсутствии масштабируемости?

С какой это радости - не должно быть? Т.е. однопоточная обработка запросов в порядке очереди - это хорошая, годная практика? Обычно есть поток-менеджер, и потоки-воркеры, на которые менеджер раскидывает задания...

Ну и куда его, с егойными 16к маршрутов? В 16к даже Украина не влезет ЕМНИП... Как балансировать-то трафик по двум каналам на нем? А главное - нафига строить ядро сети на свиче, максимум годном на агрегацию? А по сабжу - первый признак того, что где-то затык - низкая скорость одиночной tcp сессии (к примеру - низкие показатели спидтеста). И да, эти показатели в принципе нормальны для такого онлайна.

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

А с чего вы взяли, что логика в СУБД? В СУБД только хранилище активных сессий и собссно пулов. Логика вся в перле (составление карты адресов для пулов, исключение из карты адресов уже занятых сессиями, и соответственно занесение в БД новой сессии). Из-за чего и локи таблиц Ну и да, в той же гидре логика в СУБД вся. Из-за чего она и применяется при больших нагрузках...

Из файловой системы Прекрасно, пилим свою нескучную СУБД, которая будет вести таблицу выделенных адресов в файле... Так вот, auth.pm - это и есть плагин радиус-сервера, который выдает адреса

Прекрасно. Сервис падает (OOM, глюк железа, плановый перезапуск - неважно), и поднимается немного погодя. Где брать актуальную инфу о выданных адресах? Лезть в БД, от использования которой якобы ушли? И ничего, что таковым сервисом по всем правилам должен являться радиус-сервер (ибо это, наряду с авторизацией - его основная задача)? Не, можно конечно и к примеру memcached использовать в качестве хранилища временной "таблицы" адресов, и свой нескучный велосипед напилить, но все же проблм с этим огрести можно больше, чем получить профита.

Что под этим имелось ввиду?

Не совсем корректно. Приоритет пулов нечеткий получается...