Руководство по установке

Данное Руководство адресовано системным администраторам, ответственным за установку и управление системой Tarantool Column Store (TCS). В их круг задач входят:

• подготовка серверов;
• установка системы в производственной среде;
• обновление системы, откат к предыдущей версии и удаление системы.

Процессор (CPU) должен поддерживать профиль x86-64-v3 и дополнительные расширения: AES-NI/PCLMULQDQ, ADX, RDRAND/RDSEED, XSAVEOPT/XSAVEC/XSAVES.

TCS поддерживает установку на следующие операционные системы (ОС) семейства Linux:

• Astra Linux 1.7;
• РЕД ОС 7.3 Стандарт;
• МосОС Арбат 15.5.

Также возможна установка на Ubuntu и CentOS, но без гарантии полноценной работоспособности.

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

• etcd версии не ниже 3.4.
• python версии не ниже 3.11.
• Ansible версии не ниже 9.7.0.
• Инсталлятор Ansible Tarantool Enterprise версии не ниже 1.21.2.

Tarantool Column Store – колоночная транзакционно-аналитическая СУБД, построенная на платформе Tarantool Enterprise Edition.

TCS наследует от Tarantool следующие возможности хранения и масштабирования:

• данные хранятся в оперативной памяти;
• хранение персистентно;
• доступны механизмы шардирования и репликации.

Таким образом, перед установкой и эксплуатацией TCS требуется подготовить сервера для использования сопутствующего ПО:

• Tarantool;
• инсталлятора Ansible Tarantool Enterprise.

1. Настройте межсетевой экран (firewall):

   a. Настройте порты для бинарного протокола Tarantool.

   Tarantool использует как TCP, так и UDP, для взаимодействия внутри кластера.

   Откройте пул портов 3301 — 3401 для TCP и UDP трафика, для внутреннего трафика на всех серверах, на которых устанавливается Tarantool.

   Если внешние приложения обращаются к кластеру по бинарному протоколу, также необходимо открыть пул портов 3301 — 3401, но достаточно TCP.

   b. Настройте порты для TCP и HTTP(s).

   • TCP используется для взаимодействия администраторов с веб-интерфейсом модуля Tarantool Cluster Manager (TCM).

     На всех серверах, на которых устанавливается TCM, откройте порт для TCP-трафика, указанный в конфигурации TCM (по умолчанию 8080).

   • Встроенный в Tarantool сервер может принимать SSL трафик, поэтому проксирование HTTPs-трафика на HTTP-порты настраивать не нужно.

     Откройте пул портов 8001 – 8101 для HTTPs-трафика на всех серверах, на которых устанавливается Tarantool.

   • HTTP используется для взаимодействия с интерфейсом сервиса TCS, где ждет ввод обработчик /sql.

     Откройте пул портов 7700-7800 для HTTPs трафика на всех серверах, на которых будет запущен сервис TCS.

   c. Настройте порты для внутреннего трафика для etcd. По умолчанию используется порт 2379.

   d. В случае, если у вас:

   • отдельно стоящий сервер, или
   • один из серверов под Tarantool, или
   • агент CI/CD системы,

   настройте также:

   • доступ по 22 порту (ssh) для devops-инженера;
   • сетевой доступ по 22 порту (ssh) до всех серверов, на которые производится установка. В том числе до серверов под etcd и других сервисов.

2. Настройте DNS.

   Все сервера должны находить друг друга по FQDN (доменное имя локальной машины). Удобно использовать доменное имя для обозначения экземпляров Tarantool в кластере.

3. Разбейте дисковое пространство в соответствии с рекомендациями для оптимальной работы экземпляров Tarantool:

   • журналы (logs) – 2 GB * количество экземпляров Tarantool, но не менее 15 GB
   • журнал упреждающей записи (WAL) – 40-50% от RAM, используемого всеми экземплярами Tarantool
   • снимки данных (snapshots) – 100-110% от RAM, используемого всеми экземплярами Tarantool

   Разбейте диски в соответствие с расчетами и подключите директории с помощью команды mount.

