Эксплуатация кластера

Управление квотами для хранения данных

Управление квотами для хранения данных осуществляется с помощью аккаунтов. Подробнее про аккаунты можно узнать по ссылке.

В данном разделе приведено несколько стандартных примеров работы с аккаунтами с помощью CLI.

Просмотр аккаунтов

Дерево аккаунтов в Кипарисе можно найти по пути //sys/account_tree. Полный плоский список доступен по пути //sys/accounts (имена аккаунтов глобально уникальны, несмотря на иерархическую организацию).

Листинг 1 — Древовидное и плоское представления аккаунтов в Кипарисе

$ yt list //sys/account_tree/my_account
my_subaccount1
my_subaccount2

$ yt list //sys/accounts
my_account
my_subaccount1
my_subaccount2

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

Запросить атрибуты любого объекта Кипариса и, в частности, аккаунта можно командой:

$ yt get //sys/account_tree/my_account/@
Создание аккаунта

Листинг 2 — Создание нового аккаунта

$ yt create account --attributes='{ name = "my_subaccount3"; parent_name = "my_account" }'
Удаление аккаунта

Чтобы удалить аккаунт, достаточно указать путь к нему:

Листинг 3 — Удаление аккаунта

$ yt remove //sys/accounts/my_subaccount3

# или

$ yt remove //sys/account_tree/my_account/my_subaccount3
Изменение ресурсов аккаунта

Пример изменения количества нод Кипариса в лимитах аккаунта.

Листинг 4 — Изменение ресурсов аккаунта

# Просмотр текущего количества
$ yt get //sys/accounts/my_subaccount3/@resource_limits/node_count
1000

# Установка нового значения
$ yt set //sys/accounts/my_subaccount3/@resource_limits/node_count 2000

Обратите внимание, что дисковое место, управляемое через аккаунты, не лимитировано реальным доступным местом на кластере.
Одна из задач системного администратора — с помощью лимитов на аккаунтах предотвращать ситуацию, когда на кластере заканчивается физическое место на дисках.

Управление вычислительными квотами

За распределение вычислительных ресурсов в кластере отвечает планировщик, но описание деревьев пулов и пулов (сущностей, которые хранят информацию о вычислительных квотах) хранится в Кипарисе. Рекомендуется прочитать общую документацию про устройство планировщика и отдельную страницу про управление пулами.

В данном разделе приведено несколько стандартных примеров работы с пулами с помощью CLI.

Просмотр пулов

Листинг 1 — Просмотр пулов

yt get //sys/pool_trees/physical
{
    "project-root" = {
        "project-subpool1" = {
        };
        "project-subpool2" = {
        };
    };
}
Создание вложенного пула

Листинг 2 — Создание подпула

yt create scheduler_pool --attributes='{pool_tree=physical;name=project-subpool1;parent_name=project-root}'

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

Изменения атрибутов пула

Листинг 3 — Изменения атрибутов пула

# Простановка веса
yt set //sys/pool_trees/physical/project-root/project-subpool1/@weight 10

# Простановка запрета на запуск операций в пуле
yt set //sys/pool_trees/physical/project-root/@forbid_immediate_operations '%true'
Выдача и изменение гарантий на пуле

Первичное выставление гарантии пула (при условии что у родителя имеется нераспределённая гарантия):

Листинг 4 — Первичная установка гарантии

yt set //sys/pool_trees/physical/project-root/project-subpool1/@strong_guarantee_resources '{cpu=50}'

Для изменения уже выставленной гарантии можно указать конкретный параметр:

Листинг 5 — Изменение гарантии

yt set //sys/pool_trees/physical/project-root/project-subpool1/@strong_guarantee_resources/cpu 100

В отличии от квот на хранение данных планировщик проверяет, что выданные вычислительные квоты обеспечены фактическими ресурсами exec-нод кластера.

Управление пользователями, группами и правами доступа

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

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

Примеры управления пользователями и группами.

Просмотр пользователей и групп

Листинг 1 — Просмотр пользователей

yt get //sys/users
{
    "file_cache" = #;
    "guest" = #;
    "root" = #;
    "scheduler" = #;
    "operations_cleaner" = #;
    "operations_client" = #;
    "queue_agent" = #;
    "tablet_balancer" = #;
}

Листинг 2 — Просмотр групп

$ yt get //sys/groups
{
    "devs" = #;
    "admins" = #;
    "superusers" = #;
    "everyone" = #;
    "users" = #;
    "admin_snapshots" = #;
}

Листинг 3 — Просмотр состава группы

$ yt get //sys/groups/users/@members
[
    "superusers";
]
Создание пользователей и групп

Листинг 4 — Создание пользователя

$ yt create user --attributes '{name=my_user}'
1-4a7d-101f5-f881885

$ yt exists //sys/users/my_user
true

Листинг 5 — Создание группы

$ yt create group --attributes '{name=my_group}'
1-bedc-101f6-45aec437

Листинг 6 — Добавление пользователя в группу

$ yt add-member my_user my_group

$ yt get //sys/users/my_user/@member_of
[
    "users";
    "my_group";
]
Изменение RPS-лимитов у пользователя

Листинг 7 — Изменения RPS-лимитов у пользователя

$ yt get //sys/users/my_user/@read_request_rate_limit
100
$ yt get //sys/users/my_user/@write_request_rate_limit
100

$ yt set //sys/users/my_user/@read_request_rate_limit 300
$ yt set //sys/users/my_user/@write_request_rate_limit 200
Просмотр ACL на узле

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

Листинг 8 — Просмотр ACL на узле

