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

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

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

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

$ 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/@

$ yt create account --attributes='{ name = "my_subaccount3"; parent_name = "my_account" }'

$ yt remove //sys/accounts/my_subaccount3

# или

$ yt remove //sys/account_tree/my_account/my_subaccount3

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

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

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

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

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

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

yt get //sys/pool_trees/physical
{
    "project-root" = {
        "project-subpool1" = {
        };
        "project-subpool2" = {
        };
    };
}

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

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

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

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

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

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

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

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

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

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

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

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

$ yt get //sys/groups/users/@members
[
    "superusers";
]

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

$ yt exists //sys/users/my_user
true

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

$ yt add-member my_user my_group

$ yt get //sys/users/my_user/@member_of
[
    "users";
    "my_group";
]

$ 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

$ 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";
    };
]

$ 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. В то же время полезно знать, как ,ноды представлены в Кипарисе и какие у них есть атрибуты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# Просмотр текущего значения данной опции
$ 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