4. Скорректируйте параметры ядра.

   a. Задайте параметры overcommit по памяти:

    
   sudo cat << EOF >> /etc/sysctl.confvm.overcommit_memory = 2vm.overcommit_ratio = 100EOF

   b. При ошибочном завершении Tarantool должен быть создан coredump-файл, который понадобится нашим специалистам для исследования проблемы. Файлы должны собираться в доступную на запись директорию, иметь в названии PID, signal и timestamp. Для корректного сохранения отладочной информации потребуются следующие настройки:

    
   sudo cat << EOF >> /etc/sysctl.confkernel.core_uses_pid = 1kernel.core_pattern = /app/tarantool/coredump/core-%e-%u-%g-%p-%tEOF

   c. Настройте пул портов для исходящих запросов.

   Исходящие соединения могут занимать порты, предназначенные для бинарного протокола Tarantool.

    
   sudo cat << EOF >> /etc/sysctl.confnet.ipv4.ip_local_port_range = 32768   61000EOF

5. Установите etcd требуемой версии:

6. Установите вспомогательные утилиты.

   Команды для поддерживаемых ОС:

   Для Astra Linux:

    
   sudo apt updatesudo apt install -y \         logrotate \        # Для ротации журналов         cronie \           # Утилита crontab         gdb \              # Для сбора отладочной информации в случае падения         gcore \            # Для создания coredump-файла на лету         telnet \           # Для проверки сетевой связности узлов         iperf3 \           #         iptraf-ng \        #         htop               # Более наглядный top

   Для РЕД ОС:

    
   sudo dnf install -y \         logrotate \         cronie \         gdb \         telnet \         iperf3 \         iptraf-ng \         htop

7. Создайте учетные записи.

   Создайте группу tarantool и локального пользователя tarantool для запуска и управления Tarantool:

    
   sudo groupadd -g 3301 tarantoolsudo useradd -m -u 3301 -g 3301 --system tarantool

   Для корректной работы пользователя tarantool с systemctl в пользовательском окружении выполните команду:

    
   sudo loginctl enable-linger tarantool

   Аналогично tarantool, потребуется учетная запись для работы с etcd. Соответствующий пользователь должен создаваться в процессе установки etcd. Если этого не произошло, создайте его самостоятельно:

    
   sudo groupadd etcdsudo useradd -m -g etcd --system etcd

8. Активируйте пользовательское пространство systemd:

    
   sudo loginctl enable-linger tarantool

9. Создайте директории для записи на диск:

    
   sudo mkdir -p /app/tarantoolsudo mkdir -p /app/tarantool/coredumpsudo mkdir -p /app/logssudo mkdir -p /app/snapsudo mkdir -p /app/etcd

   И задайте права:

    
   sudo chown tarantool:tarantool /app/tarantoolsudo chown tarantool:tarantool /app/tarantool/coredumpsudo chown tarantool:tarantool /app/logssudo chown tarantool:tarantool /app/snapsudo chown etcd:etcd /app/etcd

10. Настройте лимиты для группы tarantool.

     
    sudo cat << EOF >> /etc/security/limits.d/tarantool.conf@tarantool    -   nproc   64000@tarantool    -   nofile   64000@tarantool    -   core   unlimitedEOF

