Подписка и лицензирование

Система лицензирования Rediacc состоит из трёх компонентов:

• account подписывает права доступа и отслеживает использование
• rdc проводит аутентификацию, запрашивает лицензии, доставляет их на машины и проверяет их во время выполнения
• renet (среда выполнения на машине) проверяет установленные лицензии локально без обращения к серверу account

На этой странице объясняется, как эти компоненты работают вместе в локальных развёртываниях.

Что делает лицензирование

Лицензирование контролирует две разные вещи:

• Учёт доступа к машинам через плавающие лицензии
• Авторизация выполнения репозитория через лицензии репозиториев

Это связанные, но не идентичные артефакты.

Как работает лицензирование

account является источником истины для планов, переопределений контракта, состояния слотов машин и месячного выпуска лицензий репозиториев.

rdc работает на вашей рабочей станции. Он входит на сервер account, запрашивает необходимые ему лицензии и устанавливает их на удалённые машины по SSH. Когда вы запускаете команду репозитория, rdc убедитесь, что требуемые лицензии установлены, и проверяет их на машине во время выполнения.

Нормальный поток выглядит следующим образом:

1. Вы проводите аутентификацию с помощью rdc subscription login
2. Вы запускаете команду репозитория, например rdc repo create, rdc repo up или rdc repo down
3. Если требуемая лицензия отсутствует или истекла, rdc запрашивает её на сервере account
4. rdc записывает подписанную лицензию на машину
5. Лицензия проверяется локально на машине и операция продолжается

О разделении между рабочей станцией и сервером см. rdc vs renet, а о жизненном цикле репозитория см. Репозитории.

Для автоматизации и AI-агентов используйте токен подписки с ограниченной областью вместо входа через браузер:

rdc subscription login --token "$REDIACC_TOKEN"

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

export REDIACC_TOKEN="rdt_..."
export REDIACC_ACCOUNT_SERVER="https://www.rediacc.com/account"

Слоты машин и лицензии репозиториев

Слоты машин (проверка на сервере)

Отслеживание слотов машин проверяется на сервере. Когда CLI выпускает лицензию репозитория, сервер account проверяет квоту слотов машин подписки. Каждый самостоятельно оформляемый план (Community, Professional, Business) включает один слот машины; развёртывания с несколькими машинами являются конфигурацией Enterprise, которую подбирают вместе с нашими партнёрами. Слот удерживается в течение 5 часов с момента последнего выпуска лицензии репозитория на этой машине и автоматически освобождается после неактивности. Поскольку слот удерживается только во время активного управления ресурсами, один слот всё равно может охватывать несколько машин в течение месяца.

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

Выпуск и продление проверяются по-разному, и эта разница важна:

• Выпуск новой лицензии блокируется на потолке. Если все слоты заняты, запрос завершается ошибкой MAX_MACHINES_REACHED и ничего не подготавливается.
• Продление существующей лицензии не блокируется никогда. Машина, которая продлевает лицензию, когда все слоты заняты, продолжает работать, а её слот записывается как превышающий лимит. Это видно в портале на странице машин, в выводе rdc subscription status и в поле overLimitCount API статуса лицензий. Отметка снимается сама, как только машина снова укладывается в лимит.

Продление намеренно сделано более мягким путём. Машина, продлевающая лицензию, которая у неё уже есть, не добавляет новой ёмкости, и отказ остановил бы резервное копирование на инфраструктуре, за которую уже заплачено. Блокируется по-прежнему именно добавление ёмкости.

Файл лицензии машины не хранится на машине. Проверка слотов происходит во время выпуска на сервере.

Лицензия репозитория

Лицензия репозитория является подписанной лицензией для одного репозитория на одной машине. Это единственный файл лицензии, хранящийся на машине, и раскладывается он по хранилищу данных и по ключу подписи:

/var/lib/rediacc/license/repos/{guid}/{keyId}.json
/var/lib/rediacc/license/datastores/{datastoreId}/repos/{guid}/{keyId}.json

