Миграция с ATE 1.x на ATE 2.x

Инструкция описывает переход кластера с коллекции ATE 1.x на ATE 2.x. Удалять и разворачивать кластер заново не нужно: достаточно привести инвентарь к формату 2.x и повторно запустить установку коллекцией 2.x. Данные и конфигурация в хранилище сохраняются. Юниты экземпляров перегенерируются, экземпляры перезапускаются.

Применимо к кластерам, где конфигурация хранится в etcd или в TbCS (Tarantool-based config storage).

Без изменений в кластере можно проверить:

• инвентарь: ansible-inventory -i <inventory> --graph (генератор принимает новый формат, хосты попадают в нужные группы);
• синтаксис: ansible-playbook -i <inventory> playbooks/install.yml --syntax-check;

Для перехода на 2.x внесите в инвентарь следующие изменения.

1. Переименуйте все переменные cartridge_* в tarantool_*, суффикс остаётся тем же. Например, cartridge_systemd_dir → tarantool_systemd_dir.

2. Удалите tarantool_3_0_version_support.

3. Ключ шифрования TCM. Если TCM используется с шифрованием, сохраните значение tcm_security_encryption_key или файл с ключом.

4. Тип экземпляра. Для статического инвентаря задайте ate_instance_type. В инвентаре для генератора переменная не нужна: тип экземпляра определяется по секции components.

   Тип экземпляра	Значение ate_instance_type	Группа хостов (формирует роль prepare)
   Экземпляр Tarantool (TDB)	tarantool (по умолчанию)	tarantool_platform_hosts
   Tarantool Cluster Manager	tcm	tarantool_cluster_manager_hosts
   Tarantool Queue Enterprise (gRPC API)	tqe-grpc	tarantool_queue_enterprise_hosts
   Планировщик TCS	tcs-scheduler	tarantool_scheduler_hosts
   Шлюз потоков данных TCF	tcf-gateway	tcf_gateway_hosts
   Приёмник потоков данных TCF	tcf-destination	tcf_destination_hosts
   Tarantool CDC	cdc	tarantool_cdc_hosts

Тип tcs-scheduler используется только для TCS версии 0.x. В более новых версиях TCS планировщик является экземпляром Tarantool, а не отдельной сущностью. Он устанавливается как tarantool (значение переменной по умолчанию).