11. Настройте оркестратор.

    a. Создайте systemd сервис-файлы для экземпляров Tarantool.

    Сервис-файлы – это стандартный способ управления процессами в современных Linux, который работает на всех systemd-совместимых ОС. Сервис-файлы задают конфигурацию для запуска экземпляров Tarantool как фоновых сервисов с автозагрузкой, журналированием и контролем состояния.

    Можно создать один файл /etc/systemd/system/tarantool@.service (шаблон для нескольких экземпляров) или отдельные файлы под каждый экземпляр.

    Пример сервис-файла с ключевыми параметрами:

     
    # /etc/systemd/system/tarantool@.service  (шаблон для нескольких экземпляров)[Unit]Description=Tarantool Column Store instance: %i   # %i = имя из названия файла (например, instance1)After=network-online.target                       # Ждём готовности сети (критично для full-mesh кластера)[Service]Type=simple                                       # Один главный процесс, systemd отслеживает его PIDUser=tarantool                                    # Запуск от непривилегированного пользователяGroup=tarantoolExecStart=/usr/bin/tarantool /app/tarantool/%i.lua  # Запуск экземпляра с его lua-конфигурациейRestart=on-failure                                # Автоперезапуск при крахе (но не при ручном stop)LimitNOFILE=64000                                 # Лимит открытых файлов (синхронно с limits.conf)LimitNPROC=64000                                  # Лимит потоков/процессовStandardOutput=journal                            # Журналы stdout → journaldStandardError=journal                             # Журналы stderr → journald[Install]WantedBy=multi-user.target                        # Включать в стандартный режим загрузки ОС

    b. Настройте персистентное хранилище journald (для РЕД ОС и RHEL).

    Журналы экземпляров, отправляемые в stdout и stderr, автоматически попадают в journald. Правильная настройка journald нужна для персистентного хранения журналов сервисов (включая Tarantool), чтобы они сохранялись после перезагрузки и были доступны через journalctl. Это упрощает отладку, делая вызовы типа journalctl -u tarantool@instance1 -f доступными даже при ротации файловых журналов.

    Изменение настроек Tarantool здесь не требуется. Достаточно, чтобы сервис Tarantool был запущен под systemd.

    Пример настройки journald:

     
    sudo mkdir -p /var/log/journal                     # Создаём директорию для персистентного храненияsudo chown root:systemd-journal /var/log/journal   # Владелец root, группа systemd-journalsudo chmod 2755 /var/log/journal                   # Sticky bit + право записи группеsudo systemd-tmpfiles --create --prefix /var/log/journal # Применяем правила tmpfiles.dsudo systemctl restart systemd-journald            # Перезапуск службы для применения изменений

    Проверка:

     
    journalctl -u tarantool@* -f # Теперь журналы не пропадут после перезагрузки

    c. Выдайте sudo-права администратору Tarantool.

    Точечные sudo-права для администраторов обеспечивают безопасность, удобство автоматизации, возможность аудита и разделение ответственности без предоставления полного root-доступа:

    • Принцип наименьших привилегий: администраторы не работают под root, а переключаются в tarantool/etcd только тогда, когда нужно.
    • Автоматизация: скрипты развертки/мониторинга могут выполнять команды через sudo -u tarantool без знания пароля.
    • Аудит: все действия через sudo журналируются (кто, когда, какую команду выполнил).
    • Разделение ролей: например, одной группе можно выдать права только на systemctl status, а другой — на restart.

    Пример безопасной настройки (/etc/sudoers.d/tarantool-admins):

     
    # Создавать только через: sudo visudo -f /etc/sudoers.d/tcs-admins%GROUP@domain.ru ALL=(tarantool) NOPASSWD: ALL      # Группа может выполнять ЛЮБЫЕ команды ОТ ИМЕНИ tarantool%GROUP@domain.ru ALL=(etcd) NOPASSWD: ALL           # То же самое для пользователя etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl status etcd    # Проверка статуса от root%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl restart etcd   # Перезапуск сервиса%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/journalctl -u etcd -f    # Просмотр логов в реальном времени.

    Для обслуживания серверов с Tarantool удобно выделить некоторую доменную группу из AD и выдать ей соответствующие права на переход под пользователей tarantool и etcd. Также нужны права на управление сервисами и просмотр журналов для etcd.

    Указанный список в формате sudoers может выглядеть так:

     
    # пример для Astra Linux%GROUP@domain.ru ALL=(tarantool) NOPASSWD: ALL%GROUP@domain.ru ALL=(etcd) NOPASSWD: ALL%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl status etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl restart etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl reload etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl start etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl stop etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl enable etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl disable etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/systemctl edit etcd%GROUP@domain.ru ALL=(ALL) NOPASSWD: /bin/journalctl -u etcd

12. Настройте ротацию журналов.

    Здесь подразумевается добавление пользователя tarantool в группу crontab для того, чтобы снять возможное ограничение ОС на использование команды crontab -e. В результате пользователь tarantool сможет использовать crontab -e для планирования своих внутренних задач (создание резервных копий, ротация журналов) без прав root. Никаких других дополнительных прав в системе пользователю tarantool это на даст.

    Для Astra Linux:

    1. Убедитесь, что утилита crontab установлена.
    2. Добавьте пользователя tarantool в группу crontab.

     
    sudo usermod -a -G crontab tarantool

    Для РЕД ОС:

    Права на crontab организуются через файлы /etc/cron.allow и /etc/cron.deny. Проверьте, что выполняется любое из двух условий:

    1. Пользователь tarantool есть в файле /etc/cron.allow, либо
    2. Файла /etc/cron.allow нет, а файл /etc/cron.deny пуст (crontab доступен всем).

