2.4. Администрирование кластера | Tdg
Tarantool
Check out the new release policy
2. Руководство по эксплуатации 2.4. Администрирование кластера

2.4. Администрирование кластера

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

2.4.1. Изменение топологии кластера (добавление экземпляров)

Рассмотрим добавление нового экземпляра (инстанса, instance) в кластер на примере топологии, которую мы использовали при описании установки системы.

Допустим, нам нужно добавить еще один экземпляр с кластерной ролью storage. Как и в случае первоначальной устновки, сначала необходимо подготовить файл конфигурации разворачиваемого экземпляра в формате JSON. Значения параметров конфигурации см. в описании примера.

Важно

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

{
    "general":
    {
        "cluster_cookie": "ilikerandompasswords"
    },
    "servers":
    [
        {
            "address": "172.19.0.3",
            "username": "vagrant",
            "instances":
            [
                {
                    "name": "storage_3",
                    "binary_port": 3003,
                    "http_port": 8083,
                    "memory_mb": 1024
                }
            ]
        }
    ]
}

Далее разверните экземпляр с помощью скрипта tdgctl.py аналогично тому, как это выполнялось при установке системы.

./tdgctl.py -c deploy_add.json deploy -f tdg-<version>.tar.gz

где

  • deploy_add.json — файл с конфигурацией нового экземпляра;
  • tdg-<version>.tar.gz — файл дистрибутива (<version> — версия релиза TDG). Используйте тот же дистрибутив, с помощью которого выполнялась установка системы.

После успешного выполнения команды новый экземпляр должен появиться в web-интерфейсе на вкладке Cluster в таблице Unconfigured servers.

../../_images/clusterconf07.png

Если новый экземпляр не появился в web-интерфейсе, используйте функцию Probe server для проверки его доступности (см. подробнее).

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

В нашем примере мы включим развернутый экземпляр в новый набор реплик, присвоив ему кластерную роль storage. Экземпляр успешно добавлен в кластер:

../../_images/clusterconf08.png

Необходимо отметить, что новый набор реплик с ролью storage имеет вес (параметр Replica set weight), равный «0». Это определяется при инициализации модуля vshard, которая происходит во время первоначального развертывания кластера.

В данном случае — после добавления экземпляра в новый набор реплик — нужно увеличить значение параметра Replica set weight для того, чтобы система произвела балансировку данных, перенеся их часть на новый набор реплик с ролью storage.

Для этого нажмите кнопку Edit у нужного набора реплик. В диалоговом окне Edit Replica Set, увеличьте значение параметра Replica set weight и нажмите Save, чтобы начать балансировку данных.

../../_images/weight_1.png

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

При добавлении нового экземпляра в набор реплик (новый или уже существующий) происходит следующее:

  1. Кластер валидирует обновление конфигурации, проверяя доступность нового экземпляра с помощью модуля Tarantool membership. Все узлы в кластере должны быть рабочими, чтобы валидация была пройдена.
  2. Новый экземпляр ожидает, пока другой экземпляр в кластере не получит обновление конфигурации и не обнаружит его. На этом шаге у нового экземпляра еще нет своего UUID.
  3. Как только экземпляр понимает, что кластер знает о нем, экземпляр вызывает функцию box.cfg() и начинает работу.

2.4.2. Балансировка данных

Балансировка данных (решардинг) запускается регулярно, а также после добавления в кластер нового набора реплик с ненулевым весом (параметр Replica set weight).

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

Чтобы отслеживать текущее количество сегментов, подключитесь к нужному экземпляру с ролью storage через консоль и выполните команду

vshard.storage.info().bucket

В web-интерфейсе администратора это можно сделать на вкладке Console. Эта вкладка доступна только в режиме разработки (начиная с версии 1.6.3).

../../_images/vshard_buckets.png

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

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

Для исключения экземпляра из кластера:

  1. В web-интерфейсе на вкладке Cluster для нужного экземпляра нажмите […] > Expel server.
../../_images/instance_expel.png
  1. В окне подтверждения нажмите OK.

Экземпляр больше не будет отображаться на вкладке Cluster.