1. Параметры хранилища конфигурации. Адрес и префикс задаются общими переменными tarantool_config_storage_*. Учётные данные и TLS зависят от типа хранилища.

   etcd

   Переменная 1.x	Переменная 2.x	Действие
   tarantool_etcd_prefix tarantool_config_etcd_prefix	tarantool_config_storage_prefix	Переименовать
   tarantool_etcd_host tarantool_etcd_port tarantool_etcd_schema_definition	tarantool_config_storage_endpoints	Удалить, адрес указать в endpoints (<схема>://<хост><порт>)
   tarantool_etcd_username tarantool_etcd_password	без изменений	—
   tarantool_etcd_ssl_*	без изменений	—

    
   tarantool_config_storage_prefix: /tarantool/tarantooldb   tarantool_config_storage_endpoints:     - https://etcd-1:2379   tarantool_etcd_username: root   tarantool_etcd_password: <пароль>   tarantool_etcd_ssl_ca_file: /path/ca.crt

   TbCS

   Включается переменной tarantool_config_storage: tarantool. Логин, пароль и TLS задаются в словаре каждого endpoint, отдельных переменных для них нет. Переменные tarantool_etcd_* в этом режиме не используются.

   Переменная 1.x	Переменная 2.x	Действие
   tarantool_config_storage tarantool_config_storage_prefix tarantool_config_storage_endpoints	без изменений	—
   tarantool_config_storage_username tarantool_config_storage_password	—	Удалить, указать в login и password endpoint

    
   tarantool_config_storage: tarantool   tarantool_config_storage_prefix: /tarantool/tarantooldb   tarantool_config_storage_endpoints:     - uri: "https://tbcs-1:4401"       login: config-storage       password: <пароль>       params:         transport: ssl         ssl_cert_file: /opt/tarantool/certs/server.crt         ssl_key_file: /opt/tarantool/certs/server.key

 
tarantool_config_storage_prefix: "/tarantool/{{ cluster_name }}"tarantool_config_storage_endpoints:  - "https://etcd:2379"tarantool_config_storage_username: "root"tarantool_config_storage_password: "mysecurepassword"tarantool_tt_connect_username: clienttarantool_tt_connect_password: secrettarantool_etcd_ssl_key_file: "/certs/client.key"tarantool_etcd_ssl_cert_file: "/certs/client.crt"tarantool_etcd_ssl_ca_file: "/certs/rootCA.crt"

1. Установите коллекцию ATE 2.x на управляющий хост и проверьте, что используется именно она:

    
   ansible-galaxy collection install tarantool-enterprise-*.tar.gz -p ./collectionsexport ANSIBLE_COLLECTIONS_PATH=$PWD/collectionsansible-galaxy collection list tarantool.enterprise

2. Внесите изменения в инвентарь по разделу Общие изменения инвентаря.

3. Проверьте, что инвентарь собирается и все экзмепляры попали в группы своих компонентов:

    
   ansible-inventory -i <inventory> --graph

4. Проверьте мигрированный инвентарь плейбуком check.yml:

    
   ansible-playbook -i <inventory> playbooks/check.yml

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

5. Запустите повторную установку кластера, но уже с помощью новой версии коллекции:

    
   ansible-playbook -i <inventory> playbooks/install.yml --diff

   В systemd-юнитах экземпляров изменится формат строк Environment: кавычки переносятся с всей строки на значение переменной. В выводе --diff это выглядит так:

    
   -Environment='TT_CONFIG_ETCD_PREFIX=/tarantooldb'+Environment=TT_CONFIG_ETCD_PREFIX='/tarantooldb'

Начиная с 2.0 установка и применение конфигурации выполняются через плейбук install.yml.

• Юниты systemd и конфигурация кластера рендерятся по шаблонам 2.x. Если мигрированный инвентарь эквивалентен старому, результат совпадает с текущим и изменений нет.
• Экзмепляр перезапускается, так как изменилась конфигурация.
• Конфигурация кластера записывается в хранилище по прежнему префиксу.
• Данные экземпляров и состояние хранилища TCM сохраняются.
• TCM перезапускается, так как изменилась его конфигурация.

Обновление прошло успешно, если выполнены все условия ниже.

1. Все юниты экземпляров, координаторов и TCM находятся в состоянии active (running). Дублей юнитов с другими именами нет. Проверьте от пользователя tarantool на каждом хосте:

    
   systemctl --user list-units --all --type=service '*@*'systemctl --user --failed

   В первом выводе — юниты всех экземпляров, координаторов и TCM этого хоста, все active running, их количество совпадает с количеством экземпляров в инвентаре. Второй вывод пустой.

   Время запуска процессов (видно, какие экземпляры перезапускались):

    
   ps -eo lstart,cmd | grep -E '[t]arantool|[c]luster-manager'

2. В окружении юнитов есть параметры подключения к хранилищу. Для etcd это:

   • TT_CONFIG_ETCD_ENDPOINTS
   • TT_CONFIG_ETCD_PREFIX
   • TT_CONFIG_ETCD_USERNAME
   • TT_CONFIG_ETCD_PASSWORD
   • TT_CONFIG_ETCD_SSL_* (если используется TLS)

   Проверьте командой от пользователя tarantool:

    
   systemctl --user show <unit> -p Environment

3. Каждый экземпляр находится в статусе running, в каждом наборе реплик есть ровно один лидер.

    
   tt status <имя приложения>

   Имя приложения — часть имени юнита до @ (например, tarantooldb@storage-r01-i01 → tt status tarantooldb). У всех экземпляров должен быть RUNNING, в колонке MODE — ровно один RW на набор реплик.

4. Данные на месте: контрольные спейсы и количество записей совпадают с состоянием до обновления.

5. TCM подключился к кластеру:

   • в tcm.log после последнего старта нет recover panic;
   • есть строки tarantool connection role changed;
   • кластер открывается в веб-интерфейсе.