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

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

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

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

• Astra Linux 1.7;
• РЕД ОС.

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

• При подготовке серверов к использованию Tarantool необходимо дополнительно установить:
  • etcd версии не ниже 3.4.
  • OpenSSL версии выше 3.0.0.
• При настройке шардирования убедитесь, что используется инсталлятор ATE версии не ниже 1.13.0.

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. Установите необходимое стороннее ПО требуемых версий:

   a. Установите etcd.

   b. Установите OpenSSL.

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 доступен всем).

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

Кластер TCS может включать в себя следующие компоненты:

• Узлы Storage – для хранения данных и обработки запросов на чтение/запись
• Узлы Scheduler – для маршрутизации запросов на экземпляры Storage
• Узлы Coordinator – для управления переключением в случае сбоя экземпляров Storage
• etcd – для хранения и управления конфигурацией кластера
• Tarantool Cluster Manager (TCM) – для мониторинга и управления кластером

Состав кластера TCS зависит от режима работы кластера: проксированный или шардированный.

В проксированном режиме типовой кластер TCS состоит из следующих компонентов:

• Storage: один набор реплик из нескольких узлов (1 мастер-экземпляр + 1 или больше экземпляров-реплик), развернутый на 1 или более серверах – для хранения данных и обработки запросов на чтение/запись
• Scheduler: (необязательно без шардирования) один набор реплик из 1 и более узлов -- для маршрутизации запросов на экземпляры Storage
• Coordinator: (необязательно) по 1 экземпляру на каждый сервер с развернутыми экземплярами Storage -- для управления переключением в случае сбоя экземпляров Storage
• (необязательно) etcd – для хранения и управления конфигурацией кластера
• (необязательно) Tarantool Cluster Manager (TCM) – для мониторинга и управления кластером

В шардированном режиме кластер TCS состоит из аналогичных компонентов, но со следующими отличиями:

• в кластере может быть больше одного набора реплик с узлами типа Storage
• наличие набора реплик с узлами типа Scheduler становится обязательным

Наборов реплик с экземплярами Scheduler и Storage может быть несколько.

Любой набор реплик TCS можно разворачивать как на одном сервере, так и на нескольких серверах.

Клиентское приложение может устанавливать соединение с любым экземпляром в наборе реплик (Scheduler или Storage), по любому поддерживаемому TCS протоколу (HTTP, JDBC/ADBC). Однако тип экземпляров, доступных клиентам для прямого подключения, зависит от режима работы кластера TCS:

• в режиме проксирования – Scheduler (если они присутствуют в кластере) и Storage
• в режиме шардирования – только Scheduler

Все запросы принимаются в формате SQL.

Для обработки запросов на экземплярах Storage используется одинаковая логика. Конвейер обработки запроса включает в себя:

• парсер SQL-запросов
• кеш физических планов (для аналитических расчетов)
• планировщик с оптимизатором
• исполнитель плана запроса

В режиме шардирования тот же конвейер обработки действует также на экземплярах Scheduler.

В набор реплик Storage входят экземпляры двух видов:

• мастер-экземпляр (может быть только один)
• экземпляры-реплики (любое количество от 0 до 30)

Все экземпляры Storage в наборе реплик работают с одинаковым набором данных, поскольку все экземпляры-реплики связаны процессом непрерывной репликации с мастер-экземпляром. Других видов движения данных, кроме репликации, между экземплярами нет.

Запросы на чтение данных могут обрабатываться на всех экземплярах. Запросы на запись/изменение данных – только на мастер-экземпляре. Поэтому при установлении прямого соединения с экземпляром Storage из клиентского приложения следует явно выбирать экземпляр Storage, на котором будут выполняться запросы в рамках сессии. Если для обработки запроса на чтение/модификацию данных выбран экземпляр-реплика, то в ответ вернется ошибка.

Экземпляры Scheduler осуществляют автоматическую маршрутизацию запросов на экземпляры Storage.

Экземпляры Scheduler являются stateless-компонентами, т.е. хранение данных на экземплярах Scheduler не осуществляется.

В одном наборе реплик может быть любое количество узлов типа Scheduler (от 1 до 31).

