Перейти к содержанию

Управление тенантами

Страница нужна администратору кластера, который создаёт и удаляет тенантов — изолированные пространства имён со своими бакетами, пользователями и ключами доступа. Здесь же описаны состояния тенанта, столбцы таблицы s3r_tenant и два служебных тенанта, которые удалить нельзя.

Состояния тенанта

Запросы обслуживаются только для тенанта в состоянии active.

Состояние Что означает
new тенант создаётся и ещё не готов
active тенант работает
draining тенант удаляется; аутентификацию он больше не проходит
dropped тенант удалён; от него осталась только строка в s3r_tenant

Создание бакета в тенанте, который не находится в состоянии active, отклоняется.

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

Что должно быть выполнено заранее. У пользователя есть роль s3r_superuser (см. Ролевая модель тенантов).

Не добавляйте строки в s3r_tenant командой INSERT

Такой запрос игнорирует проверку FQDN и обходит счётчик идентификаторов: следующий запрос к API получит уже занятый идентификатор и завершится ошибкой.

Шаги.

  1. Отправьте запрос к API управления либо создайте тенанта на экране тенантов консоли:

    curl -u ivanov -X POST https://console.example.net/s3gateway/api/v2/tenants \
      -H 'content-type: application/json' \
      -d '{"name": "acme", "fqdn": "acme.s3.example.net"}'
    
  2. Действуйте по коду ответа:

    Ответ Что произошло Что делать
    201 с идентификатором тенанта тенант создан и уже активен ничего
    202 тенант не стал активным за две минуты. Это успешный ответ: создание продолжается само повторять запрос не нужно; следите за состоянием запросом GET /v3/tenants/{id}
    503 запись строки тенанта через Raft не подтверждена за две минуты проверьте GET /v3/tenants: запись может завершиться позже, и тогда тенант появится в списке
    409 с кодом NameInUse тенант с таким именем уже есть, в том числе созданный запросом, который получил 503 —

Что происходит. Запрос записывает строку в глобальную таблицу s3r_tenant в состоянии new. Эта запись запускает фоновый процесс tenant, который создаёт таблицы нового тенанта и переводит его в состояние active.

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

Идентификатор выдаёт счётчик tenant_id таблицы s3r_seq той же записью Raft, которая добавляет строку тенанта, поэтому идентификатор никогда не выдаётся повторно.

Ответ 202: тенант ещё создаётся

  • Поле result содержит тенанта в том виде, в каком его показывает GET /v3/tenants/{id}, с состоянием pending. В таблице s3r_tenant тенант при этом остаётся в состоянии new.
  • Поле message рядом с result содержит идентификатор тенанта и запрос GET /v3/tenants/{id}. Этот запрос показывает состояние pending, пока тенант не станет активным.
  • Если создание не завершается, процесс tenant при каждой попытке записывает причину в журнал инстанса строкой tenant <id> (new): ....

Удаление тенанта

Удаление уничтожает данные тенанта и сразу отзывает доступ

Вместе с тенантом удаляются его бакеты и таблицы с объектами. Блокировки объектов удаление не останавливают. Тенант в состоянии draining больше не проходит аутентификацию: перевод в удаление отзывает доступ той же записью Raft.

Запроса на удаление в API управления нет, поэтому удаление выполняется командой SQL.

Шаги.

  1. Переведите тенанта в состояние draining:

    UPDATE s3r_tenant SET state = 'draining' WHERE tenant_id = 1;
    
  2. Дождитесь, пока строка тенанта в s3r_tenant перейдёт в состояние dropped.

Что происходит. Фоновый процесс tenant на координаторе кластера:

  1. Помечает удалёнными все бакеты тенанта и ждёт, пока пометки применят мастеры всех репликасетов.
  2. Освобождает ссылки дедупликации, которые объекты тенанта держат в таблицах других тенантов.
  3. Удаляет отпечатки содержимого объектов тенанта из индекса дедупликации s3r_content_fingerprint.
  4. Удаляет таблицы тенанта, его строки учёта квот и строки его бакетов.
  5. Оставляет строку тенанта в состоянии dropped.

Служебные тенанты

Два тенанта принадлежат самому кластеру и не удаляются.

Тенант Идентификатор Назначение
Тенант по умолчанию 0 пространство имён по умолчанию
Системный тенант 4294967295 (последний идентификатор) в его таблицах хранятся данные, не принадлежащие ни одному пользовательскому тенанту, а именно объекты дедупликации

У системного тенанта нет ни FQDN, ни ключей доступа. Если перевести его в состояние draining, фоновый процесс tenant вернёт его в состояние active.

Правила CORS тенанта по умолчанию

У тенанта можно задать набор правил CORS по умолчанию. Набор копируется в бакет при его создании операцией CreateBucket или запросом POST /v2/buckets, и бакет сразу отвечает на предварительные запросы для источников из набора.

Например, так всем новым бакетам тенанта разрешается загрузка из веб-консоли, открытой на любом порту адреса console.example.net:

curl -u ivanov -X PUT 'https://console.example.net/s3gateway/api/v2/tenants?tenant_id=1' \
  -H 'content-type: application/json' \
  -d '{"default_cors": [{"id": "console-uploads", "methods": ["GET", "PUT", "HEAD"],
       "origins": ["https://console.example.net:*"], "headers": ["*"],
       "expose": ["ETag"], "max_age": 3600}]}'

Набор задают суперпользователь и администратор тенанта: запросом к API управления или в консоли (см. Тенанты).

Задача Запрос
Задать или заменить набор PUT /v2/tenants с полем default_cors. Правило записывается в том же формате, что и в запросе PUT /v2/buckets/{bucket}/cors, и проверяется так же, как правила PutBucketCors
Задать набор при создании тенанта то же поле в запросе POST /v2/tenants
Удалить набор "default_cors": null. Пустой список отклоняется ответом 400
Оставить набор без изменений запрос без поля default_cors
Прочитать набор поле default_cors ответа GET /v3/tenants/{id}: строка с массивом правил в формате JSON. Если набор не задан или некорректен, поле равно null. Некорректный набор можно записать только командой SQL

Набор применяется только при создании бакета:

  • изменение и удаление набора не затрагивают существующие бакеты, а бакетам, созданным до появления набора, правила не добавляются; им правила задаются операцией PutBucketCors;
  • полученные правила становятся обычными правилами бакета. Владелец бакета и все, кому разрешена операция GetBucketCors, видят их, в том числе адрес консоли. Изменить правила можно операцией PutBucketCors, а удалить — операцией DeleteBucketCors. После удаления правила консоли загрузка из консоли в этот бакет перестаёт работать;
  • поле cors в запросе POST /v2/buckets заменяет набор целиком;
  • без набора бакет создаётся без правил.