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

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

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

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

{
    "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 и нажмите Submit, чтобы начать балансировку данных.

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

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

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

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

Балансировка данных (решардинг) запускается регулярно, а также после добавления в кластер нового набора реплик с ненулевым весом (параметр Replica set weight ). Для получения дополнительной информации см. раздел о процессе балансировки в документации по модулю vshard.

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

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

vshard.storage.info().bucket

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

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

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

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

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

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

Инстанс больше не будет отображаться на вкладке Cluster.

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

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

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

1. В web-интерфейсе на вкладке Cluster, нажмите кнопку Edit у нужного набора реплик.
2. В диалоговом окне отсортируйте, используя drag-and-drop, инстансы в списке в нужном порядке приоритета и нажмите Save.

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

В диалоговом окне FAILOVER CONTROL, выберите нужный тип автоматического восстановления и нажмите кнопку Save. Для опции Stateful понадобится указать адрес и пароль для внешнего провайдера.

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

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

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

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

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

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

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

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

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

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

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

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

   

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