Резервное копирование и восстановление

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

В KeyStack реализовано резервное копирование данных LCM-узла и баз данных MariaDB для регионов OpenStack.

Резервное копирование LCM-узла

Для резервного копирования компонентов LCM-узла используется Velero — инструмент резервного копирования для Kubernetes. Резервные копии хранятся во внешнем S3-хранилище. Хранилище необходимо предоставить со стороны заказчика.

Предварительное требование: S3-совместимое хранилище с выделенным bucket и учётными данными доступа (Access Key ID, Secret Access Key).

Для первоначальной настройки Velero выполните следующие действия на первом LCM-узле:

  1. Создайте файл credentials-velero с учётными данными доступа к S3-хранилищу:

    [default]
aws_access_key_id = <access-key>
aws_secret_access_key = <secret-key>

  2. Установите Velero в Kubernetes-кластер, где <образ velero-plugin-for-aws> — образ из списка custom-images-list.txt дистрибутива:

    $ velero install \
    --features=EnableCSI \
    --provider aws \
    --plugins <образ velero-plugin-for-aws> \
    --bucket <имя bucket> \
    --secret-file ./credentials-velero \
    --backup-location-config region=<регион S3>,s3ForcePathStyle="true",s3Url=<адрес API S3>

  3. Проверьте, что под Velero запущен:

    $ kubectl get pod -n velero

  4. Удалите файл с учётными данными — настройки доступа хранятся в Kubernetes Secret:

    $ rm -f ./credentials-velero

Для создания резервной копии выполните следующие действия:

  1. Запустите резервное копирование нужных компонентов, указав их namespace:

    $ velero backup create <имя-копии> --include-namespaces <необходимые пространства имён компонентов LCM>

  2. Проверьте статус резервной копии:

    $ velero backup describe <имя-копии>

Для создания резервных копий по расписанию выполните следующие действия:

  1. Создайте расписание, указав cron-выражение, пространства имён необходимых компонентов и, при необходимости, срок хранения копий:

    $ velero schedule create <имя-расписания> \
    --schedule="<cron-выражение>" \
    --include-namespaces <необходимые пространства имён компонентов LCM> \
    --ttl <срок хранения в формате XhYmZs (часы, минуты, секунды)>

    Например, для ежедневного запуска резервного копирования компонента GitLab в 04:00 с хранением 30 дней команда создания расписания будет выглядеть следующим образом:

    $ velero schedule create lcm-daily \
    --schedule="0 4 * * *" \
    --include-namespaces lcm-gitlab \
    --ttl 720h0m0s

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

    $ velero schedule get

Резервное копирование базы данных OpenStack

Данные региона OpenStack хранятся в базе данных MariaDB. При резервном копировании MariaDB выполняется только полное копирование базы данных — инкрементальные резервные копии не поддерживаются. Резервные копии баз данных регионов шифруются алгоритмом AES-256 с использованием PBKDF2 для усиления безопасности ключа.

Резервное копирование MariaDB включено по умолчанию. При необходимости его отключения добавьте в конфигурационный файл globals.d/REGION.yml параметр:

enable_mariabackup: "no"

После изменения конфигурации запустите пайплайн развёртывания региона:

  1. Откройте веб-интерфейс развёрнутого GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В списке Run for branch name or tag оставьте ветку по умолчанию, соответствующую установленному релизу.

  4. Запустите задачу deploy в созданном пайплайне.

  5. Дождитесь завершения выполнения задачи.

Перед созданием резервной копии выполняется проверка доступности управляющих узлов:

  • три управляющих узла — резервное копирование выполняется в штатном режиме;

  • два управляющих узла — резервное копирование продолжается, в лог записывается предупреждение, состояние отражается в метриках мониторинга;

  • один управляющий узел или менее — пайплайн завершается с ошибкой.