Репозитории в хранилище машины по умолчанию используют первый путь. Репозитории в именованном хранилище данных используют второй, где {datastoreId} - это идентичность, которую хранилище данных получило при создании. Именно эта привязка заставляет форк хранилища данных считаться честно: форкнутое хранилище получает совершенно новую идентичность, поэтому его репозитории стартуют без единой лицензии, на первой же лицензируемой операции сообщают missing и получают собственные выпущенные лицензии. Репозиторий, в лицензии которого названо не то хранилище данных, в котором он лежит, быстро отказывает с identity_mismatch, а не переиздаёт лицензию автоматически, и именно это не даёт скопировать файл лицензии вбок.

{keyId} - это 16-символьный шестнадцатеричный отпечаток (первые 8 байт SHA-256 открытого ключа Ed25519 подписывающего сервера). Репозиторий, которым управляет более одной учётной вселенной (например, production и bench, разворачивающиеся на одной и той же машине), хранит по одному файлу на каждый ключ подписи в своей директории {guid}. Сборка renet на машине проверяет только тот файл, который может подтвердить встроенный в неё ключ или делегированный сертификат, привязанный к цепочке этого ключа; файлы других вселенных остаются неактивными. Переключение между вселенными никогда не делает лицензии недействительными: первая операция в новой вселенной один раз выпускает лицензию этой вселенной (результат missing приводит к автоматическому выпуску), и после этого обе лицензии сосуществуют.

Она используется для:

• rdc repo create, rdc repo fork и rdc repo commit, проверка перед подготовкой (предварительно выпускаются без доказательств идентичности, затем переиздаются с доказательствами идентичности после создания, потому что в момент проверки репозитория ещё не существует)
• rdc repo resize, rdc repo expand, rdc repo merge и rdc repo promote, полная проверка, включая срок действия
• передача резервных копий, полная проверка, включая срок действия: rdc repo push, rdc repo pull, rdc repo migrate и запланированные резервные копии
• rdc repo up, rdc repo up --all, rdc repo exec и автозапуск репозитория при перезагрузке машины, проверка с пропуском и срока действия, и окна сертификата делегирования
• rdc repo down, rdc repo delete и команды только для чтения, например перечисление репозиториев, вообще не требуют лицензии

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

Лицензии репозиториев привязаны к машине и целевому репозиторию. Каждая лицензия содержит ID машины, GUID репозитория, ID подписки, ограничения плана и срок действия. Для зашифрованных репозиториев Rediacc также проверяет идентичность LUKS основного тома.

Несколько подписок могут сосуществовать на одной машине. Каждый репозиторий имеет собственную лицензию со своим контекстом подписки.

Кластеры

Кластеризация продаётся через наших партнёров в рамках соглашения Enterprise. Это не самостоятельно подключаемая опция плана, и разделы ниже описывают, как она тарифицируется, а не как её купить.

Узел - это машина. У кластера нет собственной лицензионной идентичности. Каждый его узел является обычной машиной с установленным Renet Agent и учитывается точно так же, как отдельно стоящая машина.

Никакого объединения в пул. Кластер из пяти узлов не берёт один общий кластерный слот. Каждый узел занимает собственный слот, когда на нём впервые размещается репозиторий, и этот слот плавает так же, как любой другой: он удерживается 5 часов с момента последнего выпуска лицензии репозитория на этом узле и после этого освобождается сам.

Построение кластера бесплатно. Тарифицируется размещение репозиториев. Создание кластера, присоединение узлов, установка распределённого слоя хранения и поднятие control plane Kubernetes не стоят ни одного слота. Учёт начинается, когда на узел попадает репозиторий.

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

Продление в кластере подчиняется описанному выше правилу мягкого захвата. Узлы продлевают свои лицензии без участия человека, поэтому кластер, переросший своё число активаций, продолжает работать и сообщает о превысивших лимит узлах, а не роняет резервное копирование посреди ночи. Добавление нового узла по-прежнему блокируется на потолке.

