¶ 10.1. Обслуживание и диагностика Мастер-сервера
Для контроля работоспособности программных модулей Системы на Мастер-сервере используются следующие методы:
- контроль статуса сервисов, работающих в контейнерах;
# docker ps
В выводе команды необходимо убедиться в работоспособности минимум 4-х контейнеров со следующими именами brst-db, brst-redis, brst-master, brst-web
- В случае, если любой из перечисленных контейнеров не работает или находится в статусе «Restarting», для диагностики неисправности необходимо выполнить команду:
# docker logs <имя контейнера> -f
¶ 10.2. Резервное копирование данных Системы
При установке Мастер-сервера, резервное копирование БД конфигурации Системы и необходимых для восстановления файлов конфигурации доступно путем регулярного резервирования автоматически регистрируемого источника данных с именем хоста – «brst-db». Этот источник представляет собой контейнер, с котором на Мастер-сервере работает СУБД Postgresql, хранящая актуальную конфигурацию Системы. Перейдите в панели «Конфигурация» → «Источники данных» → «Агентские». Нажмите на меню «Открыть» напротив записи, где в качестве «Хост», указано «brst-db»:
Перейдите слева во вкладку «Базы данных». Откроется объект, который представляет из себя БД, содержащую актуальную конфигурацию и метаданные Системы:
В свойства этого объекта автоматически добавляются каталоги с файлами, которые будут резервироваться одновременно с данными БД Postgresql для создания консистентной резервной копии Системы:
Для постановки на регулярное резервное копирование, создайте политику и расписание для этого объекта. Перейдите в панели «Конфигурация» → «Политики Береста» → «Создать» Укажите произвольное имя политики и тип — «Базы данных». Оставьте приоритет политики максимальным – 255 и в поле "Максимум джобов" также оставьте значение по умолчанию – 1000:
Нажмите кнопку «Далее» и среди всех доступных объектов с типом «БД» выберите объект «brst-db»:
Нажмите кнопку «Далее» и выберите хранилище для резервных копий.
Внимание: в качестве хранилища резервной копии служебной БД допустимо использовать только следущие типы (FS,ZFS). Это необходимо для обеспечения возможности автоматической синхронизации на резервный узел кластера Мастер-сервера, а также возможности упрощенного аварийного восстановления Служебной БД на "пустой" Мастер с помощью сценария, описанного в данном разделе.
Рекомендация по выбору: используйте хранилище, созданное на сервере, отличном от сервера Мастера Системы.
- Завершите создание политики нажав кнопку «Далее» → «Создать»;
- В результате, в списке политик появится созданная политика. Активируйте политику, выберите ее и нажмите кнопку «Расписания»;
- В окне редактирования «Расписаний» выберите существующее или создайте новое расписание для резервирования данных Системы;
- Для объема БД Мастер-сервера (до 50 ГБ, рекомендуется создать расписания для резервирования каждый час, от 100 ГБ до 500 ГБ – каждые 12 часов, более 500 ГБ – каждый день). Нажмите кнопку «Создать» в меню «Расписания» и заполните параметры следующим образом имя – произвольно, время ожидания и количество попыток (по умолчанию), «Не удалять последнюю копию», тип копии БД «Полная копия БД», тип копии для ФС «Полный блочный».
Время хранения копии «1 неделя», периодичность запуска «1 час».
Нажмите кнопку «Далее» и задайте окно резервного копирования (в данном примере будет выполнятся ежечасное резервное копирование 24 часа в сутки, 7 дней в неделю).
Нажмите «Далее» → «Создать» и в списке расписаний появится вновь созданное расписание:
Если вы вернетесь на страницу «Политики Береста», то созданное расписание будет привязано к политики резервного копирования данных Системы:
Необходимые настройки выполнены. Перейдите в панели навигации «Центр управления» → «Монитор заданий» → «Береста». В таблице справа вы увидите записи об успешно выполненном задании на резервирование БД конфигурации Системы (если время запуска заданий уже наступило):
Также вы можете проверить, что задания запланированы в будущем, нажав кнопку отображения запланированных заданий:
Файлы с описанием местоположения всех резервных копий Системы (DR-файл) всегда хранятся на Силовых серверах Системы, на которых хранятся эти копии. Каталог для хранения DR-файлов /opt/beresta/brst-powerproxy/dr. Имена файлов (пример beresta_master_2024-05-20_133943.conf).
Рекомендуется дополнительно настраивать отправку DR-файлов на email Администратора Системы. Для этого в панели «Конфигурация» → «Настройки» → «Конфигурация Системы» → закладка «Планировщик», укажите Email Администратора системы.
¶ 10.3. Восстановление данных Системы
Для восстановления данных Системы в случае потери данных БД конфигурации следует:
- Выполнить начальную установку нового Мастер-сервера (см. «Руководство по установке») с именем хоста, совпадающим с именем восстанавливаемого Мастер-сервера (IP-адрес другой). Или если для подключения к Мастер-серверу вы использовали DNS-алиса, с любым именем хоста и другим IP-адресов;
- После развертывания нового Мастер-сервера проверьте доступность его WEB-консоли и логин, подключившись к ней по IP-адресу https://<IP-адрес нового Мастера>/ или по имени DNS-алиаса (если вы использовали этот вариант https<DNS-алиас Мастера>;
- Внесите изменения в DNS, заменив A-запись для имени Мастер-сервера, изменив IP-адрес на новый. (если на Силовых серверах или Агентах Системы вы используете hosts файл, внесите изменения в hosts файл);
- (Опционально). Дождитесь обновления DNS-кэша на Силовых серверах или Агентах (зависит от настроек вашего DNS). Проверьте, что имя Мастера резолвится на новый IP-адрес;
- (Опционально). Для ускорения процесса переподключения, вы можете сделать перезапуск служб на Силовых серверах и Агентах;
- В консоли нового Мастер-сервера «Конфигурация» - «Силовые серверы» убедитесь, что Силовые серверы подключены к новому Мастеру (достаточно подключения одного Силового сервера, на котором хранится нужная вам копия Системы);
- Откройте содержание DR-файла (см. п.10.2) за дату и время, на которую вы хотите выполнить восстановления данных Системы. В файле будет указан скрипт, который надо запустить на Силовом сервере (указан в DR-файле), для восстановления конфигурации и данных Мастер-сервера Системы.
Запустите данный скрипт на Силовом сервере и выберите опцию (1) – Восстановление:
В результате вы получите tar-файл c восстановленной резервной копией Системы:
Скопируйте данный файл в каталог /opt/beresta/brst-master на новый Мастер-сервер.
Остановите контейнеры на новом Мастер-сервере:
# docker stop brst-web brst-master brst-redis brst-db
На новом Мастере распакуйте архив в каталоге /opt/beresta/brst-master.
# tar xvf <имя tar файла>
В каталоге /opt/beresta/brst-master/db выполните следующую команду:
# chown -R 70:root ./
В каталоге /opt/beresta/brst-master выполните следующие команды:
# chmod -R 755 ./config/
# chmod -R 755 ./db/
# chmod -R 755 ./uploads/
# chmod -R 755 ./temp/
! Для автоматизации пунктов 8-14, вы можете использовать скрипт:
/usr/bin/python/opt/beresta/scripts/master_dr_copy.py
Данный скрипт обнаруживает последнюю копию каталога и передает ее на целевой, восстанавливаемый Мастер-сервер.
На новом Мастере запустите контейнеры:
# docker start brst-db brst-redis brst-master brst-web
Убедитесь, что контейнеры запущены. (# docker ps)
Процедура восстановления конфигурации Системы (Мастер-сервера) завершена. Перейдите в WEB-консоль по старому имени или новому IP-адресу, чтобы убедиться, что данные по резервным копиям и конфигурация доступны.
После смены А-записи в DNS или DNS-алиаса, все настроенные ранее Силовые серверы и Агенты постепенно переподключатся к восстановленному Мастеру. Для ускорения процесса переподключения, вы можете сделать рестарт сервисов Береста на данных хостах.
¶ 10.4. Обслуживание и диагностика Силового сервера
Для контроля работоспособности программных модулей Системы на Силовых сервере используются следующие методы:
- контроль статуса сервисов, работающих в виде процессов на ОС:
# ps -ef|grep brst_powerproxy
В выводе команды необходимо убедиться в работоспособности одного процесса с именем brst_powerproxy.
- В случае, если такой процесс не обнаружен, для диагностики неисправности необходимо выполнить анализ логов в каталоге на Силовом сервере:
/opt/beresta/brst-powerproxy/logs/
¶ 10.5. Резервное копирование метаданных пулов дедупликации
Для обеспечения отказоустойчивости рекомендуется дублировать резервные копии на разных устройствах хранения — это защищает от сбоев силовых серверов и подключенных хранилищ. Дополнительно система поддерживает резервное копирование метаданных пулов дедупликации, что позволяет восстановить работоспособность пулов при логических повреждениях или случайном удалении данных. Процесс настройки этого механизма описан ниже.
Для резервного копирования метаданных пулов дедупликации, настроенных на Силовых серверах необходимо выполнить следующие настройки:
- Установить Агента Береста на все Силовые серверы, на которых настроены пулы дедупликации;
- В панели «Конфигурация» → «Источники данных» → «Агентские». Для Агентов на всех Силовых серверах с пулами дедупликации создайте файловый объект для каталога /opt/beresta/brst-powerproxy/dr;
- В панели «Конфигурация» → «Настройки» → «Командные сценарии». Создайте новый командный сценарий (напр. с именем brst-dedup-meta-save). Среда исполнения – bash, содержание сценария.
echo "Запуск резервного копирования метаданных дедуп-пула для Хранилища $BRST_STORAGE_PATH"
/usr/sbin/zfs snapshot <pool-name>@brst_snap_$BRST_BACKUP_DIR
/usr/bin/dd if=/dev/<dev-name> of=/opt/beresta/brst-powerproxy/dr/dedup-special.img bs=4096
echo "Запуск очистки резервных копий метаданных дедуп-пула для Хранилища $BRST_STORAGE_PATH"
/usr/sbin/zfs list -H -t snapshot -o name | grep brst_snap_ | tac | tail -n 1 | xargs -n 1 /usr/sbin/zfs destroy -vr
Директива dd используется только если вы размещали SPECIAL VDEV дедуп-пула на отдельно устройстве.
- Отредактируйте свойства ранее созданных файловых объектов, выбрав в качестве сценария «После РК@Силовой сервер» ранее созданный сценарий:
- В панели «Конфигурация» → «Политики Береста». Создайте политику и расписание (рекомендуется ежедневное расписание) для регулярного резервного копирования созданных ранее файловых объектов.
¶ 10.6. Восстановление метаданных пулов дедупликации
В случае порчи данных на пуле дедупликации и невозможности использования дубликатов резервных копий на других пулах для восстановления, процедура восстановления метаданных пула дедупликации выполняется следующим образом:
- На Силовом сервере, где необходимо восстановить метаданные дедуп-пула, выполните команду для получения списка резервных копий:
# zfs list -t snapshot -o name <имя_пула>
- В выводе команды вы получите полный список резервных копий метаданных пула (окончание файла UTC-метка времени создания копии). Выберите нужную копию и выполните восстановление с помощью команды:
# zfs rollback -r <имя пула>@<имя копии>
- Проверьте доступность утраченных ранее данных на дедуп-пуле.
- В случае, если данные недоступны, вы можете дополнительно восстановить блочную копию отдельного тома с метаданными (SPECIAL VDEV), если вы настраивали это специальное устройство при создании пула дедупликации:
# dd if=/opt/beresta/brst-powerproxy/dr/dedup-special.img of=/dev/<имя SPECIAL VDEV)>
¶ 10.7. Обслуживание и диагностика Агента
Для контроля работоспособности программных модулей Системы на Агентах используются следующие методы:
- Контроль статуса сервисов, работающих в виде процессов на ОС:
# ps -ef|grep brst_agent
В выводе команды необходимо убедиться в работоспособности одного процесса с именем brst_agent.
- В случае, если такой процесс не обнаружен, для диагностики неисправности необходимо выполнить анализ логов в каталоге на Силовом сервере:
/opt/beresta/brst-agent/logs/
¶ 10.8. Смена пароля администратора Системы
Для смены пароля администратора (admin) системы перейдите в браузере на следующий URL, задайте новый пароль и нажмите кнопку «Change password».
https://<имя мастер сервера>/brs-api/admin/authuser/1/password/