Режим обслуживания

Елена Дворядкина

Обзор

Для хостов ADQM в пользовательском интерфейсе ADCM поддерживается режим обслуживания (maintenance mode). Временно недоступные или работающие некорректно хосты можно перевести в режим обслуживания, чтобы исключить их участие в действиях на уровне кластера или сервисов и выполнять действия без возможных ошибок, которые могут быть связаны с этими хостами. Состояние хостов в режиме обслуживания не учитывается при агрегировании информации по состоянию кластера/сервиса.

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

 
Особенности и ограничения использования режима обслуживания для ADQM:

  • На хост в режиме обслуживания запрещается добавлять какие-либо компоненты сервисов ADQM, но можно на логическом уровне удалить компоненты с хоста в режиме обслуживания, если он недоступен.

  • Если хотя бы один хост кластера переведен в режим обслуживания, кластерные/сервисные действия Install и Upgrade недоступны.

  • Для сервисов Zookeeper и Clickhousekeeper выполнение действия Reconfig and restart может завершаться ошибкой, если лидер кластера ZooKeeper/ClickHouse Keeper находится на хосте в режиме обслуживания.

  • Выполнение действий сервиса ADQMDB (кроме Install и Upgrade) при наличии хостов в режиме обслуживания поддерживается в том числе если используется интегрированный ClickHouse Keeper.

ПРИМЕЧАНИЕ
Режим обслуживания в ADQM на данный момент поддерживается только для хостов.

Примеры

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

  • шард 1 с двумя репликами — dev-adqm-1.ru-central1.internal и dev-adqm-2.ru-central1.internal;

  • шард 2 с двумя репликами — dev-adqm-3.ru-central1.internal и dev-adqm-4.ru-central1.internal.

В кластере установлены сервисы ADQMDB и Zookeeper, компоненты которых распределены по хостам кластера как показано на следующем рисунке.

Распределение по хостам компонентов тестового кластера
Распределение по хостам компонентов тестового кластера

В кластер добавлена одна реплицируемая таблица для тестирования:

CREATE TABLE test_repl_table on cluster 'default_cluster' (id UInt64)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/test_repl_table', '{replica}')
ORDER BY id;

В таблицу шарда 2 добавлена строка данных:

INSERT INTO test_repl_table VALUES ('1');

Перевод хоста в режим обслуживания

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

  1. Выключите хост, на котором установлены компоненты сервиса ADQMDB — например, хост dev-adqm-4.ru-central1.internal.

    Проверка соединения с хостом по SSH

     
    В Ansible [stdout] действия Check connection выводится сообщение о недоступности хоста.

    Результат действия Check connection
    Результат действия Check connection
    Проверка состояния кластера

     
    Выполнение кластерного действия Check завершается ошибкой, так как при проверке сервиса ADQMDB обнаружено, что один из хостов недоступен.

    Результат кластерного действия Check
    Результат кластерного действия Check
    Сообщение о недоступности хоста ADQMDB
    Сообщение о недоступности хоста ADQMDB

  2. Переведите хост dev-adqm-4.ru-central1.internal в режим обслуживания. Для этого в строке хоста на вкладке Hosts страницы кластера нажмите на иконку maintenance default.

    Включение режима обслуживания для хоста
    Включение режима обслуживания для хоста
    Хост в режиме обслуживания

     
    Для хоста в режиме обслуживания становятся недоступны действия в интерфейсе ADCM.

    Хост в режиме обслуживания
    Хост в режиме обслуживания

    Теперь полная недоступность хоста по сети не приводит к ошибке выполнения кластерных действий (например, Check) и действий сервиса ADQMDB (Check, Start, Stop, Restart, Reconfig and restart, Manage auto core dump).

    Успешное выполнение действия Check для кластера
    Успешное выполнение действия Check для кластера

    При этом в начале Ansible [stdout] шага действия, соответствующего проверке сервиса ADQMDB, выводится сообщение о том, что хост не участвует в обработке, так как находится в режиме обслуживания.

    Сообщение о хосте ADQMDB в режиме обслуживания
    Сообщение о хосте ADQMDB в режиме обслуживания

