--- metadata: - name: generator content: Diplodoc Platform v5.50.6 alternate: - https://ytsaurus.tech/docs/en/admin-guide/cluster-operations.md - https://ytsaurus.tech/docs/ru/admin-guide/cluster-operations.md --- > **Documentation Index:** Fetch the complete configuration index at https://ytsaurus.tech/docs/ru/llms.txt ## Эксплуатация кластера { #main } ### Управление квотами для хранения данных Управление квотами для хранения данных осуществляется с помощью аккаунтов. Подробнее про аккаунты можно узнать [по ссылке](https://ytsaurus.tech/docs/ru/user-guide/storage/accounts.md). В данном разделе приведено несколько стандартных примеров работы с аккаунтами с помощью CLI. {% cut "Просмотр аккаунтов" %} Дерево аккаунтов в Кипарисе можно найти по пути `//sys/account_tree`. Полный плоский список доступен по пути `//sys/accounts` (имена аккаунтов глобально уникальны, несмотря на иерархическую организацию). Листинг 1 — Древовидное и плоское представления аккаунтов в Кипарисе ```bash $ yt list //sys/account_tree/my_account my_subaccount1 my_subaccount2 $ yt list //sys/accounts my_account my_subaccount1 my_subaccount2 ``` У аккаунта есть [множество атрибутов](https://ytsaurus.tech/docs/ru/user-guide/storage/accounts.md#account_attributes), описывающих лимиты на ресурсы, их текущее использование и другие. Запросить атрибуты любого объекта Кипариса и, в частности, аккаунта можно командой: ``` $ yt get //sys/account_tree/my_account/@ ``` {% endcut %} {% cut "Создание аккаунта" %} Чтобы создать аккаунт, в атрибуте `name` необходимо указать его имя, а в `parent_name` — имя родителя. Если имя родителя не указано, будет создан аккаунт верхнего уровня. Создавать такие аккаунты имеют право лишь администраторы кластера. Листинг 2 — Создание нового аккаунта ```bash $ yt create account --attributes='{ name = "my_subaccount3"; parent_name = "my_account" }' ``` {% endcut %} {% cut "Удаление аккаунта" %} Чтобы удалить аккаунт, достаточно указать путь к нему: Листинг 3 — Удаление аккаунта ```bash $ yt remove //sys/accounts/my_subaccount3 # или $ yt remove //sys/account_tree/my_account/my_subaccount3 ``` {% endcut %} {% cut "Изменение ресурсов аккаунта" %} Пример изменения количества нод Кипариса в лимитах аккаунта. Листинг 4 — Изменение ресурсов аккаунта ```bash # Просмотр текущего количества $ yt get //sys/accounts/my_subaccount3/@resource_limits/node_count 1000 # Установка нового значения $ yt set //sys/accounts/my_subaccount3/@resource_limits/node_count 2000 ``` {% endcut %} Обратите внимание, что дисковое место, управляемое через аккаунты, не лимитировано реальным доступным местом на кластере. Одна из задач системного администратора — с помощью лимитов на аккаунтах предотвращать ситуацию, когда на кластере заканчивается физическое место на дисках. {% note info "Примечание" %} Для каждого из служебных аккаунтов `tmp` и `intermediate` рекомендуется выставлять дисковую квоту в размере 2-3% от общего объёма розданной квоты в кластере. {% endnote %} ### Управление вычислительными квотами За распределение вычислительных ресурсов в кластере отвечает планировщик, но описание деревьев пулов и пулов (сущностей, которые хранят информацию о вычислительных квотах) хранится в Кипарисе. Рекомендуется прочитать [общую документацию](https://ytsaurus.tech/docs/ru/user-guide/data-processing/scheduler/scheduler-and-pools.md) про устройство планировщика и [отдельную страницу про управление пулами](https://ytsaurus.tech/docs/ru/user-guide/data-processing/scheduler/manage-pools.md). В данном разделе приведено несколько стандартных примеров работы с пулами с помощью CLI. {% cut "Просмотр пулов" %} Листинг 1 — Просмотр пулов ```bash yt get //sys/pool_trees/default { "project-root" = { "project-subpool1" = { }; "project-subpool2" = { }; }; } ``` {% endcut %} {% cut "Создание вложенного пула" %} Листинг 2 — Создание подпула ```bash yt create scheduler_pool --attributes='{pool_tree=default;name=project-subpool1;parent_name=project-root}' ``` В attributes можно дополнительно передать атрибуты пула, они будут провалидированы. В случае неуспешной валидации объект создан не будет. {% endcut %} {% cut "Изменения атрибутов пула" %} Листинг 3 — Изменения атрибутов пула ```bash # Простановка веса yt set //sys/pool_trees/default/project-root/project-subpool1/@weight 10 # Простановка запрета на запуск операций в пуле yt set //sys/pool_trees/default/project-root/@forbid_immediate_operations '%true' ``` {% endcut %} {% cut "Выдача и изменение гарантий на пуле" %} Первичное выставление гарантии пула (при условии что у родителя имеется нераспределённая гарантия): Листинг 4 — Первичная установка гарантии ```bash yt set //sys/pool_trees/default/project-root/project-subpool1/@strong_guarantee_resources '{cpu=50}' ``` Для изменения уже выставленной гарантии можно указать конкретный параметр: Листинг 5 — Изменение гарантии ```bash yt set //sys/pool_trees/default/project-root/project-subpool1/@strong_guarantee_resources/cpu 100 ``` {% endcut %} В отличии от квот на хранение данных планировщик проверяет, что выданные вычислительные квоты обеспечены фактическими ресурсами exec-нод кластера. ### Управление пользователями, группами и правами доступа В модели системы поддержаны такие сущности, как пользователи и группы, а через атрибуты объекта можно управлять правами доступа. Подробнее о модели прав доступа рассказано в отдельном [разделе](https://ytsaurus.tech/docs/ru/user-guide/storage/access-control.md). Как правило управление пользователями, группами и правами доступа делегируется в стороннюю систему (например в [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)), но для небольших инсталляций это бывает удобно делать вручную. Примеры управления пользователями и группами. {% cut "Просмотр пользователей и групп" %} Листинг 1 — Просмотр пользователей ```bash yt get //sys/users { "file_cache" = #; "guest" = #; "root" = #; "scheduler" = #; "operations_cleaner" = #; "operations_client" = #; "queue_agent" = #; "tablet_balancer" = #; } ``` Листинг 2 — Просмотр групп ```bash $ yt get //sys/groups { "devs" = #; "admins" = #; "superusers" = #; "everyone" = #; "users" = #; "admin_snapshots" = #; } ``` Листинг 3 — Просмотр состава группы ```bash $ yt get //sys/groups/users/@members [ "superusers"; ] ``` {% endcut %} {% cut "Создание пользователей и групп" %} Листинг 4 — Создание пользователя ```bash $ yt create user --attributes '{name=my_user}' 1-4a7d-101f5-f881885 $ yt exists //sys/users/my_user true ``` Листинг 5 — Создание группы ```bash $ yt create group --attributes '{name=my_group}' 1-bedc-101f6-45aec437 ``` Листинг 6 — Добавление пользователя в группу ```bash $ yt add-member my_user my_group $ yt get //sys/users/my_user/@member_of [ "users"; "my_group"; ] ``` {% endcut %} {% cut "Изменение RPS-лимитов у пользователя" %} Листинг 7 — Изменения RPS-лимитов у пользователя ```bash $ 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 ``` {% endcut %} {% cut "Просмотр ACL на узле" %} Следует отличать права доступа, непосредственно сконфигурированные на узле кипариса, и права доступа с учетом наследования от родителя. Листинг 8 — Просмотр ACL на узле ```bash $ 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"; }; ] ``` {% endcut %} {% cut "Изменение ACL на узле" %} Листинг 9 — Изменение ACL на узле ```bash $ 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"; }; ] ``` {% endcut %} #### Рекомендации по управлению правами доступа * используйте группы и выдавайте права исключительно группам; это позволяет выдавать/забирать скоуп доступов у пользователя путем добавления его в группу или исключения его из группы; * выдавайте права на крупные проектные директории и не выдавайте права на конкретные таблицы; таблица может быть пересоздана (тогда права потеряются), перемещена (в этом случае `effective_acl` с учетом нового расположения в Кипарисе окажется другим, могут быть унаследованы нежелательные доступы); * используйте право `deny` только в исключительных ситуациях, когда необходимо срочно отобрать права у конкретного пользователя. Правильный способ разграничения прав заключается в аккуратном управлении составами групп и использовании `inherit_acl=%false`, чтобы не наследовать широкие права родительского узла. ### Управление нодами кластера Существенная часть управления кластером состоит в управлении нодами кластера: их вводом и выводом, диагностикой проблем на конкретной ноде. Большую часть информации про ноды кластера можно посмотреть в UI. В то же время полезно знать, как ,ноды представлены в Кипарисе и какие у них есть атрибуты. {% cut "Как посмотреть список нод в кластере" %} Листинг 1 — Просмотр списка нод ```bash $ yt get //sys/cluster_nodes { "localhost:17359" = #; } ``` {% endcut %} Атрибуты ноды представлены в таблице 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 | Список [тегов](node-tags.md) данной ноды | | last_seen_time | DateTime | Момент времени, когда нода последний раз обращалась к мастеру | | registered_time | DateTime | Момент времени, когда нода была зарегистрирована в мастере | Перечисленные атрибуты носят информационный характер, то есть вычисляются системой исходя из конфигов и текущего состояния кластера. Существуют управляющие атрибуты, значения которых можно менять с помощью вызова `set`. Тем самым можно запросить выполнение какого-то действия, связанного с данной нодой. Таблица 2 — Управляющие атрибуты ноды | **Атрибут** | **Тип** | **Описание** | | ------------------------- | ---------------- | ------------------------------------------------------------ | | resource_limits_overrides | ClusterResources | Override на текущие ресурсы ноды (не работает для `user_slots`) | | user_tags | list | Список дополнительных [тегов](node-tags.md) ноды | | banned | bool | Указание значения `%true` банит данную ноду | | decommissioned | bool | Указание значения `%true` заказывает перенос чанков с этой ноды на другие ноды кластера | | disable_write_sessions | bool | Указание значения `%true` останавливает новые записи на данную ноду | | disable_scheduler_jobs | bool | Указание значения `%true` останавливает планирование новых джобов и приводит к прерыванию существующих по небольшому таймату | Корректно работающая нода, подключенная к кластеру, имеет состояние `online`. Состояние `offline` означает, что нода выключена или не может подняться. Существует ряд промежуточных состояний, в которых может находиться нода, пока происходит её регистрация в мастере. {% cut "Просмотр атрибутов ноды" %} Листинг 2 — Просмотр атрибутов ноды ```bash $ yt get //sys/cluster_nodes/localhost:17359/@ { "state" = "online"; ... } ``` {% endcut %} ### Динамические конфиги { #ytdyncfgen } Большинство компонент кластера поддерживает механизм динамического управления конфигами через Кипарис. Общая концепция выглядит следующим образом: в специальную ноду Кипариса можно написать конфиг-патч в виде документа. Компоненты кластера периодически перечитывают соответствующие им узлы Кипариса и применяют увиденные изменения. Важно понимать, что не все опции поддерживают механизм динамического изменения: зачастую реализовать подобную логику сложно или невозможно, хотя чаще она может быть просто не реализована, так как опции динамизировались по мере надобности. #### Динамический конфиг нод кластера Данный конфиг управляется через узел `//sys/cluster_nodes/@config`, в котором должен быть записан словарь: ключом словаря является фильтр, а значением — динамический конфиг, который требуется применить к нодам, подходящим под данный фильтр. Используемые в данном словаре фильтры не должны пересекаться, то есть каждая нода кластера должна попадать не более чем под один фильтр из данного словаря. #### Динамический конфиг планировщика и контроллер-агентов Конфиг планировщика управляется через узел `//sys/scheduler/config`. Данный узел представляет собой объект типа документ, который содержит патч к конфигу планировщика. Патч относится непосредственно к подсистеме планирования, то есть к секции `scheduler` из статического конфига данной компоненты. Аналогичным образом устроен конфиг контроллер-агентов: он управляется через узел `//sys/controller_agents/config` и содержит патч к подсистеме управления контроллерами операций, то есть к секции `controller_agent` из статического конфига контроллер-агентов. {% cut "Примеры управления конфигами планировщика и контроллер-агентов" %} Листинг 1 — Увеличение максимального размера файла, разрешенного в sandbox джобов ```bash # Просмотр текущего значения данной опции $ yt get //sys/controller_agents/instances//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//orchid/controller_agent/config/user_file_limits/max_size 53687091200 ``` {% endcut %}