Размер кластера обсуждается, а не выбирается галочкой. Число активаций для кластеров согласуется в заказе, и ваш партнёр проставляет его прямо в подписке. Начните этот разговор со страницы Контакты.

Ограничения по умолчанию

Размер репозитория зависит от уровня прав:

• Community: до 10 GB
• платные планы: лимит плана или контракта

Ограничения платных планов по умолчанию:

План	Плавающие лицензии	Размер репозитория	Месячные выпуски лицензий репозитория	Срок действия сертификата делегирования (по умолч./макс.)
Community	1	10 GB	100	15d / 30d
Professional	1	100 GB	2 000+	60d / 120d
Business	1	500 GB	5 000+	90d / 180d
Enterprise	Индивидуально	1 TB+	15 000+	120d / 365d

Специфичные для контракта ограничения могут повышать или понижать эти значения для конкретного клиента. Срок действия сертификата делегирования также жёстко ограничен subscription.expiresAt + 3 day grace, поэтому ежемесячно выставляемые подписки естественным образом получают сертификаты, выровненные по их циклу выставления счётов. Полные правила см. в разделе Цепочка лицензий и делегирование - Политика валидности.

Бесплатный пробный период и откат на Community

Новые регистрации начинаются с 14-дневного бесплатного пробного периода на плане Professional или Business. Банковская карта запрашивается уже при регистрации, но первое списание происходит только после окончания пробного периода, поэтому отмена до этого момента ничего не стоит. На одного клиента доступен только один пробный период.

Community остаётся постоянным бесплатным базовым уровнем. Он больше не доступен для прямой регистрации новых аккаунтов; вместо этого аккаунт переходит на Community всякий раз, когда подписка заканчивается: отмена во время пробного периода, отмена платного плана позже или неудачный платёж. На плане Community вы сохраняете одну машину с 10 GB на репозиторий и 100 настроек в месяц. Аккаунты, созданные до запуска модели с пробным периодом, сохраняют свой прежний доступ к Community.

Ограничения остаются мягкими там, где это важнее всего: работающие репозитории (up, down, delete, автозапуск) продолжают функционировать даже после окончания подписки. Дальше действуют два разных правила, и именно их путаница создаёт впечатление, будто 60-дневная отсрочка работает непоследовательно:

• Операции, которым нужен сервер аккаунтов, без активной подписки невозможны, потому что сервер отказывается подписывать. Это create, fork и любое обновление или продление лицензии. После окончания подписки ничего нового не подготавливается.
• Операции, которым достаточно действующей установленной лицензии, работают до жёсткого истечения этой лицензии и вообще без участия сервера. Это resize и expand на уже имеющихся у вас репозиториях, а также передача резервных копий (push, pull, запланированные резервные копии). Основная лицензия репозитория жёстко истекает через 60 дней после даты окончания подписки, отсюда и берётся 60-дневная отсрочка. Лицензия форка живёт куда меньше, максимум 7 дней, и поэтому машины с большим количеством форков зависят от самопродления, описанного ниже.

То есть закончившаяся подписка сразу останавливает рост вашего парка машин, а через 60 дней останавливает и рост репозиториев в нём.

Период отсрочки при миграции ВМ

Когда поставщик хостинга переносит ВМ на другое физическое оборудование, ID машины меняется (он получается из идентификаторов оборудования, таких как DMI UUID, /etc/machine-id и MAC-адреса NIC). Лицензии репозиториев привязаны к ID машины, поэтому миграция обычно делала бы все лицензии недействительными.

Чтобы справиться с этим прозрачно, лицензии репозиториев включают 40-дневный период отсрочки ID машины. Если ID машины не совпадает, но лицензия была выпущена менее 40 дней назад, лицензия всё ещё принимается. Поскольку лицензии обновляются каждые 30 дней, следующее обновление автоматически привяжет его к новому ID машины.

На практике:

• ВМ перенесена, ID машины изменился: репозитории продолжают работать (в окне 40 дней)
• Следующая операция rdc обновляет лицензию с новым ID машины
• Никакого ручного вмешательства не требуется
• Проверьте ID машины и статус лицензии с помощью rdc machine status <machine> --system --licenses

