Аккаунты

В данном разделе рассказывается об аккаунтах и связанных с ними квотах в системе YTsaurus. Приводится описание иерархии аккаунтов, даются примеры действий с аккаунтами, приводится перечень атрибутов аккаунта.

Общие сведения

Все типы квот для хранения данных привязаны к аккаунту проекта. Аккаунт — это служебный объект в Кипарисе. Все аккаунты имеют уникальные имена. При этом они находятся в отдельном пространстве имён, так что имя пользователя и аккаунта могут совпадать. Имя аккаунта хранится в атрибуте name, доступном как на чтение, так и на запись.

Все известные системе аккаунты можно найти в //sys/accounts. Создание и удаление аккаунтов производится командами create и remove.

Атрибуты узлов

Каждый узел Кипариса имеет атрибут account, доступный на чтение и запись. Этот атрибут хранит имя аккаунта, к которому привязан данный узел. В случае файлов и таблиц назначение аккаунта влечет за собой расход его дисковой квоты. При этом учитывается пространство, физически выделенное на узлах кластера для хранения данных, поэтому оно зависит от степени репликации (атрибут replication_factor), способа erasure-кодирования (атрибут erasure_codec) и используемой компрессии (атрибут compression_codec).

Различные узлы Кипариса (файлы или таблицы) могут ссылаться на одни и те же чанки. Кроме того, один и тот же узел может ссылаться на чанк несколько раз. Подобное повторное использование может возникнуть, например, в результате работы команды copy для таблиц и файлов, а также команд merge и erase для таблиц. Такие чанки учитываются в квоте единожды (с максимальным среди ссылающихся на них таблиц коэффициентом репликации).

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

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

Чтобы узнать, сколько и каких ресурсов потребляет данный узел Кипариса, следует использовать его атрибут resource_usage. Также существует вычисляемый атрибут recursive_resource_usage, отмеряющий использование ресурсов с учетом потомков. Данные атрибуты имеют структуру ClusterResources, смотрите далее.

Чтобы выставить аккаунт A некоторому узлу Кипариса, пользователь, инициировавший данное изменение, должен иметь право use на аккаунте A. Кроме того, у него должно быть право write. Аккаунт для узла можно также указать сразу в момент создания узла; в этом случае также необходимо иметь право use.

При копировании частей Кипариса командой copy, а также при перемещении командой move аккаунты, а также владельцы в копируемом поддереве изменяются — они становятся равными аккаунту каталога, куда происходит копирование, и пользователю, выполняющему копирование, соответственно. Чтобы предотвратить изменение аккаунта, существует опция preserve_account.

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

Иерархия аккаунтов

Аккаунты могут быть вложены в другие аккаунты. Это позволяет гибко настраивать квоты и естественным образом отражать в них организационную структуру, которой принадлежат пользователи и проекты. Например, может существовать общая квота отдела и вложенные в нее проектные квоты или, например, аккаунт сервиса и подаккаунты входящих в него групп. Основным преимуществом представления аккаунтов в виде дерева является то, что пользователи получают возможность самостоятельно управлять выданными им квотами, разделяя их на части и объединяя воедино по необходимости.

Далее в разделе описывается иерархическая организация аккаунтов и принципы работы с этой иерархией — из командной строки и веб-интерфейса.

Квотирование

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

По умолчанию сумма квот подаккаунтов не может превышать квоту родителя. Но иногда такая переподписка может быть удобной, поэтому её можно включить:

yt set //sys/account_tree/my_account/@allow_children_limit_overcommit %true

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

Написанное выше относится к лимитам потребления (limits), а не к используемым ресурсам (usage). Ресурсы, использованные в некотором аккаунте, учитываются в его квоте, а также в квотах всех его предков. Валидация работает так же: если увеличение потребления привело бы к исчерпанию квоты в аккаунте или в любом из его предков, генерируется ошибка.

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

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

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

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

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

$ yt list //sys/accounts
my_account
my_subaccount1
my_subaccount2

Создание аккаунта

Максимальная допустимая высота дерева аккаунтов равна 10.

Создать аккаунт верхнего уровня можно в веб-интерфейсе YTsaurus, нажав Create account на странице Accounts. Вложенные аккаунты создаются из командой строки или в веб-интерфейсе YTsaurus.

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 set //sys/account_tree/my_account/my_subaccount3/@parent_name my_subaccount2
$ yt exists //sys/account_tree/my_account/my_subaccount3
%false
$ yt exists //sys/account_tree/my_account/my_subaccount2/my_subaccount3
%true

yt move //sys/account_tree/my_account/my_subaccount3 //sys/account_tree/my_account/my_subaccount2/my_subaccount3

Передача ресурсов одного аккаунта другому

# yt transfer-account-resources <src_account> <dst_account> --resource-delta <resource_delta>
yt transfer-account-resources my_subaccount1 my_subaccount2 --resource-delta '{node_count=10}'

Встроенные аккаунты

Данные аккаунты появляются в системе в момент инициализации. Их нельзя удалить.

1. Аккаунт tmp. При инициализации назначается каталогу //tmp, а значит и всем его потомкам. По умолчанию правом пользоваться данным аккаунтом имеют все аутентифицированные пользователи системы (группа users).
2. Аккаунт sys. При инициализации назначается всем остальным узлам. Явных разрешений на его использование по умолчанию никому не выдаётся. Аккаунт используется для внутренних нужд системы YTsaurus.

Атрибуты аккаунта

ClusterResources представляет собой следующую структуру:

Структура ClusterResources

Поле disk_space доступно только для чтения. Для изменения лимитов следует следует изменять значения словаря disk_space_per_medium.

ViolatedClusterResources представляет собой следующую структуру:

Структура ViolatedClusterResources

RecursiveViolatedClusterResources представляет собой следующую структуру:

Структура RecursiveViolatedClusterResources