1. Для Astra Linux: Установите обязательный пакет user D-Bus.

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

    
   /usr/lib/systemd/user/dbus.service/usr/lib/systemd/user/dbus.socket/usr/lib/systemd/user/sockets.target.wants/dbus.socket

   Его требуется установить для пользовательских systemd-сервисов в случае установки TCS с помощью Ansible Tarantool Enterprise версий 1.22.0 и выше на ОС Astra Linux SE 1.7. Для установки выполните:

    
   apt-get install -y dbus-user-session

   После запуска пользовательского процесса systemd (user manager) должен появиться сокет:

    
   /run/user/UID/bus

   Этот файл проверяет роль systemd в задаче Wait for user D-Bus socket.

   Также необходимо обеспечить запуск пользовательского процесса systemd для пользователя tarantool. Для этого, например, можно включить linger:

    
   loginctl enable-linger tarantool

2. См. документацию по инсталлятору Ansible Tarantool Enterprise, глава Настройка среды.

Пример кластера TCS, развернутого на нескольких серверах:

Архив с пакетом поставки TCS доступен в личном кабинете на сайте tarantool.io.

Установка TCS в производственной среде производится с использованием инсталлятора Ansible Tarantool Enterprise (ATE).

В случае установки системы TCS с использованием ATE доступны 2 варианта:

• Установка TCS с помощью Docker-образа;
• Установка TCS с помощью Ansible-коллекции.

Выполните следующие шаги:

1. Подготовьте сервера.

   a) Выполните все шаги из раздела Подготовка серверов. b) [Только на сервере с ATE] Запустите сценарий подготовки сервера, выполнив следующую команду:

    
   docker run --network host -it --rm \    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook -i /ansible/inventories/hosts.yml \    --extra-vars  '{        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",        "super_user":"'${SUPER_USER_NAME}'",        "tarantool_shared_become_user":"root",    }' \    playbooks/env_prepare.yml

2. Настройте конфигурацию TCS.

   См. подробнее:

   • Настройка кластера
   • Примеры статических инвентарей

3. Настройте отправку конфигурации TCS в etcd.

   Задайте следующие переменные:

   • [обязательно] cartridge_app_name (string) — Специфичная для TCS часть ключа, по которому файл конфигурации TCS сохраняется в ETCD. Полный ключ имеет вид /tarantool/{{ cartridge_app_name }}/config/all. Файл конфигурации генерирутеся инсталлятором ATE из инвентаря.

   • [обязательно] tarantool_etcd_host — Aдрес сервера ETCD в переменной tarantool_etcd_host. Адрес должен быть доступен с сервера, на котором разворачиваются экземпляры Tarantool.

   • tarantool_etcd_schema_definition (string) — Протокол используемый для передачи данных в etcd.

     • http ← (default)

   • tarantool_etcd_validate_certs (string) — Наличие проверки серверного сертификата etcd.

   • tarantool_config_etcd_ssl_cert_file (string) — Путь к ssl-сертификату используемому для установки соединения с etcd.

   • tarantool_config_etcd_ssl_key_file (string) — Путь к ssl-ключу используемому для установки соединения с etcd.

   • tarantool_config_etcd_ssl_ca_file (string) — Путь к ca-сертификату используемому для установки соединения с etcd.

   • tarantool_etcd_username (string) — Имя пользователя для логина в etcd.

   • tarantool_etcd_password (string) — Пароль пользователя для логина в etcd.

   После настройки нужно отправить конфигурацию в etcd с помощью плейбука etcd_3_0.yml.

   Пример вызова плейбука:

    
   export PATH_TO_INVENTORY="/ATE/1.1.0_tarantool/inventory-tcs"export SUPER_USER_NAME=rootexport DEPLOY_TOOL_VERSION_TAG=1.15.0export PATH_TO_PRIVATE_KEY="/root/.ssh/id_rsa"docker run --network host --rm \    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook -i /ansible/inventories/hosts.yml \    --extra-vars  '{        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",        "super_user":"'${SUPER_USER_NAME}'",        "tarantool_shared_become_user":"tarantool",        "tarantool_shared_hosts":"tcs-r01-s01,tcs-r01-s02,tcs-r01-c01,tcs-r01-c02"    }' \    playbooks/etcd_3_0.yml

   См. также раздел Tarantool 3.x: Отправка конфигурации в etcd. в документации по инсталлятору Ansible Tarantool Enterprise.