После выполнения действия Reconfig and restart для сервиса ADQMDB введенный в режим обслуживания хост будет удален из описания топологии кластера в секции remote_servers конфигурационного файла /etc/clickhouse-server/config.xml на всех хостах ADQMDB, кроме хоста в режиме обслуживания. При этом кластер без этого хоста остается в работоспособном состоянии — на других хостах данные доступны, с ними можно продолжать работать.

Чтобы вернуть хост в обработку действиями в ADCM, необходимо вывести его из режима обслуживания, затем выполнить действие Reconfig and restart для сервиса ADQMDB.

Удаление хоста из кластера

Если один из хостов ADQM вышел из строя, он может быть удален из кластера (например, такой сценарий допускается, если в кластере останутся реплики данных и наличие этого хоста не критично, или взамен удаленного хоста будет добавлен новый хост).

В следующем примере из кластера удаляется хост dev-adqm-4.ru-central1.internal, на котором установлены компоненты сервиса ADQMDB.

  1. Переведите хост dev-adqm-4.ru-central1.internal в режим обслуживания как описано выше.

  2. Удалите реплику, соответствующую хосту dev-adqm-4.ru-central1.internal, из топологии логического кластера, используя настройку Cluster Configuration сервиса ADQMDB. Нажмите Save и выполните действие Reconfig and restart для сервиса ADQMDB, чтобы применить новую топологию кластера.

  3. Запустите действие Add/Remove components для сервиса ADQMDB и удалите компоненты Clickhouse Server и Clickhouse JDBC Bridge с хоста dev-adqm-4.ru-central1.internal.

  4. После освобождения хоста от компонентов его можно удалить из кластера — на странице Hosts нажмите на иконку unlink default.

    Удаление хоста из кластера
    Удаление хоста из кластера

    Подтвердите действие, нажав Unlink в появившемся окне.

ВНИМАНИЕ
При удалении хоста ZooKeeper или ClickHouse Keeper необходимо подготовить хост-замену и поменять вышедший из строя хост на хост-замену в одно действие Add/Remove components для сервиса Zookeeper или Clickhousekeeper (так как число хостов ZooKeeper/ClickHouse Keeper не должно быть четным).

Замена хоста ADQMDB

Следующий пример показывает, как вместо удаленного хоста ADQMDB добавить в кластер новый хост (с тем же именем — dev-adqm-4.ru-central1.internal) и восстановить репликацию данных между новым хостом и dev-adqm-3.ru-central1.internal.

  1. Создайте в ADCM новый хост dev-adqm-4.ru-central1.internal и добавьте его в кластер ADQM.

  2. Добавьте этот хост в топологию кластера через параметр Cluster Configuration сервиса ADQMDB, указав его как реплику хоста dev-adqm-3.ru-central1.internal в шарде 2.

  3. Вызовите действие Add/Remove components для сервиса ADQMDB. Добавьте компоненты Clickhouse Server и Clickhouse JDBC Bridge на новый хост.

  4. На новом хосте создайте таблицу:

    CREATE TABLE test_repl_table on cluster 'default_cluster' (id UInt64)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/test_repl_table', '{replica}')
ORDER BY id;

    При возникновении ошибки REPLICA_ALREADY_EXISTS перед созданием таблицы на новом хосте выполните следующую команду на хосте dev-adqm-3.ru-central1.internal, который является репликой dev-adqm-4.ru-central1.internal:

    SYSTEM DROP REPLICA 'dev-adqm-4.ru-central1.internal';

    Убедитесь, что в таблицу на новом хосте вставились данные с реплики dev-adqm-3.ru-central1.internal:

    SELECT * FROM test_repl_table;
       ┌─id─┐
1. │  1 │
   └────┘
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней