Сценарии администрирования кластера

Добавлено в версии 1.18.0

Данная инструкция описывает процесс добавления и удаления роутеров и хранилищ (как отдельных экземпляров, так и целых наборов реплик) в существующий кластер Tarantool 3 с использованием Ansible-ролей.

Все операции добавления выполняются в три этапа с помощью следующих плейбуков:

1. install_3_0.yml — установка и запуск новых экземпляров
2. etcd_3_0.yml — загрузка обновленной конфигурации в ETCD
3. tbcs.yml — загрузка обновленной конфигурации в TbCS (Tarantool-based Config Storage)
4. check_3_0.yml — проверка статуса кластера

Роутеры (routers) отвечают за маршрутизацию запросов к хранилищам. Добавление роутера не требует ребалансировки данных.

На примере инвентаря inventory.yml добавляем новый роутер core_router-r03:

 
all:  children:    tarantool:      children:        core_router:          children:            # Существующие роутеры            core_router-r01:              hosts:                core_router-r01-i01:                  iproto:                    advertise:                      client: 127.0.0.1:3307                    listen:                    - uri: 127.0.0.1:3307                  replicaset_alias: core_router-r01                  roles_cfg:                    roles.httpd:                      default:                        listen: 8087            core_router-r02:              hosts:                core_router-r02-i01:                  iproto:                    advertise:                      client: 127.0.0.1:3308                    listen:                    - uri: 127.0.0.1:3308                  replicaset_alias: core_router-r02                  roles_cfg:                    roles.httpd:                      default:                        listen: 8088            # Новый экземпляр роутера            core_router-r03:              hosts:                core_router-r03-i01:                  iproto:                    advertise:                      client: 127.0.0.1:3309                    listen:                    - uri: 127.0.0.1:3309                  replicaset_alias: core_router-r03                  roles_cfg:                    roles.httpd:                      default:                        listen: 8089

 
vm_1:      hosts:        # ... существующие хосты        core_router-r03-i01: {}

 
# Установка и запуск нового экземпляраansible-playbook -i inventory.yml playbooks/install_3_0.yml# Загрузка конфигурации в ETCDansible-playbook -i inventory.yml playbooks/etcd_3_0.yml# Проверка статуса кластераansible-playbook -i inventory.yml playbooks/check_3_0.yml

 
journalctl -xe -u my-app@core_router-r03-i01

После успешного добавления роутера проверьте его состояние в веб-интерфейсе TCM (Tarantool Cluster Manager):

