В данном руководстве рассматриваются вопросы эксплуатации приложений, входящих в состав АСР «Гидра». С полной схемой их взаимодействия можно ознакомиться на странице с описанием взаимодействия приложений.

Веб-приложения

• Офис оператора связи (hoper или arm_isp)
• Личный кабинет абонента (hupo или arm_private_office)
• «Миграция» (arm_migration)
• Платежный портал (arm_payments)
• Портал авторизации (huas)

Каждое приложение устанавливаются на сервере в отдельную директорию (например, «Офис оператора связи» — в /opt/hydra/rails/arm_isp, «Личный кабинет абонента» — в /opt/hydra/rails/arm_ispprivate_office и т.д.), которая имеет следующее содержимое:

• releases — директория с релизами (версиями) приложений. В данной директории хранятся все устанавливаемые на сервер версии заданного приложения для возможности отката к предыдущей версии в случае неудачного обновления.

• current — символическая ссылка на директорию с текущей используемой версией приложения. На данную ссылку устанавливается путь до приложения в настройках виртуального хоста в настройках веб-сервера.

• shared — директория с общими данными приложения, которые используются независимо от релизов. В данной директории, в частности, хранятся временные файлы и логи, которые генерирует приложение во время своей работы.

Эксплуатация

1. Ротация и архивация лога
   
   В процессе своей работы веб-проложения сохраняет лог выполнения запросов в файл shared/log/production.log, размеры которого со временем эксплуатации системы могут достигать нескольких гигобайтгигабайт. Чтобы избежать угрозы нехватки свободного дискового пространства, рекомендуется регулярно производить ротацию и архивацию данного лога, например, с помощью logrotate.
    
   
2. Удаление старых релизов
   
   Со времением эксплуатации в директории releases может накопиться большое количество устаревших версий приложения, которые уже не совместимы с текущей установленной версией. Чтобы избежать засорения заполненного дискового пространства, рекомендуется производить регулярное удаление старых релизов, например, спустя месяц с момента их последнего использования.
   
   

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

   Code Block
   rails@server:~/arm_isp$ touch current/tmp/restart.txt

   
   

4. Запуск, остановка, перезапуск
   
   Управление работой веб-приложений в общем случае осуществляется с помощью инит-скрипта веб-сервера nginx Apache /etc/init.d/nginxapache. Например, команда на перезапуск nginx-а Apache имеет следующий вид:

   Code Block
   root@server:~# /etc/init.d/nginxapache2 restart

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

Менеджер соединений с БД

• connection_manager или hcmd
  

Менеджер соединений написан с использованием фреймворка Ruby on Rails на языке Ruby, запускается под пользователем ОС rails и имеет аналогичную веб-приложениям структуру директорий. Он запускается в режиме демона и предоставляет интерфейс взаимодействия с БД со стороны веб-приложений.

Эксплуатация

...

Запуск, остановка, перезапуск
 
Управление работой менеджера соединений осуществляется с помощью инит-скрипта /etc/init.d/hydra_connection_manager. Например, команда на перезапуск имеет следующий вид: 

root@server:~# /etc/init.d/hydra_connection_manager restart

Приложения-агенты

• Коллектор трафика (hcd)
• Автономный RADIUS-демон (hard)
• Менеджер активного оборудования (hamd)
• Платежный шлюз (hpd)
• Демон интерфейса (hid)

Все агенты написаны на языке Python и имеют одинаковые возможности по настройке и управлению выполнением. При промышленной эксплуатации они запускаются в режиме демона и управляются с помощью индивидуального инит-скрипта (например, для hcd — /etc/init.d/hcd). Для работы каждого приложения существует персональный конфигурационный файл, в котором задаются параметры запуска и логгирования. Например, для hard (файл /etc/hard/hard.conf):

# Уровень лог-сообщений
log level = debug
# Путь до лог-файла
log path = /var/log/hard/hard.log
# Максимальный размер лог-файла до создания нового, Кб
log rotate size = 10240
# Количество резервируемых лог-файлов
log rotate count = 25
# Путь до PID-файла приложения
pid path = /var/run/hydra/hard.pid 

