Управление сервером СмИТ Биллинг 1.0

Раздел описывает настройку, обслуживание и администрирование сервера СмИТ Биллинг 1.0. Здесь представлена полная информация по конфигурации сетевых параметров, безопасности, управлению модулями и удалённому доступу к серверу.

Настройка сервера

Первоначальная настройка сервера выполняется через веб-интерфейс управления или через конфигурационные файлы. Ниже описаны основные подразделы настройки.

Настройки сети

Конфигурация сетевых интерфейсов сервера: IP-адреса, маски подсети, шлюзы, DNS-серверы. Настройка VLAN-интерфейсов и бондинга (агрегации каналов). Для изменения сетевых параметров используется раздел Сервер → Настройки сети в веб-интерфейсе управления. После внесения изменений требуется перезагрузка сетевых служб.

При смене IP-адреса сервера необходимо также обновить настройки NAS-устройств, указывающих на RADIUS-сервер, а также конфигурацию DNS-записей.

Безопасность

Настройка параметров безопасности сервера: правила межсетевого экрана (firewall), ограничение доступа по IP-адресам, настройка SSL/TLS-сертификатов для веб-интерфейса. Рекомендуется ограничить доступ к портам управления (SSH, веб-интерфейс) только доверенными IP-адресами. Встроенный firewall позволяет создавать правила фильтрации трафика на уровне сетевых интерфейсов.

Настройки watchdog

Watchdog-модуль автоматически отслеживает состояние критических сервисов и перезапускает их в случае зависания или аварийного завершения. Настраиваемые параметры включают: интервал проверки (по умолчанию 30 секунд), список контролируемых процессов, действия при обнаружении сбоя (перезапуск сервиса, отправка уведомления, перезагрузка сервера). Журнал срабатываний watchdog доступен в разделе мониторинга.

Система уведомлений об ошибках

Настройка оповещений о критических событиях и ошибках системы. Поддерживаемые каналы уведомлений: электронная почта (SMTP), Telegram-бот, SMS-шлюз. Для каждого канала настраиваются: список получателей, уровень критичности событий (info, warning, error, critical), шаблоны сообщений. Уведомления отправляются при сбоях в работе RADIUS, проблемах с дисковым пространством, высокой нагрузке на процессор и других аномалиях.

Настройка времени

Корректная настройка времени критична для работы биллинговой системы: тарификация, логирование, RADIUS-авторизация зависят от точного времени. Настраивается часовой пояс и NTP-серверы для автоматической синхронизации. Рекомендуется использовать не менее двух NTP-серверов для обеспечения отказоустойчивости.

Настройки (в файле)

Расширенные настройки конфигурируются через переменные окружения (.env) и файл config/settings.py. После редактирования перезапустите контейнеры:

docker compose restart web celery celery-beat

Сервисное обслуживание

Регулярные операции обслуживания для обеспечения стабильной работы биллинговой системы.

Обновление биллинга

Обновление выполняется через Docker-образы и Django-миграции:

# Бэкап → обновление → миграция → перезапуск
docker compose exec db pg_dump -U carbon carbon > backup.sql
docker compose pull
docker compose exec web python manage.py migrate
docker compose exec web python manage.py collectstatic --noinput
docker compose up -d

Рекомендуется выполнять обновления в период минимальной нагрузки (ночные часы).

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

Резервное копирование

Резервное копирование PostgreSQL и конфигурации:

# Бэкап БД
docker compose exec db pg_dump -U carbon carbon > backup_$(date +%Y%m%d).sql

# Бэкап конфигурации и данных
docker compose exec web tar czf /tmp/config_backup.tar.gz .env config/ docker/

# Восстановление
docker compose exec -T db psql -U carbon carbon < backup.sql

Настраивается расписание автоматического копирования (ежедневно, еженедельно через cron), глубина хранения копий, удалённое хранилище (FTP, SFTP, S3).

Замена оборудования

Процедура переноса биллинговой системы на новое серверное оборудование. Включает создание полного бэкапа, подготовку нового сервера, восстановление данных и верификацию работоспособности. При замене оборудования может потребоваться повторная активация лицензии (см. раздел «Повторная активация»).

Выключение/перезагрузка

Корректное выключение и перезагрузка сервера через веб-интерфейс управления. Перед выключением система автоматически завершает текущие сессии и сохраняет состояние. При плановой перезагрузке рекомендуется предварительно уведомить пользователей. Кнопки управления доступны в разделе Сервер → Выключение.

Отказоустойчивость БД

Настройка репликации базы данных PostgreSQL для обеспечения отказоустойчивости. Поддерживается потоковая репликация (streaming replication) с автоматическим переключением на резервную копию при сбое основного сервера. Конфигурация включает настройку master-slave репликации, мониторинг отставания реплики и автоматический failover.

