Jump to content

Масовий ресет


Recommended Posts

За яких обставин (налаштувань) може відбуватися масовий ресет?

NAS і Ubilling(0.7.0 rev. 4720) на окремих серверах. Користувачів 470. Сьогодні пару абонентів подзовинили і повідомили що у них пропав Інтернет.

Перевіряю  таблицях ipfw на NAS - IP прописане в таблицях 3 і 4, а от pipe для цього IP є тільки до таблиці 3 а до 4 нема. І так по кожному абоненту. В логах allconnect.log на NAS - масовий ресет користувачів з часу до двух ночі. При чому якраз на цих користувачах, що не прописалися pipe вискакували помилки:

Warning: mysql_connect(): MySQL server has gone away in /etc/rscriptd/GetUpSpeed on line 5
 
Warning: mysql_connect(): Error while reading greeting packet. PID=40025 in /etc/rscriptd/GetUpSpeed on line 5
 
Warning: mysql_connect(): MySQL server has gone away in /etc/rscriptd/GetUpSpeed on line 5
 
Warning: mysql_select_db(): No such file or directory in /etc/rscriptd/GetUpSpeed on line 6
 
Warning: mysql_select_db(): A link to the server could not be established in /etc/rscriptd/GetUpSpeed on line 6
 
Warning: mysql_query(): No such file or directory in /etc/rscriptd/GetUpSpeed on line 8
 
Warning: mysql_query(): A link to the server could not be established in /etc/rscriptd/GetUpSpeed on line 8
 
Кожному з цих абонентів я зробив ресет вручну - все працює. Але чому могла виникнути така ситуація. Раніше такого не помічав. Ніяких серйозних змін в системі не робив, крім оновлення Ubilling. Правда вночі пропадав канал із шлюзом пару раз і як раз приблизно в цей час. Але хіба при падінні каналу зі шлюзом повинен відбуватися масовий ресет? Перевірив в логах піврічної давності - такого не спостерігалося. В alter.ini MASSRESET_ENABLED=0
Link to post
Share on other sites

 

 

NAS і Ubilling(0.7.0 rev. 4720)

Доброго дня панове некрофіли.

 

http://wiki.ubilling.net.ua/doku.php?id=faq

 

Q: У вас так часто выходят релизы, обновляться объязательно?
A: Да. Что платной, что бесплатной поддержке подлежат только текущие версии Ubilling с ревизиями равными или большими ревизии последнего стабильного релиза. Обновления для того и выходят, чтобы вы любимые наши, не напоминали нам о багах исправленных еще год назад. И нет - предложения о портировании новых модулей в ваш «старый любимый 0.2.8» тоже не рассматриваются.

 

 

 

Кожному з цих абонентів я зробив ресет вручну - все працює. Але чому могла виникнути така ситуація.

Написано ж англіцьким по білому

 

 

 

MySQL server has gone away

 

 

 

Але хіба при падінні каналу зі шлюзом повинен відбуватися масовий ресет?

Дивлячись, шо ви розумієте під "масовим ресетом". Очевидно далеко не те, чим воно є насправді. В такому випадку, остаточно не зрозуміло, чому ви намагаєтесь оперувати невідомою вам термінологією, і при цьому сподіваєтесь, що хтось буде вгадувати, в чому ваша проблема і як в вас побудовано взаємодію з NAS-ами.

Link to post
Share on other sites

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

ну и да, загадка что ж там с бд такого происходит

Link to post
Share on other sites

Під "масовим ресетом" я мав на увазі масове відключення всіх користувачів і повторне їх включення за дуже малий проміжок часу. В прикріпленому файлі - лог цих подій(з allconnect.log).

allconnect.txt

Схоже дійсно на те як сказав l1ght - втрачається звязок між білінгом і насом, я дійсно і раніше спостерігав при падінні каналу перших секунд 10-20 не маю доступу до сервера з насом. Що відбувалося з бд в той час не можу сказати, логування в mysql не було включено.

А на рахунок, як побудована взаємодія з NAS, то як описано в рекомендціях до Ubilling так і зробив. Два сервера, на обох intel i350-t4, один інтерфейс NAS аплінковий, інший - на обонентів і біллінг. Установлював і біллінг і NAS зі скриптів інсталяторів, що вказані в документації до Ubilling.

Link to post
Share on other sites

 

 

Під "масовим ресетом" я мав на увазі масове відключення всіх користувачів і повторне їх включення за дуже малий проміжок часу. В прикріпленому файлі - лог цих подій(з allconnect.log).

Як водиться просто дісконнект при втраті зв'язку між rscript та біллінговим сервером. Це штатна поведінка - так і має бути. Має це якесь відношення до події "ресет"? Ні - не має. Має це якесь відношення до старої механіки примусового массресету? Ні - не має. А ви собі продовжуйте розуміти як хочете.

 

 

 

А на рахунок, як побудована взаємодія з NAS, то як описано в рекомендціях до Ubilling так і зробив. Два сервера, на обох intel i350-t4, один інтерфейс NAS аплінковий, інший - на обонентів і біллінг.

Ну про існування зовнішнього NAS-у з rscript очевидно, з вигляду оригінальної теми треба було здогадуватись. Окей - повгадували. Далі шо?