$ yt create map_node //home/my_user
1-283e-1012f-63684d08
$ yt get //home/my_user/@acl
[]
$ yt get //home/my_user/@inherit_acl
%true
$ yt get //home/my_user/@effective_acl
[
    {
        "action" = "allow";
        "subjects" = [
            "users";
        ];
        "permissions" = [
            "read";
        ];
        "inheritance_mode" = "object_and_descendants";
    };
    {
        "action" = "allow";
        "subjects" = [
            "admins";
        ];
        "permissions" = [
            "write";
            "administer";
            "remove";
            "mount";
        ];
        "inheritance_mode" = "object_and_descendants";
    };
]
Изменение ACL на узле

Листинг 9 — Изменение ACL на узле

$ yt set //home/my_user/@acl '[{subjects=[my_group];permissions=[read;write;remove;];action=allow}]'
$ yt set //home/my_user/@inherit_acl '%false'
$ yt get //home/my_user/@effective_acl
[
    {
        "action" = "allow";
        "subjects" = [
            "my_group";
        ];
        "permissions" = [
            "read";
            "write";
            "remove";
        ];
        "inheritance_mode" = "object_and_descendants";
    };
]

Рекомендации по управлению правами доступа

  • используйте группы и выдавайте права исключительно группам; это позволяет выдавать/забирать скоуп доступов у пользователя путем добавления его в группу или исключения его из группы;
  • выдавайте права на крупные проектные директории и не выдавайте права на конкретные таблицы; таблица может быть пересоздана (тогда права потеряются), перемещена (в этом случае effective_acl с учетом нового расположения в Кипарисе окажется другим, могут быть унаследованы нежелательные доступы);
  • используйте право deny только в исключительных ситуациях, когда необходимо срочно отобрать права у конкретного пользователя. Правильный способ разграничения прав заключается в аккуратном управлении составами групп и использовании inherit_acl=%false, чтобы не наследовать широкие права родительского узла.

Управление нодами кластера

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

Большую часть информации про ноды кластера можно посмотреть в UI. В то же время полезно знать, как ,ноды представлены в Кипарисе и какие у них есть атрибуты.

Как посмотреть список нод в кластере

Листинг 1 — Просмотр списка нод

$ yt get //sys/cluster_nodes
{
    "localhost:17359" = #;
}

Атрибуты ноды представлены в таблице 1:

Таблица 1 — Атрибуты ноды

Атрибут Тип Описание
state ENodeState Состояние ноды с точки зрения мастера
flavors list Список flavor-ов данной ноды
resource_limits ClusterResources Доступные ресурсы на данной ноде
resource_usage ClusterResources Используемые ресурсы
alerts list Список алертов на данной ноде
version string Версия бинарного файла YTsaurus, запущенная на данной ноде
job_proxy_build_version string Версия бинарного файла ytserver-job-proxy, используемого exe-нодой
tags list Список тегов данной ноды
last_seen_time DateTime Момент времени, когда нода последний раз обращалась к мастеру
registered_time DateTime Момент времени, когда нода была зарегистрирована в мастере

Перечисленные атрибуты носят информационный характер, то есть вычисляются системой исходя из конфигов и текущего состояния кластера.

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

Таблица 2 — Управляющие атрибуты ноды

Атрибут Тип Описание
resource_limits_overrides ClusterResources Override на текущие ресурсы ноды (не работает для user_slots)
user_tags list Список дополнительных тегов ноды
banned bool Указание значения %true банит данную ноду
decommissioned bool Указание значения %true заказывает перенос чанков с этой ноды на другие ноды кластера
disable_write_sessions bool Указание значения %true останавливает новые записи на данную ноду
disable_scheduler_jobs bool Указание значения %true останавливает планирование новых джобов и приводит к прерыванию существующих по небольшому таймату

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

Просмотр атрибутов ноды

Листинг 2 — Просмотр атрибутов ноды

$ yt get //sys/cluster_nodes/localhost:17359/@
{
    "state" = "online";
    ...
}

Динамические конфиги

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

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

Динамический конфиг нод кластера

Данный конфиг управляется через узел //sys/cluster_nodes/@config, в котором должен быть записан словарь: ключом словаря является фильтр, а значением — динамический конфиг, который требуется применить к нодам, подходящим под данный фильтр. Используемые в данном словаре фильтры не должны пересекаться, то есть каждая нода кластера должна попадать не более чем под один фильтр из данного словаря.

Динамический конфиг планировщика и контроллер-агентов

Конфиг планировщика управляется через узел //sys/scheduler/config. Данный узел представляет собой объект типа документ, который содержит патч к конфигу планировщика. Патч относится непосредственно к подсистеме планирования, то есть к секции scheduler из статического конфига данной компоненты.

Аналогичным образом устроен конфиг контроллер-агентов: он управляется через узел //sys/controller_agents/config и содержит патч к подсистеме управления контроллерами операций, то есть к секции controller_agent из статического конфига контроллер-агентов.

Примеры управления конфигами планировщика и контроллер-агентов

Листинг 1 — Увеличение максимального размера файла, разрешенного в sandbox джобов

# Просмотр текущего значения данной опции
$ yt get //sys/controller_agents/instances/<controller_agent>/orchid/controller_agent/config/user_file_limits/max_size
10737418240

# Создание узла конфига (если его еще нет)
$ yt create document //sys/controller_agents/config --attributes '{value={}}'

# Простановка нового значения
$ yt set //sys/controller_agents/config/user_file_limits '{max_size=53687091200}'

# Удостоверяемся, что контроллер-агент подхватил новое значение
$ yt get //sys/controller_agents/instances/<controller_agent>/orchid/controller_agent/config/user_file_limits/max_size
53687091200