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

Ограничения развертывания 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 config infra set --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 config infra set -m server-1 --tcp-ports 25,587,993   # mail server
rdc config infra push -m server-1

Справочник CLI: rdc config infra set · rdc config infra push

Никогда не открывайте порты базы данных или кэша снаружи, если у вас нет особых требований. Используйте автоматические 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 --parent X --tag Y --checkpoint с последующим rdc repo up работает, пока родительский репозиторий продолжает работать. Восстановленные процессы несут loopback-адреса родителя на момент чекпоинта, поэтому система прозрачно перенаправляет их на собственные адреса форка (тот же сервис, копия данных форка). Первое использование восстановленного TCP-соединения по-прежнему завершается ошибкой, и приложение должно переподключиться, см. пункт о TCP выше.

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

Limit	Value
Пункты назначения резервной копии на репозиторий	Неограниченно
Одновременные задачи резервного копирования	1 на репозиторий (задачи ставятся в очередь при одновременном запуске)
Частота резервного копирования	Минимальный интервал не установлен; ограничен пропускной способностью вашего хранилища. Используйте `rdc config backup-strategy set --name <name> --bwlimit "6M"` для ограничения скорости загрузки (синтаксис rclone `--bwlimit`: простой `6M`, направленный `6M:off` или расписание `08:00,3M;22:00,10M`)
Хранение	Контролируется вашим поставщиком хранилища (S3, Cloudflare R2 и т. д.). Rediacc не устанавливает политик хранения.
Резервное копирование между машинами	Поддерживается; целевая машина должна иметь достаточно места в хранилище данных

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	да	да