Або осильте хоч якийсь стабільний лінк між біллінгом та НАС-ом(нормальний варіант), або крутіть таймаут в rscriptd.conf (ублюдський варіант) - більше вам порадити нічого.

Link to post
Share on other sites

Дякую за поради. 

До речі, про існування зовнішнього NAS-су, я написав ще в першому пості

 

 

NAS і Ubilling(0.7.0 rev. 4720) на окремих серверах.
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 camchatix
      Добрий день,
      створили запасний NAS із зайвою хромосомою, все працює але коли треба вбити сесію користувача - то у списку NAS серверів лише один (той що основний)
      переназначити швидкість теж не можу
      я так розумію пакети CoA Disconnect, CoA connect, PoD - ідуть на IP адресу старого NAS ?
    • By grach_witch_cheese
      Вітаю, колеги!
      Маю наступну схему:
      DHCP-сервер: Accel-PPP (IPoE) DHCP-Relay: MikroTik RADIUS: Запущений безпосередньо на сервері uBilling Зараз авторизація абонентів здійснюється за MAC-адресою, але планується перехід на авторизацію через Option 82.
      У документації uBilling наведені приклади конфігурацій, коли DHCP-сервер працює локально (на самому uBilling) і містить відповідні шаблони для обробки Option 82.
      Однак немає чіткої інформації про використання Option 82 при віддаленому DHCP-сервері, зокрема, коли Accel-PPP використовується як DHCP-сервер у режимі remote та налаштований через Купаген.
      Питання:
      Чи можливо використовувати Accel-PPP як віддалений DHCP-сервер з авторизацією через Option 82? Якщо так, то де відбувається парсинг значень Remote-ID і Circuit-ID? Де в цьому випадку мають зберігатися шаблони для Option 82? Буду вдячний за роз'яснення або посилання на відповідні приклади.
    • By nightfly
      Ubilling 1.5.2 rev 9302 Book of Endings
       
      Зміни в структурі БД. alter.ini: нова опція FASTPROFITCALC_ENABLED, що вмикає швидкий підрахунок прибутку. alter.ini: нова необов'язкова опція KARMA_IN_PROFILE що вмикає показ карми в профілі користувача. alter.ini: нова опція SWITCHES_AUTH_ENABLED, що вмикає довідник даних авторизації пристроїв. alter.ini: нова опція PON_SCRIPTS_ENABLED, що вмикає підтримку скриптів OLT в ПОНізаторі. alter.ini: нова опція PON_ONU_FDB_SELFFILTER, що вмикає фільтр MAC-ів при відображенні FDB за ONU. alter.ini: нова опція USERBYIP_ENABLED, що вмикає виклик userbyip в RemoteAPI. alter.ini: пачка нових опцій PB_FASTURL_*, що керують поведінкою модулю відсилання коротких посилань на оплату. Модуль PONizer: виправлена помилка зникнення PON інтерфейсів при опиті BDCOM GP3600 Модуль “Профіль користувача”: для опису плагінів профілю та оверлеїв на кшталт “чорної магії” тепер опційно можливо вказувати link_target. Модуль “Панель задач”: для опису елементів панелі задач, тепер опційно можна вказувати LINK_TARGET. Модуль Записи телефонних розмов: вирішено проблеми швидкодії, при перегляді списку записів дзвінків. Модуль “Записи телефонних розмов”: більше не призводить до вичерпання пам'яті процесу, при перегляді великих архівів дзвінків. Модуль “Записи телефонних розмов”: новий аудіо-плеєр для прослуховування записів з візуалізацією аудіо-хвилі. Модуль “Пошук оплат”: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модуль УКВ: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модулі Мапа обладнання та користувачів: трішки вичищено код. Ліпше не стало. Модуль “Мапа будинків”: поле пошуку при розташуванні будинку, тепер попередньо заповнено локацією, при переході за посиланням “розташувати на мапі”. Модуль “Панель задач”: опція TB_QUICKSEARCH_INLINE змінила свою поведінку, та може тепер приймати значення 0|1|2. Модуль “Звіт по трафіку”: виправлено проблему відображення графіків OphanimFlow для NAS на роздільних здатностях менше ніж FullHD. Кабінет користувача: в модулі “Відеоспостереження” відображення попереднього перегляду каналів користувача, стало трішки притомнішим. Сховище зображень: трішки покращено поведінку форми завантаження. RemoteAPI: новий виклик onusigcompressor, що радикально стискає розпухаючі дані історії сигналів ONU. RemoteAPI: новий виклик pbxmonrefill, що оновлює кеш записів телефонних розмов. RemoteAPI: новий виклик userbyip, що повертає дані про користувача за його IP. OpenPayz: в бекенді та фронтенді platon виправлено проблему диких заокруглень, при вказанні зовнішньої комісії.  
      Повний чейнджлог
      Оновлена демка
       

    • By ppv
      Після оновлення до 1.5.1 не відображаються сигнали на
      OLT BDCOM P3310B (Device version10.1.0B)

      та
      P3608-2TE (Firmware Version10.1.0E). 

      3310C та P3608B ніяких проблем немає, знімає все добре. 
      З GPON3600-8 все зрозуміло будуть виправлення в Ubilling: 1.5.2.
       
      Може в когось було щось подібне? Хочу знати куди копати.
    • By mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

×
×
  • Create New...