Для отказоустойчивости в кластер TCS рекомендуется добавлять координаторы обработки сбоев (failover coordinator) из расчета 1 экземпляр Coordinator на каждый сервер с развернутыми экземплярами Storage. Один координатор должен быть активным, остальные – пассивными.

Координаторы следят за состоянием всего кластера Storage, получая информацию об узлах хранилищ по прямому запросу состояния к экземплярам Storage. В случае сбоя активный координатор осуществляет аварийное переключение, выбирая один из экземпляров-реплик Storage и переводя его в режим RW. Переключение может настроено в ручном или автоматическом режиме.

Между собой координаторы связаны через etcd, получая мета-информацию об активном координаторе.

etcd позволяет централизованно хранить конфигурацию кластера и управлять ей. На основе etcd построено управление кластером с помощью ATE и TCM.

Рекомендованный вариант установки TCS – с файлом конфигурации, хранящимся в etcd. См. подробнее Первичная установка системы.

Для тестовых целей возможна установка кластера TCS с локальным файлом конфигурации.

TCM предоставляет веб-интерфейс, который позволяет отслеживать состояние набора реплик TCS, а также управлять конфигурацией кластера (как альтернатива etcd). Взаимодействие TCM с конфигурацией кластера TCS идет только через etcd. См. подробнее Управление кластером с помощью TCM

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

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

• Установка с помощью Ansible-коллекции.

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

  • раздел Подготовка серверов в текущем Руководстве по установке
  • раздел Использование Ansible-коллекции в документации по инсталлятору Ansible Tarantool Enterprise

• Установка с помощью Docker-образа.

  В этом случае установка TCS должна включать следующие шаги:

  1. Подготовка серверов, в том числе установка и настройка кластера etcd.

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

     • раздел Подготовка серверов в текущем Руководстве по установке
     • раздел Сценарий первичной настройки в документации по инсталлятору Ansible Tarantool Enterprise

  2. Загрузка конфигурации в etcd.

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

     • Настройка кластера
     • Примеры статических инвентарей
     • Пример вызова плейбука etcd_3_0.yml для отправки конфигурации в etcd
     • раздел Tarantool 3.x: Отправка конфигурации в etcd в документации по инсталлятору Ansible Tarantool Enterprise.

  3. Установка TCS.

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

     • Пример вызова плейбука tcs/install.yml для развертывания кластера
     • раздел Tarantool Column Store: Установка приложения в документации по инсталлятору Ansible Tarantool Enterprise.

  4. Установка TCM.

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

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

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

• с 1.1.0 на 1.2.0
• с 1.1.0 на 1.2.1
• с 1.2.0 на 1.2.1

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