Эксплуатация 

1. Ротация и архивация лога

   В процессе своей работы приложения ведут лог в индивидуальном файле, путь к которому задается в конфиге (например, для hard — /var/log/hard/hard.log). Все агенты имеют встроенный функционал встроенную функциональность по ротации лог-файла. При настройке параметров, отвечающих за ротацию (log rotate size и log rotate count) важно уделить внимание интенсивности заполнения лог-файла во время эксплуатации системы, на основе которой выставить подходящие значения в конфиге. Лог-файл должен содержать данные минимум за последнюю неделю работы приложения.

   
   

2. Ротация лога MongoDB
   
   Агент hard для своей работы использует объектную БД MongoDB, которая в процессе своей работы формирует лог в файле /var/log/mongodb/mongodb.log, размеры которого со временем эксплуатации системы могут достигать нескольких гигабайт. Чтобы избежать угрозы нехватки свободного дискового пространства, рекомендуется регулярно производить ротацию и архивацию данного лога, например, с помощью logrotate. 

   Code Block
   language bash title /etc/logrotate.d/mongodb-server
   /var/log/mongodb/mongodb.log { daily missingok rotate 7 compress delaycompress notifempty create 640 mongodb mongodb sharedscripts # find в скриптах удаляет log files, которые mongodb ротирует встроенным механизмом. postrotate killall -SIGUSR1 mongod find /var/log/mongodb/ -type f -regex ".*\.\(log.[0-9].*-[0-9].*\)" -exec rm {} \; endscript }

   
   

3. Очистка кэша hard

   В некоторых случаях при работе агента hard (Автономный RADIUS-демон) необходима очистка кэша внутренней объектной БД MongoDB, используемой для кэширования данных. Осуществить очистку кэша можно с помощью следующих команд:

   Code Block
   root@server:~# mongo MongoDB shell version: 1.4.4 url: test connecting to: test type "help" for help > use hard_cache switched to db hard_cache > db.dropDatabase() { "dropped" : "hard_cache.$cmd", "ok" : 1 }

   
   

4. Запуск, остановка, перезапуск
   

    
   Управление работой приложений-агентов осуществляется с помощью индивидуального инит-скрипта (например, для hpd — для hpd — /etc/init.d/hpd). Команда на перезапуск имеет следующий вид:

   Code Block
   root@server:~# /etc/init.d/hpd restart

   
   

SNMP-коллектор данных (hsnmp)

SNMP-коллектор данных аналогично агентам имеет собственный конфигурационный файл /etc/hsnmp/hsnmp.conf, в котором задаются параметры его работы и логгирования.

Эксплуатация

1. Ротация и архивация лога
   

   В процессе своей работы коллектор ведет лог в индивидуальном файле, путь к которому задается в конфиге. Аналогично агентам hsnmp имеет встроенную функциональность по ротации лог-файла. При настройке параметров, отвечающих за ротацию (log rotate size и log rotate count) важно уделить внимание интенсивности заполнения лог-файла во время эксплуатации системы, на основе которой выставить подходящие значения в конфиге. Лог-файл должен содержать данные минимум за последнюю неделю работы приложения.

   
   

2. Архивация датафайлов
   
   Во время работы коллектор генерирует датафайлы, которые удаляются после загрузки в систему (режим load, см. описание работы коллектора). Однако в некоторых случаях загружаемые датафайлы могут потребоваться для анализа причин появления трафика у абонентов. Чтобы иметь такую возможность, перед загрузкой рекомендуется производить копирование готовых к загрузке датафайлов в отдельное хранилище, где они будут храниться в течение длительного времени.

Ядро (БД Oracle 11g)

Файлы с данными БД располагаются на сервере, как правило, в директории /var/oradata. В данной директории находятся файлы табличного пространства (основные — HYDRA и HYDRA_INDEX), redo-логи и вспомогательные датафайлы. В процессе работы БД СУБД создает файлы журналы работы и трассировки в директориях /opt/oracle/admin и /opt/oracle/diag/rdbms.

Эксплуатация

1. Мониторинг свободного табличного пространства
   
   Для предупреждения внезапной нехватки свободного табличного пространства в процессе эксплуатации системы настоятельно рекомендуется произвести настройку мониторинга свободного табличного пространства, подробнее о котором отдельно можно узнать на отдельной странице.
   
2. Контроль выполнения заданий системы
   
   Для предотвращения нарушения логики работы системы крайне важно настроить мониторинг выполнения встроенных заданий, который необходимо адаптировать под конкретно используемые для инсталляции задания.
   
   

3. Ротация и архивация файлов журналов и трассировки
   
   В процессе своей работы БД может создавать большое количество файлов журналов и трассировки в директориях /opt/oracle/admin и /opt/oracle/diag/rdbms, которые могуг занимать большое количество дискового пространства. Чтобы этого не произошло рекомендуется производить регулярное удаление старых файлов, например, спустя месяц с момента их создания. В случае, если установлен резервный (standby) сервер, то также необходимо проводить ротацию файла /opt/hydra/oracle/logs/update.log
    

4. Ротация и архивация логов работы с внешними таблицами
   
   При работе с внешними таблицами Oracle пишет данные о результатах работы в отдельные для каждой таблицы файлы. Внешние таблицы используются, например, для загрузки в основную БД данных аккаунтинга агентом HARD (начиная с версии 4.0). Рекомендуется настроить ротацию этих логов и периодически удалять старые файлы. Например, ротацию выполнять ежедневно, и удалять те файлы, с момента изменения которых прошло более месяца.
   
   Путь к директории с файлами может быть получен с помощью запроса:
   

   Code Block
   language sql
   SELECT DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE DIRECTORY_NAME = 'HYDRA_TMP_DIR'

   
   

   Note
   При работе с директорией HYDRA_TMP_DIR следует учитывать, что логи работы с внешними таблицами хранятся только в файлах *.log: удаление или изменение других файлов может привести к некорректной работе системы.

    

5. Запуск, остановка, перезапуск

    
   Управление работой установленных на сервере БД осуществляется с помощью инит-скрипта /etc/init.d/ora.database. Например, команда на перезапуск имеет следующий вид: 

   Code Block
   root@server:~# /etc/init.d/ora.database restart

   
   

6. Удаление данных о неучтенном трафике
   

   При появлении в системе большого количества данных о неучтенном трафике (таблица EX_TRAFFIC_COLLECT_C, число строк — более 2 млн.), необходимо производить очистку данных с помощью следующего SQL-запроса:

   Code Block
   language sql
   SQL> TRUNCATE TABLE EX_TRAFFIC_COLLECT_C;

   Запрос необходимо выполнять от имени пользователя AIS_NET.
   
   

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

Возможные проблемы

1. Ошибка «ORA-01555: snapshot too old» в задании по анализу схемы БД
   В ходе эксплуатации системы при работе задания по анализу схемы БД может возникать ошибка, связанная с недостаточным размером rollback-сегментом БД. Например:

   Code Block
   ORA-01555: snapshot too old: rollback segment number 8 with name "_SYSSMU8_2372141723$" too small

   Для решения проблемы необходимо узнать текущую величину rollback-сегмента при помощи запроса:

   Code Block
   select p.value undo_retention, max(maxquerylen) maxquerylen, (max(maxquerylen) * 1.2) undo_retention_optimal, (p.value - max(maxquerylen) * 1.2) delta from v$undostat s, v$parameter p where p.name = 'undo_retention' group by p.value;

   Если значение undo_retention_optimal сильно отличается от undo_retention в большую сторону (параметр delta отрицательный), необходимо выполнить следующую команду:

   Code Block
   SQL> alter system set undo_retention=$undo_retention_optimal scope=both;

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

   Запрос необходимо выполнять от имени пользователя AIS_NET.