Jump to content
Local
AoW

Проблема с НАСом

Recommended Posts

Добрый день!

Шлюз управляется через remote script ex....от стг. Все правила построены на основе айписет-а. Ситуация следующая возникает: время от времени абонент удаляется из разрешающего списка, даже те кто стоит со "всегда он-лайн" помогает переподключение авторизатором или ожидание в случае с "всегда онлайн". Кто то сталкивался с таким?

Share this post


Link to post
Share on other sites

Такое поведение возможно аж в двух случаях - либо rscripd теряет связь с mod_remote_script либо слишком медленно выполняются OnConnect/OnDisconnect и до соединения всех нужных абонентов проходит таймаут отвала.

Попробуйте увеличить количество ExecutersNum для rscriptd скажем до 2 - при тяжелых OnConnect/OnDisconnect может возыметь действие. Хотя да - лучше их облегчить.

 

ЗЫ Версия надеюсь 2.407+? В 2.406 пользователи начинали отваливаться уже чисто по количеству. В более поздних madf там очень много чего пофиксил.

Share this post


Link to post
Share on other sites

а что означает usertimeout в конфиге рскрипта?

а может спасет SendPeriod в настройках стг?

Share this post


Link to post
Share on other sites

Могут и помочь - но корень зла всегда кроется в сверхмедленно выполняющихся OnConnect/OnDisconnect, в этом случае наиболее ефективным решением выглядит таки увеличение количества ExecutersNum а также естественно оптимизация логики в стартующем при коннекте веселье.

Share this post


Link to post
Share on other sites

UserTimeout - время через которое абон будет отключен если по нему не приходит alive-пакетов.

SendPeriod - периодичность отсылки alive-пакетов.

В общем случае увеличение UserTimeout и уменьшение SendPeriod должно помочь, но судя по вашей симптоматике у вас проблема в другом месте.На сколько я понял, после отключения они назад сами не подключаются?

Share this post


Link to post
Share on other sites

нет, абонент назад возвращается, спустя минуту - две

Share this post


Link to post
Share on other sites
нет, абонент назад возвращается, спустя минуту - две

Да, походу наблюдал такое еще на 2.406 при >600-800 юзеров на 1 NAS, в 2.407 пофиксилось более менее но всеравно ExecutersNum=2

 

Более 1.2-1.5к и сейчас не держу но упирается больше в количество трафика и продуктивность железа при таком pps. Размазывать абонентов по большему количеству тазиков попроще вместо закладывания всех в один атомный реактор - религия такая.

Share this post


Link to post
Share on other sites

нет, абонент назад возвращается, спустя минуту - две

Тогда проблем нет - увеличивайте UserTimeout, уменьшайте SendPreriod (тут осторожно) и проверяйте канал связи между NAS и биллингом на потери.

Share this post


Link to post
Share on other sites

Да, еще как правильно заметил nightfly, в случае "тяжелых" скриптов имеет смысл увеличить ExecutersNum до 2-3. Ну или даже больше - тут надо мониторить ситуацию.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Какие точные значения UserTimeout и SendPeriod сейчас? Есть ли потери пакетов между биллинговым сервером и NAS? Какая версия Stargazer?

Share this post


Link to post
Share on other sites

Пинги

 

root@bill:/etc/stargazer# ping 192.168.1.10 -f

PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.

192.168.1.10 ping statistics 19120935 packets transmitted, 19120934 received, 0% packet loss, time 3146574ms

rtt min/avg/max/mdev = 0.032/0.121/22.083/0.207 ms, pipe 2, ipg/ewma 0.164/0.381 ms

 

 

 

rscriptd.conf

 

UserTimeout=60

 

 

 

stargazer.conf

 

 

 

Module remote_script

SendPeriod = 10

 

Module auth_ia

Port = 5555

UserDelay = 60

UserTimeout = 200

FreeMb = cash

 

 

 

 

 

Stg v. 2.407-p1

Storage plugin: mysql_store v.0.67

CAP_NF v. 0.4

Remote script v 0.3

InetAccess authorization plugin v.1.4

Always Online authorizator v.1.0

Pinger v.1.01

Stg configurator v.0.08

 

Share this post


Link to post
Share on other sites

В rscriptd.conf UserTimeout можно смело поднимать в 2-3 раза. Если абонов много - возможно придется поднимать SendPeriod. А так вроде все нормально.

Share this post


Link to post
Share on other sites

Хозяйке на заметку - если при коннекте происходят какие-то SELECT-ы по БД, добавьте по всем полям из WHERE индексов. Это целительно - честно :)

Share this post


Link to post
Share on other sites

Хозяйке на заметку - если при коннекте происходят какие-то SELECT-ы по БД, добавьте по всем полям из WHERE индексов. Это целительно - честно :)

 

Поля индесованные )))

Share this post


Link to post
Share on other sites
Поля индесованные )))

я в вас верил :)

Share this post


Link to post
Share on other sites

добрый день!

Хотел дописать заглушку для должников, и встретился с тем, что OnChange не выполняется при использовании Remote Script. Это правда?

Share this post


Link to post
Share on other sites

Да. Поэтому он нигде не используется в ubilling.

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

Share this post


Link to post
Share on other sites

Добрый день!

