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

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

изменение топологии кластера (добавление экземпляров);
исключение экземпляра из кластера;
включение автоматического восстановления после отказа (Failover);
изменение мастера в наборе реплик;
отключение набора реплик.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

vshard.storage.info().bucket

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

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

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

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

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

В окне подтверждения нажмите OK.

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

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

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

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

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

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

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

Для опций 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 в зависимости от выбранного типа функции восстановления.

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

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

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

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

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

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

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

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

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

В web-интерфейсе на вкладке Cluster нажмите кнопку Edit у нужного набора реплик.
В диалоговом окне установите значение параметра Replica set weight равным «0» и нажмите Save.
Подождите, пока процесс балансировки не завершит перенос всех виртуальных сегментов. Текущее количество сегментов в данном наборе реплик можно отслеживать как это описано в разделе о балансировке данных.