2.4.4. Включение автоматического восстановления после отказа (Failover)

Если в кластере задана конфигурация «мастер-реплика» и включено автоматическое восстановление после отказа (failover), то при отказе мастера в каком-либо наборе реплик кластер автоматически выбирает следующую реплику из списка приоритетов и назначает ей роль активного мастера (read/write). Когда вышедший из строя мастер возвращается к работе, его роль восстанавливается, а назначенный ранее активный мастер снова становится репликой (read-only).

Чтобы установить приоритет экземпляров в наборе реплик:

  1. В web-интерфейсе на вкладке Cluster нажмите кнопку Edit у нужного набора реплик.
  2. В диалоговом окне с помощью перетаскивания мышью (drag-and-drop) отсортируйте экземпляры в списке в нужном порядке приоритета и нажмите Save.
../../_images/instance_priority.png

По умолчанию восстановление после отказа отключено, на что указывает статус на кнопке Failover: disabled. Нажмите эту кнопку для включения данной функции.

В диалоговом окне Failover control выберите нужный тип автоматического восстановления.

../../_images/failover_control.png

Для опций Eventual и Stateful указано значение по умолчанию 20 секунд для параметра Failover timeout — время, через которое запустится восстановление после отказа, если мастер вышел из строя.

Для опции Stateful также понадобится указать следующие параметры:

  • State provider — выбор внешнего поставщика состояния:

    • Tarantool (stateboard) — изолированный экземпляр Tarantool. Для него требуется указать следующие параметры:

      • URI — адрес для внешнего провайдера;
      • Password — пароль для внешнего провайдера.
    • Etcd — требует указания следующих параметров:

      • Endpoints — адреса ресурсов;
      • Lock delay — время действия блокировки роли failover-coordinator, значение по умолчанию: 10 секунд;
      • Prefix — префикс;
      • URI — адрес для внешнего провайдера;
      • Password — пароль для внешнего провайдера.
  • Fencing (опционально) — фенсинг (изоляция узла), включается, если отметить чекбокс «Enabled». Если включить фенсинг, то когда поставщик состояния и одна из реплик одновременно станут недоступны, лидер перейдет в режим «только для чтения». Для этого нужно указать следующие параметры:

    • Fencing timeout — время для запуска фенсинга, если проверка (health check) выявила, что экземпляр функционирует неправильно. Значение по умолчанию: 10 секунд;
    • Fencing pause — временной интервал в секундах для проверки состояния экземпляров (health check). Значение по умолчанию: 2 секунды.

После настройки нужных параметров нажмите кнопку Save. Статус функции восстановления изменится на Failover: eventual или Failover: stateful в зависимости от выбранного типа функции восстановления.

../../_images/failover_enabled.png

2.4.5. Изменение мастера в наборе реплик

Текущий мастер в наборе реплик отображается символом короны. На вкладке Cluster цвет короны символизирует статус данной реплики — зеленый для исправно работающей реплики и красный для неработающей реплики.

../../_images/crown1.png

В диалоге Edit replica set цвет короны всегда остается красным.

../../_images/crown2.png

В режимах Failover: eventual и Failover: disabled, чтобы вручную изменить мастера в наборе реплик, необходимо выполнить следующие действия:

  1. В web-интерфейсе на вкладке Cluster нажмите кнопку Edit у нужного набора реплик.
  2. В диалоговом окне в разделе Failover priority при помощи перетаскивания мышью (drag-and-drop) переместите на первую строку ту реплику, которую хотите сделать мастером, и нажмите Save.
../../_images/master_change.png

В режиме Failover: stateful выбор мастера осуществляется во внешней системе.

2.4.6. Отключение набора реплик

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

Чтобы отключить набор реплик:

  1. В web-интерфейсе на вкладке Cluster нажмите кнопку Edit у нужного набора реплик.

  2. В диалоговом окне установите значение параметра Replica set weight равным «0» и нажмите Save.

    ../../_images/weight_0.png
  3. Подождите, пока процесс балансировки не завершит перенос всех виртуальных сегментов. Текущее количество сегментов в данном наборе реплик можно отслеживать как это описано в разделе о балансировке данных.