Skip to main content

Сценарии аварийного восстановления

НазначениеОписание

ОписаниеНиже типовыхописаны сценариевтиповые сценарии аварийного восстановления системы Printum: симптомы, порядок действий и ориентировочное время восстановления. Для успешного восстановления системы обязательно иметь резервные копии Мониторинга и ПринтМенеджера(ов) в рабочем состоянии, созданные с помощью встроенного функционала резервного копирования или внешними средствами (например, снапшота\бэкапами на гипервизоре).

Сценарий 1 —1: Отказ одного сервера ПринтМенеджера в кластере

конфигурации

кластера

Симптомы

  • СтраницаНа состоянияпанели администратора HAProxy показывает один или несколько узловсервисов конкретного сервера ПМ отображаются как «DOWN». и подсвечены красным цветом.
  • Часть заданий непечати, обрабатывается;копирования пользователии сканирования пользователей не замечаютобрабатывается сбояустройствами (еслипод узловуправлением ≥ 2).печатью.

Порядок действий

  1. ПроверитьПроверьте статус контейнеров на отказавшем сервере:
cd /opt/printmanager && sudo docker-compose ps
    Соберите логи для последующей диагностики: 
    sudo /opt/printmanager/logs.sh
      ИзучитьПерезапустите логи:контейнеры ПМ: 
      sudo docker-compose logsdown
--tail=200sudo
      Перезапустить контейнеры: docker-compose restartup -d
      1. Если работоспособность ПМ не помогаетвернулась, —выполните восстановитьего восстановление из резервной копии (см. «ВосстановлениеРезервное изкопирование резервнойи копии»восстановление данных»).
      2. После восстановления проверитьпроверьте страницусостояние состояниясервисов всех ПМ на странице панели администратора HAProxy.
      Проведите анализ собранных логов для установления причин отказа. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

      Ориентировочное время: 15–30 минут при перезапуске; 60–120 минут при восстановлении из резервной копии.

      Сценарий 2 — Отказ нескольких серверов ПринтМенеджера

      Симптомы

      • Большинство заданий печати, копирования и сканирования пользователей не обрабатываются.обрабатываются не обрабатываются на устройствах под управлением печатью.
      • На панели администратора HAProxy показывает менее половины узлов отображаются в статусе «UP» и отмечены зелёным цветом (кластер утратил кворум).

      Порядок действий

      1. ВосстановитьВосстановите наибольшеесервера числоПринтМенеджера, серверовпо ПринтМенеджер (перезапуск контейнеров или восстановлениеописанию из резервнойсценария копии)№1 (пункты 1-6).
      2. Убедиться,После чтовосстановления: активно
        ≥
      3. Проверьте (N/2состояние +сервисов 1)всех узловПМ (кворум),на гдестранице Nпанели —администратора общее число узлов.HAProxy.
      4. ПроверитьПроверьте статусуспешность HAProxyвыполнения заданий печати, копирования и синхронизациюсканирования сна Мониторингом.устройствах под управлением печатью.
      Проверьте работу синхронизации данных между Мониторингом и ПМ. Проведите анализ собранных логов для установления причин отказа. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

      Ориентировочное время: 60–240 минут в зависимости от числа отказавших узлов.

      Сценарий 3 — Потеря базы данных PostgreSQL

      Симптомы

      • Ошибки в логах ПМ: django.db.utils.OperationalError: connection to server failed
      • Веб-интерфейс Личного кабинета недоступен или отображает ошибки.

      Порядок действий

      1. Убедиться,Убедитесь, что контейнер PostgreSQL запущен:

      sudo docker ps | grep postgres

      1. Если контейнер упалне запущен — перезапустить:запустите его:

        Для Мониторинга 
        cd /opt/printum
sudo docker-compose up -d postgres
          Для ПМ 
          cd /opt/printmanager
sudo docker-compose up -d db

          1. Если данныевозникают поврежденыошибки — восстановитьсоберите базулоги работы контейнеров и выполните восстановление из резервной копии.

            копии:
          sudo /opt/printum/logs.sh
#или
sudo /opt/printmanager/logs.sh

            Для восстановления на чистый сервер выполнитьвыполните команды (см.из раздела «Восстановление изрезервных резервнойкопий» копии»):

            на 
            sudoстранице tar«Резервное xzvfкопирование printum_backup_<date>и восстановление данных».tar.gz
sudo printum_backup_<date>/restore.sh

            ПодождатьПодождите несколько минут для запуска системы.

            Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

            Ориентировочное время: 30–120 минут в зависимости от объёма данных.

            Важно: IP-адрес или hostname сервера должны совпадать с теми, что были при создании резервной копии.

            Сценарий 4 — Потеря NFS-хранилища (кластер)

            Симптомы

            • Пользователи при попытке печатипечати, копирования и сканирования заданий на устройствах под управлением печатью получают ошибку «Файл недоступен».
            • Логи ПринтМенеджерПринтМенеджера содержат ошибки обращения к NFS-директории.

            Порядок действий

            1. ПроверитьПроверьте доступность 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-сервера в /opt/printmanager/.env:

              файле конфигурации ПМ: 
              sudo cat /opt/printmanager/.env

              Проверить

              DRIVER_OPTS_DEVICE,Соберите DRIVER_OPTS_O,логи DRIVER_OPTS_TYPE.работы ПМ для последующей диагностики: 
              sudo /opt/printmanager/logs.sh
                Выполните

                восстановление NFS-сервера из резервной копии. После восстановления NFSперезапустите перезапуститьконтейнеры контейнеры:ПМ:

                cd /opt/printmanager
sudo docker-compose restartdown
sudo docker-compose up -d

                1. Проверить,Проверьте, что задания в отложенной очереди обрабатываются.

                  печати, копирования и сканирования обрабатываются корректно.
                Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

                Ориентировочное время: 15–60 минут.

                Связанные страницы

                Проверка резервных копий Резервное копирование —и обзорвосстановление данных
                Back to top