Заглушку решили, релиши добавить еще один НАС, но споткнулись. итак:

 

 

root@bill:/etc/stargazer# cat subnets

192.168.8.0/22 192.168.1.10

192.168.12.0/22 192.168.1.10

192.168.16.0/22 192.168.1.10

192.168.8.0/22 192.168.1.3

192.168.12.0/22 192.168.1.3

192.168.16.0/22 192.168.1.3

 

stargazer.conf

<Module remote_script>

 

SendPeriod = 10

SubnetFile = /etc/stargazer/subnets

Password = *******

UserParams = Cash Tariff EnabledDirs

Port = 9999

</Module>

 

 

root@bill:/etc/stargazer# iptables-save | grep 192.168.1.3

-A INPUT -s 192.168.1.3/32 -d 192.168.1.1/32 -p tcp -m tcp --sport 9999 -j ACCEPT

-A INPUT -s 192.168.1.3/32 -d 192.168.1.1/32 -p udp -m udp --sport 9999 -j ACCEPT

-A OUTPUT -s 92.168.1.1/32 -d 192.168.1.3/32 -p tcp -m tcp --dport 9999 -j ACCEPT

-A OUTPUT -s 192.168.1.1/32 -d 192.168.1.3/32 -p udp -m udp --dport 9999 -j ACCEPT

 

при этом:

 

 

root@bill:/etc/stargazer# tcpdump -n -i eth2 | grep 192.168.1.10

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes

15:05:26.623321 IP 192.168.1.1.36820 > 192.168.1.10.9999: UDP, length 1048

15:05:26.623458 IP 192.168.1.1.36820 > 192.168.1.10.9999: UDP, length 1048

15:05:26.623470 IP 192.168.1.1.36820 > 192.168.1.10.9999: UDP, length 1048

15:05:26.623549 IP 192.168.1.1.36820 > 192.168.1.10.9999: UDP, length 1048

15:05:26.623634 IP 192.168.1.1.36820 > 192.168.1.10.9999: UDP, length 1048

15:05:26.623711 IP 192.168.1.1.36820 > 192.168.1.10.9999: UDP, length 1048

 

а вот :

 

root@bill:/etc/stargazer# tcpdump -n -i eth2 | grep 192.168.1.3

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes

15:05:55.066401 IP 192.168.1.3.50817 > 192.168.1.1.42111: UDP, length 120

 

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

и в довесок:

 

root@192.168.1.3:~# cat /etc/rscriptd/rscriptd.conf

LogFileName=/var/log/rscriptd.log

ExecutersNum=1

ConfigDir=/etc/rscriptd

Password=*******

Port=9999

UserTimeout=300

ScriptOnConnect=/etc/rscriptd/OnConnect

ScriptOnDisconnect=/etc/rscriptd/OnDisconnect

 

 

Кто-что думает по этому поводу?

Share this post


Link to post
Share on other sites

Reload после добавления делали?

Share this post


Link to post
Share on other sites

А, понял. Вы не соблюли формат файла. Должно быть так:

192.168.8.0/22 192.168.1.10 192.168.1.3
192.168.12.0/22 192.168.1.10 192.168.1.3
192.168.16.0/22 192.168.1.10 192.168.1.3

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By 9at0z
      подскажите, в личном кабинете в "Платежные карты" когда вводишь номер карты, нажимаешь кнопку "Использовать карту"  то если быстро несколько раз нажать то получается задвойка, картачка ложится на баланс 2 суммы, и в деньгах в профиле 2 одинаковых карты. как исправить?
    • By revomix
      Привет, используем модуль CORPS, проблема с добавление денег через платежные системы, добавляються деньги только основному пользователю, хотя если из билинга добавлять деньги то добавляються всем связаным пользователям, подскажите как исправить?
    • By cetim
      Если сменить view при формировании платежного ID , чем это чревато со стороны приема платежей (кроме недовольства пользователей) ?
    • By mac
      Добрый день.
      Можно ли задать очередность инициализации NAS-ов после рестарта сервера биллинга?
       
      Вобщем вот в чем проблема в моем случае.
      Схема сети: Local NAS Ubilling <-OpenVPN tunnel-> Remote NAS Mikrotik
      Допустим по какой-то причине нет связи с Remote NAS Mikrotik.
      Теперь если сделать рестарт сервера Local NAS Ubilling, то Ubilling пытается в первую очередь проинициализировать Remote NAS Mikrotik.
      И делать это он будет ну очень долго.
      А делать это как-бы и не нужно пока: если Remote NAS Mikrotik уже был инициал. (пусть сейчас и нет связи с биллингом) - абоненты в списке ALLOW есть и интернетом они пользуются,
      а если выключен и/или с ним нет связи - то инициализация списков и т.д. не имеет смысла.
      При этом в Local NAS пока еще ipfw таблицы и пайпы не заполнены и еще долго не будут заполнены, и у абонентов доступа в Интернет нет.
       
      Можно ли как-то задать приоритет инициализации для локального NAS более высокий, чем для Remote NAS ?
      Спасибо
    • By cetim
      Добрый день. Подскажите пожалуйста возможно ли настроить ubilling для снятия абонплаты различными способами ("размазанная" и раз в месяц). В данный момент работает ежедневное снятие.
×