1. Откройте веб-интерфейс TCM (по умолчанию http://<tcm-host>:8080).
2. Авторизуйтесь с учетными данными администратора.
3. В списке кластеров выберите нужный кластер.
4. Убедитесь, что новый роутер отображается в топологии кластера со статусом Online.

При добавлении хранилища (storage) в существующий набор реплик данные автоматически синхронизируются с мастера. Ребалансировка данных не требуется, так как бакеты остаются в тех же наборах реплик.

На примере набора реплик core_storage-r01 добавляем новый экземпляр хранилища core_storage-r01-i04:

 
core_storage:          children:            core_storage-r01:              vars:                labels:                  server: '{{ tarantool_ansible_host }}'                tarantool_config_replicaset:                  memtx:                    memory: 512000000                  roles:                  - app.roles.queue                  sharding:                    roles:                    - storage                replicaset_alias: core_storage-r01              hosts:                # Существующие экземпляры                core_storage-r01-i01:                  iproto:                    advertise:                      client: 127.0.0.1:3301                    listen:                    - uri: 127.0.0.1:3301                  roles_cfg:                    roles.httpd:                      default:                        listen: 8081                core_storage-r01-i02:                  iproto:                    advertise:                      client: 127.0.0.1:3302                    listen:                    - uri: 127.0.0.1:3302                  replication:                    anon: true                  roles_cfg:                    roles.httpd:                      default:                        listen: 8082                core_storage-r01-i03:                  iproto:                    advertise:                      client: 127.0.0.1:3303                    listen:                    - uri: 127.0.0.1:3303                  roles_cfg:                    roles.httpd:                      default:                        listen: 8083                # Новый экземпляр хранилища                core_storage-r01-i04:                  iproto:                    advertise:                      client: 127.0.0.1:3313                    listen:                    - uri: 127.0.0.1:3313                  replication:                    anon: true  # Если реплика анонимная                  roles_cfg:                    roles.httpd:                      default:                        listen: 8093

 
vm_1:      hosts:        # ... существующие хосты        core_storage-r01-i04: {}

 
# Установка и запуск нового экземпляраansible-playbook -i inventory.yml playbooks/install_3_0.yml# Загрузка конфигурации в ETCDansible-playbook -i inventory.yml playbooks/etcd_3_0.yml# Проверка статуса кластераansible-playbook -i inventory.yml playbooks/check_3_0.yml

В журналах нового экземпляра должна быть информация о синхронизации данных:

 
journalctl -xe -u my-app@core_storage-r01-i04 | grep -i replica

1. Откройте веб-интерфейс TCM.
2. Авторизуйтесь с учетными данными администратора.
3. В списке кластеров выберите нужный кластер.
4. Найдите набор реплик core_storage-r01.
5. Проверьте информацию о состоянии репликации между мастером и новой репликой, убедитесь в отсутствии ошибок.

При добавлении нового набора реплик происходит автоматическая ребалансировка данных между всеми наборами реплик. Новый шард получит свою долю бакетов.

Параметр rebalancer_mode в конфигурации шардирования управляет режимом ребалансировки:

 
tarantool_config_global:  sharding:    bucket_count: 1000    rebalancer_mode: 'auto'  # Автоматическая ребалансировка

Возможные значения:

• auto — ребалансировка выполняется автоматически (по умолчанию)
• off — ребалансировка отключена
• manual — ручной режим ребалансировки

Добавляем новый набор реплик core_storage-r04 с тремя экземплярами:

 
core_storage:          children:            # ... существующие наборы реплик (core_storage-r01, r02, r03)            # Новый набор реплик            core_storage-r04:              vars:                labels:                  server: '{{ tarantool_ansible_host }}'                tarantool_config_replicaset:                  memtx:                    memory: 512000000                  roles:                  - app.roles.queue                  sharding:                    roles:                    - storage                replicaset_alias: core_storage-r04              hosts:                core_storage-r04-i01:                  iproto:                    advertise:                      client: 127.0.0.1:3320                    listen:                    - uri: 127.0.0.1:3320                  roles_cfg:                    roles.httpd:                      default:                        listen: 8100                core_storage-r04-i02:                  iproto:                    advertise:                      client: 127.0.0.1:3321                    listen:                    - uri: 127.0.0.1:3321                  replication:                    anon: true                  roles_cfg:                    roles.httpd:                      default:                        listen: 8101                core_storage-r04-i03:                  iproto:                    advertise:                      client: 127.0.0.1:3322                    listen:                    - uri: 127.0.0.1:3322                  roles_cfg:                    roles.httpd:                      default:                        listen: 8102

 
vm_1:      hosts:        # ... существующие хосты        core_storage-r04-i01: {}        core_storage-r04-i02: {}        core_storage-r04-i03: {}

 
# Установка и запуск новых экземпляровansible-playbook -i inventory.yml playbooks/install_3_0.yml# Загрузка конфигурации в ETCD (здесь происходит ребалансировка)ansible-playbook -i inventory.yml playbooks/etcd_3_0.yml# Проверка статуса кластераansible-playbook -i inventory.yml playbooks/check_3_0.yml

После добавления набора реплик можно отслеживать процесс ребалансировки в журналах:

 
# Журналы одного из экземпляров нового набора репликjournalctl -xe -u my-app@core_storage-r04-i01 | grep -i rebalance# Или проверка через консоль экземпляраtt connect core_storage-r04-i01:3320> vshard.router.info()

Подключитесь к любому экземпляру хранилища и проверьте статус шардирования:

 
-- Проверка количества бакетов в наборе репликvshard.storage.buckets_count()-- Проверка статуса ребалансировкиvshard.storage.rebalancer_state()

1. Откройте веб-интерфейс TCM.
2. Авторизуйтесь с учетными данными администратора.
3. В списке кластеров выберите нужный кластер.
4. Убедитесь, что новый набор реплик отображается в топологии кластера.
5. Проверьте распределение бакетов между всеми наборами реплик.

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

Пример для gRPC-сервера из инвентаря:

 
consumer:                      queues:                        queue:                          connections:                            storage-1:                            # Добавить новые хранилища, если добавлялся набор реплик                            - 127.0.0.1:3320                            - 127.0.0.1:3321                            - 127.0.0.1:3322                      tarantool:                        connections:                          storage-1:                          # Добавить новые хранилища                          - 127.0.0.1:3320                          - 127.0.0.1:3321                          - 127.0.0.1:3322                    producer:                      queues:                        queue:                          connections:                            routers:                            # Добавить новые роутеры                            - 127.0.0.1:3309                      tarantool:                        connections:                          routers:                          # Добавить новые роутеры                          - 127.0.0.1:3309

После всех операций выполните полную проверку:

 
# Проверка всех экземпляровansible-playbook -i inventory.yml playbooks/check_3_0.yml# Проверка через eval (пример — получение списка наборов реплик)ansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "eval_command='return box.info.replication'"

Для автоматизации удаления экземпляров и наборов реплик используйте плейбук remove_instances.yml. Плейбук выполняет следующие шаги автоматически:

1. Ребалансировка данных (установка sharding.weight: 0 и мониторинг переноса бакетов) — только для наборов реплик хранилищ при удалении целиком.
2. Исключение экземпляров или наборов реплик из конфигурации кластера в ETCD.
3. Остановка systemd-юнитов и очистка директорий данных, run-файлов и журналов.
4. Проверка статуса оставшихся экземпляров кластера.

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

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

• Удаление отдельных экземпляров — через параметр instances_to_remove или --limit. Ребалансировка не выполняется.
• Удаление целого набора реплик — через параметр replicaset_alias. Для наборов реплик хранилищ автоматически выполняется ребалансировка.

Добавлено в версии Tarantool 3.3.0

При удалении экземпляров из конфигурации кластера (инвентаря и ETCD) может возникнуть ошибка mismatch of the number of replicas in the config with box.space._cluster. Это происходит потому, что информация об удаленных экземплярах остается в системном спейсе _cluster, и кластер продолжает ожидать их подключения. Для автоматического удаления экземпляров из _cluster при их исключении из конфигурации используется опция replication.autoexpel.

Опция replication.autoexpel позволяет экземпляру в режиме read-write (мастеру) автоматически удалять из _cluster те экземпляры, чьи имена начинаются с заданного префикса и которые отсутствуют в текущей YAML-конфигурации кластера.

Опция настраивается на уровнях global, group или replicaset (не на уровне отдельного экземпляра).

Добавьте секцию autoexpel в конфигурацию репликации:

 
replication:  autoexpel:    enabled: true    by: prefix    prefix: '{% raw %}{{ replicaset_name }}{% endraw %}'

В примере выше {% raw %}{{ replicaset_name }}{% endraw %} — это переменная конфигурации Tarantool. Конструкция {% raw %}...{% endraw %} используется для экранирования Jinja2-синтаксиса Ansible, чтобы значение {{ replicaset_name }} попало в конфигурацию Tarantool как есть и было интерпретировано уже самим Tarantool, а не Ansible.

Параметры:

В примере выше используется переменная {{ replicaset_name }}, которая автоматически подставляет имя набора реплик. Это гарантирует, что экземпляры, относящиеся к данному набору реплик, будут корректно обработаны при удалении.

После добавления опции autoexpel в конфигурацию необходимо обновить конфигурацию в ETCD:

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

Или через консоль экземпляра:

 
require('config'):reload()

1. Удалите экземпляр из инвентаря (закомментируйте или удалите его секцию).
2. Обновите конфигурацию в ETCD с помощью плейбука etcd_3_0.yml.
3. Read-write экземпляр (мастер) автоматически обнаружит, что экземпляр с заданным префиксом отсутствует в новой конфигурации, и удалит его из _cluster.
4. Ошибка mismatch исчезает, кластер перестает ожидать подключения удаленного экземпляра.

Удаление роутера не требует ребалансировки данных, так как роутеры не хранят данные.

Запустите плейбук remove_instances.yml, указав имя экземпляра через --limit или переменную instances_to_remove:

 
ansible-playbook -i inventory.yml playbooks/remove_instances.yml \  --limit core_router-r03-i01# илиansible-playbook -i inventory.yml playbooks/remove_instances.yml \  -e '{instances_to_remove: ["core_router-r03-i01"]}'

Плейбук исключит экземпляр из конфигурации ETCD, остановит systemd-юнит и очистит директории данных.

Удалите или закомментируйте удаляемый роутер в инвентаре:

 
# Было:core_router:  children:    core_router-r01:    core_router-r02:    core_router-r03:  # Удалить эту секцию# Стало:core_router:  children:    core_router-r01:    core_router-r02:

Также удалите хост из всех групп:

 
vm_1:  hosts:    # ... другие хосты    # core_router-r03-i01: {}  # Удалить

1. Откройте веб-интерфейс TCM.
2. Авторизуйтесь с учетными данными администратора.
3. В списке кластеров выберите нужный кластер.
4. Убедитесь, что удаленный роутер больше не отображается в топологии кластера.
5. Проверьте, что статус кластера Healthy или все узлы в статусе Online.

При удалении хранилища из набора реплик данные остаются на оставшихся экземплярах набора реплик. Ребалансировка данных не требуется.

Запустите плейбук remove_instances.yml, указав имя экземпляра через --limit или переменную instances_to_remove:

 
ansible-playbook -i inventory.yml playbooks/remove_instances.yml \  --limit core_storage-r01-i04# илиansible-playbook -i inventory.yml playbooks/remove_instances.yml \  -e '{instances_to_remove: ["core_storage-r01-i04"]}'

Плейбук исключит экземпляр из конфигурации ETCD, остановит systemd-юнит и очистит директории данных.

--limit также принимает имя группы набора реплик (например, --limit core_storage-r01) — в этом случае будут удалены все экземпляры группы из их набора реплик, но сами наборы реплик в config.groups сохранятся. Для полного удаления набора реплик вместе с его структурой в конфигурации используйте параметр replicaset_alias (см. раздел «Удаление набора реплик хранилищ»).

Удалите или закомментируйте удаляемый экземпляр хранилища в инвентаре:

 
core_storage-r01:  hosts:    core_storage-r01-i01: {}    core_storage-r01-i02: {}    core_storage-r01-i03: {}    # core_storage-r01-i04: {}  # Удалить

Также удалите хост из всех групп:

 
vm_1:  hosts:    # ... другие хосты    # core_storage-r01-i04: {}  # Удалить

1. Откройте веб-интерфейс TCM.
2. Авторизуйтесь с учетными данными администратора.
3. В списке кластеров выберите нужный кластер.
4. Проверьте информацию о состоянии репликации, убедитесь в отсутствии ошибок.

При удалении набора реплик и установке параметра sharding.rebelancer_mode: auto происходит автоматическая ребалансировка данных между оставшимися наборами реплик.

Параметр rebalancer_mode в конфигурации шардирования управляет режимом ребалансировки:

 
tarantool_config_global:  sharding:    bucket_count: 1000    rebalancer_mode: 'auto'  # Автоматическая ребалансировка

Возможные значения:

• auto — ребалансировка выполняется автоматически (по умолчанию)
• off — ребалансировка отключена
• manual — ручной режим ребалансировки

При удалении набора реплик хранилищ необходимо сначала перенести все бакеты на другие наборы реплик. Плейбук remove_instances.yml выполняет перенос автоматически.

Запустите плейбук remove_instances.yml с параметром replicaset_alias:

 
ansible-playbook -i inventory.yml playbooks/remove_instances.yml \  -e replicaset_alias=core_storage-r04

Плейбук автоматически выполнит:

1. Установку sharding.weight: 0 для core_storage-r04 и rebalancer_mode: auto в конфигурации ETCD.
2. Ожидание завершения ребалансировки (опрос vshard до total: 0, rebalancing: false).
3. Исключение набора реплик из конфигурации кластера в ETCD.
4. Остановку systemd-юнитов и очистку директорий данных всех экземпляров набора реплик.
5. Проверку статуса оставшихся экземпляров кластера.

После успешного выполнения плейбука удалите набор реплик из инвентаря:

 
# Было:core_storage:  children:    core_storage-r01:    core_storage-r02:    core_storage-r03:    core_storage-r04:  # Удалить эту секцию полностью# Стало:core_storage:  children:    core_storage-r01:    core_storage-r02:    core_storage-r03:

Также удалите хосты из всех групп`:

 
vm_1:  hosts:    # ... другие хосты    # core_storage-r04-i01: {}  # Удалить    # core_storage-r04-i02: {}  # Удалить    # core_storage-r04-i03: {}  # Удалить

1. Откройте веб-интерфейс TCM.
2. Авторизуйтесь с учетными данными администратора.
3. В списке кластеров выберите нужный кластер.
4. Убедитесь, что удаленный набор реплик больше не отображается в топологии кластера.
5. Убедитесь в корректном распределении бакетов между оставшимися наборами реплик.

После всех операций выполните полную проверку:

 
# Проверка всех экземпляровansible-playbook -i inventory.yml playbooks/check_3_0.yml# Проверка статуса vshardansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "eval_command='return vshard.router.info()'"# Проверка распределения бакетовansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "eval_command='return vshard.storage.buckets_count()'"