Аккаунты канала Edge работают на плане Community с удвоенными лимитами (20 GB репозиториев, 200 настроек в месяц, 2 машины). Платные планы доступны только на канале Stable. Подробнее см. Каналы выпуска.

Что происходит при создании, запуске, остановке и перезагрузке репозитория

Создание и форк репозитория

Когда вы создаёте или создаёте форк репозитория:

1. rdc убедитесь, что ваш токен подписки доступен (запускает аутентификацию по коду устройства, если необходимо)
2. rdc предварительно выпускает лицензию репозитория с сервера account (сервер проверяет квоту слотов машин и месячные ограничения выпусков в этот момент)
3. Предварительно выпущенная лицензия репозитория записывается на машину и проверяется локально (подпись, ID машины, GUID репозитория, срок действия и лимит размера)
4. После успешного создания rdc повторно выпускает лицензию репозитория с доказательствами идентичности репозитория (UUID LUKS или отпечаток хранилища)

Это выпущенное на основе account лицензирование учитывается в отношении вашего месячного использования выпусков лицензий репозиториев. Каждая лицензия содержит адрес электронной почты и название компании владельца account, которые регистрируются при проверке лицензии renet.

Запуск, остановка и удаление репозитория

rdc проверяет установленную лицензию репозитория на машине, но пропускает проверку срока действия. Подпись, ID машины, GUID репозитория и идентичность всё ещё проверяются. Пользователи никогда не блокируются из-за невозможности управлять своими репозиториями, даже с истекшей подпиской.

Изменение размера и расширение репозитория

rdc выполняет полную проверку лицензии репозитория включая срок действия и ограничения размера.

Перезагрузка машины и автозапуск

Автозапуск использует те же правила, что и rdc repo up: срок действия пропускается, поэтому репозитории всегда перезапускаются свободно.

Лицензии репозиториев используют модель долгосрочной валидности:

• refreshRecommendedAt это мягкая точка обновления
• hardExpiresAt это точка блокировки

Если лицензия репозитория устарела, но всё ещё до жёсткого истечения, выполнение может продолжаться. После достижения жёсткого истечения rdc должен обновить его для операций изменения размера/расширения.

Другие операции с репозиториями

Операции, такие как перечисление репозиториев, проверка информации репозитория и монтирование, не требуют никакой проверки лицензии.

Проверка статуса и обновление лицензий

Вход человека:

rdc subscription login

Вход для автоматизации или AI-агента:

rdc subscription login --token "$REDIACC_TOKEN"

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

Показать статус подписки на основе account:

rdc subscription status

Показать детали активации машины для одной машины:

rdc subscription status -m hostinger

Показать детали установленной лицензии репозитория на одной машине:

rdc subscription status -m hostinger

Обновить лицензию репозитория на машине:

rdc subscription refresh -m hostinger --repo my-app

Ref в --repo должен разрешаться в вашей локальной конфигурации rdc. Репозиторий, обнаруженный на машине, но отсутствующий в локальной конфигурации, отклоняется: он сообщается как сбой и не классифицируется автоматически.

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

В неинтерактивных средах CLI не ждёт одобрения браузера. Вместо этого он говорит вам предоставить токен с ограниченной областью с помощью rdc subscription login --token ... или REDIACC_TOKEN.

О первоначальной настройке машины см. Настройка машины.

Самопродление лицензий

Всё сказанное выше предполагает, что вы сидите за клавиатурой. Запланированные резервные копии за ней не сидят, и самопродление существует именно ради этого случая.

Запланированная резервная копия проверяется по строгому уровню, поэтому ей нужна не истёкшая лицензия. Лицензия форка ограничена 7 днями. Ваши машины по замыслу не хранят учётных данных аккаунта, поэтому до появления самопродления резервная копия форка просто переставала делаться через неделю после его создания, тихо, в три часа ночи.

Как машина продлевает лицензию, не имея токена