Поддерживается три варианта хранения резервных копий:

  • Хранение на LCM-узле (встроенное S3-хранилище Garage) — по умолчанию:

    Параметры хранилища настраиваются автоматически при установке LCM и сохраняются как переменные группы в GitLab: s3_host, s3_backet, s3_access_key, s3_secret_key, s3_region. Ручная настройка не требуется.

    После создания резервной копии и до передачи в хранилище выполняется проверка возможности восстановления: поднимается контейнер с пустой MariaDB и выполняется восстановление из созданного файла. Если восстановление завершается с ошибкой, пайплайн прерывается.

    После успешной проверки файл копируется в хранилище. При этом выполняется проверка контрольной суммы SHA-256: контрольная сумма файла на управляющем узле сравнивается с контрольной суммой файла в хранилище. Если суммы не совпадают, шаг копирования повторяется ещё раз. Если после повтора несоответствие сохраняется, пайплайн завершается с ошибкой.

  • Хранение во внешнем S3:

    Для этого варианта добавьте следующие переменные в раздел Settings > CI/CD > Variables репозитория региона project_k / deployments / <имя региона>:

    • s3_host — адрес сервиса S3;

    • s3_backet — имя bucket для хранения резервных копий;

    • s3_access_key — Access Key ID;

    • s3_secret_key — Secret Access Key;

    • s3_region — регион S3.

    Проверка контрольной суммы SHA-256 при хранении во внешнем S3 не выполняется.

  • Хранение в Nexus:

    Для этого варианта добавьте следующие переменные в раздел Settings > CI/CD > Variables репозитория региона project_k / deployments / <имя региона>:

    • KEYSTACK_NEXUS_BACKUP — адрес сервиса Nexus, например http://nexus:8081/repository/k-backup/;

    • NEXUS_USER — имя пользователя Nexus.

    Пароль пользователя Nexus берётся автоматически из Vault.

По умолчанию на LCM-узле и во внешнем S3 хранятся последние 2 резервных копии, более старые удаляются автоматически. Чтобы изменить количество хранимых копий, добавьте в конфигурационный файл региона globals.d/REGION.yml параметр backup_keep_count и запустите пайплайн развёртывания, чтобы применить новую конфигурацию:

backup_keep_count: <количество>

В Nexus автоматическая ротация не выполняется — настройте её на стороне хранилища.

Статус резервных копий отображается:

  • на Портале администратора в разделе DB Backups на вкладке Состояние системы — данные за последние 7 дней;

  • в Grafana на дашборде OpenStack Dashboard — дата и статус последнего резервного копирования (метрики db_backup_job_status и db_backup_job_last_run).

Предупреждение

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

При запуске резервного копирования под высокой нагрузкой возможна блокировка таблиц БД: ряд сервисов управляющего слоя (nova-compute, ovs, ovs-agent, cinder-volume, cinder-scheduler) может кратковременно перейти в состояние down и автоматически восстановиться после завершения пайплайна. Ориентируйтесь на графики загрузки MariaDB и выбирайте время с низкими показателями.

Требования к дисковой подсистеме управляющих узлов (Enterprise SSD, RAID1) приведены в разделе Аппаратные и программные требования к инфраструктуре. Их соблюдение обязательно в том числе для корректной работы резервного копирования.

Для запуска резервного копирования базы данных MariaDB выполните следующие действия:

  1. Откройте веб-интерфейс развёрнутого GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В списке Run for branch name or tag оставьте ветку по умолчанию, соответствующую установленному релизу.

  4. Запустите пайплайн New pipeline.

  5. Вручную запустите задачу backup-db на этапе deploy.

  6. Дождитесь выполнения пайплайна.

Также вы можете настроить регулярное выполнение резервного копирования БД с помощью Pipeline Schedules. Подробнее см. в разделе Резервное копирование базы данных OpenStack.

Восстановление из резервной копии

Восстановление LCM-узла из резервной копии

Восстановление LCM-узла выполняется средствами Velero.

Для восстановления LCM-узла из резервной копии выполните следующие действия:

  1. Получите список доступных резервных копий:

    $ velero backup get

  2. Запустите восстановление из выбранной резервной копии:

    $ velero restore create --from-backup <имя-копии>

  3. Проверьте статус восстановления:

    $ velero restore describe <имя-восстановления>

Восстановление базы данных OpenStack из резервной копии

Примечание

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

Для использования задачи restore-db необходима предварительная настройка на LCM-узле.

Поддерживается два варианта восстановления: из последней успешной резервной копии и из выбранной резервной копии.

Для восстановления из последней успешной резервной копии выполните следующие действия:

  1. Откройте веб-интерфейс развёрнутого GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В списке Run for branch name or tag оставьте ветку по умолчанию, соответствующую установленному релизу.

  4. Запустите пайплайн New pipeline.

  5. Вручную запустите задачу restore-db на этапе deploy.

  6. Дождитесь выполнения пайплайна.

Для восстановления из выбранной резервной копии поместите нужный файл резервной копии (.enc и соответствующий .sha256) на первый управляющий узел в volume MariaDB, после чего выполните те же шаги.

После восстановления проверьте статус кластера базы данных и региона в целом по дашбордам Grafana OpenStack Dashboard и Galera/MariaDB Dashboard.