Обслуживание системы

Создание резервных копий

Полная копия DPA включает в себя следующие компоненты:

1. Резервная копия базы данных Host
2. Резервные копия баз данных KPI, UserActionLog, Mesenger (если компоненты используются)
3. Установочный файл соответствующей версии DPA
4. Архив индикаторов
5. Архив медиафайлов

Перед началом резервного копирования: Определите номер установленной версии и директивы хранения файлов, для этого перейдите: Меню настройки -> Мониторинг , выберите DPA Host (ваш экземпляр может называться иначе) и в правой части экрана вы увидите установленную версию.

Для того чтобы воспользоваться резервной копией, вам потребуется установочный файл этой версии DPA Определите место хранение индикаторов. По умолчанию индикаторы хранятся в файловой системе и поэтому не будут включены в резервную копию. Директорию хранения вы можете посмотреть: Меню настройки -> Настройки системы -> Хранение данных

Файлы из директории, указанной в пункте «Лог индикаторов» необходимо хранить и архивировать вручную или настроить архивирование по расписанию с помощью стороннего ПО (например, Windows Планировщик заданий и WinRAR https://winrar-fansite.com/instructions/kak-nastroit-avtomaticheskoe-arhivirovanie-fajlov-cherez-winrar.html)

Примечание 1: при создании/редактировании индикаторов настройки хранения могли быть изменены на базу данных (пример приведен на рисунке ниже), такая настройка не является рекомендуемой, но в этом случае копировать файлы индикаторов отдельно – не нужно.

Примечание 2: при определении периодичности создания резервных копий важно учитывать интервалы очистки журналов и индикаторов. Проверка и запуск автоматической процедуры очистки журналов и файлов происходит ежедневно в 3:00 AM.

Определите место хранение медиа-файлов, используемых модулем «Технологии» (если таковые имеются).

Для резервного копирования БД (Host и KPI, UserActionLog, Mesenger) предлагается воспользоваться SQL Server Management Studio:

1. После подключения к соответствующему экземпляру в обозревателе объектов выберите требуемую базу данных, щелкните правой кнопкой мыши на базу данных, выберите Задачи и выберите команду Создать резервную копию...
2. В диалоговом окне Резервное копирование базы данных выбранная база данных приводится в раскрывающемся списке (ее можно изменить на любую другую базу данных на сервере).
3. В раскрывающемся списке Тип архивной копии выберите нужный вариант (по умолчанию выбран тип Полная).
4. В разделе Компонент резервного копирования выберите База данных.
5. В разделе Назначение проверьте расположение по умолчанию для файла резервной копии
6. Чтобы начать резервное копирование, нажмите кнопку OK.

После успешного завершения резервного копирования щелкните ОК, чтобы закрыть диалоговое окно SQL Server Management Studio.

Развертывание резервных копий

Для развертывания DPA на архивных данных необходимо:

• Подготовить отдельный ПК/сервер, отвечающий системным требованиям системы:
  • ОЗУ: 1000 Гб
  • SQL 2016 Standard+, 64 bit
  • Windows Server 2016+, Standart+, 64 bit
• Разархивировать файлов индикаторов и медиафайлов в директориях (стандартных см. Рисунок 2 или пользовательских)
• Развернуть резервную копию базы данных
  • После подключения к соответствующему экземпляру в обозревателе объектов создайте базу данных с именем идентичным имени резервируемой базы
  • Выберите созданную базу данных, щелкните правой кнопкой мыши на базу данных, выберите Задачи и выберите команду Восстановить/База данных
  • В диалоговом окне Восстановление базы данных выбранная база данных приводится в раскрывающемся списке (ее можно изменить на любую другую базу данных на сервере).
  • Выберите опцию «Устройство» в разделе «Источник», в раскрывшемся диалоговом окне нажмите кнопку добавить и выберите файл искомой резервной копии
  • Чтобы начать восстановление, нажмите кнопку OK.
  • После успешного завершения щелкните ОК, чтобы закрыть диалоговое окно SQL Server Management Studio.

Финальный шаг - Установить DPA на подготовленный ПК в соответствии с инструкцией по установке, на шагах «DPA Host» (а так же «DPA KPI», «DPA UserActionLog», «DPA Mesenger», если требуется) выберите существующую восстановленную базу.

Самостоятельная диагностика неполадок

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

Возможные проявления:

• не доступен Host (сайт)
• не поступают данные с оборудования:
  • со всего оборудования
  • части оборудования
• не доступен один или несколько микросервисов

1. Первое что нужно проверить - запущена ли служба компонента.

На сервере, на котором установлен соответствующий компонент: Диспетчер задач -> Службы -> Открыть службы

Удостоверьтесь, что служба запущена и выполняется.

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

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

Неконтролируемые периодические остановки службы могут быть вызваны работой антивируса или недостаточностью ресурсов сервера.

Пример: Раз в сутки в 3:59 PM происходила остановка службы, выяснилось, что в это время работает ПО, которое завершает все процессы, не внесенные в белый список.

На сервере, на котором установлен соответствующий компонент: Диспетчер задач -> Производительность -> Мониторинг ресурсов

Оцените на сколько загружен процессор и какие службы получают большую долю ресурсов, возможно службам компонентов DPA не хватает ресурсов для запуска.

Пример: в ходе диагностики обнаружилось, что SQL сервер после перезагрузки сервера потреблял ~100% ОЗУ и не позволял стартовать другим службам, после настройки ограничений на потребление ОЗУ для SQL проблема решилась. Такая проблема, как правило, характерна для низкопроизводительных серверов, выделенных на тестовый период, особенно в случаях когда к системе мониторинга подключено много высокопроизводительного оборудования.