logo

Предупреждения при обновлении

Важные изменения в текущей поставке

  1. В Закрома.Хранение 2.9 изменена схема адресации S3 API: path-style и virtual-hosted-style доступны через единый адрес <workspace>.<FQDN>, а адрес глобального namespace изменён с gs.<FQDN> на global.<FQDN>. Перед обновлением подготовьте DNS-записи и проверьте настройки клиентских приложений. Для обратной совместимости старые адреса <workspace>.ps.<FQDN> и <workspace>.vs.<FQDN> можно добавить как дополнительные домены.

  2. Nginx теперь является опциональным компонентом поставки. Его настройка требуется только для инсталляций, в которых Nginx использовался раньше как обязательный компонент.

  3. Из поставки исключена версия Keycloak 26.3.2. Роль keycloak (8.0.1) поставляет только версию 26.5.5, которая используется по умолчанию (keycloak_quarkus_version: 26.5.5). Для новых установок и обновлений используйте Keycloak 26.5.5.

  4. В group_vars/zakroma-storage.yml параметры PostgreSQL вынесены в глобальный блок zakroma_storage_postgresql_*; компоненты (core, gateway, workers и др.) ссылаются на них через Jinja-шаблоны. При обновлении с более ранних поставок перенесите учётные данные и параметры подключения в глобальные переменные.

  5. Переменная zakroma_storage_nginx_proxy удалена. Для доступа к Admin UI через reverse proxy используйте блок zakroma_storage_admin.reverse_proxy.

  6. Добавлена опциональная переменная zakroma_storage_config_encrypt (по умолчанию false). При значении true конфигурационные файлы сервисов шифруются через systemd LoadCredentialEncrypted=; на целевых хостах требуются systemd ≥ 250 и утилита systemd-creds.

  7. В поставке 8.0.0 (Закрома.Хранение 2.10.0) сервисы gateway и core объединены в один сервис zakroma-storage-monolith. Отдельный сервис zakroma-storage-gateway больше не устанавливается, переменная zakroma_storage_gateway_version удалена, файл лицензии располагается по пути /opt/zakroma/zakroma-storage-monolith/bin/licence. Для обновления используйте плейбук playbooks/sample-play-zakroma-storage-upgrade.yml — он переносит лицензию из каталога legacy-сервиса и выполняет обновление. После успешного обновления и ручной проверки удалите артефакты legacy gateway плейбуком playbooks/sample-play-delete-old-version.yml с явным подтверждением -e cleanup_approved=true. Порядок запуска приведён в разделе «Запуск плейбука обновления» ниже.

  8. В group_vars/zakroma-storage.yml изменён набор параметров блока zakroma_storage_gateway: удалены host, api_enable и max_conns_per_host, параметр aws_sing_v4_logs_enable переименован в aws_sig_v4_logs_enable, ключи шифрования scrambler_keys перенесены из блока zakroma_storage_core в блок zakroma_storage_gateway. При обновлении перенесите собственные значения в новую структуру параметров.

  9. Автоматическое создание топиков Kafka по умолчанию отключено (topic_auto_creation.enabled: false). В group_vars/kafka.yml добавлены топики ZakromaCoreBackgroundMonitoring и ZakromaCoreBackgroundMonitoringDL.

Поддерживаемый порядок обновления

Обновление на целевую версию поддерживается только с предыдущей версии продукта. Прямой переход через одну или несколько версий не поддерживается.

Для перехода на Закрома.Хранение 2.10 сначала обновите инсталляцию до последней доступной версии 2.9.X, выполните проверку работоспособности сервисов и только после этого выполняйте обновление до версии 2.10.X.

Пример корректной цепочки обновления:

12.8.X -> 2.9.X -> 2.10.X

Пример неподдерживаемого перехода:

12.8.X -> 2.10.X

Запуск плейбука обновления