Система мониторинга

Встроенная система мониторинга состояния сервера и сервисов: загрузка процессора, использование оперативной памяти, дискового пространства, сетевой активности. Поддерживается интеграция с внешними системами мониторинга (Zabbix, Prometheus/Grafana). Оповещения при превышении пороговых значений отправляются через настроенные каналы уведомлений.

Количество абонентов

Информация о текущем количестве абонентов в системе и лимитах лицензии. Отображается число активных, заблокированных и архивных абонентов. При приближении к лимиту лицензии система отправляет уведомление. Для увеличения числа абонентов требуется расширение лицензии.

Расширение лицензии

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

Повторная активация

Повторная активация лицензии требуется при замене серверного оборудования, переустановке операционной системы или изменении аппаратной конфигурации сервера (замена материнской платы, сетевых адаптеров). Для повторной активации необходимо обратиться в техническую поддержку с указанием номера лицензии и нового аппаратного идентификатора.

Управление модулями

Система состоит из Docker-контейнеров, управляемых через Docker Compose:

Сервис	Контейнер	Назначение
db	PostgreSQL 16 Alpine	Основная база данных
redis	Redis 7 Alpine	Кэш, сессии, брокер Celery
web	Python 3.11 + Gunicorn	Веб-интерфейс (Django 4.2)
celery	Python 3.11	Фоновые задачи (тарификация, блокировки, рассылки)
celery-beat	Python 3.11	Планировщик задач
freeradius	FreeRADIUS 3.2.3	Авторизация абонентов (rlm_python3)
nginx	Nginx 1.25 Alpine	Reverse proxy, статика, SSL

Управление сервисами:

# Статус всех контейнеров
docker compose ps

# Перезапуск биллинга
docker compose restart web celery celery-beat

# Просмотр логов
docker compose logs -f web
docker compose logs celery --tail=100

Диагностика

Инструменты диагностики Docker-контейнеров:

# Статус контейнеров и health checks
docker compose ps

# Логи конкретного сервиса
docker compose logs web --tail=200
docker compose logs celery --tail=200

# Потребление ресурсов
docker stats

# Подключение к контейнеру
docker compose exec web bash
docker compose exec db psql -U carbon carbon

Web (Django + Gunicorn)

Основной модуль биллинга. Содержит: веб-интерфейс (AdminLTE 3 + Bootstrap 5.3), REST API v2, SOAP API. Конфигурация через .env и config/settings.py. Перезапуск: docker compose restart web.

Celery (фоновые задачи)

10 задач в 7 модулях: тарификация (5 мин), блокировки (5 мин), смена тарифов (10 мин), рассылки (1 мин), CSV-импорт (10 мин) и др. Перезапуск: docker compose restart celery celery-beat.

Collector

Модуль сбора статистики трафика. Принимает данные Netflow/sFlow от маршрутизаторов и коммутаторов, агрегирует их и передаёт в биллинг для тарификации. Настраивается порт приёма данных и формат (Netflow v5/v9, IPFIX, sFlow).

Zabbix

Модуль интеграции с системой мониторинга Zabbix. Обеспечивает экспорт метрик состояния сервера и сервисов биллинга в Zabbix-сервер. Настраивается адрес Zabbix-сервера, интервал отправки данных и набор отслеживаемых параметров.

Хуки/firewall

Модуль пользовательских хуков и управления межсетевым экраном. Хуки позволяют выполнять пользовательские скрипты при определённых событиях (авторизация абонента, блокировка, изменение тарифа). Firewall-модуль управляет правилами iptables/nftables для ограничения и перенаправления трафика абонентов.

Удалённое управление. Смена стандартного пароля

Удалённый доступ к серверу осуществляется по протоколу SSH (порт 22 по умолчанию). При первом подключении к серверу необходимо сменить стандартный пароль.

Для смены пароля root выполните команду:

passwd root

Рекомендации по безопасности удалённого доступа:

Смените стандартный порт SSH (например, на 2222 или другой нестандартный).
Используйте авторизацию по ключам вместо пароля.
Ограничьте доступ по SSH с помощью firewall (разрешите только доверенные IP).
Установите fail2ban для защиты от перебора паролей.
Отключите вход под root по паролю, используйте sudo.

Дополнительные возможности

Расширенные функции сервера СмИТ Биллинг 1.0:

API-интерфейс — REST API для интеграции со сторонними системами (CRM, ERP, личные кабинеты).
Кластеризация — объединение нескольких серверов для обеспечения отказоустойчивости и балансировки нагрузки.
Пользовательские скрипты — возможность добавления собственных скриптов обработки событий (хуки).
Интеграция с внешними БД — подключение к внешним базам данных для обмена данными.
Журналирование — расширенное логирование всех операций системы с возможностью экспорта в SIEM-системы.