Каждая лицензия, которую Rediacc выпускает или продлевает, несёт renewalUrl - полный адрес эндпоинта продления на подписавшем её сервере аккаунтов. Машина читает этот адрес из собственной установленной лицензии, поэтому ей никогда не надо объяснять, где находится её сервер аккаунтов.

Затем машина предъявляет этому эндпоинту свою установленную лицензию. Лицензия сама является удостоверением: она подписана, сервер проверяет эту подпись, и никакого API-токена нигде не участвует. Сервер возвращает свежую лицензию с новыми окнами валидности, а машина устанавливает её и заново проверяет, прежде чем считать продление завершённым.

Продление выполняется сразу для всей машины:

sudo renet license renew

Репозитории группируются по подписавшему их серверу, поэтому машина, обслуживающая две учётные вселенные, обращается к каждой по одному разу. Файл блокировки не даёт двум продлениям идти одновременно, а --jitter разводит по времени парк машин, которые иначе проснулись бы все ровно в начале часа.

Сервер отказывает в продлении в трёх случаях, и каждый означает разное:

Отказ	Что это значит
Подписка закончилась, приостановлена или её льготный период истёк	Вопрос оплаты. Продление возобновится само, как только подписка снова станет активной
Сертификат делегирования истёк или отозван	Вопрос локальной установки. Продлите сертификат на своём on-premise сервере, после чего машины продлятся нормально
Идентичность машины больше не совпадает, а 40-дневная отсрочка истекла	Лицензия принадлежит другой машине. Переиздайте её из контекста текущей машины

Отказ никогда не останавливает весь прогон. Один просроченный репозиторий не мешает продлить остальные на той же машине.

Запланированные резервные копии продлеваются сами

Каждый юнит резервного копирования, который создаёт Rediacc, сначала запускает продление:

ExecStartPre=-<renet> license renew --jitter 45s

Ведущий - намеренно помечает шаг как выполняемый по возможности. Отказ в продлении, сбой сети или более старый Renet Agent, ещё не знающий этой команды, никогда не должны валить саму резервную копию. Резервная копия делается, а лицензия продлевается по пути, когда это удаётся.

Когда резервное копирование заблокировано

Если лицензирование всё же отказывает в резервном копировании, машина это запоминает. Такая отметка является единственным сигналом, что автоматические резервные копии перестали копировать данные, поэтому её показывают громко:

rdc machine status <machine> --licenses

В колонке backups появляется BLOCKED с причиной, и та же информация печатается под таблицей как ошибка, чтобы не потеряться среди тридцати репозиториев. Колонка renewed показывает, чем закончилось последнее автоматическое продление, включая код отказа сервера, если он был, и именно это подсказывает, вопрос ли это оплаты или сертификата локальной установки.

Успешное продление снимает отметку, и то же делает резервная копия, прошедшая проверку лицензии. Ничего подтверждать или сбрасывать вручную не нужно.

Автономное поведение и истечение

Проверка лицензии происходит локально на машине. Вам не нужно обращаться к серверу account для управления своими репозиториями.

Это означает:

• работающая среда не требует активного подключения к account на каждую команду
• все репозитории всегда могут запускаться, останавливаться и удаляться даже с истекшими лицензиями, пользователи никогда не блокируются из-за невозможности управлять своими собственными репозиториями
• операции подготовки (create, fork) требуют предварительно выпущенной лицензии репозитория, а операции расширения (resize, expand) требуют действительной лицензии репозитория
• действительно истекшие лицензии репозиториев перед изменением размера/расширением должны быть заменены, либо через rdc с вашей рабочей станции, либо самой машиной, которая продлевает их сама
• подписи лицензий проверяются против встроенного открытого ключа, проверку подписей невозможно отключить

Поведение восстановления

Автоматическое восстановление намеренно узко:

