Separate storage shard meshes and unify Endor backup topology
Verify and deploy Tabularium / verify-and-deploy (push) Has been cancelled
Verify and deploy Tabularium / verify-and-deploy (push) Has been cancelled
This commit is contained in:
@@ -1,46 +1,50 @@
|
||||
# 理解 Endor：从全球入口到对象数据
|
||||
|
||||
Endor 的概念模型把全球访问、区域运行时和对象数据连接起来：请求从统一入口进入，在合适的区域找到 Nexus Runtime，再由它承载的 Aster VM 执行对象操作。数据以分片组织，在区域内保持高可用，并为每个分片安排跨区域恢复目标。
|
||||
Endor 的概念模型把全球访问、区域运行时和对象数据连接起来：请求从统一入口进入，在合适的区域找到 Nexus Runtime，再由它承载的 Aster VM 执行对象操作。PostgreSQL、Aerarium 和 S3 各自维护独立的分片群，在区域内保持高可用，并由统一备份系统追踪所有区域、所有存储类型的分片与恢复材料。
|
||||
|
||||
> **概念设计草案**：本文按当前讨论绘制目标架构，不表示这些组件和协议已经全部实现。图中的区域、节点、分片数量仅为示例；CDN 和身份服务的接入方式是建议方案。
|
||||
|
||||
## 架构总览
|
||||
|
||||
|
||||
|
||||
|
||||
图中绿色/蓝色实线表示请求路径或区域内数据依赖，紫色虚线表示身份控制与公钥分发，蓝色点线表示 CDN 回源，金色虚线表示跨区复制和备份。连线表示可达或依赖关系，**不表示请求向所有节点广播**。
|
||||
|
||||
图的编排由 Python 生成 SVG：节点图标、二分全连接和复制线路都能复现和编辑。Python 更适合这张静态架构图；页面查看、缩放与下载由 TypeScript/React 负责。
|
||||
图中绿色/蓝色实线表示请求路径或区域内数据依赖，紫色虚线表示身份控制与公钥分发，蓝色点线表示 CDN 回源，金色虚线表示向统一备份系统采集数据。连线表示可达或依赖关系，**不表示请求向所有节点广播**。
|
||||
|
||||
## 全球入口与区域入口
|
||||
|
||||
客户端包括浏览器、Tessera、SDK 和 CLI。`endorphin API` 是逻辑上的全球流量入口，尚未在本文规定一个真实的域名。全球调度根据健康、延迟、项目归属和数据放置策略选择区域；不能只选择网络最近的区域而忽略对象在哪个分片。
|
||||
|
||||
示例使用北美和亚洲两个区域。每个区域有自己的负载均衡入口，下面是 Traefik 网关，负责按配置进行 TLS、主机名或路径路由。图中的第二个 Traefik 标记为 **HA 副本**：多副本是生产冗余选项，单实例概念部署不要求两个网关。
|
||||
图中展开北美和亚洲两个区域，并用“ … / etc · 其他区域”表示可以继续扩展。每个区域有自己的负载均衡入口，下面是 Traefik 网关，负责按配置进行 TLS、主机名或路径路由。图中的第二个 Traefik 标记为 **HA 副本**：多副本是生产冗余选项，单实例概念部署不要求两个网关。
|
||||
|
||||
### 为什么画成二分全连接
|
||||
|
||||
每个区域示例中有两个 Traefik 和三个 Nexus Runtime，画出全部六条边，即二分图 **K₂,₃**。每个网关都能把请求路由到任意一个符合条件的健康 Runtime，避免把一个网关固定绑定到一个运行时。
|
||||
每个区域示例中有两个 Traefik 和五个 Nexus Runtime，画出全部十条边，即二分图 **K₂,₅**。网关使用独立的路由分流图标，与 Nexus 的服务器图标区分。每个网关都能把请求路由到任意一个符合条件的健康 Runtime，避免把一个网关固定绑定到一个运行时。
|
||||
|
||||
这是逻辑可达关系。实际转发仍需考虑服务发现、健康检查、项目和对象归属，以及有状态连接的路由策略；Runtime 之间并没有因此形成全连接网状网络。
|
||||
|
||||
## Nexus Runtime 与 Aster VM
|
||||
|
||||
此处采用 **一个 Nexus Runtime 节点配一个 Aster VM** 的概念约定。Nexus 表示对外接入与运行时承载边界，Aster VM 执行对象相关逻辑。图中每台服务器下面都单独画出一个 VM 芯片，避免把多个 VM 误读成另一个共享池。
|
||||
此处采用 **一个 Nexus Runtime 节点配一个 Aster VM** 的概念约定。Nexus 表示对外接入与运行时承载边界，Aster VM 执行对象相关逻辑。图中每台服务器侧下方单独画出一个 VM 芯片，用点线连接到对应 Nexus；节点与 VM 采用错位排布，保持一对一归属。
|
||||
|
||||
请求经过区域入口和 Traefik 到达 Nexus，再定位目标分片。图中运行时下方的连接汇入分片路由层，表示节点可以按归属访问区域分片，**不是**「Runtime 1 只能访问分片 1」。对象身份、远程引用、生命周期与调用语义仍需结合[节点与对象挂载草案](/docs/02-mounting-draft)继续定义。
|
||||
|
||||
## 三类存储如何组成一个分片
|
||||
## 三类存储各自独立分片
|
||||
|
||||
示例中每个区域都有两个逻辑数据分片。每个分片展示三个协作部分，它们是逻辑数据边界，不要求一分片对应三台独占物理机器。
|
||||
PostgreSQL、Aerarium Object data pool 和 S3 是三组独立的分片群。图中每组各展开三个分片，数量可以独立增长，分片边界也可以不同；不能将一个 PG 分片、一个 Aerarium 分片和一个 S3 分片打包成固定“三件套”。
|
||||
|
||||
| 部分 | 概念职责 | 依赖关系 |
|
||||
| ------------------------- | ------------------------------------------------------------ | ------------------------- |
|
||||
| PostgreSQL | 结构化元数据、对象索引及需要事务约束的状态；具体数据模型待定 | 提供关系数据与事务能力 |
|
||||
| Aerarium Object data pool | 对象数据的逻辑组织与访问层；不是把 S3 换一个名字 | 同时依赖 PostgreSQL 与 S3 |
|
||||
| S3 兼容存储 | Blob、文件、快照和适合对象存储的数据；具体格式待定 | 提供对象持久化能力 |
|
||||
| 分片群 | 概念职责 | 分片标识示例 |
|
||||
| ------------------------- | ------------------------------------------------------------ | ---------------------------- |
|
||||
| PostgreSQL | 结构化元数据、对象索引及需要事务约束的状态；具体数据模型待定 | NA-PG-01、NA-PG-02、NA-PG-03 |
|
||||
| Aerarium Object data pool | 对象数据的逻辑组织、对象池状态和访问层；同时依赖 PG 与 S3 | NA-AO-01、NA-AO-02、NA-AO-03 |
|
||||
| S3 兼容存储 | Blob、文件、快照和适合对象存储的数据；具体格式待定 | NA-S3-01、NA-S3-02、NA-S3-03 |
|
||||
|
||||
图中 Aerarium 向左右各画一条依赖箭头，分别连接 PostgreSQL 和 S3。它们**不是**三个互不相关的平行数据池。
|
||||
### 分片群之间的全连接
|
||||
|
||||
每个 Aerarium 分片都能按映射访问任意一个 PostgreSQL 分片，也能访问任意一个 S3 分片。图中左右各画一组 **K₃,₃**：Aerarium ↔ PostgreSQL 有九条边，Aerarium ↔ S3 也有九条边；每区合计十八条存储关系边。
|
||||
|
||||
这些线表示逻辑可达关系，实际读写仍根据对象归属、分片映射、授权与健康状态选择目标。它们不表示广播，也不表示所有分片保存相同数据。PostgreSQL 和 S3 之间没有凭空增加直接全连接；两种存储通过 Aerarium 的对象模型与版本映射协作。
|
||||
|
||||
运行时访问先进入对象池的分片定位层，再由 Aerarium 按映射访问 PG 和 S3。因此不同层可以采用不同的分片数量和容量规划，而无需一一绑定。
|
||||
|
||||
### 区域内高可用
|
||||
|
||||
@@ -48,16 +52,23 @@ Endor 的概念模型把全球访问、区域运行时和对象数据连接起
|
||||
|
||||
这是逻辑 HA 要求，各层的实现不同：PostgreSQL 可以使用主备复制，Aerarium 需要自己的状态协调和故障恢复设计，S3 的耐久性与副本由选定的存储系统提供。图不强制三者采用同一种同步复制机制，也不把单纯增加副本等同于已经实现故障自动切换。
|
||||
|
||||
## 每个分片都要有跨区恢复目标
|
||||
## 一个统一的备份系统
|
||||
|
||||
区域内副本解决本地节点或故障域失效；跨区备份解决整个区域不可用。四个源分片均有独立的异地目标：
|
||||
备份是覆盖所有区域的总体系统，不按“北美备份亚洲、亚洲备份北美”分成两个固定系统。它统一编排各区域、各存储类型的备份采集、持久化、校验、保留与恢复。物理副本应隔离源区域的故障风险，实际存放位置由备份策略决定；图中不将该系统固定放进任何业务区域。
|
||||
|
||||
| 源分片 | 异地备份位置 | 覆盖内容 |
|
||||
| ------------ | ------------ | -------------------------------------------- |
|
||||
| NA-01、NA-02 | 亚洲区域 | 各分片的 PostgreSQL、Aerarium 状态和 S3 数据 |
|
||||
| AS-01、AS-02 | 北美区域 | 各分片的 PostgreSQL、Aerarium 状态和 S3 数据 |
|
||||
图中金色线路将每个区域的三类分片群接入同一备份边界，代表采集组内全部分片。统一恢复目录按“区域 + 存储类型 + 分片 ID”追踪每个分片，避免遗漏或将不同层的编号误当作同一个分片。
|
||||
|
||||
每个目标应保留可校验的恢复清单，将关系数据恢复点、对象池元数据版本与 S3 对象版本关联起来；不能只复制其中一种存储就宣称整个分片可恢复。图中的金色线路明确跨越区域，备份集按源分片编号标识。
|
||||
### 备份中的 PG、Aerarium、S3 分别是什么
|
||||
|
||||
| 备份内容 | 保存什么 | 恢复时的用途 |
|
||||
| --------------- | -------------------------------------------------------------------- | ------------------------------------------ |
|
||||
| PostgreSQL 备份 | 各 PG 分片的基础备份、WAL 与可恢复时间点等事务恢复材料 | 恢复结构化元数据与事务状态 |
|
||||
| Aerarium 备份 | 各对象池分片的状态、索引、对象身份和版本映射等恢复材料，具体格式待定 | 重建对象池，并关联 PG 恢复点与 S3 对象版本 |
|
||||
| S3 备份 | 各 S3 分片的实际对象版本、Blob、文件及快照 | 恢复被对象池引用的实际字节数据 |
|
||||
|
||||
这里展示的是**统一系统内三类不同的备份内容与采集能力**，不是每个备份槽里又放一套在线 PG + Aerarium + S3 服务。系统还要维护统一恢复清单、校验和、重试状态，以及各层的版本对应关系。
|
||||
|
||||
恢复某个对象或项目时，清单应能定位所需的 PG 分片恢复点、Aerarium 分片状态与 S3 对象版本。因为三类存储独立分片，恢复集合也可能涉及多个不同编号的分片；不能按固定三件套恢复，也不能只备份其中一种存储就宣称整个对象可恢复。
|
||||
|
||||
### “最终一定拿到数据”需要怎样的保证
|
||||
|
||||
|
||||
Reference in New Issue
Block a user