1. Сохранение всех резервных копий.

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

   a. Для Tarantool.

   Убедитесь, что файлы снимков (.snap) и журналов (.xlog) Tarantool, используемые на старой версии, сохранены.

   b. Для etcd.

   В случае использование etcd убедитесь, что его файл снимка сохранен.

   c. Для планов выполнения.

   В случае использования представлений (views) и персистентных подготовленных выражений (persisted prepared statements) убедитесь, что они сохранены, поскольку в настоящее время они сбрасываются при обновлении. Для выгрузки можно использовать следующие запросы:

    
   select * from tcs_prepareds()select * from tcs_views()

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

   a. Остановите текущий кластер TCS версии 1.1.0.

   b. Отключите TCS-роли (tcs_roles/*) в конфигурации кластера.

   Для этого их можно закомментировать, а в случае их явного удаления нужно убедиться в том, что предыдущая версия конфигурации сохранена. После этого обновите конфигурацию кластера в etcd.

   c. Запустите кластер TCS версии 1.2.1.

   Здесь используется именно версия 1.2.1, поскольку необходимая для обновления утилита tcsctl входит в пакет поставки TCS только начиная с версии 1.2.1.

   d. Произведите запуск скрипта миграций с помощью утилиты tcsctl (команда upgrade):

    
   $ tcsctl upgrade --etcd_host <ETCD_HOST> --etcd_port <ETCD_PORT>    --iproto_username <USER> --iproto_password <PASS>    --migrations_dir <MIGRATIONS_DIR>    --from_version 1.2.0 --to_version 1.2.1

   e. Остановите кластер TCS версии 1.2.1.

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

   g. Запустите кластер версии 1.2.0.

Производится аналогично обновлению TCS с версии 1.1.0 на 1.2.0.

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

1. Сохранение всех резервных копий.

   Производится аналогично сохранению резервных копий при обновлении TCS с версии 1.1.0 на 1.2.0 (см. шаг 1).

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

   a. Остановите текущий кластер TCS версии 1.2.0.

   b. Запустите кластер TCS версии 1.2.1.

   c. Произведите запуск скрипта миграций с помощью утилиты tcsctl (команда upgrade):

    
   $ tcsctl upgrade --etcd_host <ETCD_HOST> --etcd_port <ETCD_PORT>    --iproto_username <USER> --iproto_password <PASS>    --migrations_dir <MIGRATIONS_DIR>    --from_version 1.2.0 --to_version 1.2.1

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

1. Остановить все экземпляры Storage 1.2.0 и полностью очистить среду (в ATE плейбук uninstall.yml).

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

3. Развернуть все экземпляры Storage 1.1.0 (в ATE плейбук tcs/install.yml).

4. С помощью SQL-запросов загрузить схему данных и сами данные.

Производится аналогично откату TCS с версии 1.2.0 на 1.1.0.

Производится аналогично откату TCS с версии 1.2.0 на 1.1.0.

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

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

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

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

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

Установка TCS в тестовой среде может производиться как с использованием инсталлятора Ansible Tarantool Enterprise (аналогично установке в производственной среде, так и вручную. Ниже приведены инструкции по ручной установке.

В пакет поставки TCS включены следующие файлы конфигурации:

• Файл конфигурации config.yml описывает конфигурацию для кластера TCS (набор реплик из 2 экземпляров).
• Файл конфигурации instances.yml указывает, какие именно экземпляры должны быть запущены на текущем хосте.

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

• с локальным файлом конфигурации;
• с файлом конфигурации, хранящимся в etcd.

Также кластер TCS можно разворачивать как на одном сервере (по умолчанию), так и на нескольких серверах.

1. Распаковать архив с поставкой версии TCS 1.0 и перейти в распакованную директорию.
2. Убедиться, что в файле instances.yml указаны те экземпляры, которые нужно развернуть на текущем сервере.
3. Запустить команду ./tt start, чтобы развернуть кластер.
4. Запустить команду ./tt status для проверки того, что кластер поднят.

Пример результата успешной установки:

 
/tt start• Starting an instance [tarantool_column_store: instance1]...• Starting an instance [tarantool_column_store: instance2].../tt statusINSTANCE                           STATUS   PID     MODE  CONFIG  BOX      UPSTREAMtarantool_column_store: instance1  RUNNING  319481  RW    ready   running  --tarantool column store: instance2  RUNNING  319482  RO    ready   running  --

1. Распаковать архив с поставкой версии TCS 1.0 и перейти в распакованную директорию.

2. В файле config.yml прописать, откуда в etcd брать конфигурацию.

   Например:

    
   config:  etcd:    prefix: /tcs    endpoints:    - http://localhost:2379    http:      request:        timeout: 1

3. Убедиться, что в файле instances.yml указаны те экземпляры, которые нужно развернуть на текущем сервере.

4. Запустить команду ./tt start, чтобы развернуть кластер.

5. Запустить команду ./tt status для проверки того, что кластер поднят.

На каждом сервере нужно выполнить установку нужного типа (с локальным файлом конфигурации или хранящимся в etcd). При этом:

• Файлы конфигурации TCS на серверах должны совпадать и содержать настройки для всех экземпляров TCS на всех серверах.
• В файле instances.yml для каждого сервера нужно указать те экземпляры TCS, которые нужно развернуть на данном сервере.

Например:

• instances.yml на сервере А:

   
  instance1:instance2:

• instances.yml на сервере B:

   
  instance3:instance4:

1. Выполните команду ./tt stop -y для остановки кластера.
2. (Необязательно) Выполните команду ./tt clean для зачистки журналов и данных.

1. Остановить старый кластер, чтобы он не помешал поднять новую версию, если экземпляры старой и новой версии привязаны к одинаковым портам на одном сервере. Журналы и данные можно не очищать.
2. Установить новую версию системы, не забыв обновить файл конфигурации.