Установка¶

Обновление версии системы c 1.1.0 до 1.2.0¶

Чтобы обновить 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.

Обновление версии системы c 1.1.0 до 1.2.1¶

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

Обновление версии системы c 1.2.0 до 1.2.1¶

Чтобы обновить 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
   

Откат версии системы c 1.2.0 до 1.1.0¶

Чтобы откатить 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-запросов загрузить схему данных и сами данные.

Откат версии системы c 1.2.1 до 1.1.0¶

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

Откат версии системы c 1.2.1 до 1.2.0¶

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

Добавление экземпляров Scheduler¶

Добавление новых экземпляров Scheduler может понадобиться, когда системе не хватает пропускной способности для маршрутизации или мощности для SQL-вычислений.

Для добавления нового экземпляра Scheduler с помощью инсталлятора Ansible Tarantool Enterprise:

1. Добавьте экземпляры Scheduler в инвентарь TCS.

2. Запустите плейбук tcs/install.yml, указав в переменной tarantool_shared_hosts список имен экземпляров, которые нужно установить и запустить. При необходимости задайте параметр limit.

   См. Пример вызова плейбука tcs/install.yml для добавления экземпляра.

3. (Обязательно!) Перезагрузите конфигурацию кластера в etcd, чтобы восстановить конфигурацию запущенных ранее экземпляров Scheduler и Storage.

Добавление экземпляров Storage¶

Производится аналогично добавлению экземпляров Scheduler.

Добавление экземпляров Coordinator¶

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

Настройка шардирования¶

См. Настройка кластера в режиме шардирования.

Управление кластером с помощью ATE¶

Инсталлятор Ansible Tarantool Enterprise предоставляет следующие сценарии по управлению кластером (см. соответствующие разделы в документации по инсталлятору Ansible Tarantool Enterprise):

• Tarantool 3.0: Отправка конфигурации в etcd

• Запуск экземпляр(ов)

• Остановка экземпляра(ов)

• Перезагрузка экземпляра(ов)

• Автоматическое резервирование

• Автоматическое восстановление

Управление кластером с помощью TCM¶

Tarantool Cluster Manager – это административная панель для настройки и отслеживания кластеров, а также управления ими. Основные задачи, доступные через веб-интерфейс TCM:

• Создание/остановка кластера и изменение его конфигурации:

  • Переключение лидера в наборах реплик;

  • Изменение некоторых других настроек кластера, с простоем и в runtime;

  • Исключение экземпляра из кластера.

• Управление пользователями и ролями в кластере:

  • Управление пользователями Tarantool;

  • Изменение паролей пользователей Tarantool Enterprise.

• Контролируемое аварийное переключение узлов кластера;

• Восстановление и пересоздание экземпляров;

• Проверка работоспособности кластера;

• Просмотр журналов аудита.

См. документацию по Tarantool Cluster Manager.

Полная инструкция¶

1. Зайдите на сервер TCS с экземплярами Storage по SSH.

2. Переключитесь на пользователя tarantool:

   sudo su tarantool
   

3. Установите переменную окружения для работы с SystemD в userspace:

   export XDG_RUNTIME_DIR=/run/user/$(id -u)
   

   Объяснение: Это нужно для выполнения команд утилит SystemD (systemctl, journalctl) в userspace.

   Рекомендация: Чтобы не выполнять экспорт каждый раз, можно добавить команду export XDG_RUNTIME_DIR=/run/user/$(id -u) в файл $HOME/.profile.

4. Посмотрите список сервисов пользователя tarantool:

   systemctl --user list-units --type=service
   

   Пример вывода:

   tarantool@tcs-testing-1:~$ systemctl --user list-units --type=service
     UNIT                               LOAD   ACTIVE SUB     DESCRIPTION
     tarantool-cluster-manager.service  loaded active running Tarantool Cluster Manager
     tcs-scheduler@scheduler-01.service loaded active running Tarantool Column Store scheduler API service
   ● tcs@i-01.service                   loaded failed failed  Tarantool application tcs@i-01 #сервис инстанса стораджа
   

   В примере выше:

   • tcs@i-01.service – полное название сервиса для экземпляра с именем i-01;

   • tcs – название приложения Tarantool.

   В директории $HOME/.config/systemd/user находятся:

   • Шаблонный сервис для всех экзепляров tcs@.service;

   • Символическая ссылка на шаблонный сервис tcs@i-01.service.

