BiTel

После аварийного отключения питания
InetNas - Can't reserve ip address for inetNas:2 and realm: disable!
что делать уже достало !!! постоянно какие-то сюрпризы

версия?

6.1

После непоследовательных действий как-то: перезапуск десятки раз и перекомпиляция классов ВДРУГ заработало
НО всю ночь это чудо неработало!!!

посмотриnе сколько записей в таблице inv_ip_resource_dyn_reserve_$mid и сколько текущих сессиий(inet_sessipn_$mid). Возможно какие-то сессии подвисли и занимают весь пул динамических ip.

Эта ошибка говорит о том, что пул динамических ip исчерпан. Но почему - это уже другой вопрос .

Амир напиши faq в wiki как диагностировать в таких случаях

Скорее всего сессии на NAS'е были сброшены, а в биллинге они остались, т.к. стопа не приходило.
Соответственно сессии до connection.close.timeout биллинг считал активными, а их адреса занятыми.
Вполне логично, что пул в этом случае закончился.

Либо у вас таблицы в БД в MyISAM, а не InnoDB, и отключение питания привело к конфликтам в БД.


Последний раз вы обращались в июле, поэтому не совсем понимаю выражений "постоянно", "чудо".

канешна. 220 - это дело такое. следить нужно, чтобы сюрпризов не было. отключение питания - это нештатная ситуация и случиться может всё что угодно (например, база вообще упасть). поэтому тут необходимо понимать что делать в таких случаях и подетальней разобраться в механизмах Inet. В данном случае (как крайняя мера) можно было остановить AA-серверы, грохнуть в базе все активные сессии (трафики, резервы IP-адресов, наработку) и снова запустить с чистого листа. Да, потеряются сессии, но это лучше, чем ночь без интернета.

кстати, тут надо еще посмотреть на максимальное кол-во сессий в типе сервиса.

Добавил в wiki возможные варианты:
http://wiki.bitel.ru/index.php/Inet_FAQ#.D0.A1.D0.B2.D0.BE.D0.B1.D0.BE.D0.B4.D0.BD.D1.8B.D0.B9_IP-.D0.B0.D0.B4.D1.80.D0.B5.D1.81_.D0.BD.D0.B5_.D0.BD.D0.B0.D0.B9.D0.B4.D0.B5.D0.BD_.D0.B8.D0.BB.D0.B8_Can.27t_reserve_ip_address

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

к этому можно было бы предложить например такой порядок действий:
1. ручной старт/стоп приводит к выставлению флага например в базе об этом событии.
2. при запуске проверяем наличие флага стоп, если такового нет вероятна нештатная ситуация,
а дальше возможны варианты с запуском, коих может быть быть множество, например:
а. имеем специальный "аварийный конфиг" который должен отработать в этой ситуации
b. либо определенный сценарий
c. либо просто проверяем некоторые параметры и принимаем решение о запуске с очисткой всех сессий
и т.д. и тому подобное

ситуация отнють не так редка, а дежурить рядом с ним ночью это как-то ... тем более, что в целом работает относительно стабильно ...

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

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

если влом, что-то проверять самим отдадим на откуп клиентам,
пусть бросает событие например СтартБезПредыдущегоСтопа, все на это клиент сам если надо повесит скрипт для отработки ситуации, и желательно функцию РелоадПриложение (любое Биллинг, Ассеss и т.д.) например по идентификатору из настроек соответсвующих приложений, и дальше это уже его проблемы ... НАПИСАЛ МОЛОДЕЦ НЕТ ЗНАЧИТ ПЕНЯЙ НА СЕБЯ

К чему вся эта писанина? Во первых, отключение питания - это хреново, и ты как минимум должен радоваться, что у тебя не умерла база. Нужно позаботиться об его бесперебойности. В задачи биллинга не входит какая-то там зачистка. Он запустился с того состояния, с которого ушел в пике - и это уже хорошо. При правильных настройках таймаутов и режимов двойных сессий проблем не должно быть в таких ситуациях - сессия либо по таймауту завершится, либо при попытке подключения новой того же абонента.

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

Моторчик в данном случае это всякий там типа мифический аварийный конфиг, множество каких-то мифических аварийных запусков и сценариев или просто проверка некоторых непонятно каких параметров, а лучше просто просто вызов метода Pesdato!!!

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

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

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

Я о том, говорил, что если ситуация хоть и нештатная, но возможная и в принципе известная, и методы исправления известны, но они такие посмотрите тут подкрутите тут, а затем верните как было когда запуститься, но это как-то в 2 часа ночи ... поэтому я и говорю, что необходима возможность ее хотя-бы обработать ...
Автоматически ... Вот карбон например говорит, что у них с этим все окей будем пробовать

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

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

Вместо этого просите запилить в биллинге какой-то функционал, который сам определит в чем точно проблема и решит ее.

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

У нас сейчас есть внедрение, переходят от них к нам..Видимо там не все гладко ..У нас с этим тоже все OK, если правильно настроить.

Во первых, АСР - Автомазированная Система Расчетов, а не автоматизированная система распознавания причин неполадок и восстановления после сбоя питания. Здесь явный перебор уже.

Во вторых - еще раз напомню, что сбой питания на узле связи, тем более 3й раз за неделю - это уже конкретный такой сигнал хорошенько задуматься об его бесперебойном обеспечении. А если это типа нормально, упало-поднялось и всё должно дальше заработать с того же самого места - хрен то там, меняется очень много состояний всего и вся.

