VK Private Cloud logo
Помощь
Обновлена 17 июля 2026 г. в 15:55

Подготовка

Обновление Платформы запустит обновление Tarantool с версии 2.10 на версию из дистрибутива tarantool-enterprise-3. Возможны задержки в работе Портала самообслуживания и IAM на момент обновления.

Платформа будет недоступна во время выполнения плейбука breeze-deploy.yml и восстановится после успешной отработки плейбуков breeze-deploy.yml и dusk-deploy.yml.

Среднее время задержки составит приблизительно 15-20 минут.

Рекомендуется проводить обновление в менеджере терминалов Tmux или Screen.

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

Перед началом создания резервной копии оцените наличие свободного места на сервере, на котором производится резервное копирование, и следите за его количеством в процессе копирования.

Резервные копии создаются в директориях, в которых находятся запускаемые скрипты. После создания перенесите их на сервер или в отдельное хранилище.

Список баз данных

На Платформе используются следующие средства хранения служебных данных:

  • MySQL/Galera.
  • PostgreSQL.
  • Tarantool (сервисы Dusk и Breeze).
  • RabbitMQ.
  • Apache ZooKeeper.
  • etcd.
  • OpenSearch.

MySQL/Galera

При обновлении с версии 4.1.1:

  1. На управляющем узле выполните команды:

    $ sudo bash /srv/backup/backup_xtra_barbican.sh$ sudo bash /srv/backup/backup_xtra_billingaccountservice.sh$ sudo bash /srv/backup/backup_xtra_cinder.sh$ sudo bash /srv/backup/backup_xtra_ghosts.sh$ sudo bash /srv/backup/backup_xtra_glance.sh$ sudo bash /srv/backup/backup_xtra_karboii.sh$ sudo bash /srv/backup/backup_xtra_keycloak.sh$ sudo bash /srv/backup/backup_xtra_keystone.sh$ sudo bash /srv/backup/backup_xtra_maas.sh$ sudo bash /srv/backup/backup_xtra_magnum.sh$ sudo bash /srv/backup/backup_xtra_manila.sh$ sudo bash /srv/backup/backup_xtra_neutron.sh$ sudo bash /srv/backup/backup_xtra_nova.sh$ sudo bash /srv/backup/backup_xtra_octavia.sh$ sudo bash /srv/backup/backup_xtra_quotamanager.sh$ sudo bash /srv/backup/backup_xtra_scroogearchive.sh$ sudo bash /srv/backup/backup_xtra_scrooge.sh$ sudo bash /srv/backup/backup_xtra_sdnbilling.sh$ sudo bash /srv/backup/backup_xtra_sdnprojectsapi.sh$ sudo bash /srv/backup/backup_xtra_sprut.sh$ sudo bash /srv/backup/backup_xtra_trove.sh

  2. Проверьте, что резервные копии созданы:

    $ sudo ls -la /srv/backup/*$(date '+%Y%m%d')*.tgz

    Ответ должен содержать список файлов резервных копий вида:

    /srv/backup/<ИМЯ_БД>_db_bcp_<ДАТА>_<ВРЕМЯ>.tgz.

    Здесь:

    • <ИМЯ_БД> — имя базы данных.
    • <ДАТА> — дата создания резервной копии.
    • <ВРЕМЯ> — время создания резервной копии.

При обновлении с версии 4.2.0:

  1. На управляющем узле выполните команды:

    $ cd /srv/backup/galera/scripts$ sudo bash ./backup_xtra.sh

  2. Проверьте, что резервные копии созданы:

    $ sudo ls -la /srv/backup/galera/*/*$(date '+%Y%m%d')*.tgz

    Ответ должен содержать список файлов резервных копий вида:

    /srv/backup/galera/backup_<ИМЯ_БД>/xtrabackup_<ИМЯ_БД>_db_bcp_<ДАТА>_<ВРЕМЯ>.tgz.

    Здесь:

    • <ИМЯ_БД> — имя базы данных.
    • <ДАТА> — дата создания резервной копии.
    • <ВРЕМЯ> — время создания резервной копии.

Postgres