4. [Необязательно] Установите CIAM.

   См. подробнее Установка CIAM.

5. Установите TCS.

   Установка предполагает развертывание кластера TCS с помощью плейбука tcs/install.yml.

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

   • tcs_v1_support (bool) - установите значение true, если используете динамический инвентарь для установки TCS 1.x.
   • tcs_http_credentials (object) - задайте username и password для секции конфигурации roles_cfg.app/aggregator_role.http.credentials, если используете динамический инвентарь для установки TCS 1.x.
   • tcs_sql_credentials (object) - задайте username и password для секции конфигурации roles_cfg.app/aggregator_role.arrow_flight_sql.credentials, если используете динамический инвентарь для установки TCS 1.x.
   • tcs_http_enabled (bool) - задайте значение false, если хотите отключить поддержку http-запросов для TCS. Значение по умолчанию: true.

   Пример вызова плейбука:

    
   export PATH_TO_INVENTORY="/ATE/1.1.0_tarantool/inventory-tcs"export SUPER_USER_NAME=rootexport DEPLOY_TOOL_VERSION_TAG=1.15.0export PATH_TO_PRIVATE_KEY="/root/.ssh/id_rsa"export PACKAGE_NAME=tarantool_column_store.x86_64.tar.gzexport PATH_TO_PACKAGE="/TCS/tarantool3"docker run --network host --rm \    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \    -v ${PATH_TO_PACKAGE}/${PACKAGE_NAME}:/ansible/packages/${PACKAGE_NAME}:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    -e PACKAGE_NAME=${PACKAGE_NAME} \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook -i /ansible/inventories/hosts.yml \    --extra-vars '{        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",        "super_user":"'${SUPER_USER_NAME}'",        "tarantool_shared_become_user":"tarantool",        "tarantool_shared_hosts":"tcs-r01-s01,tcs-r01-s02,failover_coordinator_1,failover_coordinator_2,tcs-r01-c01,tcs-r01-c02"    }' \    playbooks/tcs/install.yml

   где:

   • PATH_TO_INVENTORY — путь до файла инвентаря.
   • PATH_TO_PACKAGE - путь до артефакта.
   • PACKAGE_NAME — имя архива с поставкой Tarantool Column Store.
   • HOSTS - группа хостов кластерного хранилища.

   См. также раздел Tarantool Column Store: Установка приложения в документации по инсталлятору Ansible Tarantool Enterprise.

6. [Необязательно] Установите TCM.

   См. раздел Tarantool Cluster Manager: Установка и запуск в документации по инсталлятору Ansible Tarantool Enterprise.

Выполните следующие шаги:

1. Подготовьте сервера к установке.
2. Установите TCS так, как описано в разделе Использование Ansible-коллекции в документации по инсталлятору Ansible Tarantool Enterprise.

Архив для установки CIAM не входит в пакет поставки TCS. Его следует скачивать отдельно на Портале Дистрибуции VK Tech, продукт VK CIAM (On-Premise). Доступ предоставляется зарегистрированным клиентам с подтвержденным номером телефона.

1. [На целевом сервере] Настроить локальный DNS.

    
   echo "127.0.0.1 ciam.local" | sudo tee -a /etc/hosts

2. [На целевом сервере] Установить nginx. Настройка не требуется.

    
   sudo apt updatesudo apt install nginx -ysudo systemctl enable nginx

3. [На целевом сервере] Установить и запустить postgresql.

   Создать пользователя app и необходимые базы данных:

    
   CREATE USER app WITH PASSWORD 'secret';CREATE DATABASE hydra OWNER app;CREATE DATABASE flow OWNER app;CREATE DATABASE audit OWNER app;CREATE DATABASE notifications OWNER app;CREATE DATABASE spicedb OWNER app;CREATE DATABASE access_control OWNER app;CREATE DATABASE access_agent OWNER app;CREATE DATABASE providers OWNER app;

