Работа с UTM5 при критических сбоях
Работа с UTM5 при критических сбоях
Хотелось бы услышать о методах работы при критических сбоях на сервере обслуживающем UTM. Как часто вы бы порекомендовали делать полный бэкап DB. Какими методами можно снизить или свести к минимуму "потерю" учтенного трафика и изменений в базе (внесение платежей, изменение параметров абонентов) с момента последнего бэкапа до момента восстановления работы. В общем буду благодарен за любые высказывания подтвержденные опытом либо просто предположения в теории.
Re: Работа с UTM5 при критических сбоях
Немного продолжу тему. Как лучше хранить данные utm в mysql или postgressSql?
UTM5 сможет обсчитать объемы, которые пока сложно создать в реальной сети. Более подробно цифры приводились в старом форуме http://old.netup.ru/phorum/viewthread.php?tid=2292dalex писал(а):если честно мощных систем кроме cboss не знаю (но она стоит по другому десятки тысяч зеленых).
Интересно а реально использовать всетаки utm5 в таких масштабаХ?
на очень мощном сервере и т.п. Ведь есть же у нее какой то предел обработки информации.
В реальных инсталляциях UTM5 максимально зафиксированный нами трафик составил в районе 15 ТБайт в месяц.
и люди ходят по вахтам, чтобы круглосуточно смотреть на этот UTM, ведь не дай бог свалится, и каждая минута простоя будет стоить. а дневная смена сидит и в ручную удаляет старую статистику из базы, потому как автоматом это не делается. телефонные направления в ручную сортируют. а если вдруг понадобится детальная статистика, то все приехали, UTM 100% сдохнет если период чуть больше часа поставить. в логах одни "error" и "request not found" - это не старшно, "так и должно быть". расчетные периоды сами по себе плодятся и временные рамки меняют. интерфейс наполовину русский наполовину английский. про радиус вообще говорить не стоит.
aospan Вам не стыдно такое людям в глаза говорить?
aospan Вам не стыдно такое людям в глаза говорить?
не стыдно т.к. уверен на все 100%, что большая часть проблем связана не столько с самой системой.void писал(а):и люди ходят по вахтам, чтобы круглосуточно смотреть на этот UTM, ведь не дай бог свалится, и каждая минута простоя будет стоить. а дневная смена сидит и в ручную удаляет старую статистику из базы, потому как автоматом это не делается. телефонные направления в ручную сортируют. а если вдруг понадобится детальная статистика, то все приехали, UTM 100% сдохнет если период чуть больше часа поставить. в логах одни "error" и "request not found" - это не старшно, "так и должно быть". расчетные периоды сами по себе плодятся и временные рамки меняют. интерфейс наполовину русский наполовину английский. про радиус вообще говорить не стоит.
aospan Вам не стыдно такое людям в глаза говорить?
Теперь по пунктам:
1. По поводу простоя. Навскидку сразу могу привести несколько инсталляций, где ядро не перегружалось месяцами и работало как часы. Есть вариант нам встретиться (можно у нас в офисе) и посмотреть эти инсталляции. Как вы заметите это не супер навроченное железо, не экзотическая операционная система и т.д.
2. По поводу удаления старой статистики. Тут действительно есть недоработка, но в стадии тестирования сейчас скрипт для оптимизации старых данных, который вы можете по запросу получить в техподдержке. Так же, есть вариант перемещать записи в SQL базе вручную запросом. Как это сделать можно уточнить в техподержке. В остальном можно сказать, что данная проблема это проблема базы данных, хотя к MySQL с грамотными настройками (http://old.netup.ru/fom-serve/cache/49.html) претензий нет. Спокойно работает с базой 2 ГБ и выше.
3. Телефонные направления давно сортируются автоматически - у Вас немного устаревшие данные. Обновитесь до UTM5.1.10-011.
4. Насчет выбора детальной статистики за большой период. Данный вопрос специально занесли в ФАК - http://old.netup.ru/fom-serve/cache/18.html . Так же, в наличи имеется специальная консольная утилита (utm5ctl) для выборки детальных данных прямо на сервере, не "вытаскивая" эти данные на машину администратора. Для получения обратитесь в службу технической поддержки.
5. По поводу логов. Есть критичные ошибки, есть не очень ... обо всех ошибках система честно сообщает в логи. Что тут плохого ?
6. Насчет расчетных периодов. Система действительно создает "технические" (вспомогательные) расчетные периоды по необходимости. при этом на функционирование системы они никак не влияют. Что касается самопроизвольного изменения длины расчетных периодов - действительно слышу в первый раз. Если такая проблема есть - просьба связаться (можно по телефону, можно на email: aospan@netup.ru) и привести как можно более подробную информацию по этой проблеме.
7. Интерфейс последовательно переводим. Сейчас очень мало мест где остались не переведенные фразы. В следующем билде таких мест будет еще меньше.
8. Скажите пожалуйста про радиус. Желательно аргументированно. Если есть какие-то недоработки, будем дорабатывать ...
В любом случае просьба высказываться максимально аргументированно.
С уважением,
Абылай
Компания НетАП
Последний раз редактировалось aospan Пт июн 03, 2005 08:32, всего редактировалось 1 раз.
1. было бы у меня лишние 15000 р. я обязательно бы прилетел в Москву к Вам в гости.
У меня UTM 5.1.9.006 проработал почти с самого выхода до вчерашнего дня без остановок. дернул меня хрен сгенерировать детальную статистику по пользователю за день.
2. да я понимаю что все можно делать в ручную
3. ну не давно, а только с версии 5.1.10-011
4. у меня не хватает времени каждый раз читать в факе можно нажимать ту или иную кнопочку в интерфейсе, и что из этого получится.
5. только удивляет например почему "file not found" это значит не добавлен NAS сервер.
6. в UTM я пользуюсь только подсчетом трафика по NetFlow и pppoe. ни периоды ни тарифные планы не применяю. расчетные периоды просто были заведены при инсталяции системы и теперь они живут своей жизнью, то их появляется некоторое количество, то потом исчезают.
7. интерфейс был написан в Индии? и теперь Вы его переводите?
8. я давно мечтал завести обсчет voip на UTM, но останавливало отсутствие сортировки направлений. и вот УРА вышел 5.1.10-011. думаю "вот молодцы ребятя, действительно нужная вещь!"
ну ясно решил сначала испытать все шаги перехода на новую версию. взял бэкап с основного сервера, залил на тестовый, поставил 5.1.10-011,обновил базу скриптом, запустил, все стартануло.
теперь надо проверить pppoe. отключаю радиус основного сервера, cisco автоматом начала посылать запросы на тестовый. в логах сразу получил "unable to claim IP", не мне Вам рассказывать что это значит.
посмотрел я отчеты dialup и увидел увидел у всех сессию со статусом 1, т.е. незавершенная, "залипшая". а получается, что при создинии бэкапа базы практически у всех пользователей открыты pppoe сессии, и при восстановлении из бзкапа и запуске UTM сессии так и остались висеть. из интерфейса не убиваются.
это пол беды.
проверяем voip, может, думаю, здесь все хорошо.
делаю один звонок, в логах вроде все прилично. иду в интерфейс смотрю отчет. опять засада! время начала звонка 5:18:11 конец 12:18:15. длительность 0 сек. цена посчитана правильно. время соединения было 4 сек. что это значит? делаю второй звонок, он уже в отчеты не попадает, смотрю логи радиуса и вижу:
Device busy
Acct: Error: 1: Operation not permited
Acct: Error: 2: No such file or directory
перевожу аккаунтинг на 5.1.9-006 там все нормально.
ну, думаю, вот и перешел на новую версию.
Ваш биллинг становится похож на анекдот:
сисадмин на стрельбищах выпускает магазин по мишени. ему говорят-" ни одна пуля не попала в цель". он в ответ-"не знаю, от меня все пули улетели, это что-то с вашей стороны".
У меня UTM 5.1.9.006 проработал почти с самого выхода до вчерашнего дня без остановок. дернул меня хрен сгенерировать детальную статистику по пользователю за день.
2. да я понимаю что все можно делать в ручную
3. ну не давно, а только с версии 5.1.10-011
4. у меня не хватает времени каждый раз читать в факе можно нажимать ту или иную кнопочку в интерфейсе, и что из этого получится.
5. только удивляет например почему "file not found" это значит не добавлен NAS сервер.
6. в UTM я пользуюсь только подсчетом трафика по NetFlow и pppoe. ни периоды ни тарифные планы не применяю. расчетные периоды просто были заведены при инсталяции системы и теперь они живут своей жизнью, то их появляется некоторое количество, то потом исчезают.
7. интерфейс был написан в Индии? и теперь Вы его переводите?
8. я давно мечтал завести обсчет voip на UTM, но останавливало отсутствие сортировки направлений. и вот УРА вышел 5.1.10-011. думаю "вот молодцы ребятя, действительно нужная вещь!"
ну ясно решил сначала испытать все шаги перехода на новую версию. взял бэкап с основного сервера, залил на тестовый, поставил 5.1.10-011,обновил базу скриптом, запустил, все стартануло.
теперь надо проверить pppoe. отключаю радиус основного сервера, cisco автоматом начала посылать запросы на тестовый. в логах сразу получил "unable to claim IP", не мне Вам рассказывать что это значит.
посмотрел я отчеты dialup и увидел увидел у всех сессию со статусом 1, т.е. незавершенная, "залипшая". а получается, что при создинии бэкапа базы практически у всех пользователей открыты pppoe сессии, и при восстановлении из бзкапа и запуске UTM сессии так и остались висеть. из интерфейса не убиваются.
это пол беды.
проверяем voip, может, думаю, здесь все хорошо.
делаю один звонок, в логах вроде все прилично. иду в интерфейс смотрю отчет. опять засада! время начала звонка 5:18:11 конец 12:18:15. длительность 0 сек. цена посчитана правильно. время соединения было 4 сек. что это значит? делаю второй звонок, он уже в отчеты не попадает, смотрю логи радиуса и вижу:
Device busy
Acct: Error: 1: Operation not permited
Acct: Error: 2: No such file or directory
перевожу аккаунтинг на 5.1.9-006 там все нормально.
ну, думаю, вот и перешел на новую версию.
Ваш биллинг становится похож на анекдот:
сисадмин на стрельбищах выпускает магазин по мишени. ему говорят-" ни одна пуля не попала в цель". он в ответ-"не знаю, от меня все пули улетели, это что-то с вашей стороны".
Not Found
The requested URL /fom-serve/cache/18.html. was not found on this server.
Apache/1.3.27 Server at old.netup.ru Port 80
По поводу 8... ещё session-timeout не выставляет и idle-timeout... а надо бы... Вообще когда будет возможность в радиус вставлять свои ответы 1. для конкретных юзверей, 2. для роутера (реализация по типу правил файрволов....)
The requested URL /fom-serve/cache/18.html. was not found on this server.
Apache/1.3.27 Server at old.netup.ru Port 80
По поводу 8... ещё session-timeout не выставляет и idle-timeout... а надо бы... Вообще когда будет возможность в радиус вставлять свои ответы 1. для конкретных юзверей, 2. для роутера (реализация по типу правил файрволов....)