[E^X]

Гы, чёт меняли в найтройках коннекта к БД postgres, думали, что utm5 само сконектится к БД после перезапуска БД, да там ещё и параметры специальные есть, что типа такое возможно. Да ещё были неприятно удивлены, что БД вообще может пойти к чертям, если стопануть её ну или связь с нетапа до сервера с БД вдруг пропадёт, всякое бывает....(хотя БД и Биллинг у нас на одном сервере) Вот чудная переписка с их отлайном, как всегда всё через одно место (просьба не цепляться к сказаному нашим инженером, просто хотелось бы реконнект и не убивание БД из-за каикх-то не доработок в софте и пропаданий связи между узлами)

 

Я

После перезапуска базы:

/etc/init.d/postgresql restart

 

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

Подключается только после остановки биллинга и запуска заново.

Как можно решить эту проблему?

 

Техническая поддержка:

Во-первых мы не рекомендуем перезагружать сервер БД при работающем

биллинге.

Поскольку биллинг активно использует БД, то за время перезагрузки вы

можете

потерять часть данных, а также получить нарушение логической целостности

БД

UTM5 в худшем случае.

 

Во-вторых, уточните, через какое время с момента старта сервера БД вы

самостоятельно пробовали подключиться к БД UTM5? Получилось ли это у вас

 

быстрее, чем у биллинга?

 

 

Я:

Подклчиться к базе по psql с логином паролем можно сразуже когда скрипт с init.d напишет

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

и не запускать ещё раз, то он не подключается.

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

потери связи между базой и клиентом-биллингом. Тем более в utm5.cfg есть параметр database_reconnect_count=5,

database_reconnect_sleep=2. Если эти параметры использует биллинг, то почему он не переподключается

и пишет DBCtx: PgSQL query failed: no connection to

> the server.

 

Техническая поддержка:

Вы должны понимать, что работа биллинга без связи с сервером БД является

 

нештатной ситуацией вне зависимости от того, где физически находится

сервер

БД. Задача системного администратора как раз обеспечить непрерывную

связь

биллинга и БД. Параметры, которые вы перечислили, конечно имеют место,

но

штатная работа биллинга при потере связи с БД нами не гарантируется. С

нашей

стороны мы проведем необходимое тестирование, однако возникновение

подобных

ситуаций с потерей связи с БД является примером некорректной

эксплуатации

биллинга UTM5.

 

 

Я:

Представьте работу банковскую программу которая находится в дата центре банка которая взаимодействует

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

обеспечить 100% связь до банкомата, связь рвётся в случайный момент времени. Но не смотря

на это, транзакции или проходят или нет в случае разрыва или потерь, но целостность БД

не портится.

Если ваша система не гарантирует целостность данных и корректность расчётов, то почему

биллинг имеет сертификат?

 

 

Техническая поддержка:

Не нужно сравнивать банковские программы с их дополнительным уровнем

дублирования

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

"коробочной"

версией биллинга. При желании под ваше ТЗ наша компания может

реализовать биллинг

с избыточным функционалом для дублирования всех транзакций, однако он

уже не

будет называться UTM5 и цена его будет отличаться от текущей цены

биллинга.

По этому вопросу вы можете связаться с менеджерами нашей компании,

обратившись

на info@netup.ru.

 

> Если ваша система не гарантирует целостность данных и корректность расчётов,

> то почему биллинг имеет сертификат?

>

 

Система сертифицирована при условии стабильной связи биллинга с БД.

Сертификация

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

связи, оборудования

и пр.), это необходимо иметь в виду и в документации об этом написано.

 

P.S. Биллинг UTM5 также использует транзакции, но полного дублирования

всех операций в нем не

предусмотрено, именно поэтому мы не можем гарантировать штатную работу

биллинга.

За часть рисков при эксплуатации несет ответственность системный

администратор, в том числе и

за потерю связи с БД. В противном случае биллингу вообще не требовался

бы технический

персонал для обслуживания.

[littlesavage]

C mysql то же самое. Раздражает. Из установленного, единственная программа, которую нужно перезапускать вместе с БД.

Бывает, что при загрузке utm запускается до того, как mysql начинает принимать запросы.

[orlik]

C mysql то же самое. Раздражает. Из установленного, единственная программа, которую нужно перезапускать вместе с БД.

Бывает, что при загрузке utm запускается до того, как mysql начинает принимать запросы.

 

 

а UTM как был сырой подделкой 5 лет назад, так и остался...

[E^X]

Да они тама жгут

 

> Я не смог понять, функцией пересчёта телефонии он обладает? Т.е. поменялся

> тариф в услуге, можно ли пересчитать за предыдущий период времени?

>

 

Нет, биллинг UTM5 не может пересчитывать уже тарифицированные данные.

Изменения

вступают в силу с момента их внесения.

 

На что им ответил, ну грубо, но шибко бесит

биллинг который не может пересчитать телефонию за определённый отрезок времени, не биллинг.

Ну как бы больше считалка, которую на коленках 100 людей сделали, а не биллинг, сугубо моё мнение. VOIP которые я видел (мало штуки три), все пересчитывали.

 

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