4. [На управляющем сервере] Установить Ansible.

    
   sudo apt install ansible -y

5. Скопировать архив для установки CIAM, распаковать его локально и перейти в корневую директорию распакованного архива.

6. [На управляющем сервере] Установить зависимости из списка requirements.yml.

    
   cd ansiblepip install -r requirements.txt

7. [На управляющем сервере] Настроить параметры конфигурации для CIAM.

   Параметры задаются в инвентаре inventory.yml для каждого хоста или группы ciam_hosts. Ниже описаны только обязательные параметры.

   В инвентаре inventory.yml:

   • ansible_host — адрес целевого сервера;
   • ansible_user — пользователь для SSH-подключения; должен совпадать с именем системного пользователя для сервиса CIAM (см. параметр ciam_service_user в файле конфигурации group_vars/ciam_hosts.yml)
   • ciam_domain — домен CIAM (используется в redirect_uri, CORS, nginx и т.д.);
   • ciam_ssl_cert — путь к SSL-сертификату (на целевом сервере);
   • ciam_ssl_key — путь к ключу SSL-сертификата (на целевом сервере);
   • ciam_archive_path — путь к архиву CIAM (на управляющем сервере);
   • ciam_flow_pat_secret - "соль" для генерации и сверки токенов (любая строка длиной от 1 символа).

   Пример:

    
   all:  children:    ciam_hosts:      hosts:       ciam-ansible:          ansible_host: vm2          ansible_user: astra          ciam_domain: "ciam.local"          ciam_ssl_cert: "/home/astra/helpers/certs/cert.pem"          ciam_ssl_key: "/home/astra/helpers/certs/cert-key.pem"          ciam_archive_path: "/home/astra/ciam.tar.gz"          ciam_flow_pat_secret: "secret"

   В файле конфигурации group_vars/ciam_hosts.yml:

   • ciam_service_user — имя системного пользователя для сервиса CIAM;
   • ciam_service_group — имя группы системного пользователя для сервиса CIAM.

8. [На управляющем сервере] Сгенерировать SSL-сертификат и ключ с помощью плейбука ssl_certs.yml.

    
   ansible-playbook -i inventory.yml playbooks/ssl_cert.yml -l ciam-ansible

9. [На управляющем сервере] Запустить развертывание CIAM с помощью плейбука install.yml.

    
   ansible-playbook -i inventory.yml playbooks/install.yml

10. [На управляющем сервере] Обновить клиента для получения токенов в формате JWT.

     
    ansible-playbook -i inventory.yml playbooks/update_client.yml -l ciam-ansible

Дальнейшая работа с CIAM (настройка доступа к веб-интерфейсу, создание пользователей, выдача токенов) подробно описана в документации по CIAM.

Чтобы обновить TCS 1.3.2 до версии 1.3.3 (с сохранением данных), нужно выполнить следующие действия:

