BiTel

Биллинг версии 5.0, ОС Linux Ubuntu 9.0, установлены последние апдейты.
вер. 5.0 сборка 241 от 12.10.2010 12:44:02
dialup вер. 5.0 сборка 243 от 10.08.2010 13:32:48
ipn вер. 5.0 сборка 260 от 24.11.2010 10:47:43
npay вер. 5.0 сборка 227 от 08.10.2010 19:03:15

NAS Cisco 7206VXR NPE-G1, PPPoE абоненты, в онлайне около 100 абонентов.
Сервер биллинга DELL PE 2950, 2x CPU 4xCORE 2Ghz, 12Gbyte RAM, процессоры загружены на 5-10% в пиках.

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

Результаты команды статуса радиуса в момент проблем:
(немного могу ошибаться с цифрами, вставил на память, но в общем картина верная)

root@BGBill:/usr/local/BGRadiusDialup# ./radius_status.sh
version 5.0 build 298 from 09.12.2010 18:59:44
18.12.2010 15:24:25 113 77 53 12
Request accounts per minute start: 1; stop: 2; update: 78
Request auths per minute accept: 53; reject: 0
Netfow packets per minute: 496
Ignore per minute auth: 53; update: 0
Antispam ban count: 0; used per minute: 0
Started: 17.12.2010 17:23:16 Uptime: 0 d 22:01:09
Memory total: 17 825 792; max: 1 431 699 456; free: 1 992 584
Trees in cache: 17
Connections pool to Master status Idle: 10; Active: 313; maxActive: 500; maxIdle: 40
root@BGBill:/usr/local/BGRadiusDialup#

Параметр Active: 313; после обрыва сети равен нулю, потом растет до цифры 313-318 и стоит на месте.

Настройки radius.properties:
db.maxIdle=40
db.maxActive=500
auth.thread.count=110
acct.thread.count=110
auth.thread.must.be.free.count=10
acct.thread.must.be.free.count=10
То есть тут все корректно, согласно рекомендациям документации и разработчиков.

Параметр ulimit в ОС настроен корректно. 8192 открытых файлов, ошибок на нехватку сокетов нет.

Но, при вводе команды netstat -n видно большое количество строк с CLOSE_WAIT, они обусловлены
работой скрипта, который выполняет след функции:
По событию авторизации абонента он берет его IP адрес и по SSH сессии загоняет его в RouterOS, тем самым
открывая этому IP адресу доступ во внешку. При отключении абонента по событию Таймер он заносит
его IP адрес в блок лист, закрывая этому адресу доступ во внешний мир. Сделано это для ликвидации
паразитного трафика с внешних сетей в то время, когда абонент не находится в онлайне.

До последнего момента вся схема работала нормально. При этом кол-во абонентов в онлайне не превышало 60-70.
Как только их кол-во приблизось к 100 и больше, начались такие проблемы.

Ребут радиуса не лечит проблему. Ребут всего сервера не помогает. Ребут NASа тоже НЕ помогает.
Проходит определенное время, около 30 минут, проблема рассасывается, за 10 секунд все абоненты авторизовываются.

Если радиус обрывает сессии на границе месяца, то этой проблемы НЕ наблюдается, все происходит корректно.

Пробовали остановить работу этого скрипта, дергали пару раз сеть, не помогло.

Не знаем, куда рыть. Спасибо заранее за оказанную поддержку. Если что надо выложить, сделаем.

у меня такое же было и не раз, объяснили тем что радиус просто при таком потоке загибается, восстанавливается сам минут через 10-15

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

100 одновременно ломящихся абонентов - это разве много для этого радиуса? Это же мизер.
У нас большинство сидят на IPN.

И почему в течении получаса никто не может авторизоваться? Если бы очередь рассасывалась,
то было бы все понятно. А она не рассасывается.

Память вроде не вся съедена, коннекты к базе - тоже. Странно. Когда скрипт отключали, делали ./radius.sh flush_script_cache либо ребут радиуса?

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

Думаете, стоит попробовать?

Ну, когда скрипт меняется, точно нужно это делать, т.к. они кэшируются. При снятии галки - это нужно у разработчиков спросить.

Посмотрел - нужно, т.к. тоже кэшируется похоже:

public void flushCache()
{
this.scriptCache.clear();
this.scriptLibraryCache.clear();
FunctionManager.resetFunctionCache();
}

(с) dialup.jar

Спасибо. Мы завтра же, в первый рабочий день, проверим.

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

А в script.log время выполнения скрипта на событие авторизации не смотрели?
Process time => ms

Разборки показали следующее:

Согласно доке:
Скрипты обработки RADIUS запросов кэшируются RADIUS сервером при первом исполнении. Для сброса кэша необходимо перезапустить RADIUS сервер либо выполнить команду в каталоге RADIUS сервера.
Для LINUX:
./radius.sh flush_script_cache
Стало быть это касается только скрипт обработки радиус запросов, они вписываются в конфу НАСа и кэшируюся для скорости обработки.
Скриты по событию - это другое и кэш тут ни причем.

Мы правильно разобрались?

Не смотрели...
Посмотрим. Какое время является нормальным?

Нет, они тоже кэшируются. Проверено на собственном опыте.

У нас это порядка 8-25 ms

В общем, посмотрели мы время работы скрипта,

Время выполнения скрипта по событию радиус- авторизации от 1000 мс до 3000....

Это много?

Вот сам скрипт:
import bitel.billing.server.radius.*;
import bitel.billing.common.*;
import bitel.billing.server.util.ssh.*;
adrl="deny_parazit_all";

response = event.getResponse();
sip=IPUtils.convertIpToString(response.getIntAttribute( 8 ));
login = "ХХХ";
timeout = 0 ;
pswd = "ХХХ";
String host = "ХХ.ХХ.ХХ.ХХ";
port = 22;
try
{
mysession = new SSHSessionExec( host, port, login, pswd );
mysession.setTimeout( timeout );
address_list = mysession.command( "ip firewall address-list print without-paging where list=" + adrl );
if (address_list.indexOf(sip+" ")>-1){//probel dlya tochnogo poiska
str_find = "/ip firewall address-list find address=\"" + sip + "\" list=" + adrl; cmd_ssh = ":if ([:len [" + str_find + "]] > 0) do={/ip firewall address-list remove [" + str_find + "]}";
result = mysession.command( cmd_ssh );
print("removed IP="+sip);

}


}
catch( Exception e )
{
throw new RuntimeException( e );
}
finally
{
}

Кто там что про прогноз погоды по каждому пакету радиуса говорил?

Поднимать SSH-сессию - дорогое удовольствие. 1-3 секунды - очень много. Скрипт работает синхронно, поэтому всё, что не требуется для дальнейшей процедуры авторизации, должно выполняться асинхронно. Например, можно писать в определённую собственную табличку задания и выполнять их каким-нибудь другим процессом, постоянно проверяя её. Внутренняя шина событий в биллинге сейчас так и работает. Или отправлять задания в собственный брокер ActiveMQ, выполняя их потом сторонней прогой или скриптом.
Но это всё сложно.

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

ps. А может вообще отказаться от хождения на роутер при каждой авторизации

В общем... Отключили события скрипта, выполнили команду очистки кэша радиуса,
дернули опорный линк... Дождались пока все абоненты скинулись с циски по keep-alive (1 минута).
Подключили линк снова.

За 5 секунд все абоненты свободно авторизовались одним махом... Никаких проблем не было замечено...

За подсказку, как чистить скриптовый кэш, спасибо огромное, теперь хоть понятно куда рыть.