• missing: rdc может авторизовать доступ к account, если необходимо, массовое обновление лицензий репозиториев и повторить один раз
• expired: rdc может массовое обновление лицензий репозиториев и повторить один раз
• machine_mismatch: быстрый отказ и указание на переиздание из текущего контекста машины
• repository_mismatch: быстрый отказ и указание на явное обновление лицензий репозиториев
• sequence_regression: быстрый отказ как проблема целостности/состояния лицензии репозитория
• invalid_signature: быстрый отказ как проблема целостности/состояния лицензии репозитория
• identity_mismatch: быстрый отказ, идентичность репозитория не совпадает с установленной лицензией
• cert_expired: быстрый отказ при операциях роста (create, fork, resize) и при передаче резервных копий (push, pull); repo up и автозапуск продолжают работать, что соответствует модели мягкого истечения срока действия лицензии. Продлите делегированный сертификат
• cert_invalid: быстрый отказ, делегированный сертификат не прошёл проверку ограничения (недействительная подпись мастер-ключа, несоответствие подписки/плана, превышение предельного размера или последовательность выше maxTotalIssuances). Переиздайте сертификат после устранения соответствующего ограничения

Эти случаи быстрого отказа не автоматически потребляют вызовы обновления или выпуска на основе account.

Два замечания о том, как читать этот список:

• missing не всегда означает проблему. Это ещё и нормальный результат при первом обращении к репозиторию внутри только что форкнутого хранилища данных, и именно он заставляет такой форк тарифицироваться: лицензия выпускается, слот занимается, операция продолжается. identity_mismatch является намеренной противоположностью, чтобы файл лицензии, скопированный из другого хранилища данных, быстро отказывал, а не переиздавался втихую.
• Этот список описывает восстановление с вашей рабочей станции. У машины, которая продлевает лицензии сама, свои исходы, и сообщает о них rdc machine status <machine> --licenses, а не ошибка команды, потому что у запланированной резервной копии нет никого, кому можно пожаловаться.

Сертификаты делегирования для локальной установки

Для локальных и воздухонепроницаемых развёртываний это становится сложнее. Сервер account upstream выпускает сертификат делегирования, который авторизует вашу локальную установку подписывать лицензии своим собственным ключом Ed25519. Это ограничивает вас лимитами вашего плана и создаёт цепь, защищённую от подделок.

Ключевые моменты для владельцев подписки:

• Один активный сертификат на подписку. Каждая локальная установка проверяет квоты за месяц и за машину против своего собственного локального реестра, поэтому несколько установок многократно увеличили бы эффективную квоту без возможного примирения. Клиентам, нуждающимся в production + staging + DR, необходимо приобрести одну подписку на установку.
• Валидность на основе уровня (15d / 60d / 90d / 120d) и потолки (30d / 120d / 180d / 365d) - см. таблицу ограничений выше.
• Самообслуживание с портала клиента. Владельцы org и администраторы могут создавать, обновлять и отзывать сертификаты делегирования в /account/delegation-certs. Страница видна всем клиентам независимо от уровня плана - различаются только ограничения.
• Автоматическое обновление поддерживается через одноклассное начальное выполнение, которое выпускает токен API с областью delegation:renew для локальной установки, чтобы использовать для вызовов обновления upstream.
• Автономное обновление поддерживается через подписанный манифест запроса на обновление, который администратор локальной установки загружает, передаёт офлайн на upstream, а upstream обрабатывает для выпуска нового сертификата.

Об эксплуатационной настройке см. Локальная установка - Лицензирование изолированных развёртываний, а о криптографическом дизайне см. Цепочка лицензий и делегирование.

Месячные выпуски лицензий репозиториев

Эта метрика подсчитывает успешные выпуски лицензий репозиториев на основе account в текущем календарном месяце UTC.

Она включает:

• первый выпуск лицензии репозитория
• успешное обновление лицензии репозитория, которое возвращает вновь подписанную лицензию

Она не включает:

• неизменённые записи пакета
• неудачные попытки выпуска
• неотслеживаемые репозитории, отклонённые перед выпуском

Если вам нужен обращённый к клиенту вид использования и недавнюю историю выпусков лицензий репозиториев, используйте портал account. Если вам нужна проверка на стороне машины, используйте rdc subscription status -m и rdc subscription status -m.