1. Сохранение данных.

   a. Остановите текущий кластер TCS версии 1.3.2 (в ATE плейбук stop.yml).

   b. Сохраните все резервные копии.

   Данный шаг необходим на случай отказа во время исполнения обновления (например, если произойдет обрыв сети). В таком случае процедуру обновления будет необходимо повторить целиком с самого начала.

   • Для Tarantool:

     • файлы снимков (.snap);
     • файлы журналов (.xlog);
     • мета-данные внешних томов и файлы Parquet.

   • Для etcd:

     • файл снимка etcd.

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

   a. Внесите правки в конфигурацию TCS.

   Отключите TCS-роли (tcs_roles/*) в конфигурации кластера. Для этого их можно закомментировать, а в случае их явного удаления нужно убедиться в том, что предыдущая версия конфигурации сохранена.

   После этого обновите конфигурацию кластера в etcd (см. Пример вызова плейбука etcd_3_0.yml для отправки конфигурации в etcd).

   b. Запустите кластер TCS версии 1.3.3 (в ATE плейбук start.yml).

   Кластер запустится на конфигурации с выключенными ролями.

   c. Остановите кластер TCS версии 1.3.3.

   d. Откатите кластерную конфигурацию на версию, в которой включены TCS-роли, и загрузите конфигурацию в etcd.

   e. Запустите кластер версии 1.3.3 (в ATE плейбук start.yml).

   Кластер запустится на конфигурации с включенными ролями.

Чтобы откатить TCS 1.3.3 обратно к версии 1.3.2, нужно выполнить следующие действия:

1. Остановите текущий кластер TCS версии 1.3.3 (в ATE плейбук stop.yml).

2. Сохраните все резервные копии.

   Данный шаг необходим на случай отказа во время исполнения отката (например, если произойдет обрыв сети). В таком случае процедуру отката будет необходимо повторить целиком с самого начала.

   • Для Tarantool:

     • файлы снимков (.snap);
     • файлы журналов (.xlog);
     • мета-данные внешних томов и файлы Parquet.

   • Для etcd:

     • файл снимка etcd.

3. Разверните кластер TCS версии 1.3.2 (в ATE плейбук tcs/install.yml).

Начиная с версии TCS 1.3.2 доступно обновление версии системы без простоя. Ниже приводится пример обновления для кластера из 1 набора реплик (1 мастер-узел + 1 реплика).

Порядок обновления:

1. Убедиться, что на всех экземплярах Storage включен стейтборд (роль tcs_roles/stateboard) с тем же префиксом etcd, что у экземпляров Scheduler.

2. Обновить экземпляры Scheduler.

3. Обновить экземпляры Storage.

4. Обновить экземпляры Coordinator.

5. (При необходимости) Обновить версию схемы данных.

   Если экземпляры были созданы на предыдущей версии TCS, то при запуске Tarantool выводит в журнал предупреждение об устаревшей версии схемы данных. На работу TCS это не влияет. При желании версию схемы можно обновить, вызвав box.schema.upgrade() на мастер-экземпляре после обновления всех экземпляров набора реплик. После этого откат на TCS 1.3.2 будет возможен только после вызова box.schema.downgrade().

1. Остановить экземпляр Scheduler с наименьшей нагрузкой.
2. Обновить его, заменяя символические ссылки на новую версию.
3. Запустить обновленный экземпляр Scheduler.
4. Остановить оставшийся экземпляр Scheduler.
5. Обновить его, заменив символические ссылки на новую версию.
6. Запустить обновленный экземпляр Scheduler.

Порядок обновления: сначала обновляется неактивный узел (реплика), затем выполняется переключение роли мастер-узла, после чего обновляется второй узел.

1. Переключить роль мастер-узла на реплику.
2. Остановить узел, который стал репликой.
3. Обновить остановленный узел:
   • распаковать новый архив;
   • переключить символические ссылки, чтобы хранилище использовало новую версию.
4. Запустить обновленный узел.
5. Дождаться завершения синхронизации репликации: убедиться, что реплика полностью синхронизирована с мастер-узлом (объем/состояние данных на мастер-узле и реплике сравняется).
6. Переключить роль мастер-узла обратно. После этого роль мастер-узла вернется исходному узлу.
7. Остановить второй узел. С этого момента он становится репликой.
8. Обновить остановленный узел (реплику).
9. Распаковать новую версию и заменить символические ссылки на нее.
10. Запустить обновленный узел.

1. Остановить пассивные (резервные) экземпляры Coordinator и обновить их, заменив символические ссылки на новую версию.
2. Запустить обновленные пассивные экземпляры Coordinator.
3. Остановить активный экземпляр Coordinator и обновить его, заменив символические ссылки на новую версию.
4. Запустить активный экземпляр Coordinator.

Откат версии TCS без простоя осуществляется аналогично обновлению без простоя.

1. Запустите плейбук uninstall.yml, указав следующие параметры:

   • tags и значение tarantool
   • limit и список имен всех экземпляров кластера

   См. Пример вызова плейбука uninstall.yml для удаления кластера.

   Также см. подробнее раздел Удаление кластера Tarantool в документации по инсталлятору Ansible Tarantool Enterprise.

2. При удалении кластера, работавшего в режиме шардирования, выполните также команду etcdctl del --prefix "/tarantool/{prefix}/sharding", где {prefix} – это префикс для конфигурации TCS в etcd.