Документация по АСР «Гидра»
Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

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


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

  • Офис оператора связи (hoper или arm_isp)
  • Личный кабинет абонента (hupo или arm_private_office)
  • «Миграция» (arm_migration)
  • Платежный портал (arm_payments)
  • Портал авторизации (huas)
Веб-приложения, работающие с АСР «Гидра», основаны на фреймворке Ruby on Rails (язык Ruby). Они функционируют под пользователем ОС rails с помощью веб-сервера Apache в связке с модулем passenger. Версии веб-приложений устанавливаются на сервере сотрудниками компании «Латера» собственными средствами.

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

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

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

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

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

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

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

  2. Удаление старых релизов

    Со времением эксплуатации в директории releases может накопиться большое количество устаревших версий приложения, которые уже не совместимы с текущей установленной версией. Чтобы избежать заполненного дискового пространства, рекомендуется производить регулярное удаление старых релизов, например, спустя месяц с момента их последнего использования.

  3. Сброс кэша

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

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

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

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

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

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

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

  • connection_manager или hcmd

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

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

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

    В процессе своей работы менеджер соединений сохраняет лог выполнения запросов в файле shared/log/connection_manager.log, размеры которого со временем эксплуатации системы могут достигать нескольких гигабайт. Чтобы избежать угрозы нехватки свободного дискового пространства, рекомендуется регулярно производить ротацию и архивацию данного лога, например, с помощью logrotate.

  2. Удаление старых релизов

    Со времением эксплуатации в директории releases может накопиться большое количество устаревших версий приложения, которые уже не совместимы с текущей установленной версией системы. Чтобы избежать засорения дискового пространства, рекомендуется производить регулярное удаление старых релизов, например, спустя месяц с момента их последнего использования.

  3. Запуск, остановка, перезапуск
     
    Управление работой менеджера соединений осуществляется с помощью инит-скрипта /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. Очистка кэша hard

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

    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 }

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

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

    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, которые могуг занимать большое количество дискового пространства. Чтобы этого не произошло рекомендуется производить регулярное удаление старых файлов, например, спустя месяц с момента их создания.
     

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

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

    root@server:~# /etc/init.d/ora.database restart
  • No labels