限制与配额
Rediacc 部署限制。三个限制是硬性的,无法通过添加硬件更改:每个仓库的 61 个服务上限(网络地址空间分配)、Linux 6.1 最低内核版本要求(CRIU 需求),以及 Let’s Encrypt 每个注册域名每周 50 个通配符证书的签发上限。其他所有限制都是软性的:增加硬件时这些限制会改变。在规划拓扑前,请了解两者的区别。
每个仓库的服务数
每个仓库支持同时运行最多 61 个服务。
这是由分配给每个仓库的网络地址空间决定的硬性限制。每个服务都获得自己的专用私有 IP 地址,每个仓库的地址块恰好容纳 61 个服务槽位。
注意:在单个仓库中达到 61 个服务通常表示架构设计问题,而不是 Rediacc 的限制。解决方案是将辅助容器和监控代理迁移到具有独立隔离边界的单独仓库中,或减少应用程序本身中独立运行的进程数量。
每台机器的仓库数
Rediacc 没有强制的硬性上限。实际限制取决于您机器的资源:
| 资源 | 影响 |
|---|---|
| 磁盘空间 | 每个仓库都是加密的磁盘镜像。拥有 1 TB 可用存储的机器可以容纳许多仓库,但所有镜像的总大小必须在数据存储池范围内。 |
| 内存 | 每个运行中的仓库都会启动自己的 Docker daemon 和容器。内存使用取决于您的工作负载。 |
| CPU | 并行仓库操作(启动、备份、分支)会增加临时 CPU 负载。 |
典型部署在每台机器上运行 10 到 50 个仓库,不会出现问题。拥有 32 GB 以上内存和 500 GB 以上存储的机器通常可以运行 100 个以上的仓库。
系统范围的网络 ID 限制
每个仓库被分配一个唯一的网络 ID(用于计算其私有 IP 地址范围的数字)。此池在同一 Rediacc 配置管理的所有机器和仓库之间共享。
| 限制 | 值 |
|---|---|
| 可用网络 ID 总数 | ~261,944 |
| 范围 | 每个配置(在配置中的所有机器之间共享) |
删除仓库时,其网络 ID 被释放并可供重新使用。Rediacc 按顺序分配 ID,仅在前向计数器接近上限时才扫描已释放的间隙。实际上,此限制永远不会达到。这需要在单个配置的生命周期内创建和跟踪数十万个仓库。
分支
仓库的活跃分支数量没有限制。每个分支都是一个完整的写时复制克隆,拥有自己的加密存储、网络地址和 Docker daemon。分支消耗的磁盘空间与创建后写入的数据成正比(而非父仓库的完整大小)。
外部端口
始终活跃的端口
只有在使用 rdc config infra set --public-ipv4 配置公共 IP 后,端口才会打开。在此之前,机器上没有开放的端口。配置后:
| 端口 | 协议 | 用途 |
|---|---|---|
| 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
除非有特定需求,否则切勿将数据库或缓存端口暴露到外部。使用 HTTPS 自动路由为 Web 服务提供访问,并将存储服务保持在内部。
数据存储
数据存储是在首次设置机器时创建的固定大小池。其大小不会自动增长。
- 最小推荐大小:50 GB
- 最大大小:受限于您的磁盘。单个池可以跨越整个磁盘。
- 调整大小:使用
rdc datastore resize更改存储池大小(所有仓库必须先卸载)。 - 文件系统:Rediacc 内部使用 BTRFS 实现写时复制快照和高效分支。需要运行 Linux 6.1 或更高版本内核的机器以获得完整的生产稳定性。
每个仓库在创建时设有最大容量上限(默认:10 GB)。使用 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 个以上新仓库的部署将达到此上限。
分支重用父仓库现有的通配符证书,不消耗任何证书配额。
检查点/恢复 (CRIU)
通过 CRIU 进行实时迁移有以下约束:
- 可选启用:仅对带有
rediacc.checkpoint=true标签的容器创建检查点。数据库和无状态服务默认排除,在恢复时重新启动。 - 内核要求:源机器和目标机器都需要 Linux 6.1 或更高版本。
- 网络模式:CRIU 要求主机网络模式。使用自定义网络配置的容器无法创建检查点。
- 内存:检查点数据大小等于被检查点进程的驻留内存。大型内存数据集(例如,缓存 4 GB 数据的 Node.js 应用程序)会产生 4 GB 的检查点文件。
- TCP 连接:应用程序必须能够容忍恢复过程中的连接丢失。活跃的 TCP 连接不会被保留,恢复后的进程会看到套接字处于关闭状态,必须重新连接。这同时适用于同机恢复和跨机恢复两种路径。
- 同机热 fork 会重定向父仓库地址:在父仓库持续运行时,先执行
rdc repo fork --parent X --tag Y --checkpoint再执行rdc repo up即可正常工作。恢复出的进程仍带着 checkpoint 时刻父仓库的 loopback 地址,系统会将其透明地重定向到 fork 自己的地址(同一服务,fork 的数据副本)。恢复的 TCP 连接首次使用时仍会失败,应用需要重连,见上文 TCP 条目。
备份
| 限制 | 值 |
|---|---|
| 每个仓库的备份目标 | 无限制 |
| 同时备份任务 | 每个仓库 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
| 限制 | 值 |
|---|---|
对同一机器的并发 rdc 命令 | 无限制(每个命令打开自己的 SSH 连接) |
| 默认并行仓库启动并发数 | 3(可通过 --concurrency 调整) |
| SSH 连接超时 | 初始连接 30 秒 |
rdc 会话持续时间 | 无超时;长时间运行的操作保持连接活跃 |
支持的操作系统版本
远程机器必须运行以下操作系统之一,以满足 Rediacc 的内核、文件系统和网络隔离要求。此列表是经过 CI 测试的权威集合(Bridge Workers 矩阵),必须与要求保持同步:
| 操作系统 | 最低版本 | 默认内核 | 备注 |
|---|---|---|---|
| Ubuntu | 24.04 LTS (推荐) | 6.8 | AppArmor 默认。 |
| Debian | 13 (Trixie);12 Bookworm 也可使用 | 6.12(Debian 12 上为 6.1) | |
| 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 进行加密仓库存储和写时复制分支。Linux 6.1 引入了关键的 BTRFS 改进,显著减少了大型数据存储的挂载时间,提高了快照删除性能,并修复了早期内核中存在的数据完整性问题。内核 6.1 还需要支持内核级网络隔离钩子,这些钩子在仓库之间强制执行隔离,透明地重写
bind()调用并阻止仓库之间的连接。
为什么不是 Rocky Linux 10 / RHEL 10 原厂内核? RHEL 10 的原厂内核不包含
btrfs模块(modprobe btrfs失败,提示 “Module btrfs not found”)。Rediacc 的加密存储后端没有 btrfs 无法运行。Oracle Linux 10 是支持列表中唯一的 RHEL 兼容目标,因为它默认使用保留了 btrfs 的 Unbreakable Enterprise Kernel(UEK)。完整说明请参阅要求:为什么选择 UEK?。
内核功能矩阵
该矩阵提供每个经 CI 测试的操作系统在开箱即用情况下所提供功能的一览视图。五个系统均满足所有要求,因此这是面向运营人员的参考信息,而非门控标准。
| 操作系统 | btrfs 模块 | cgroups v2 | Landlock (ABI >= 1) | eBPF cgroup 钩子 |
|---|---|---|---|---|
| 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 | 是 | 是 |