Ограничения и квоты

Ограничения развертывания Rediacc. Три из них жесткие и не могут быть изменены добавлением оборудования: лимит в 61 сервис на репозиторий (выделение адресного пространства сети), минимум ядра 6.1 (требования CRIU) и лимит выпуска Let’s Encrypt в 50 подстановочных сертификатов на зарегистрированный домен в неделю. Все остальное мягкое: оно изменяется при добавлении оборудования. Знайте разницу перед тем, как принять решение о топологии.

---

Сервисы на репозиторий

Каждый репозиторий поддерживает до 61 сервиса, работающих одновременно.

Это жесткий лимит, определяемый адресным пространством, выделенным для каждого репозитория. Каждый сервис получает собственный выделенный частный IP-адрес, и блок адресов каждого репозитория вмещает ровно 61 слот сервиса.

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

---

Репозитории на машину

Rediacc не устанавливает жестких ограничений. Практический лимит зависит от ресурсов вашей машины:

Resource	Impact
Дисковое пространство	Каждый репозиторий это зашифрованный образ диска. Машина с 1 ТБ полезного хранилища может содержать много репозиториев, но общий размер всех образов должен соответствовать размеру пула хранилища данных.
ОЗУ	Каждый работающий репозиторий запускает собственный демон Docker и контейнеры. Использование памяти зависит от ваших рабочих нагрузок.
CPU	Параллельные операции с репозиториями (запуск, резервная копия, fork) добавляют временную нагрузку на CPU.

Типичные развертывания работают с 10-50 репозиториями на машину без проблем. Машины с 32 ГБ+ ОЗУ и 500 ГБ+ хранилища регулярно работают с 100+ репозиториями.

Лимит сетевого ID на уровне системы

Каждому репозиторию присваивается уникальный сетевой ID, число, используемое для расчета его диапазона частных IP-адресов. Этот пул является общим для всех машин и репозиториев, управляемых одной конфигурацией Rediacc.

Limit	Value
Всего доступных сетевых ID	~261 944
Область	На конфигурацию (общее для всех машин в конфигурации)

Когда репозиторий удаляется, его сетевой ID освобождается и становится доступным для повторного использования. Rediacc выделяет ID последовательно и только сканирует освобожденные пробелы, когда счетчик приближается к потолку. На практике вы никогда этого не достигнете. Мы никогда не видели этого. Исчерпание пула потребовало бы создания и отслеживания сотен тысяч репозиториев под одной конфигурацией.

---

Форки

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

---

Внешние порты

Всегда активные порты

Порты открываются только после настройки публичного IP с помощью rdc machine infra set <machine> --public-ipv4. До этого момента машина не имеет открытых портов. После настройки:

Port	Protocol	Purpose
80	TCP	HTTP: обрабатывается Traefik; возвращает 404 для неконфигурированных доменов, не передается никаким сервисам
443	TCP	HTTPS: то же самое выше; запросы без совпадающего маршрута отклоняются на уровне прокси
10000–10010	TCP	Динамический диапазон для управляемой Rediacc переадресации TCP

HTTP/HTTPS отличаются от обычных TCP-портов: хотя порты 80 и 443 открыты, каждый запрос проверяется обратным прокси по отношению к явной таблице маршрутизации. Без настроенного сервиса и совпадающего домена код приложения не достигается и никакие данные не открываются.

Дополнительная переадресация TCP/UDP

Все остальные порты (базы данных, кэши, брокеры сообщений, DNS, почта) закрыты по умолчанию и должны быть явно открыты. Это минимизирует поверхность атаки машины.

Чтобы открыть порт из конкретного сервиса:

labels:
  - "rediacc.tcp_ports=5432"   # expose PostgreSQL from this container
  - "rediacc.udp_ports=53"     # expose DNS from this container

Чтобы открыть порт на уровне машины (доступно всем сервисам):

rdc machine infra set server-1 --tcp-ports 25,587,993   # mail server
rdc machine infra push server-1

Никогда не открывайте порты базы данных или кэша снаружи, если у вас нет особых требований. Используйте автоматические HTTPS-маршруты для веб-сервисов и держите сервисы хранилища внутри.

---

Хранилище данных

