Сценарии аварийного восстановления
Описание
Ниже описаны типовые сценарии аварийного восстановления системы Printum: симптомы, порядок действий и ориентировочное время восстановления.
Для успешного восстановления системы обязательно создавайте резервные копии Мониторинга и ПринтМенеджера(ов) в рабочем состоянии с помощью встроенного функционала резервного копирования или внешними средствами (например, снапшота\бэкапами на гипервизоре).
Сценарий 1: Отказ одного сервера ПринтМенеджера в конфигурации кластера
Симптомы
- На панели администратора HAProxy один или несколько сервисов конкретного сервера ПМ отображаются как «DOWN» и подсвечены красным цветом.
- Часть заданий печати, копирования и сканирования пользователей не обрабатывается устройствами под управлением печатью.
Порядок действий
- Проверьте статус контейнеров на отказавшем сервере:
cd /opt/printmanager && sudo docker-compose ps
- Соберите логи для последующей диагностики:
sudo /opt/printmanager/logs.sh
- Перезапустите контейнеры ПМ:
sudo docker-compose down
sudo docker-compose up -d
- Если работоспособность ПМ не вернулась, выполните его восстановление из резервной копии (см. «Резервное копирование и восстановление данных»).
- После восстановления проверьте состояние сервисов всех ПМ на странице панели администратора HAProxy.
- Проведите анализ собранных логов для установления причин отказа. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).
Ориентировочное время: 15–30 минут при перезапуске; 60–120 минут при восстановлении из резервной копии.
Сценарий 2 — Отказ нескольких серверов ПринтМенеджера
Симптомы
- Большинство заданий печати, копирования и сканирования пользователей не обрабатываются не обрабатываются на устройствах под управлением печатью.
- На панели администратора HAProxy менее половины узлов отображаются в статусе «UP» и отмечены зелёным цветом (кластер утратил кворум).
Порядок действий
- Восстановите сервера ПринтМенеджера, по описанию из сценария №1 (пункты 1-6).
- После восстановления:
- Проверьте состояние сервисов всех ПМ на странице панели администратора HAProxy.
- Проверьте успешность выполнения заданий печати, копирования и сканирования на устройствах под управлением печатью.
- Проверьте работу синхронизации данных между Мониторингом и ПМ.
- Проведите анализ собранных логов для установления причин отказа. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).
Ориентировочное время: 60–240 минут в зависимости от числа отказавших узлов.
Сценарий 3 — Потеря базы данных PostgreSQL
Симптомы
- Ошибки в логах ПМ:
django.db.utils.OperationalError: connection to server failed - Веб-интерфейс Личного кабинета недоступен или отображает ошибки.
Порядок действий
- Убедитесь, что контейнер PostgreSQL запущен:
sudo docker ps | grep postgres
- Если контейнер не запущен — запустите его:
- Для Мониторинга
cd /opt/printum
sudo docker-compose up -d postgres
- Для ПМ
cd /opt/printmanager
sudo docker-compose up -d db
- Если возникают ошибки — соберите логи работы контейнеров и выполните восстановление из резервной копии:
sudo /opt/printum/logs.sh
#или
sudo /opt/printmanager/logs.sh
- Для восстановления на чистый сервер выполните команды из раздела «Восстановление резервных копий» на странице «Резервное копирование и восстановление данных».
- Подождите несколько минут для запуска системы.
- Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).
Ориентировочное время: 30–120 минут в зависимости от объёма данных.
Важно: IP-адрес или hostname сервера должны совпадать с теми, что были при создании резервной копии.
Сценарий 4 — Потеря NFS-хранилища (кластер)
Симптомы
- Пользователи при попытке печати, копирования и сканирования заданий на устройствах под управлением печатью получают ошибку «Файл недоступен».
- Логи ПринтМенеджера содержат ошибки обращения к NFS-директории.
Порядок действий
- Проверьте доступность NFS-сервера с сервера ПМ: вручную создайте тестовый файл на NFS-сервере:
cd /opt/printmanager
sudo docker-compose exec app touch /opt/app/public/media/test.txt
- Убедитесь в правильности параметров DRIVER_OPTS_DEVICE, DRIVER_OPTS_O, DRIVER_OPTS_TYPE для NFS-сервера в файле конфигурации ПМ:
sudo cat /opt/printmanager/.env
- Соберите логи работы ПМ для последующей диагностики:
sudo /opt/printmanager/logs.sh
- Выполните восстановление NFS-сервера из резервной копии. После восстановления перезапустите контейнеры ПМ:
cd /opt/printmanager
sudo docker-compose down
sudo docker-compose up -d
- Проверьте, что задания в отложенной очереди печати, копирования и сканирования обрабатываются корректно.
- Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).
Ориентировочное время: 15–60 минут.