5. Откройте шаблонный сервис для экземпляров Storage:

   vim $HOME/.config/systemd/user/tcs@.service
   

6. В шаблонном сервисе посмотрите путь до исполняемого файла tarantool:

   [Service]
   Type=simple
   ExecStart="/app/tarantool/tcs/bin/tcs.%i/tarantool --name %i" # запоминаем этот путь
   Restart=on-failure RestartSec=2
   

   Объяснение:

   При автоматическом развертывании TCS исполняемые файлы размещаются в разных местах в зависимости от:

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

   • названия приложения (app_name);

   • других параметров конфигурации.

   Вместо того чтобы пытаться угадать правильный путь к исполняемому файлу Tarantool при настройке службы (в параметре ExecStart), лучше сразу посмотреть точное расположение файла в конфигурационном файле службы vim ~/.config/systemd/user/tcs@.service.

7. Выполните команду systemctl --user edit название_сервиса_storage для того, чтобы начать редактирование (во временном буфере) файла с перезаписью опций в шаблонном сервисе:

   systemctl --user edit tcs@i-01
   

8. Добавьте перезапись опции ExecStart из секции [Service]. В новом ExecStart указан запуск процесса через утилиту numactl с нужными опциями:

   [Service]
   ExecStart=
   ExecStart=numactl --cpunodebind=0 --membind=0 /app/tarantool/tcs/bin/tcs.%i/tarantool --name %i
   

   ВАЖНО: обязательно нужно указать сначала пустой ExecStart, чтобы в дальнейшем не возникло ошибки при применении новой конфигурации.

9. Сохраните файл.

   Объяснение: Это действие создаст директорию $HOME/.config/systemd/user/название_сервиса.d и файл override.conf в этой директории.

   Рекомендация: Чтобы в качестве редактора использовался vim (если он уже не используется по умолчанию), можно установить переменную окружения SYSTEMD_EDITOR=vim.

10. Выполните команду для перезагрузки конфигурации systemD:

systemctl --user daemon-reload

11. Перезапустите экземпляр:

systemctl --user restart tcs@i-01

Примечание: Перезапустить экземпляр можно также через ATE.

12. После перезапуска можно проверить привязку к NUMA-зоне, найдя ее в файле /proc/${PID}/numa_maps.

Краткая инструкция¶

# Зайти под пользователем tarantool:
sudo su tarantool
# Установить переменную для работы с SystemD в userspace:
export XDG_RUNTIME_DIR=/run/user/$(id -u)
# Посмотреть, какие есть сервисы:
systemctl --user list-units --type=service
# Запустить редактирование интересующего сервиса:
systemctl --user edit название_интересующего_сервиса
# Добавить в файл:
[Service]
ExecStart=
ExecStart=numactl --cpunodebind=0 --membind=0 /app/tarantool/tcs/bin/tcs.%i/tarantool --name %i
# Перезагрузить конфигурацию systemD:
systemctl --user daemon-reload
# Перезапустить экземпляр
systemctl --user restart название_сервиса

Установка кластера с локальным файлом конфигурации¶

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 status
INSTANCE                           STATUS   PID     MODE  CONFIG  BOX      UPSTREAM
tarantool_column_store: instance1  RUNNING  319481  RW    ready   running  --
tarantool column store: instance2  RUNNING  319482  RO    ready   running  --

Установка кластера с файлом конфигурации в etcd¶

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

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

   Например:

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

3. Загрузить файл конфигурации в etcd.

   Например:

   mv config.yml remote.yml
   ./tt cluster publish http://localhost:2379/tcs remote.yml
   

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

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

6. Запустить команду ./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. Установить новую версию системы, не забыв обновить файл конфигурации.