Хранилище данных это пул фиксированного размера, создаваемый при первой настройке машины. Его размер не растет автоматически.

• Минимальный рекомендуемый размер: 50 ГБ
• Максимальный размер: ограничен размером вашего диска. Один пул может занимать весь диск.
• Изменение размера: используйте rdc datastore resize для изменения размера пула (все репозитории должны быть предварительно размонтированы).
• Файловая система: Rediacc внутренне использует BTRFS для снимков копирования при записи и эффективного forking. Требует машины с ядром Linux 6.1 или позже для полной производственной стабильности.

Каждый репозиторий имеет максимальный размер, установленный при создании (по умолчанию: 10 ГБ). Используйте rdc repo resize для изменения вручную или задайте политику автоматического размера, чтобы машина автоматически увеличивала его при заполнении (ограничено явным потолком на уровне репозитория и резервом свободного пространства в пуле). Автоувеличение применяется только к отдельным репозиториям; сам пул никогда не увеличивается автоматически.

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

---

Маршруты HTTP

Каждый сервис с меткой rediacc.service_port автоматически получает один маршрут HTTPS. Нет ограничения на количество сервисов с маршрутами, при условии максимума 61 сервис на репозиторий.

Подстановочные TLS сертификаты выделяются на репозиторий при первом развертывании через Let’s Encrypt (вызов Cloudflare DNS-01). Let’s Encrypt ограничивает выпуск 50 сертификатами на зарегистрированный домен в неделю. Поскольку Rediacc использует один подстановочный сертификат на репозиторий (а не на сервис), развертывание, которое создает 50+ новых репозиториев за одну неделю, достигнет этого лимита.

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

---

Checkpoint / Restore (CRIU)

Живая миграция через CRIU имеет следующие ограничения:

• По выбору: Только контейнеры с меткой rediacc.checkpoint=true создают контрольные точки. Базы данных и stateless сервисы исключены по умолчанию и начинаются заново при восстановлении.
• Требование к ядру: Linux 6.1+ на исходной и целевой машинах.
• Сетевой режим: CRIU требует режима сетевого хоста. Контейнеры с пользовательскими конфигурациями сети не могут быть checkpointed.
• Память: размер данных контрольной точки равен резидентной памяти процесса с контрольной точкой. Большие наборы данных в памяти (например, приложение Node.js, кэширующее 4 ГБ данных) производят файлы контрольной точки размером 4 ГБ.
• TCP соединения: приложения должны переносить потерю соединения при восстановлении. Активные TCP соединения не сохраняются. Восстановленный процесс видит сокеты как закрытые и должен переподключиться. Это относится как к восстановлению на одной машине, так и к восстановлению между машинами.
• Живой форк на той же машине перенаправляет адреса родителя: rdc repo fork X --tag Y --checkpoint с последующим rdc repo up работает, пока родительский репозиторий продолжает работать. Восстановленные процессы несут loopback-адреса родителя на момент чекпоинта, поэтому система прозрачно перенаправляет их на собственные адреса форка (тот же сервис, копия данных форка). Первое использование восстановленного TCP-соединения по-прежнему завершается ошибкой, и приложение должно переподключиться, см. пункт о TCP выше.

---

Резервные копии

Лимит	Значение
Снимков на репозиторий	Без ограничений, кроме вашей квоты хранилища. Каждый снимок восстанавливается независимо, поэтому хранение большего их числа стоит только места в хранилище, и больше ничего
Одновременные снимки одного репозитория	1. Второй запуск обнаруживает, что блокировка подготовки репозитория уже удерживается, и пропускается, а не ставится в очередь: он сообщает, что блокировку держит другой запуск, и завершается. Запустите снова позже
Одновременные холодные снимки	1 на хранилище данных; второй renet backup snapshot --cold отклоняется сразу и ничего не останавливает
Частота резервного копирования	Минимальный интервал не установлен; ограничен пропускной способностью вашего хранилища. Используйте rdc backup strategy set <name> --bwlimit "6M" для ограничения скорости загрузки
Хранение	Задаётся с помощью rdc backup retention set (--keep-last, --keep-hourly, --keep-daily, --keep-weekly, --keep-monthly, --keep-yearly) и применяется на стороне сервера; rdc backup retention clear удаляет политику, после чего сохраняются все снимки
Резервное копирование между машинами	Поддерживается; целевая машина должна иметь достаточно места в хранилище данных