В третьих, то, что предлагаются очистки, загрузки аварийных конфигов и прочее - это от лукавого. Биллинг запустился в том же самом состоянии, в котором был (это всё равно что перезапустить его вручную), и 99.99% админов согласятся, что так и только так и никак иначе должно быть.

В четверых, видимо уже уже заметил, что твоим высказываниям возразили уже 4 человека, причем не новичков.

Отсюда вывод, что дело, скорее всего, в кривых руках/лени/неопытности/незнании/прочее, а не биллинге. И то, что тебе сказали что Карбон - это мегакруто и у нас нет таких проблем, приходи к нам - велкам!!! Еще не раз отрыгаться будет. Карбон - это наследние Ideco, которое многие вспоминают как страшный сон.

Вы не любите кошек? да вы их просто готовить не умеете (с).

Резюме: Как сказал Амир, лучше конструктивно разобрать конкретную ситуацию и найти решение (тут скорее всего в настройках дело окажется), чем без каких либо обоснований заявлять что биллинг плохой и не обладает искусственным интеллектом. Да, таких слов не было, но складывается ощущение, что это должно быть.

Ах, да, забыл еще. Тут еще одни также подобно про Гидру упоминали. Давайте посмотрим на их форум http://forum.carbonsoft.ru/viewforum.php?f=10 Особенно вот эта тема http://forum.carbonsoft.ru/viewtopic.php?f=10&t=6747 - просто супер биллинг, завтра же перехожу

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

Поэтому ну извините если че не так сказал

А где здесь про гидру ?

Я не думаю, что есть биллинг, который работает без админа. Есть 2 варианта: 1) админ есть у провайдера, 2) админа предоставляют со стороны биллинга(за дополнительные деньги). Мы не можем пока предложить второй вариант. Т.е по запросу решать проблемы мы можем, но не можем полностью администрировать и следить круглосуточно . Варианта чтобы само работало и переживало любые изменения внешней среды( отключение питания, выход из строй какого- то оборудования и т.п.) просто нет в природе. Ну и если проблема у клиента есть, но мы о ней не знаем(он ее не пописывает), то мы тоже не сможем помочь(мы не можем гадать что там произошло, кроме отключение электричества, какие настройки стояли, что в логах, какая ситуация с сессиями в базе и т.п. )..Не исключено что может быть какая-то ошибка, но как нам о ней узнать? Мы готовы к конструктивной критике, но нужна информация.

Критика должна быть конструктивной, а пока наблюдается только поток эмоций и ноль информации по существу. Под информацией понимается: схема подключения, конфиги, скриншоты, куски логов и прочая полезная информация для решения проблемы. Уже давно может все решили бы вместо пустой переписки. Здесь люди отзывчивые, включая разработчиков, и при подробном описании проблемы подскажут пути её решения.

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

Про гидру вот здесь упоминание было viewtopic.php?f=1&t=9845

Здесь, в нашем маленьком "междусобойчике", все (разработчики и пользователи) любят только конструктивную критику, т.е. надо разъяснить где именно и в чем кто-то был не прав (надеюсь заметили, что вам усиленно говорят про таймауты?), после этого, обычно, человек (повторюсь, разработчик или простой пользователь) идет исправлять косяки, с которыми он согласен или аргументированно отстаивает свою точку зрения.



Т.к. админ не хочет заниматься биллингом (по причине завышенного ЧСВ?), то пустите часть его з.п. на официальную поддержку БГБ, а админ пусть и дальше любуется своей прелестью в виде какой-то там самописки.



И то правда ... Всего не предусмотришь, но, думаю, в случае с отключением питания все же можно сделать что-то в духе

• Если аварийно отключился БГБ, то, после включения, сервер БГБ останавливается (руками), в корне сервера создается файл, например, power_off_server (опять же руками), после чего сервер БГБ включается (снова руками) и видя файл при старте принудительно закрывает сессии, после чего затирает файл.
• Если аварийно отключился NAS (креш софта или ХЗ что еще), то сервер БГБ останавливается, в корне сервера создается файл, например, power_off_nas_$mid, в котором указываются ID крашнутого NAS, после чего сервер БГБ включается и принудительно закрывает сессии на этом NAS.

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

Давеча на такой случай в dialup делал костыль: в контексте радиуса крутится процесс, который по snmp отслеживает аптайм устройства. Если он не может получить аптайм или если аптайм меньше, скажем, 15 минут (перегрузили NAS, затем перезапустили радиус), то помечаем все сессии, стартовавшие раньше now-uptime, как suspended.
Позволяет избежать ошибки "Превышен лимит сессий". Для выдачи ip их, пожалуй, можно просто сбрасывать.

В Inet нет сейчас подобной логики? Там же есть DeviceManager, который проверяет uptime.

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

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Ну, это надо руками включать или постоянно держать включенным. А тут именно по uptime отслеживать ребут устройства и сбрасыват сессии, т.к. очевидно, что после ребута сессии в биллинге устарели уже.

кого включать?
при этой опции он смотрит есть ли такая сессия в биллинге и если есть сбрасывает ее, и подцепляет новую

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Ну. А если мне не нужна эта логика в штатном режиме?

А что подразумевается под штатным режимом?
у меня например падает по свету район, брас жив, идёт поток абонентов(свет дали) но в биллинге они ещё живые, все отработает, или не такой штатный режим имеется ввиду?

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений