forum.bitel.ru :: Просмотр темы - СРОЧНО ПРОБЛЕМА С ACCESS

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

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

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

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

Amir писал(а):

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

dm777 писал(а):

Amir писал(а):

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

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

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

dm777 писал(а):

Amir писал(а):

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

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

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

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

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

Вот карбон например говорит, что у них с этим все окей будем пробовать

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

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

dm777 писал(а):

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

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

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

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

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

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

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

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

Особенно вот эта тема http://forum.carbonsoft.ru/viewtopic.php?f=10&t=6747 - просто супер биллинг, завтра же перехожу :lol:

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

Особенно вот эта тема http://forum.carbonsoft.ru/viewtopic.php?f=10&t=6747 - просто супер биллинг, завтра же перехожу :lol:

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

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

критику вы ребята не любите смотрю ...

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

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

Amir писал(а):

Добавил в 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

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

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

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

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

Автор:	dm777 [ 24 окт 2014, 11:17 ]
Заголовок сообщения:	СРОЧНО ПРОБЛЕМА С ACCESS
После аварийного отключения питания InetNas - Can't reserve ip address for inetNas:2 and realm: disable! что делать уже достало !!! постоянно какие-то сюрпризы

Автор:	stark [ 24 окт 2014, 11:18 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
версия?

Автор:	dm777 [ 24 окт 2014, 11:21 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
6.1

Автор:	dm777 [ 24 окт 2014, 11:26 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): После аварийного отключения питания InetNas - Can't reserve ip address for inetNas:2 and realm: disable! что делать уже достало !!! постоянно какие-то сюрпризы После непоследовательных действий как-то: перезапуск десятки раз и перекомпиляция классов ВДРУГ заработало НО всю ночь это чудо неработало!!!

Автор:	stark [ 24 окт 2014, 11:33 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
посмотриnе сколько записей в таблице inv_ip_resource_dyn_reserve_$mid и сколько текущих сессиий(inet_sessipn_$mid). Возможно какие-то сессии подвисли и занимают весь пул динамических ip.

forum.bitel.ru http://forum.bitel.ru/

СРОЧНО ПРОБЛЕМА С ACCESS http://forum.bitel.ru/viewtopic.php?f=44&t=9863	Страница 1 из 2

Автор:	stark [ 24 окт 2014, 11:35 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Эта ошибка говорит о том, что пул динамических ip исчерпан. Но почему - это уже другой вопрос . Амир напиши faq в wiki как диагностировать в таких случаях

Автор:	Amir [ 24 окт 2014, 13:28 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Скорее всего сессии на NAS'е были сброшены, а в биллинге они остались, т.к. стопа не приходило. Соответственно сессии до connection.close.timeout биллинг считал активными, а их адреса занятыми. Вполне логично, что пул в этом случае закончился. Либо у вас таблицы в БД в MyISAM, а не InnoDB, и отключение питания привело к конфликтам в БД. Последний раз вы обращались в июле, поэтому не совсем понимаю выражений "постоянно", "чудо".

Автор:	barguzin2 [ 24 окт 2014, 14:11 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): После аварийного отключения питания InetNas - Can't reserve ip address for inetNas:2 and realm: disable! что делать уже достало !!! постоянно какие-то сюрпризы канешна. 220 - это дело такое. следить нужно, чтобы сюрпризов не было. отключение питания - это нештатная ситуация и случиться может всё что угодно (например, база вообще упасть). поэтому тут необходимо понимать что делать в таких случаях и подетальней разобраться в механизмах Inet. В данном случае (как крайняя мера) можно было остановить AA-серверы, грохнуть в базе все активные сессии (трафики, резервы IP-адресов, наработку) и снова запустить с чистого листа. Да, потеряются сессии, но это лучше, чем ночь без интернета. кстати, тут надо еще посмотреть на максимальное кол-во сессий в типе сервиса.

Автор:	Amir [ 24 окт 2014, 16:49 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Добавил в 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

Автор:	dm777 [ 24 окт 2014, 20:02 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Amir писал(а): Скорее всего сессии на NAS'е были сброшены, а в биллинге они остались, т.к. стопа не приходило. Соответственно сессии до connection.close.timeout биллинг считал активными, а их адреса занятыми. Вполне логично, что пул в этом случае закончился. Либо у вас таблицы в БД в MyISAM, а не InnoDB, и отключение питания привело к конфликтам в БД. Последний раз вы обращались в июле, поэтому не совсем понимаю выражений "постоянно", "чудо". ну постоянно это потому, что за неделю уже третий раз падало питание и картина была идентичной, только в других случаях это было утром и проблему оперативно устраняли ... Поэтому я думаю было бы неплохо что-бы в "штатной" нештатной ситуации биллинг мог бы как-то сам отработать нужный порядок действий, а не ждать когда его починят

Автор:	dm777 [ 24 окт 2014, 20:13 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): Amir писал(а): Скорее всего сессии на NAS'е были сброшены, а в биллинге они остались, т.к. стопа не приходило. Соответственно сессии до connection.close.timeout биллинг считал активными, а их адреса занятыми. Вполне логично, что пул в этом случае закончился. Либо у вас таблицы в БД в MyISAM, а не InnoDB, и отключение питания привело к конфликтам в БД. Последний раз вы обращались в июле, поэтому не совсем понимаю выражений "постоянно", "чудо". ну постоянно это потому, что за неделю уже третий раз падало питание и картина была идентичной, только в других случаях это было утром и проблему оперативно устраняли ... Поэтому я думаю было бы неплохо что-бы в "штатной" нештатной ситуации биллинг мог бы как-то сам отработать нужный порядок действий, а не ждать когда его починят к этому можно было бы предложить например такой порядок действий: 1. ручной старт/стоп приводит к выставлению флага например в базе об этом событии. 2. при запуске проверяем наличие флага стоп, если такового нет вероятна нештатная ситуация, а дальше возможны варианты с запуском, коих может быть быть множество, например: а. имеем специальный "аварийный конфиг" который должен отработать в этой ситуации b. либо определенный сценарий c. либо просто проверяем некоторые параметры и принимаем решение о запуске с очисткой всех сессий и т.д. и тому подобное ситуация отнють не так редка, а дежурить рядом с ним ночью это как-то ... тем более, что в целом работает относительно стабильно ... абоненту все равно,что там у нас с биллингом ему нужен нет и днем и ночью

Автор:	dm777 [ 24 окт 2014, 20:20 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): dm777 писал(а): Amir писал(а): Скорее всего сессии на NAS'е были сброшены, а в биллинге они остались, т.к. стопа не приходило. Соответственно сессии до connection.close.timeout биллинг считал активными, а их адреса занятыми. Вполне логично, что пул в этом случае закончился. Либо у вас таблицы в БД в MyISAM, а не InnoDB, и отключение питания привело к конфликтам в БД. Последний раз вы обращались в июле, поэтому не совсем понимаю выражений "постоянно", "чудо". ну постоянно это потому, что за неделю уже третий раз падало питание и картина была идентичной, только в других случаях это было утром и проблему оперативно устраняли ... Поэтому я думаю было бы неплохо что-бы в "штатной" нештатной ситуации биллинг мог бы как-то сам отработать нужный порядок действий, а не ждать когда его починят к этому можно было бы предложить например такой порядок действий: 1. ручной старт/стоп приводит к выставлению флага например в базе об этом событии. 2. при запуске проверяем наличие флага стоп, если такового нет вероятна нештатная ситуация, а дальше возможны варианты с запуском, коих может быть быть множество, например: а. имеем специальный "аварийный конфиг" который должен отработать в этой ситуации b. либо определенный сценарий c. либо просто проверяем некоторые параметры и принимаем решение о запуске с очисткой всех сессий и т.д. и тому подобное ситуация отнють не так редка, а дежурить рядом с ним ночью это как-то ... тем более, что в целом работает относительно стабильно ... абоненту все равно,что там у нас с биллингом ему нужен нет и днем и ночью а по поводу чуда, биллинг на мой взгляд не так плох, сам выбирал из кучи других, но ... о чем я говорил выше абоненту все равно насколько он хорош ... главное, что-бы работал ...

Автор:	dm777 [ 24 окт 2014, 20:27 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): dm777 писал(а): dm777 писал(а): Amir писал(а): Скорее всего сессии на NAS'е были сброшены, а в биллинге они остались, т.к. стопа не приходило. Соответственно сессии до connection.close.timeout биллинг считал активными, а их адреса занятыми. Вполне логично, что пул в этом случае закончился. Либо у вас таблицы в БД в MyISAM, а не InnoDB, и отключение питания привело к конфликтам в БД. Последний раз вы обращались в июле, поэтому не совсем понимаю выражений "постоянно", "чудо". ну постоянно это потому, что за неделю уже третий раз падало питание и картина была идентичной, только в других случаях это было утром и проблему оперативно устраняли ... Поэтому я думаю было бы неплохо что-бы в "штатной" нештатной ситуации биллинг мог бы как-то сам отработать нужный порядок действий, а не ждать когда его починят к этому можно было бы предложить например такой порядок действий: 1. ручной старт/стоп приводит к выставлению флага например в базе об этом событии. 2. при запуске проверяем наличие флага стоп, если такового нет вероятна нештатная ситуация, а дальше возможны варианты с запуском, коих может быть быть множество, например: а. имеем специальный "аварийный конфиг" который должен отработать в этой ситуации b. либо определенный сценарий c. либо просто проверяем некоторые параметры и принимаем решение о запуске с очисткой всех сессий и т.д. и тому подобное ситуация отнють не так редка, а дежурить рядом с ним ночью это как-то ... тем более, что в целом работает относительно стабильно ... абоненту все равно,что там у нас с биллингом ему нужен нет и днем и ночью а по поводу чуда, биллинг на мой взгляд не так плох, сам выбирал из кучи других, но ... о чем я говорил выше абоненту все равно насколько он хорош ... главное, что-бы работал ... если влом, что-то проверять самим отдадим на откуп клиентам, пусть бросает событие например СтартБезПредыдущегоСтопа, все на это клиент сам если надо повесит скрипт для отработки ситуации, и желательно функцию РелоадПриложение (любое Биллинг, Ассеss и т.д.) например по идентификатору из настроек соответсвующих приложений, и дальше это уже его проблемы ... НАПИСАЛ МОЛОДЕЦ НЕТ ЗНАЧИТ ПЕНЯЙ НА СЕБЯ

Автор:	barguzin2 [ 24 окт 2014, 22:24 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
К чему вся эта писанина? Во первых, отключение питания - это хреново, и ты как минимум должен радоваться, что у тебя не умерла база. Нужно позаботиться об его бесперебойности. В задачи биллинга не входит какая-то там зачистка. Он запустился с того состояния, с которого ушел в пике - и это уже хорошо. При правильных настройках таймаутов и режимов двойных сессий проблем не должно быть в таких ситуациях - сессия либо по таймауту завершится, либо при попытке подключения новой того же абонента. Поэтому, потрудись сначала почитать документацию, подетальней разобраться с механизмами работы биллинга и будет тебе спокойный сон. А то прям как в том анекдоте про еврея - стоит, тяпку крутит в руках, слушайте, а нельзя ли к ней маторчик чтоли приделать. Ему отвечают - ну ты даешь, ты где видел тяпку с моторчиком, а он в ответ - а где вы видели еврея с тяпкой. Моторчик в данном случае это всякий там типа мифический аварийный конфиг, множество каких-то мифических аварийных запусков и сценариев или просто проверка некоторых непонятно каких параметров, а лучше просто просто вызов метода Pesdato!!!

Автор:	Amir [ 25 окт 2014, 15:06 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Вы не предоставили никаких данных кроме того, что было отключение электричества и в итоге вот такая проблема. Не обращались, когда ситуация у вас была первый раз и второй, не просили посмотреть что у вас такое. Мы могли бы уже давно диагностировать проблему. Например, если дело было все-таки в том, что соединения долго висели в биллинге, когда на NAS'е их уже не было, то это, как вы пишите "ситуация хоть и нештатная, но возможная и в принципе известная" и правильные значения Код: connection.suspend.timeout= connection.close.timeout= и/или radius.connection.checkDuplicate= решат вашу проблему, как уже писали выше. Вместо этого просите запилить в биллинге какой-то функционал, который сам определит в чем точно проблема и решит ее. Описанное же в wiki - для нештатных и неизвестных ситуаций, когда уже перестало нормально работать. И предполагается, что после (или во время) ее устранения обратятся к нам, предоставив доступ и подробности, с целью дальнейшего неповторения. А не с нападками. Сначала подробности, потом можно уже и нападки. Например, если бы вы сразу написали, о том что несколько дней повторяется ситуация с отключением электричества, я бы скорее всего сразу попросил доступ, посмотреть ваши конфиги, историю сессий и т.п. и предложить какое-то решение (несмотря на то, что это все-таки бесплатный форум).

Автор:	snark [ 29 окт 2014, 01:18 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): критику вы ребята не любите смотрю ... Здесь, в нашем маленьком "междусобойчике", все (разработчики и пользователи) любят только конструктивную критику, т.е. надо разъяснить где именно и в чем кто-то был не прав (надеюсь заметили, что вам усиленно говорят про таймауты?), после этого, обычно, человек (повторюсь, разработчик или простой пользователь) идет исправлять косяки, с которыми он согласен или аргументированно отстаивает свою точку зрения. dm777 писал(а): админ у нас работает удаленно и вашим биллингом не занимается принципиально, т.к. в другой конторе где он постоянно у него свой самописный ... Т.к. админ не хочет заниматься биллингом (по причине завышенного ЧСВ?), то пустите часть его з.п. на официальную поддержку БГБ, а админ пусть и дальше любуется своей прелестью в виде какой-то там самописки. stark писал(а): Варианта чтобы само работало и переживало любые изменения внешней среды( отключение питания, выход из строй какого- то оборудования и т.п.) просто нет в природе. И то правда ... Всего не предусмотришь, но, думаю, в случае с отключением питания все же можно сделать что-то в духе Если аварийно отключился БГБ, то, после включения, сервер БГБ останавливается (руками), в корне сервера создается файл, например, power_off_server (опять же руками), после чего сервер БГБ включается (снова руками) и видя файл при старте принудительно закрывает сессии, после чего затирает файл. Если аварийно отключился NAS (креш софта или ХЗ что еще), то сервер БГБ останавливается, в корне сервера создается файл, например, power_off_nas_$mid, в котором указываются ID крашнутого NAS, после чего сервер БГБ включается и принудительно закрывает сессии на этом NAS. Да, подобное решение далеко от идеала и да, это решение, как говорится, тупо в лоб, но возможно нечто подобное поможет ТС и таким как он пережить внезапные, не преднамеренные ребуты. Надеюсь никто пинать не будет, т.к. придумал только что, как говорится, на ходу.

Страница 1 из 2	Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/

Автор:	Phricker [ 25 окт 2014, 02:00 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): 2. при запуске проверяем наличие флага стоп, если такового нет вероятна нештатная ситуация, а дальше возможны варианты с запуском, коих может быть быть множество, например: а. имеем специальный "аварийный конфиг" который должен отработать в этой ситуации b. либо определенный сценарий c. либо просто проверяем некоторые параметры и принимаем решение о запуске с очисткой всех сессий и т.д. и тому подобное А потом внезапно оказывается что биллинг сессии почистил, а на железке доступа они еще висят активными, потому что железка не перегружалась.

Автор:	dm777 [ 25 окт 2014, 13:47 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
barguzin2 писал(а): К чему вся эта писанина? Во первых, отключение питания - это хреново, и ты как минимум должен радоваться, что у тебя не умерла база. Нужно позаботиться об его бесперебойности. В задачи биллинга не входит какая-то там зачистка. Он запустился с того состояния, с которого ушел в пике - и это уже хорошо. При правильных настройках таймаутов и режимов двойных сессий проблем не должно быть в таких ситуациях - сессия либо по таймауту завершится, либо при попытке подключения новой того же абонента. Поэтому, потрудись сначала почитать документацию, подетальней разобраться с механизмами работы биллинга и будет тебе спокойный сон. А то прям как в том анекдоте про еврея - стоит, тяпку крутит в руках, слушайте, а нельзя ли к ней маторчик чтоли приделать. Ему отвечают - ну ты даешь, ты где видел тяпку с моторчиком, а он в ответ - а где вы видели еврея с тяпкой. Моторчик в данном случае это всякий там типа мифический аварийный конфиг, множество каких-то мифических аварийных запусков и сценариев или просто проверка некоторых непонятно каких параметров, а лучше просто просто вызов метода Pesdato!!! Не согласен ... Все делать в ручную ... зачем тогда вообще, что-то автоматизировать давайте оплату принимать по квитанциям и записывать в тетрадку ... Я о том, говорил, что если ситуация хоть и нештатная, но возможная и в принципе известная, и методы исправления известны, но они такие посмотрите тут подкрутите тут, а затем верните как было когда запуститься, но это как-то в 2 часа ночи ... поэтому я и говорю, что необходима возможность ее хотя-бы обработать ... Автоматически ... Вот карбон например говорит, что у них с этим все окей будем пробовать

Автор:	stark [ 25 окт 2014, 18:29 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): Вот карбон например говорит, что у них с этим все окей будем пробовать У нас сейчас есть внедрение, переходят от них к нам..Видимо там не все гладко ..У нас с этим тоже все OK, если правильно настроить.

Автор:	barguzin2 [ 25 окт 2014, 21:42 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): Не согласен ... Все делать в ручную ... зачем тогда вообще, что-то автоматизировать давайте оплату принимать по квитанциям и записывать в тетрадку ... Я о том, говорил, что если ситуация хоть и нештатная, но возможная и в принципе известная, и методы исправления известны, но они такие посмотрите тут подкрутите тут, а затем верните как было когда запуститься, но это как-то в 2 часа ночи ... поэтому я и говорю, что необходима возможность ее хотя-бы обработать ... Автоматически ... Вот карбон например говорит, что у них с этим все окей будем пробовать Во первых, АСР - Автомазированная Система Расчетов, а не автоматизированная система распознавания причин неполадок и восстановления после сбоя питания. Здесь явный перебор уже. Во вторых - еще раз напомню, что сбой питания на узле связи, тем более 3й раз за неделю - это уже конкретный такой сигнал хорошенько задуматься об его бесперебойном обеспечении. А если это типа нормально, упало-поднялось и всё должно дальше заработать с того же самого места - хрен то там, меняется очень много состояний всего и вся. В третьих, то, что предлагаются очистки, загрузки аварийных конфигов и прочее - это от лукавого. Биллинг запустился в том же самом состоянии, в котором был (это всё равно что перезапустить его вручную), и 99.99% админов согласятся, что так и только так и никак иначе должно быть. В четверых, видимо уже уже заметил, что твоим высказываниям возразили уже 4 человека, причем не новичков. Отсюда вывод, что дело, скорее всего, в кривых руках/лени/неопытности/незнании/прочее, а не биллинге. И то, что тебе сказали что Карбон - это мегакруто и у нас нет таких проблем, приходи к нам - велкам!!! Еще не раз отрыгаться будет. Карбон - это наследние Ideco, которое многие вспоминают как страшный сон. Вы не любите кошек? да вы их просто готовить не умеете (с). Резюме: Как сказал Амир, лучше конструктивно разобрать конкретную ситуацию и найти решение (тут скорее всего в настройках дело окажется), чем без каких либо обоснований заявлять что биллинг плохой и не обладает искусственным интеллектом. Да, таких слов не было, но складывается ощущение, что это должно быть. Ах, да, забыл еще. Тут еще одни также подобно про Гидру упоминали. Давайте посмотрим на их форум http://forum.carbonsoft.ru/viewforum.php?f=10 Особенно вот эта тема http://forum.carbonsoft.ru/viewtopic.php?f=10&t=6747 - просто супер биллинг, завтра же перехожу

Автор:	dm777 [ 25 окт 2014, 22:23 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
barguzin2 писал(а): dm777 писал(а): Не согласен ... Все делать в ручную ... зачем тогда вообще, что-то автоматизировать давайте оплату принимать по квитанциям и записывать в тетрадку ... Я о том, говорил, что если ситуация хоть и нештатная, но возможная и в принципе известная, и методы исправления известны, но они такие посмотрите тут подкрутите тут, а затем верните как было когда запуститься, но это как-то в 2 часа ночи ... поэтому я и говорю, что необходима возможность ее хотя-бы обработать ... Автоматически ... Вот карбон например говорит, что у них с этим все окей будем пробовать Во первых, АСР - Автомазированная Система Расчетов, а не автоматизированная система распознавания причин неполадок и восстановления после сбоя питания. Здесь явный перебор уже. Во вторых - еще раз напомню, что сбой питания на узле связи, тем более 3й раз за неделю - это уже конкретный такой сигнал хорошенько задуматься об его бесперебойном обеспечении. А если это типа нормально, упало-поднялось и всё должно дальше заработать с того же самого места - хрен то там, меняется очень много состояний всего и вся. В третьих, то, что предлагаются очистки, загрузки аварийных конфигов и прочее - это от лукавого. Биллинг запустился в том же самом состоянии, в котором был (это всё равно что перезапустить его вручную), и 99.99% админов согласятся, что так и только так и никак иначе должно быть. В четверых, видимо уже уже заметил, что твоим высказываниям возразили уже 4 человека, причем не новичков. Отсюда вывод, что дело, скорее всего, в кривых руках/лени/неопытности/незнании/прочее, а не биллинге. И то, что тебе сказали что Карбон - это мегакруто и у нас нет таких проблем, приходи к нам - велкам!!! Еще не раз отрыгаться будет. Карбон - это наследние Ideco, которое многие вспоминают как страшный сон. Вы не любите кошек? да вы их просто готовить не умеете (с). Резюме: Как сказал Амир, лучше конструктивно разобрать конкретную ситуацию и найти решение (тут скорее всего в настройках дело окажется), чем без каких либо обоснований заявлять что биллинг плохой и не обладает искусственным интеллектом. Да, таких слов не было, но складывается ощущение, что это должно быть. Ах, да, забыл еще. Тут еще одни также подобно про Гидру упоминали. Давайте посмотрим на их форум http://forum.carbonsoft.ru/viewforum.php?f=10 Особенно вот эта тема http://forum.carbonsoft.ru/viewtopic.php?f=10&t=6747 - просто супер биллинг, завтра же перехожу не Ладно заклевали уже ... Я не говорил, что биллинг плохой ... Я знаю, что такое идеко ... И на карбон не смотрю со слишком большой надеждой ... И БГБиллинг считаю достаточно удобным, но ... Насчет питания стоят бесперебойники две независимые линии и третья генераторная (основная) т.к. разъмещаемся в здании принадлежащем Сберу ... Но критику вы ребята не любите смотрю ... может дело и в кривых руках, но тогда подскажите как сделать так, что-бы в этой ситуации биллинг мог нормально запуститься ... я не админ и не программист, я директор ... хотя и пишу по необходимости если приходится ... но помимо этого куча других проблем имеется ... админ у нас работает удаленно и вашим биллингом не занимается принципиально, т.к. в другой конторе где он постоянно у него свой самописный ... Поэтому ну извините если че не так сказал

Автор:	dm777 [ 25 окт 2014, 22:30 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Цитата: Ах, да, забыл еще. Тут еще одни также подобно про Гидру упоминали. Давайте посмотрим на их форум http://forum.carbonsoft.ru/viewforum.php?f=10 Особенно вот эта тема http://forum.carbonsoft.ru/viewtopic.php?f=10&t=6747 - просто супер биллинг, завтра же перехожу А где здесь про гидру ?

Автор:	stark [ 25 окт 2014, 22:40 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Я не думаю, что есть биллинг, который работает без админа. Есть 2 варианта: 1) админ есть у провайдера, 2) админа предоставляют со стороны биллинга(за дополнительные деньги). Мы не можем пока предложить второй вариант. Т.е по запросу решать проблемы мы можем, но не можем полностью администрировать и следить круглосуточно . Варианта чтобы само работало и переживало любые изменения внешней среды( отключение питания, выход из строй какого- то оборудования и т.п.) просто нет в природе. Ну и если проблема у клиента есть, но мы о ней не знаем(он ее не пописывает), то мы тоже не сможем помочь(мы не можем гадать что там произошло, кроме отключение электричества, какие настройки стояли, что в логах, какая ситуация с сессиями в базе и т.п. )..Не исключено что может быть какая-то ошибка, но как нам о ней узнать? Мы готовы к конструктивной критике, но нужна информация.

Автор:	barguzin2 [ 26 окт 2014, 12:05 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
dm777 писал(а): Ладно заклевали уже ... Я не говорил, что биллинг плохой ... Я знаю, что такое идеко ... И на карбон не смотрю со слишком большой надеждой ... И БГБиллинг считаю достаточно удобным, но ... Насчет питания стоят бесперебойники две независимые линии и третья генераторная (основная) т.к. разъмещаемся в здании принадлежащем Сберу ... Но критику вы ребята не любите смотрю ... может дело и в кривых руках, но тогда подскажите как сделать так, что-бы в этой ситуации биллинг мог нормально запуститься ... я не админ и не программист, я директор ... хотя и пишу по необходимости если приходится ... но помимо этого куча других проблем имеется ... админ у нас работает удаленно и вашим биллингом не занимается принципиально, т.к. в другой конторе где он постоянно у него свой самописный ... Поэтому ну извините если че не так сказал Критика должна быть конструктивной, а пока наблюдается только поток эмоций и ноль информации по существу. Под информацией понимается: схема подключения, конфиги, скриншоты, куски логов и прочая полезная информация для решения проблемы. Уже давно может все решили бы вместо пустой переписки. Здесь люди отзывчивые, включая разработчиков, и при подробном описании проблемы подскажут пути её решения. Биллинг без админа - это очень плохо. Бэкапы то хоть делаются ? А админ, который принципиально отказывается - тоже странно как-то. Можете обратиться ко мне в личном порядке - проведу аудит, посмотрю что и как, может и сотрудничать будем. У меня большой опыт работы с биллингом и разным оборудованием. Про гидру вот здесь упоминание было viewtopic.php?f=1&t=9845

Автор:	Cromeshnic [ 29 окт 2014, 07:36 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Amir писал(а): Добавил в 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 Давеча на такой случай в dialup делал костыль: в контексте радиуса крутится процесс, который по snmp отслеживает аптайм устройства. Если он не может получить аптайм или если аптайм меньше, скажем, 15 минут (перегрузили NAS, затем перезапустили радиус), то помечаем все сессии, стартовавшие раньше now-uptime, как suspended. Позволяет избежать ошибки "Превышен лимит сессий". Для выдачи ip их, пожалуй, можно просто сбрасывать. В Inet нет сейчас подобной логики? Там же есть DeviceManager, который проверяет uptime.

Автор:	skyb [ 29 окт 2014, 07:45 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Cromeshnic писал(а): Amir писал(а): Добавил в 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 Давеча на такой случай в dialup делал костыль: в контексте радиуса крутится процесс, который по snmp отслеживает аптайм устройства. Если он не может получить аптайм или если аптайм меньше, скажем, 15 минут (перегрузили NAS, затем перезапустили радиус), то помечаем все сессии, стартовавшие раньше now-uptime, как suspended. Позволяет избежать ошибки "Превышен лимит сессий". Для выдачи ip их, пожалуй, можно просто сбрасывать. В Inet нет сейчас подобной логики? Там же есть DeviceManager, который проверяет uptime. а как же Код: radius.connection.checkDuplicate= отрабатывает на ура, да и snmp есть, только мне он как то не очень понравился, хотя пытался использовать

Автор:	Cromeshnic [ 29 окт 2014, 08:10 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Ну, это надо руками включать или постоянно держать включенным. А тут именно по uptime отслеживать ребут устройства и сбрасыват сессии, т.к. очевидно, что после ребута сессии в биллинге устарели уже.

Автор:	skyb [ 29 окт 2014, 10:08 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Cromeshnic писал(а): Ну, это надо руками включать или постоянно держать включенным. А тут именно по uptime отслеживать ребут устройства и сбрасыват сессии, т.к. очевидно, что после ребута сессии в биллинге устарели уже. кого включать? при этой опции он смотрит есть ли такая сессия в биллинге и если есть сбрасывает ее, и подцепляет новую

Автор:	Cromeshnic [ 29 окт 2014, 11:57 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Ну. А если мне не нужна эта логика в штатном режиме?

Автор:	skyb [ 29 окт 2014, 13:54 ]
Заголовок сообщения:	Re: СРОЧНО ПРОБЛЕМА С ACCESS
Cromeshnic писал(а): Ну. А если мне не нужна эта логика в штатном режиме? А что подразумевается под штатным режимом? у меня например падает по свету район, брас жив, идёт поток абонентов(свет дали) но в биллинге они ещё живые, все отработает, или не такой штатный режим имеется ввиду?