При обновлении с версии 4.1.1:

  1. На управляющем узле выполните команды:

    $ sudo bash /srv/backup/backup_pg_bank_integration.sh$ sudo bash /srv/backup/backup_pg_billingcore.sh$ sudo bash /srv/backup/backup_pg_catalog.sh$ sudo bash /srv/backup/backup_pg_commander.sh$ sudo bash /srv/backup/backup_pg_glomgold.sh$ sudo bash /srv/backup/backup_pg_golden_broker.sh$ sudo bash /srv/backup/backup_pg_grange.sh$ sudo bash /srv/backup/backup_pg_hoe.sh$ sudo bash /srv/backup/backup_pg_infra_api.sh$ sudo bash /srv/backup/backup_pg_magnum_addons.sh$ sudo bash /srv/backup/backup_pg_magnumrapid.sh$ sudo bash /srv/backup/backup_pg_saas_demo_broker.sh$ sudo bash /srv/backup/backup_pg_scheduler.sh$ sudo bash /srv/backup/backup_pg_services_manager.sh$ sudo bash /srv/backup/backup_pg_store.sh$ sudo bash /srv/backup/backup_pg_sync_service.sh$ sudo bash /srv/backup/backup_pg_user_mngmnt.sh

  2. Проверьте, что резервные копии созданы:

    $ sudo ls -1t /srv/backup/*pg*$(date '+%Y%m%d')*.tgz | awk -F'_' '{db=$1"_"$2} !seen[db]++{print}'

    Ответ должен содержать список файлов резервных копий вида:

    /srv/backup/<ИМЯ_БД>_pg_<ДАТА>_<ВРЕМЯ>.tgz.

    Здесь:

    • <ИМЯ_БД> — имя базы данных.
    • <ДАТА> — дата создания резервной копии.
    • <ВРЕМЯ> — время создания резервной копии.

При обновлении с версии 4.2.0:

  1. На управляющем узле выполните команды:

    $ cd /srv/backup/postgres$ sudo bash ./backup_pg.sh

  2. Проверьте, что резервные копии созданы:

    $ sudo ls -la /srv/backup/postgres/*pg**$(date '+%Y%m%d')*.tgz

    Ответ должен содержать список файлов резервных копий вида:

    /srv/backup/postgres/<ИМЯ_БД>_pg_<ДАТА>_<ВРЕМЯ>.tgz.

    Здесь:

    • <ИМЯ_БД> — имя базы данных.
    • <ДАТА> — дата создания резервной копии.
    • <ВРЕМЯ> — время создания резервной копии.

Tarantool

На каждом управляющем узле:

  1. Создайте резервные копии Tarantool и файлов конфигураций сервисов Dusk и Breeze:

    Команда при обновлении с версии 4.1.1
    $ sudo mkdir -p /srv/backup/tarantool/$(date '+%Y%m%d')/{tarantool,etc/breeze,etc/dusk,overlord} \&& echo 'box.backup.start()' | sudo tarantoolctl enter breeze_01 \&& echo 'box.backup.start()' | sudo tarantoolctl enter dusk_01 \&& cp -r /var/lib/tarantool/snaps /var/lib/tarantool/xlogs /srv/backup/tarantool/$(date '+%Y%m%d')/tarantool/ \&& cp -r /etc/breeze/* /srv/backup/tarantool/$(date '+%Y%m%d')/etc/breeze \&& cp -r /etc/dusk/* /srv/backup/tarantool/$(date '+%Y%m%d')/etc/dusk \&& cp -r /usr/local/etc/overlord/* /srv/backup/tarantool/$(date '+%Y%m%d')/overlord \&& echo 'box.backup.stop()' | sudo tarantoolctl enter breeze_01 \&& echo 'box.backup.stop()' | sudo tarantoolctl enter dusk_01
    Команда при обновлении с версии 4.2.0
    $ sudo bash /usr/local/bin/tarantool_backup.sh

  2. Проверьте, что резервные копии созданы:

    $ sudo ls -lR /srv/backup/tarantool/*

    Ответ должен содержать список файлов резервных копий Dusk и Breeze.

  3. Заархивируйте резервные копии:

    $ sudo cd /srv/backup/tarantool/ \&& sudo tar -czvf /srv/backup/tarantool/tarantool_$(date '+%Y%m%d').tar.gz /srv/backup/tarantool/ \&& sudo rm -rf /srv/backup/tarantool/$(date '+%Y%m%d')

  4. Проверьте, что резервные копии заархивированы:

    $ sudo ll /srv/backup/tarantool/tarantool_$(date '+%Y%m%d')*.gz

    Ответ должен содержать список файлов резервных копий вида:

    /srv/backup/tarantool/tarantool_<ДАТА>.tar.gz.

    Здесь:

    • <ДАТА> — дата создания резервной копии.
    • <ВРЕМЯ> — время создания резервной копии.

Мониторинг

Zabbix

При обновлении с версии 4.1.1:

  1. На узле мониторинга запустите скрипт:

    $ sudo bash /srv/backup/backup_xtra_zabbix.sh

  2. Проверьте, что резервная копия создана:

    $ sudo ls -1t /srv/backup/ZABBIX*$(date '+%Y%m%d')*.tgz

    Ответ должен содержать файл резервной копии вида:

    /srv/backup/zabbix_db_bcp_<ДАТА>_<ВРЕМЯ>.tgz.

    Здесь:

    • <ДАТА> — дата создания резервной копии.
    • <ВРЕМЯ> — время создания резервной копии.

При обновлении с версии 4.2.0:

  1. На узле мониторинга запустите скрипт:

    $ cd /srv/backup/galera/scripts$ sudo bash ./backup_xtra.sh

  2. Проверьте, что резервная копия создана:

    $ sudo ls -1t /srv/backup/galera/backup_zabbix/*ZABBIX*$(date '+%Y%m%d')*.tgz

    Ответ должен содержать файл резервной копии вида:

    /srv/backup/galera/backup_zabbix/xtrabackup_ZABBIX_db_bcp_<ДАТА>_<ВРЕМЯ>.tgz.

    Здесь:

    • <ДАТА> — дата создания резервной копии.
    • <ВРЕМЯ> — время создания резервной копии.

OpenSearch

  1. Создайте на узле мониторинга каталог для резервной копии:

    $ sudo mkdir -p /srv/backup/opensearch/$(date '+%Y%m%d')

  2. Создайте резервную копию:

    $ sudo docker stop opensearch opensearch_dashboards \&& sudo cp -pr /var/lib/docker/volumes/opensearch-data1 /srv/backup/opensearch/$(date '+%Y%m%d')/ \&& sudo cp /etc/opensearch/opensearch-dashboards.yml /srv/backup/opensearch/$(date '+%Y%m%d')/ \&& sudo docker start opensearch opensearch_dashboards

  3. Заархивируйте резервную копию:

    $ sudo tar -czvf /srv/backup/opensearch/opensearch-$(date +%Y%m%d-%H%M).tar.gz /srv/backup/opensearch/$(date '+%Y%m%d')/$ sudo rm -rf /srv/backup/opensearch/$(date '+%Y%m%d')

  4. Проверьте, что резервная копия создана:

    $ sudo ls -lR /srv/backup/opensearch/*

    Ответ должен содержать файл резервной копии вида:

    /srv/backup/opensearch/opensearch-<ДАТА>.tar.gz.

    Здесь <ДАТА> — дата создания резервной копии.

etcd

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

$ sudo mkdir -p /srv/backup/etcd/

Kubernetes

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

$ sudo etcdctl --endpoints=https://127.0.0.1:2379 \          --cacert=/etc/etcd/ca.crt\          --cert=/etc/kubernetes/pki/kube-etcd.crt \          --key=/etc/kubernetes/pki/kube-etcd.key \          snapshot save /srv/backup/etcd/k8s-$(date +%Y%m%d-%H%M).db

Чтобы проверить, что резервная копия создана, выполните команду:

$ sudo ls -lR /srv/backup/etcd/k8s*

Ответ должен содержать файл резервной копии вида k8s-<ДАТА>-<ВРЕМЯ>.db.

Здесь:

  • <ДАТА> — дата создания резервной копии.
  • <ВРЕМЯ> — время создания резервной копии.

IAM

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

$ sudo etcdctl --endpoints=127.0.0.1:22379 snapshot save /srv/backup/etcd/iam-$(date +%Y%m%d-%H%M).db

Чтобы проверить, что резервная копия создана, выполните команду:

$ sudo ls -lR /srv/backup/etcd/iam*

Ответ должен содержать файл резервной копии вида iam-<ДАТА>-<ВРЕМЯ>.db.

Здесь:

  • <ДАТА> — дата создания резервной копии.
  • <ВРЕМЯ> — время создания резервной копии.

Scrooge

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

$ sudo etcdctl --endpoints=127.0.0.1:24379 snapshot save /srv/backup/etcd/scrooge-$(date +%Y%m%d-%H%M).db

Чтобы проверить, что резервная копия создана, выполните команду:

$ sudo ls -lR /srv/backup/etcd/scrooge*

Ответ должен содержать файл резервной копии вида scrooge-<ДАТА>-<ВРЕМЯ>.db.

Здесь:

  • <ДАТА> — дата создания резервной копии.
  • <ВРЕМЯ> — время создания резервной копии.

Apache ZooKeeper

Для резервного копирования сохраните /var/lib/zookeeper на всех управляющих узлах любым удобным способом.

Пример команды
$ sudo tar -czvf /srv/backup/zookeeper-$(date +%Y%m%d-%H%M).tar.gz /var/lib/zookeeper

Чтобы проверить, что резервная копия сохранена, выполните команду:

$ sudo ls -lR /srv/backup/zookeeper*

Ответ должен содержать файл резервной копии вида zookeeper-<ДАТА>-<ВРЕМЯ>.db.

Здесь:

  • <ДАТА> — дата создания резервной копии.
  • <ВРЕМЯ> — время создания резервной копии.

Восстановление

MySQL/Galera

  1. Остановите сервис базы данных на всех управляющих узлах:

    $ sudo systemctl stop mariadb-octavia

  2. Удалите все предыдущие данные на всех управляющих узлах:

    $ sudo rm -rf /srv/mysql/octavia/data/*

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

    Команда при обновлении с версии 4.1.1
    $ cd /srv/backup/$ tar xzvf OCTAVIA_db_bcp_20240624_1743.tgz
    Команда при обновлении с версии 4.2.0
    $ cd /srv/backup/galera/backup_octavia$ tar xzvf xtrabackup_OCTAVIA_db_bcp_20240624_1743.tgz -C /

  4. Выведите содержимое файла xtrabackup_galera_info:

    Команда при обновлении с версии 4.1.1
    $ cat /srv/backup/extrabackup_octavia/xtrabackup_galera_info
    Команда при обновлении с версии 4.2.0
    $  cat /srv/backup/galera/backup_octavia/temp_xtrabackup_octavia/xtrabackup_galera_info

  5. В выводе получите строку вида <UUID>:<SEQNO> с двумя значениями, разделенными двоеточием.

    Пример команды и ожидаемого результата
    # cat xtrabackup_galera_info4f095201-2ce3-11ef-82f6-cfa78bf73a14:52797

  6. Создайте файл grastate.dat в папке с извлеченной резервной копией следующего содержания:

    version: 2.1uuid:    <UUID>seqno:   <SEQNO>safe_to_bootstrap: 1

    Здесь:

    • <UUID> — первое значение поля uuid из файла ~/xtrabackup_galera_info.
    • <SEQNO> — первое значение поля seqno из файла ~/xtrabackup_galera_info.

  7. Восстановите резервную копию:

    Команда при обновлении с версии 4.1.1
    $ sudo mariabackup --defaults-file=/etc/octavia.cnf --copy-back \  --target-dir=/srv/backup/extrabackup_octavia
    Команда при обновлении с версии 4.2.0
    $ sudo mariabackup --defaults-file=/etc/octavia.cnf --copy-back \  --target-dir=/srv/backup/galera/backup_octavia/temp_xtrabackup_octavia

  8. Установите владельца каталога после восстановления:

    $ sudo chown -R mysql:root /srv/mysql/octavia/data

  9. Отредактируйте файл /etc/octavia.cnf:

    • Закомментируйте строку wsrep_cluster_address с адресами.

    • Добавьте строку wsrep_cluster_address="gcomm://".

      Пример
      ...# wsrep_cluster_address="gcomm://10.33.3.11:13003,10.33.3.12:13003,10.33.3.13:13003"wsrep_cluster_address="gcomm://"...

  10. На первом управляющем узле запустите сервис БД и проверьте, что он успешно запустился:

    $ sudo systemctl start mariadb-octavia$ sudo systemctl status mariadb-octavia

  11. Запустите сервис на остальных управляющих узлах и проверьте, что он успешно запустился:

    $ sudo systemctl start mariadb-octavia$ sudo systemctl status mariadb-octavia

  12. На первом управляющем узле отредактируйте файл /etc/octavia.cnf:

    • Удалите строку wsrep_cluster_address="gcomm://", добавленную ранее.

    • Раскомментируйте строку wsrep_cluster_address с адресами, закомментированную ранее.

      Пример
      ...wsrep_cluster_address="gcomm://10.33.3.11:13003,10.33.3.12:13003,10.33.3.13:13003"...

  13. На первом управляющем узле перезапустите сервис БД:

    $ sudo systemctl restart mariadb-octavia

Postgres

  1. Распакуйте архив резервной копии.

    Пример команды при обновлении с версии 4.1.1
    # cd /srv/backup/# tar xzvf magnum_addons_pg_20240626_1608.tgz
    Пример команды при обновлении с версии 4.2.0
    # cd /srv/backup/postgres/# tar xzvf magnum_addons_pg_20240626_1608.tgz

  2. Посмотрите содержимое файла /srv/backup/backup_pg_magnum_addons.sh:

    Команда при обновлении с версии 4.1.1
    $ cat /srv/backup/backup_pg_magnum_addons.sh
    Команда при обновлении с версии 4.2.0
    $ cat /srv/backup/postgres/backup_pg_magnum_addons.sh
    Пример файла
    cd /srv/backupDATE=`date "+%Y%m%d_%H%M"`export DB_NAME=magnum_addonsexport PGPASSWORD="9h3n8R23HL0z283xBZ1j"pg_dump -h standby.postgresql-${DB_NAME}.service.compute \  -U postgres -p 5445 -d ${DB_NAME} > ${DB_NAME}_pg_${DATE}.sqltar cvzf ${DB_NAME}_pg_${DATE}.tgz ${DB_NAME}_pg_${DATE}.sqlrm -f ${DB_NAME}_pg_${DATE}.sql

  3. Запомните порт 5445. Подставьте значение ${DB_NAME} из этого файла в строку standby.postgresql-${DB_NAME}.service.compute, а также замените подстроку standby на master. Если в названии БД есть символы нижних подчеркиваний (_), замените их на дефисы (-).

  4. Получите пароль для Postgres из vault-файла:

    $ cd inventory/vkcloud/$ ansible -m debug -i vkcloud.yml -a "msg=\"\n\n{{ vault_postgresql_login_password }}\n\n\"" all[0] | sed 's/\\n/\n/g'

  5. Войдите в консоль управления БД, подставив адрес и порт:

    $ psql -h master.postgresql-magnum-addons.service.compute \  -U postgres -p 5445 -d magnum_addons -c '\dt'

    Здесь:

    • master.postgresql-magnum-addons.service.compute — значение адреса.
    • 5445 — значение порта, полученное на шаге 2.
    Пример ожидаемого результата
    Password for user postgres:psql (12.12)Type "help" for help.magnum_addons=# \dt                    List of relations Schema |          Name          | Type  |     Owner--------+------------------------+-------+--------------- public | addon                  | table | magnum_addons public | cluster_addon          | table | magnum_addons public | cluster_template_addon | table | magnum_addons public | schema_migrations      | table | magnum_addons public | transition_log         | table | magnum_addons(5 rows)

  6. При наличии таблиц в БД, удалите их:

    $ psql -h master.postgresql-magnum-addons.service.compute \  -U postgres -p 5445 -d magnum_addons \  -c 'drop table addon,cluster_addon,cluster_template_addon,schema_migrations,transition_log'

  7. Восстановите базу из резервной копии:

    $ psql -h master.postgresql-magnum-addons.service.compute \ -U postgres -p 5445 \ -d magnum_addons < magnum_addons_pg_20240626_1608.sql

Проверьте, что сервис, использующий БД, запущен и работает без ошибок. Пример: чтобы проверить работу БД magnum_addons, создайте кластер Kubernetes и добавьте ему любой аддон (подробнее — в документе Руководство пользователя VK Private Cloud в разделе Контейнеры → Управление кластером → Управление аддонами).

Tarantool

  1. Проверьте наличие резервной копии:

    $ sudo ls -lah /srv/backup/tarantool/

  2. На первом управляющем узле распакуйте архив резервной копии:

    $ sudo tar -xzvf /srv/backup/tarantool/tarantool_<ДАТА>.tar.gz -C /

  3. Проверьте, на каком из узлов расположены master-узлы сервисов Dusk и Breeze:

    # export ETCDCTL_API=2 etcdctl --endpoints=http://127.0.0.1:22379 get /mcs/tarantool/dusk/clusters/dusk/masteretcdctl --endpoints=http://127.0.0.1:22379 get /mcs/tarantool/breeze/clusters/breeze/master
    Пример ожидаемого результата
    dusk_01breeze_01

  4. На деплой-ноде убедитесь, что значения master-узлов сервисов Dusk и Breeze совпадает со значениями переменных в Inventory:

    $ cd inventory/vkcloud$  grep -ri breeze_mastergroup_vars/vkcloud_mcs_breeze/vars.yml:breeze_clusters_breeze_master: breeze_01$  grep -ri dusk_mastergroup_vars/vkcloud_mcs_dusk/vars.yml:dusk_clusters_dusk_master: dusk_01

  5. При обновлении с версии 4.1.1 на деплой-ноде восстановите значения версий Tarantool, Dusk, Breeze, а также имя пакета для Tarantool.

    1. Проверьте версии Tarantool, Dusk, Breeze:

      $ grep -E 'tarantool|breeze|dusk' ./group_vars/vkcloud/versions.yml

      Для работы Tarantool 2.10 должны быть следующие версии:

      breeze: 4.0.0.rc.20230426-202405270931.gitbb89a610dusk: 4.1.1-1tarantool: 2.10.3-1

    2. Проверьте имя пакета Tarantool:

      $ grep -E 'tarantool' ./group_vars/vkcloud/packages.yml

      Имя пакета Tarantool 2.10 должно быть следующим, без слова enterprise или .el7:

      tarantool: tarantool-{{ pkg_version.tarantool }}.x86_64

  6. Поочередно подключитесь по SSH к каждому управляющему узлу, остановите сервисы БД и Overlord для сервисов:

    $ ssh <УЗЕЛ>$ sudo systemctl stop tarantool@<УЗЕЛ_BREEZE>.service tarantool@<УЗЕЛ_DUSK>.service overlord@<УЗЕЛ_BREEZE>.service overlord@<УЗЕЛ_DUSK>.service$ exit

    Здесь:

    • <УЗЕЛ> — имя управляющего узла, например cpn001.
    • <УЗЕЛ_BREEZE> — имя узла Breeze, например breeze_01.
    • <УЗЕЛ_DUSK> — имя узла Dusk, например dusk_01.

  7. При обновлении с версии 4.1.1 верните Tarantool 2.10:

    1. На каждом управляющем узле удалите Tarantool 3:

      1. При наличии файлов существующей БД, скопируйте их:

        # mv /var/lib/tarantool/xlogs/<УЗЕЛ_BREEZE> /var/lib/tarantool/xlogs/<УЗЕЛ_BREEZE>_old# mv /var/lib/tarantool/snaps/<УЗЕЛ_BREEZE> /var/lib/tarantool/snaps/<УЗЕЛ_BREEZE>_old# mv /var/lib/tarantool/xlogs/<УЗЕЛ_DUSK> /var/lib/tarantool/xlogs/<УЗЕЛ_DUSK>_old# mv /var/lib/tarantool/snaps/<УЗЕЛ_DUSK> /var/lib/tarantool/snaps/<УЗЕЛ_DUSK>_old

        Здесь:

        • <УЗЕЛ_BREEZE> — имя узла Breeze, например breeze_01.
        • <УЗЕЛ_DUSK> — имя узла Dusk, например dusk_01.

      2. Удалите Tarantool 3:

        # dnf remove tarantool-enterprise

    2. Установите Tarantool 2.10. Для этого на деплой-ноде запустите плейбуки:

      $ cd ~/inventory/vkcloud$ ../ansible-openstack/tools/box.sh   deploy   -b ../ansible-openstack   -i vkcloud.yml   --playbook breeze-deploy.yml   -s iam   -e @/home/centos/corpcloud_vars.yml -e dev_mfapanel=true   --disks-autoconfigure -e bootstrap=true$ ../ansible-openstack/tools/box.sh   deploy   -b ../ansible-openstack   -i vkcloud.yml   --playbook dusk-deploy.yml   -s iam   -e @/home/centos/corpcloud_vars.yml -e dev_mfapanel=true   --disks-autoconfigure -e bootstrap=true

  8. На каждом управляющем узле остановите сервисы БД и Overlord:

    $ sudo systemctl stop tarantool@<УЗЕЛ_BREEZE> tarantool@<УЗЕЛ_DUSK> overlord@<УЗЕЛ_BREEZE> overlord@<УЗЕЛ_DUSK>

    Здесь:

    • <УЗЕЛ_BREEZE> — имя узла Breeze, например breeze_01.
    • <УЗЕЛ_DUSK> — имя узла Dusk, например dusk_01.

  9. Очистите хранилище Tarantool:

    $ rm -rf /var/lib/tarantool/snaps/*/* /var/lib/tarantool/xlogs/*/*

  10. На первом управляющем узле восстановите резервную копию:

    $ sudo cp -r /srv/backup/tarantool/tarantool/<ДАТА>/tarantool/snaps/breeze_01 /var/lib/tarantool/snaps/$ sudo cp -r /srv/backup/tarantool/tarantool/<ДАТА>/tarantool/xlogs/breeze_01 /var/lib/tarantool/xlogs/$ sudo cp -r /srv/backup/tarantool/tarantool/<ДАТА>/tarantool/snaps/dusk_01 /var/lib/tarantool/snaps/$ sudo cp -r /srv/backup/tarantool/tarantool/<ДАТА>/tarantool/xlogs/dusk_01 /var/lib/tarantool/xlogs/$ sudo chown -R tarantool:tarantool /var/lib/tarantool

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

    $ sudo mkdir /var/lib/tarantool/snaps/<УЗЕЛ_BREEZE> /var/lib/tarantool/xlogs/<УЗЕЛ_BREEZE>$ sudo chown tarantool:tarantool /var/lib/tarantool/snaps/<УЗЕЛ_BREEZE>$ sudo chown tarantool:tarantool /var/lib/tarantool/xlogs/<УЗЕЛ_BREEZE>$ sudo mkdir /var/lib/tarantool/snaps/<УЗЕЛ_DUSK> /var/lib/tarantool/xlogs/<УЗЕЛ_DUSK>$ sudo chown tarantool:tarantool /var/lib/tarantool/snaps/<УЗЕЛ_DUSK>$ sudo chown tarantool:tarantool /var/lib/tarantool/xlogs/<УЗЕЛ_DUSK>

    Здесь:

    • <УЗЕЛ_BREEZE> — имя узла Breeze, например breeze_02.
    • <УЗЕЛ_DUSK> — имя узла Dusk, например dusk_02.

  12. На каждом управляющем узле, начиная с первого, запустите и проверьте сервисы:

    $ sudo systemctl start tarantool@<УЗЕЛ_BREEZE>.service$ sudo systemctl status tarantool@<УЗЕЛ_BREEZE>.service$ sudo systemctl start overlord@<УЗЕЛ_BREEZE>.service$ sudo systemctl status overlord@<УЗЕЛ_BREEZE>.service$ sudo systemctl start tarantool@<УЗЕЛ_DUSK>.service$ sudo systemctl status tarantool@<УЗЕЛ_DUSK>.service$ sudo systemctl start overlord@<УЗЕЛ_DUSK>.service$ sudo systemctl status overlord@<УЗЕЛ_DUSK>.service

    Здесь:

    • <УЗЕЛ_BREEZE> — имя узла Breeze, например breeze_01.
    • <УЗЕЛ_DUSK> — имя узла Dusk, например dusk_01.

  13. Проверьте корректность восстановления: авторизуйтесь в Портале самообслуживания. Если авторизация прошла успешно, БД восстановлены корректно.

Мониторинг

Zabbix

Восстановление БД mariadb-zabbix на сервере мониторинга проведите аналогично процедуре восстановления БД MySQL/Galera на управляющих узлах, приведенной в разделе MySQL/Galera.

OpenSearch

  1. Распакуйте резервную копию в /var/lib/backups/opensearch:

    $ tar -xzvf ls /srv/backup/opensearch/opensearch-<ДАТА>.tar.gz -C /

  2. Остановите OpenSearch, восстановите резервную копию и запустите OpenSearch:

    $ sudo docker stop opensearch opensearch_dashboards \&& sudo mv /srv/backup/opensearch/<ДАТА>/opensearch-data1  /var/lib/docker/volumes/ \&& sudo cp /srv/backup/opensearch/<ДАТА>/opensearch-dashboards.yml /etc/opensearch/opensearch-dashboards.yml \&& sudo chown -R redos:redos /var/lib/docker/volumes/opensearch-data1/_data \&& sudo chown opensearch:opensearch /etc/opensearch/opensearch-dashboards.yml \&& sudo docker start opensearch opensearch_dashboards

etcd

Kubernetes

  1. Остановите сервис:

    $ sudo systemctl stop etcd

  2. При наличии файлов существующей БД, скопируйте их:

    $ sudo mv /var/lib/etcd/ /var/lib/etcd-old

  3. Восстановите БД из резервной копии:

    $ sudo etcdctl --cacert=/etc/etcd/ca.crt --cert=/etc/kubernetes/pki/kube-etcd.crt --key=/etc/kubernetes/pki/kube-etcd.key snapshot restore \--name cpn001 \--initial-cluster cpn001=https://10.133.90.15:2380,cpn002=https://10.133.90.16:2380,cpn003=https://10.133.90.17:2380 \--initial-cluster-token etcd-cluster-0 \--initial-advertise-peer-urls https://10.133.90.15:2380 \--data-dir /var/lib/etcd /srv/backup/etcd/k8s-20250402-1228.db

  4. Установите права на восстановленную БД:

    $ chown -R etcd:etcd /var/lib/etcd

  5. Запустите etcd:

    $ sudo systemctl start etcd

IAM

  1. Остановите etcd:

    $ sudo systemctl stop etcd-iam-node<НОМЕР>

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  2. При наличии файлов существующей БД, скопируйте их:

    $ sudo mv /srv/etcd/etcd-iam-node<НОМЕР> /srv/etcd/etcd-iam-node<НОМЕР>-old

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  3. Восстановите БД из резервной копии на всех управляющих узлах:

    $ node=node<НОМЕР>$ rm -rf /srv/etcd/etcd-iam-$node/default.etcd/ETCDCTL_API=3 etcdctl snapshot restore /srv/backup/etcd/iam-<ДАТА>-<ВРЕМЯ>.db \--name etcd-iam-$node \--initial-cluster etcd-iam-node1=http://10.133.90.15:22380,etcd-iam-node2=http://10.133.90.16:22380,etcd-iam-node3=http://10.133.90.17:22380 \--initial-cluster-token vkcloud_iam_etcd_cluster \--initial-advertise-peer-urls http://10.133.90.15:22380 \--data-dir /srv/etcd/etcd-iam-$node/default.etcdchmod 0700 /srv/etcd/etcd-iam-$node/default.etcdchown -R etcd:etcd /srv/etcd/etcd-iam-$node/

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  4. Установите права на восстановленную БД:

    $ chown -R etcd:etcd /srv/etcd/etcd-iam-node<НОМЕР>/

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  5. Запустите etcd:

    $ sudo systemctl start etcd-iam-node<НОМЕР>

    Здесь <НОМЕР> — номер управляющего узла, например 1.

Scrooge

  1. Остановите etcd:

    $ sudo systemctl stop etcd-scrooge-node<НОМЕР>

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  2. При наличии файлов существующей БД, скопируйте их:

    $ sudo mv /srv/etcd/etcd-scrooge-node<НОМЕР> /srv/etcd/etcd-scrooge-node<НОМЕР>-old

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  3. Восстановите БД из резервной копии на всех управляющих узлах:

    $ node=node<НОМЕР>$ rm -rf /srv/etcd/etcd-iam-$node/default.etcd/ETCDCTL_API=3 etcdctl snapshot restore /srv/backup/etcd/iam-<ДАТА>-<ВРЕМЯ>.db \--name etcd-iam-$node \--initial-cluster etcd-scrooge-node1=http://10.133.90.15:22380,etcd-scrooge-node2=http://10.133.90.16:22380,etcd-scrooge-node3=http://10.133.90.17:22380 \--initial-cluster-token vkcloud_iam_etcd_cluster \--initial-advertise-peer-urls http://10.133.90.15:22380 \--data-dir /srv/etcd/etcd-iam-$node/default.etcdchmod 0700 /srv/etcd/etcd-iam-$node/default.etcdchown -R etcd:etcd /srv/etcd/etcd-iam-$node/

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  4. Установите права на восстановленную БД:

    $ chown -R etcd:etcd /srv/etcd/etcd-scrooge-node<НОМЕР>/

    Здесь <НОМЕР> — номер управляющего узла, например 1.

  5. Запустите etcd:

    $ sudo systemctl start etcd-scrooge-node<НОМЕР>

    Здесь <НОМЕР> — номер управляющего узла, например 1.

Apache Zookeeper

Чтобы восстановить Apache Zookeeper, выполните следующие операции на всех управляющих узлах:

  1. При наличии файлов существующей БД, скопируйте их:

    $ sudo mv /var/lib/zookeeper /var/lib/zookeeper-old

  2. Разархивируйте архив резервной копии:

    $ sudo tar -xvf /srv/backup/zookeeper-<ДАТА>.tar.gz -C /

  3. Перезапустите службу Apache Zookeeper:

    $ sudo systemctl restart zookeeper

  4. Проверьте состояние кластера:

    $ echo ruok | nc localhost 2181$ echo stat | nc localhost 2181

Переменные

Задайте переменные оболочки для работы с обновлением:

Пример значений переменных при обновлении с версии 4.1.1
export NEW_RELEASE_NAME="4.2.2"export PREV_RELEASE_NAME="4.1.1"export NEW_DISTRIB_DIR="$HOME/box-4.2.2"export PREV_DISTRIB_DIR="$HOME/box-4.1.1"export PREV_INVENTORY_DIR="$HOME/inventory"export INVGEN_ARCH="linux-amd64"
Пример значений переменных при обновлении с версии 4.2.0
export NEW_RELEASE_NAME="4.2.2"export PREV_RELEASE_NAME="4.2.0"export NEW_DISTRIB_DIR="$HOME/box-4.2.2"export PREV_DISTRIB_DIR="$HOME/box-4.2.0"export PREV_INVENTORY_DIR="$HOME/inventory"export INVGEN_ARCH="linux-amd64"

Здесь:

  • NEW_RELEASE_NAME — новая версия релиза Платформы.

  • PREV_RELEASE_NAME — предыдущая версия релиза Платформы.

  • NEW_DISTRIB_DIR — директория нового релиза.

  • PREV_DISTRIB_DIR — директория предыдущего релиза.

  • PREV_INVENTORY_DIR — директория предыдущего Inventory.

  • INVGEN_ARCH — архитектура Inventory-генератора. Может быть одна из следующих:

    • darwin-amd64.
    • darwin-arm64.
    • linux-amd64.
    • linux-arm64.
    • windows-amd64.

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

Создайте резервную копию Inventory предыдущего релиза:

$ cp -r $PREV_INVENTORY_DIR $PREV_INVENTORY_DIR-${PREV_RELEASE_NAME}.bck

Была ли статья полезна?