Расширение мастер-сервера

Добавление новых мастерных селлов всегда происходит с полным даунтаймом кластера. В упрощенном виде расширение кластера представляет из себя одновременное обновление статического конфига всех компонент кластера с некоторыми дополнительными действиями. Ниже описан подробный план действий, перед тем как приступать к нему, стоит прочитать его до конца.

Подготовка

1. Нужно подготовить новый статический конфиг, добавив в него информацию о новых селлах.
2. Можно заранее подготовить @cluster_connection с новыми селлами (про @cluster_connection написано ниже в пункте 14).

Детальный план

1. Погасить шедулеры и контроллер-агенты

Эти компоненты стоит гасить в первую очередь, так как при массовом уходе нод (и вытекающей из этого нехватке ресурсов) они могут абортить пользовательские операции.

2. Выключить chunk refresh и chunk requisition update

yt set //sys/@config/chunk_manager/enable_chunk_refresh %false
yt set //sys/@config/chunk_manager/enable_chunk_requisition_update %false

На мастер-серверах есть фоновая активность по репликации чанков. Следующим пунктом мы погасим все ноды, из-за чего чанки, конечно, потеряют свои реплики, что в моменте может спровоцировать всплеск бесполезной работы (на мастер-серверах, конечно, есть защита на случай, если реплик потеряно слишком много, но до того, как этот момент наступит, мастер-сервера будут активно заниматься ненужной в будущем деятельностью). Чтобы это предотвратить, можно заранее переключить описанные флажки.

3. Погасить все ноды

(Следить за состоянием нод можно по //sys/nodes/@count и //sys/nodes/@online_node_count).

Здесь очень важно убедиться, что все ноды кластера находятся в состоянии offline (проверить состояние можно с помощью //sys/cluster_nodes/{node_address}/@state). В мастер-серверах есть защита, которая остановит новый селл от регистрации в случае, если есть хотя бы одна не offline нода.

4. Погасить все прокси

5. Погасить все оставшиеся сервисы кроме мастер-серверов

(Скорее всего это clock-сервера, мастер-кеши, timestamp-провайдеры, discovery-сервера. При наличии других сервисов их тоже стоит погасить на этом шаге).

6. Построить на мастер-серверах снапшот с read-only

yt-admin build-master-snapshots —read-only —wait-for-snapshot-completion

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

Можно убедиться, что мастер-сервера перешли в read-only режим и построили снапшот по логам лидера:
"Read-only mode enabled" и "Distributed snapshot creation finished".

7. Погасить мастер-сервера

8. Поднять мастер-сервера, clock-сервера, мастер-кеши, timestamp-провайдеры, discovery сервера

9. Выйти из режима read-only

yt-admin master-exit-read-only

10. Дождаться регистрации новых селлов и репликации глобальных объектов

По логам мастер-серверов стоит убедиться, что новые селлы успешно зарегистрировались и на них отреплицировались глобальные мастерные объекты.

Сообщение об успехе регистрации нужно искать в логах первичного селла: "Master cell registered".
А сообщения о репликации объектов — в логах новых, только что добавленных, мастерных селлов: "Foreign object created" (возможно потребуется подождать пару минут, пока они появятся). Также следует учесть, что объектов на кластере может быть много, и стоит подождать именно окончания репликации глобальных объектов (дождаться, когда фон сообщений "Foreign object created" прекратится).

11. Дождаться штатной работы мастер-серверов

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

Можно поискать в логах сообщения "Leader active"/"Follower active".

12. Прописать новым селлам роли

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

Виды ролей на текущий момент:
*chunk_host — шардирование по чанкам, уносит на селл работу с чанками таблиц. Самая популярная и некогда дефолтная роль. После указания роли на селл автоматически начнут селиться новые чанки.
*cypress_node_host — шардирование дерева метаинформации, позволяет уносить на этот селл поддеревья Кипариса (это требует ручных действий, данная роль дает такую возможность, но никакой автоматики в этом месте нет). Изложение процедуры вынесения поддеревьев на отдельный селл выходит за рамки данной статьи.
*transaction_coordinator — шардирование работы с транзакциями.

Если вы не знаете, что делать, то скорее всего лучше заставить новые селлы хостить чанки (chunk_host). Две других роли нужны только для очень крупных кластеров.

Прописать новые роли нужно в //sys/@config/multicell_manager/cell_descriptors:

//sys/@config/multicell_manager/cell_descriptors/{cell_tag}/roles

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

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

13. Поднять ноды (на версию с новым конфигом)

14. Дописать новые селлы в cluster connection

Cluster connection живет в Кипарисе, по пути //sys/@cluster_connection/secondary_masters.
Прописывать селлы нужно вот в таком формате:

[
        {
            "addresses" = [
                "some_master_address:9010";
            ];
            "cell_id" = "1-2-3-4";
        };
];

15. Включить chunk refresh и chunk requisition update

Если вы не выключали их на шаге 2, то этот шаг стоит пропустить.

yt set //sys/@config/chunk_manager/enable_chunk_refresh %true
yt set //sys/@config/chunk_manager/enable_chunk_requisition_update %true

16. Дождаться, пока все ноды зарегистрируются и для чанков сойдется refresh

В зависимости от количества нод и чанков на кластере этот шаг может занимать существенное время.

17. Поднять остальные компоненты

Поднять прокси, шедулеры, контроллер-агенты и другие компоненты (если такие остались).
Компоненты нужно поднимать на версию с новым конфигом.

18. Дождаться перехода кластера в режим штатной работы