Перейти до

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


Рекомендованные сообщения

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

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
Ссылка на сообщение
Поделиться на других сайтах

 

 

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-ами.

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

allconnect.txt

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

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

Ссылка на сообщение
Поделиться на других сайтах

 

 

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

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

 

 

 

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

 

NAS і Ubilling(0.7.0 rev. 4720) на окремих серверах.
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від 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 виправлено проблему диких заокруглень, при вказанні зовнішньої комісії.  
      Повний чейнджлог
      Оновлена демка
       

    • Від 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.
       
      Може в когось було щось подібне? Хочу знати куди копати.
    • Від 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 та перевірю...
       

    • Від Plastilin
      Вітаю. Маю наступний комплект. Ubilling на Debian + Mikrotik CHR як маршрутизатор. Наче все запустилось, але виникло питання яке не вдається розрулити. Читав Wiki, ковиряв, читав знову Wiki, знову ковиряв - не допомогло.
      Чи можливо якось визначити конкретну IP адресу з пулу який видає Mikrotik клієнту через Radius? Мені пропонує обрати наступну вільну адресу з пулу при спробі зміни адреси?
      З цього з'являється додаткове питання, чи можливо контролювати доступ користувачам у яких IP назначений статично, тобто прописаний вручну? Наприклад при зміні статусу не активний - пхати до Firewall Mikrotik правила заборони доступу з IP адреси визначеної вручну, навіть якщо вона не отримана по DHCP.
       
      UPD: з першою частиною знайшов: IP_CUSTOM=1 в alter.ini 
    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
×
×
  • Створити нове...