> Сообщите пожалуйста где в админке можно увидеть отчёт динамического

> шейпирования? Я могу посмотреть о том что скорость обрезалась в файлах-логах,

> а как посмотреть это в админке менеджеру?

>

 

Подобный отчет отчет отсутствует в utm_admin. Если вам необходимо

наличие подобного

отчета, вы можете обсудить вопрос его внедрения с менеджерами нашей

компании, обратившись

на info@netup.ru.

 

P.S. В качестве возможного решения данной задачи вы можете указать в

правиле на установку

ширины канала запись в файл или БД об установленной ширине, после чего

делать необходимую

выборку.

[disappointed]

Хм, а смотрели tcpdump-ом что он делает когда пытается подключится?

[Ilya Evseev]

По этой причине при старте системы запускаю UTM5 через /etc/rc.local:

RC=/usr/local/etc/rc.d/mysql-server
if $RC rcvar >/dev/null; then
( while : ; do
   sleep 30
   $RC forcestatus >/dev/null || continue
   /netup/rc.d/utm5_core.sh start
) &
fi

[vadimus]

C mysql то же самое. Раздражает. Из установленного, единственная программа, которую нужно перезапускать вместе с БД.

Бывает, что при загрузке utm запускается до того, как mysql начинает принимать запросы.

 

 

а UTM как был сырой подделкой 5 лет назад, так и остался...

+ 500. Это уже даже не смешно!

[NetViruS]

Откиньте своё предвзятое отношение к UTM5 и просто включите мозг!

Нафига во время работы важного механизма и выполнения ответственного задания вытаскивать шнур из розетки ?

Автор ты вообще головой думаешь что делаешь ?

У меня слов нет просто, бывают же такие "экспериментаторы".

[littlesavage]

mysql restart - это не шнур их розетки. Это нормальное завершение работы СУБД. Т. е. либо завершение, либо откат всех выполняемых транзакций. Оно не должно задевать биллинг.

А по идее, и шнур из розетки не должен привеcти к несогласованной БД.

Изменено 18 июля, 2011 пользователем littlesavage

[E^X]

mysql restart - это не шнур их розетки. Это нормальное завершение работы СУБД. Т. е. либо завершение, либо откат всех выполняемых транзакций. Оно не должно задевать биллинг.

А по идее, и шнур из розетки не должен привеcти к несогласованной БД.

Угу всё так и есть, всё корректно, всё должно в сети быть согласованно, когда что-то от чего-то теряет связь, это всяк таки IP, а не TDM, да и там если посмотреть в ОКС7, есть счётчики ошибок и отправление повторных данных, если связь рвётся, а TDM это реще, ну по крайней мере на практике.

Стоит опенсорсе Cherry, конечно та ещё штука, но она цепляется к БД и как бы не выкрутасывал стопами, стартами, отрубаниями, целостность БД ни разу не ложилось. Да данные моно потерять, сам если виноват, но если к БД не сконнекченно, как минимум инет в временный файлик собирает, но это больше гемороя, чем стабильности...

[GFORGX]

Откиньте своё предвзятое отношение к UTM5 и просто включите мозг!

Нафига во время работы важного механизма и выполнения ответственного задания вытаскивать шнур из розетки ?

Автор ты вообще головой думаешь что делаешь ?

У меня слов нет просто, бывают же такие "экспериментаторы".

Вам NetUP платит за подобные "комментарии эксперта"?

[E^X]

Вот чего нетуп написал:

> Сообщите пожалуйста результат проверки биллинга на стенде. Очень интересует,

> чтобы биллинг переподключался к базе сам. Со своей стороны сделаю всё, чтобы

> доступ к базе не рвался.

>

 

Я проконсультировался с разработчиками, данная проблема действительно

существует

и зарегистрирована как mantis id 1910. Ее исправление планируется

включить в

будущие версии UTM5.

[gavru]

Вообще описанная проблема касается не только UTM (кстати у них на сайте есть варианты решения, но они не пашут, не из за того, что UTM такой плохой, а по причине описанной ниже), например в ubuntu перенесли скрипт запуска mysql к чёрту на кулички и мускул запускается в самую последнюю очередь, что соответственно тянет за собой проблемы запуска приложений зависящих от него, обращение к бубунтоводам ни чего не дали (полный игнор :) при чём в том же debian всё в норме и соответствует правильному уровню запуска согласно их схеме), просто почти та же проблема у нас возникла с traffpro, реконнектится он нормально (когда уже запущен), но при старте мускул не доступен и соответственно некоторые параметры в скриптах не могут быть получены, задавать время ожидания мускула тоже не вариант и не известно может пароль просто не верный указали в конфиге, а может он вообще не запустится, запускать из скриптов сам мускул тоже не вариант из за большого количества дистрибутивов, вот и вопрос, что делать с убунтоводами? :)

[vitalyb]

запускайте из monit :) http://mmonit.com/monit/documentation/monit.html#dependencies

[Mallorn]

Я чего-то не врубаюсь в актуальность проблемы. Перезапустили БД - перезапустили биллинг.

Сами сидим на MySQL 5.1 + UTM 5.21.007

 