Квота на хранилище резервных копий

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

План	Квота	Как показывает rdc backup usage
Community	10 ГБ	10G
Professional	100 ГБ	100G
Business	500 ГБ	500G
Enterprise	2 ТБ	2T

Это значения по умолчанию для плана. У подписки может быть собственное переопределение, поэтому проверяйте rdc backup usage, а не полагайтесь на строку выше.

Квота применяется до того, как данные начинают перемещаться: снимок, который превысил бы её, отклоняется в момент, когда машина запрашивает разрешение на загрузку, а не в середине передачи. Попадание точно в квоту разрешено; превышение на один байт отклоняется. В учтённый объём входят и загрузки, ещё выполняющиеся в данный момент, поэтому два одновременных запуска не могут оба протиснуться под лимит.

Превышение квоты никогда ничего не удаляет. Оно останавливает новые загрузки, а снимки, которые у вас уже есть, остаются на месте.

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

Копии между машинами, сделанные с помощью rdc repo push, не затрагивают эту квоту. Они попадают в хранилище данных целевой машины и ограничены его свободным местом.

---

CLI и API

Limit	Value
Одновременные команды rdc против одной машины	Неограниченно (каждая команда открывает собственное SSH соединение)
Параллелизм запуска репозиториев по умолчанию	3 (регулируемо с помощью --concurrency)
Таймаут SSH соединения	30 секунд для первоначального соединения
Продолжительность сеанса rdc	Нет таймаута; долгоживущие операции поддерживают соединение активным

---

Поддерживаемые версии ОС

Удаленные машины должны работать под одной из следующих систем, чтобы соответствовать требованиям Rediacc по ядру, файловой системе и сетевой изоляции. Этот список это авторитетный набор, протестированный CI (матрица Bridge Workers), и должен быть синхронизирован с Requirements:

OS	Minimum Version	Default Kernel	Notes
Ubuntu	24.04 LTS (рекомендуется)	6.8	AppArmor по умолчанию.
Debian	13 (Trixie); 12 Bookworm тоже работает	6.12 (6.1 на Debian 12)
Fedora	43	6.12	SELinux enforcing по умолчанию.
openSUSE Leap	16.0	6.4+	AppArmor по умолчанию.
Oracle Linux	10 (UEK)	UEK 7+	UEK сохраняет btrfs; SELinux enforcing по умолчанию.

Минимальное требуемое ядро: 6.1. Машины с более старыми ядрами отклоняются при установке с четким сообщением об ошибке.

Почему ядро 6.1? Rediacc использует BTRFS для зашифрованного хранилища репозиториев и forking копирования при записи. Linux 6.1 введен критические улучшения BTRFS, которые значительно сокращают время монтирования больших хранилищ данных, улучшают производительность удаления снимков и исправляют проблемы целостности данных, присутствующие в более ранних ядрах. Ядро 6.1 также требуется для hooks изоляции сети на уровне ядра, которые обеспечивают изоляцию между репозиториями, прозрачно переписывая вызовы bind() и блокируя соединения между репозиториями.

Почему не Rocky Linux 10 / RHEL 10 стандартное ядро? Стандартное ядро RHEL 10 поставляется без модуля btrfs (modprobe btrfs не удается с сообщением “Module btrfs not found”). Зашифрованный backend хранилища Rediacc не может работать без btrfs. Oracle Linux 10 это единственная цель, совместимая с RHEL, в поддерживаемом списке, потому что она по умолчанию использует Unbreakable Enterprise Kernel (UEK), который сохраняет btrfs. См. Requirements → Why UEK? для полного объяснения.

Матрица функций ядра

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

OS	btrfs module	cgroups v2	Landlock (ABI ≥ 1)	eBPF cgroup hooks
Ubuntu 24.04	встроено	unified hierarchy	да (5.13+)	да
Debian 13	встроено	unified hierarchy	да	да
Fedora 43	встроено	unified hierarchy	да	да
openSUSE Leap 16.0	встроено	unified hierarchy	да	да
Oracle Linux 10 (UEK)	встроено (через UEK)	unified hierarchy	да	да