Обновление Закрома.Хранение до версии 2.10 выполняется плейбуком playbooks/sample-play-zakroma-storage-upgrade.yml из архива поставки 8.0.0. Плейбук рассчитан на переход с предыдущей поддерживаемой версии (2.9.X) и подготавливает узлы к монолитной архитектуре продукта.

Перед запуском выполните подготовку:

  1. Распакуйте архив поставки 8.0.0
  2. Перенесите собственные значения из group_vars предыдущей поставки в group_vars новой поставки (см. пункты 4, 8 и 9 выше).
  3. Убедитесь, что файл лицензии присутствует на узлах Закрома.Хранение.

Плейбук выполняется последовательно, по одному узлу (serial: 1), и останавливается при первой ошибке.

Запуск для базового кластера:

1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-storage-upgrade.yml

Для других сценариев укажите соответствующий inventory: inventories/single-node/hosts для Single Node; для мультикластера выполните плейбук отдельно для каждого кластера — inventories/multicluster/cluster-1/hosts и inventories/multicluster/cluster-2/hosts. При использовании Ansible Vault в group_vars добавьте --ask-vault-pass.

Если файл лицензии расположен не по стандартному пути, задайте его через extra vars:

1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-storage-upgrade.yml \
4  -e old_license_path=/путь/к/licence

После завершения плейбука проверьте на каждом узле systemd-сервис zakroma-storage-monolith, логи приложения и доступность S3 API и Admin API. Порядок поузловой проверки приведён в разделе «Онлайн-обновление» ниже.

Удалять артефакты до завершения обновления и ручной проверки нельзя. Очистка выполняется отдельным плейбуком playbooks/sample-play-delete-old-version.yml только с явным подтверждением: без -e cleanup_approved=true плейбук прерывается с ошибкой.

1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-delete-old-version.yml \
4  -e cleanup_approved=true

Рекомендуемый порядок онлайн-обновления:

  1. Перед началом убедитесь, что текущая версия является предыдущей поддерживаемой версией для целевого релиза.
  2. Проверьте доступность сервисов Закрома.Хранение и состояние внешних зависимостей.
  3. Выберите первый узел для обновления.
  4. Запустите playbook обновления с параметром --limit <hostname> либо используйте playbook с serial: 1.
  5. После завершения обновления проверьте systemd-сервисы, логи приложения и доступность S3/Admin API.
  6. Переходите к следующему узлу только после успешной проверки предыдущего.
  7. Повторите процедуру для всех узлов группы zakroma-storage.

Рекомендуемые действия перед обновлением ПО

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

  2. Рекомендуется сделать резервную копию БД PostgreSQL.

  3. При изменении имён узлов, на которых запущен ZDS, проверьте, что в инвентаре Ansible и в конфигурации ZDS используется единообразное именование узлов в соответствии с требованиями к построению кластера.

    По умолчанию для создания первоначальной конфигурации используется переменная ansible_hostname. Если её значение отличается от текущего nodeName, кластер может стать недоступным.

    Команды для проверки имён узлов ZDS:

    Проверка текущего ansible_hostname:

    1ANSIBLE_CONFIG=ansible.cfg ansible -m setup -i inventories/тип_инсталляции/hosts zakroma-zds-v2-ec | grep ansible_hostname

    Проверка имён в конфигурации ZDS (nodeName):

    1curl -u zakromaadmin:zakromaadmin http://localhost:8088/inner/status | jq '.nodeName, .nodes[].name'

    Если ansible_hostname отличается от nodeName после глобального изменения имён узлов, то необходимо использовать переменную zakroma_zds_node_name для подстановки «старых» имён узлов в инвентаре Ansible.

    Пример:

    1[zakroma-zds-v2-ec]
2rutherford-2 ansible_host=192.168.1.2 zakroma_zds_node_name=rutherford-2
3rutherford-3 ansible_host=192.168.1.3 zakroma_zds_node_name=rutherford-3
4rutherford-4 ansible_host=192.168.1.4 zakroma_zds_node_name=rutherford-4