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

Добавлено в версии 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'"

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

Добавлено в версии 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 исчезает, кластер перестает ожидать подключения удаленного экземпляра.

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

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

 
# Было: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: {}  # Удалить

Запустите плейбук для загрузки обновленной конфигурации в ETCD:

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

После обновления конфигурации в ETCD роутер перестанет быть частью кластера.

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

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

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

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

 
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: {}  # Удалить

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

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

{note:tip} Если после удаления экземпляра возникает ошибка mismatch of the number of replicas in the config with box.space._cluster, настройте автоматическую очистку _cluster с помощью опции autoexpel. {/note}

 
# Проверка статуса кластераansible-playbook -i inventory.yml playbooks/check_3_0.yml

 
# Проверка статуса репликацииansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "eval_command='return box.info.replication()'"# Проверка кворумаansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "eval_command='return box.info.synchro.quorum()'"

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

 
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: {}  # Удалить

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

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

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

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

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

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

Добавьте weight: 0 для удаляемого набора реплик в инвентарь:

 
core_storage-r04:  vars:    labels:      server: '{{ tarantool_ansible_host }}'    tarantool_config_replicaset:      memtx:        memory: 512000000      roles:      - app.roles.queue      sharding:        roles:        - storage        weight: 0  # Добавить для ребалансировки    replicaset_alias: core_storage-r04  hosts:    core_storage-r04-i01:    core_storage-r04-i02:    core_storage-r04-i03:

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

После обновления конфигурации в ETCD начнется ребалансировка данных — все бакеты будут перенесены с core_storage-r04 на другие наборы реплик.

 
# Проверка статуса ребалансировки (рекомендуемый способ)ansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "tarantool_shared_hosts=core_storage-r04-i01" \  -e "eval_command='local i=vshard.storage.info(); return {total=i.bucket.total,active=i.bucket.active,sending=i.bucket.sending,receiving=i.bucket.receiving,rebalancing=vshard.storage.rebalancing_is_in_progress()}'"

Критерии завершения ребалансировки (все должны выполняться):

• total: 0 — все бакеты перенесены с репликасета
• active: 0 — нет активных бакетов
• sending: 0 — нет бакетов в процессе отправки
• receiving: 0 — нет бакетов в процессе получения
• rebalancing: false — ребалансер не выполняет перенос

Альтернативные способы проверки:

 
# Проверка через vshard.storage.info().bucket (только статус бакетов)ansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "tarantool_shared_hosts=core_storage-r04-i01" \  -e "eval_command='return vshard.storage.info().bucket'"# Проверка флага активности ребалансировкиansible-playbook -i inventory.yml playbooks/eval_3_0.yml \  -e "tarantool_shared_hosts=core_storage-r04-i01" \  -e "eval_command='return vshard.storage.rebalancing_is_in_progress()'"

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

• Все бакеты перенесены (total: 0)
• Нет активных переносов (sending: 0, receiving: 0)
• Ребалансер неактивен (rebalancing: false)

Только после этого можно переходить к удалению набора реплик из инвентаря.

После завершения ребалансировки (когда total: 0, sending: 0, receiving: 0 и rebalancing: false) удалите набор реплик из инвентаря:

 
# Было: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: {}  # Удалить

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

После обновления конфигурации в ETCD набор реплик перестанет быть частью кластера.

 
# Проверка статуса кластераansible-playbook -i inventory.yml playbooks/check_3_0.yml

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

Для полного удаления данных набора реплик используйте плейбук cleanup_replicaset.yml:

 
ansible-playbook -i inventory.yml playbooks/cleanup_replicaset.yml \  -e "tarantool_shared_hosts=core_storage-r04-i01,core_storage-r04-i02,core_storage-r04-i03" \  -e "tarantool_cleanup_instances=['core_storage-r04-i01','core_storage-r04-i02','core_storage-r04-i03']" \  -e "cartridge_app_name=my-app"

Параметры:

• tarantool_shared_hosts — хосты, на которых находятся экземпляры для очистки (через запятую)
• tarantool_cleanup_instances — список имен экземпляров для очистки
• cartridge_app_name — имя приложения (используется в именах systemd-юнитов)

Что делает плейбук:

1. Останавливает systemd-юниты для указанных экземпляров.
2. Удаляет директории данных (cartridge_data_dir/instance_name).
3. Удаляет run-директории (cartridge_run_dir/instance_name).
4. Удаляет лог-файлы (cartridge_log_dir_parent/instance_name*).

Ручная очистка (альтернативный способ):

Если необходимо выполнить очистку вручную:

 
# Остановка экземпляровsystemctl stop my-app@core_storage-r04-i01systemctl stop my-app@core_storage-r04-i02systemctl stop my-app@core_storage-r04-i03# Удаление директорий данныхrm -rf /var/lib/tarantool/my-app/core_storage-r04-i01rm -rf /var/lib/tarantool/my-app/core_storage-r04-i02rm -rf /var/lib/tarantool/my-app/core_storage-r04-i03

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

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

 
# Проверка всех экземпляров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()'"