Мускуль сам не падает.

[gavru]

Мускуль сам не падает.

Ну а вдруг мускул на другой машине и маленький админ нечаянно свичь потушил между ними :) но опомнился через минуту и включил. Человеческий фактор исключать ни как нельзя :)

Изменено 21 июля, 2011 пользователем gavru

[NiTr0]

и маленький админ нечаянно свичь потушил между ними

Ну зачем сразу так жестоко... Банальные проблемы с питанием, из-за чего или обе машины ребутнулись, но БД задержалась на минуту-другую, чекая диски, или же ребутнулась только машина с БД. Невозможная ситуация? :)

Конечно можно подпилить костыль для проверки живости радиуса и рестарта демона при необходимости (я так делал в другом биллинге), но все же это какбы коммерческий продукт - а покупать геморрой за свои деньги какбы не комильфо :)

Изменено 21 июля, 2011 пользователем NiTr0

[GFORGX]

Мускуль сам не падает.

Ну а вдруг мускул на другой машине и маленький админ нечаянно свичь потушил между ними :) но опомнился через минуту и включил. Человеческий фактор исключать ни как нельзя :)

Ещё можно представить более масштабную ситуацию - когда элементы AAA-системы географически разнесены и банальный обрыв оптики - но, дейстаительно, тут тогда странным оказывается использование UTM5.

 

:)

[Mallorn]

и маленький админ нечаянно свичь потушил между ними

Ну зачем сразу так жестоко... Банальные проблемы с питанием, из-за чего или обе машины ребутнулись, но БД задержалась на минуту-другую, чекая диски, или же ребутнулась только машина с БД. Невозможная ситуация? :)

Конечно можно подпилить костыль для проверки живости радиуса и рестарта демона при необходимости (я так делал в другом биллинге), но все же это какбы коммерческий продукт - а покупать геморрой за свои деньги какбы не комильфо :)

Я давно уже понял из опыта применения UTM5, что там все приходится допиливать:

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

- система архивации есть и описана в доках, но скрипт пишите сами (и ошибки в архивации исправляйте сами, разумеется);

- utm5_rfw обожает создавать дублирующиеся правила iptables. Прикручен скрипт для проверки существования правила в iptables перед выполнением;

- встроенное создание пользователей неудобно - прикручено создание пользователей через urfa;

- ...

 

Уверен, что у других еще больше всего прикручено.

[GFORGX]

и маленький админ нечаянно свичь потушил между ними

Ну зачем сразу так жестоко... Банальные проблемы с питанием, из-за чего или обе машины ребутнулись, но БД задержалась на минуту-другую, чекая диски, или же ребутнулась только машина с БД. Невозможная ситуация? :)

Конечно можно подпилить костыль для проверки живости радиуса и рестарта демона при необходимости (я так делал в другом биллинге), но все же это какбы коммерческий продукт - а покупать геморрой за свои деньги какбы не комильфо :)

Я давно уже понял из опыта применения UTM5, что там все приходится допиливать:

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

- система архивации есть и описана в доках, но скрипт пишите сами (и ошибки в архивации исправляйте сами, разумеется);

- utm5_rfw обожает создавать дублирующиеся правила iptables. Прикручен скрипт для проверки существования правила в iptables перед выполнением;

- встроенное создание пользователей неудобно - прикручено создание пользователей через urfa;

- ...

 

Уверен, что у других еще больше всего прикручено.

У меня всё в таком состоянии, что от собственно UTM5 не осталось ничего кроме админки в качестве редактора БД, приёмщика NetFlow и, собственно, управлялки лицевыми счетами и расчётными периодами. Даже вместо URFA для всего используется собственный XMLRPC-протокол. Дальше - меньше.

[~AsmodeuS~]

Если вас не устраивает UTM, посмориет в строну ABILLS. В системе есть лёгкий механизм миграции.

[Mallorn]

Я давно уже понял из опыта применения UTM5, что там все приходится допиливать:

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

- система архивации есть и описана в доках, но скрипт пишите сами (и ошибки в архивации исправляйте сами, разумеется);

- utm5_rfw обожает создавать дублирующиеся правила iptables. Прикручен скрипт для проверки существования правила в iptables перед выполнением;

- встроенное создание пользователей неудобно - прикручено создание пользователей через urfa;

- ...

 

Уверен, что у других еще больше всего прикручено.

У меня всё в таком состоянии, что от собственно UTM5 не осталось ничего кроме админки в качестве редактора БД, приёмщика NetFlow и, собственно, управлялки лицевыми счетами и расчётными периодами. Даже вместо URFA для всего используется собственный XMLRPC-протокол. Дальше - меньше.

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

И мы когда делали свою обвязку для UTM5, xmlrpc она не умела.

 

Если вас не устраивает UTM, посмориет в строну ABILLS. В системе есть лёгкий механизм миграции.

После 5+ лет общения с ней устраивает, что уж там.

[Madiyar]

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

[ichthyandr]

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

 

Если вас не устраивает UTM, посмориет в строну ABILLS. В системе есть лёгкий механизм миграции.

Уже сертифицирован?

[zlolotus]

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