CubeFS助力天基智能计算打通太空计算存储链路
天基智能计算项目是指将智能计算设施部署在太空，以构建天基智能计算基础设施。
5 月 14 日 12 时 12 分，太空计算卫星星座搭载长征二号丁运载火箭在酒泉卫星发射中心成功发射，标志着我国首个整轨互联的太空计算星座正式进入组网阶段。一箭十二颗计算卫星是之江实验室主导构建的“三体计算星座”的首次发射，也是国星宇航“星算”计划的首次发射。
之江实验室“三体”计算星座项目，旨在通过全球合作伙伴共同构建千星规模的天基智能计算基础设施，解决传统卫星数据处理模式中的瓶颈问题，即“天感地算”模式——卫星收集的数据需要传回地球进行处理，这不仅受限于带宽，还导致了效率低下和信息损耗。而“三体”计算星座则致力于实现“天感天算”，实现卫星在轨数据处理功能，从而提高数据处理效率并减少信息损失。
其中，天基分布式操作系统是确保“天感天算”得以实现的关键技术之一，也是项目的重点研究子课题。它需要在千星组成的复杂系统中协调算力、存储、载荷等资源，实现在轨任务的调度以及星地星间的数据转发、存储，提供跨星数据协同、星地数据同步能力，从而保障系统的高效运行。
存储技术选型
在经过前期调研及对比选型并结合业务场景，我们选择 CubeFS 作为天基分布式操作系统的存储底座，用于管理分布在众多卫星上的数据。主要基于以下几点考虑：
- 高可用性 由于太空中存在辐射、粒子翻转等因素，单节点故障概率较高，高可用是确保系统稳定运行的关键。CubeFS 的元数据系统设计采用 Multi-Raft 协议，能够充分利用在轨算力资源保障数据的高可用性和强一致性，有效应对单点故障，并能快速恢复。
- 海量小文件处理能力 在轨应用主要是面向遥感数据、外太空信号观测数据的处理，应用在处理过程中会产生大量小文件的读写操作，CubeFS 针对这一场景进行了优化，能够高效处理大量小文件，减少存储和检索的延迟，确保数据能够快速存储和访问，提高了整体数据处理效率。
- 国产开源 选择作为 CNCF 首个毕业的国产开源存储产品的 CubeFS，不仅符合国家自主可控的战略需求，还能在技术支持和社区生态方面获得更多优势。开源模式使得项目团队能够根据实际需求进行定制和优化，同时也能从活跃的社区中获取最新的技术更新和问题解决方案。
整体架构
我们在 24 年初开始搭建 CubeFS 测试环境，模拟卫星节点的分布式存储场景，来验证 CubeFS 作为星内分布式文件系统的可行性。主要从文件读写速率、动态扩缩容、节点故障和网络故障情况下系统可用性等方面对 CubeFS 做了充分验证，最终确认 CubeFS 在功能性和性能上均满足项目需求。 之后，我们完成了星内和星间分布式文件系统的架构设计。星内架构设计基于 CubeFS，将每颗卫星作为一个独立的存储集群，利用 CubeFS 的分布式特性实现数据的高效存储和每一个存储单元的统一管理，并设计了系统管控层，负责资源分配、任务调度和数据协同。星间架构设计基于可靠网络传输协议，通过 S3 网关实现星间数据同步，确保数据在卫星网络中的一致性，并设计了断点续传机制，以应对星间星地网络的不稳定性。
星内分布式文件系统通过管控层控制管理分布式文件系统，从而实现星内分布式文件系统的核心功能。整体架构图如下图所示：
通过外部 API 接口提供业务能力，包括以下能力：
· 资源监控：提供集群、节点、进程粒度各个维度的数据监控
· 认证：验证请求合法性
· 卷管理：卷粒度管理文件系统，关联用户权限各文件系统隔离
· 挂载管理：提供节点，容器级别挂载、卸载能力
· 用户管理：提供用户创建，删除，查询能力
· 数据同步：提供星地数据同步能力，支持断点续传
· 数据迁移：支持节点间数据迁移
· 数据清理：定时数据清理，保障数据可用容量处于阈值之下
实践
在项目实施过程中，除了上述的业务功能开发外，我们也投入了大量精力对 CubeFS 的源码进行深入解析，以更好地理解其内部机制，并为实际使用中遇到的问题提供解决方案。下面简单挑两个最近的例子，介绍一下我们在实施过程中遇到的问题以及开展的工作。
存储空间管理优化
在进行大规模算法应用测试阶段，我们发现了一些与存储空间管理相关的挑战。具体表现为：在大量文件反复新增和删除的场景下，挂载目录下的文件虽然已经被逻辑删除，但存储盘中的物理空间并未及时释放。这种情况在极端情况下会导使得文件卷变为不可写状态，直接影响算法的运行和结果输出。
通过对 CubeFS 源码的深入分析，我们发现问题的根源在于：元数据与数据块的管理不一致：文件删除后，元数据层会立即更新，标记文件为已删除，但 inode 释放操作存在延迟。为此，我们开发 CubeFS 一致性检查工具：该工具会周期性地扫描文件系统的元数据和数据块，检测并清理失效文件。同时通过对比元数据和数据块的状态，识别出逻辑上已删除但物理上未释放的文件，并主动触发空间释放操作。
元数据可靠性增强
在系统容错测试阶段，我们测试模拟太空中硬件异常掉电的场景，构造了反复下电和上电的实验环境。在多次测试中，我们发现了一个偶发性问题：某些元数据块会出现 Meta partition lack replicas 的报错。具体表现为：
如果单个节点的元数据丢失，该块数据仍然处于 writable 状态，并且通常能够自动恢复。但如果两个及以上节点的元数据丢失，该块数据则会变为 unavailable 状态，且无法自动恢复，导致文件卷不可用。
通过对存储的元数据进行深入分析，我们发现有一个名为.sign 文件的内容存在缺失。进一步排查代码后发现，问题的根源在于该文件的数据先写入了缓存，但没有及时进行落盘操作，导致在异常掉电时缓存数据丢失，从而引发元数据块丢失的问题。
值得一提的是，我们与 CubeFS 官方团队进行了深入沟通，了解到社区已经在后续版本中修复了相关问题，此外官方也额外提供了将元数据迁移到新节点来进行修复的方法。通过上面的 bug 修复，异常掉电导致的元数据丢失问题虽然大大缓解，但因为当前的磁盘选型异常掉电没有刷写能力，极端情况下依旧会发生。为此我们采取了临时措施：在特定的时间节点对每个节点的元数据进行统一快照。当故障发生时，可以通过快照快速恢复元数据，最大限度地减少数据丢失的影响
未来计划
我们接下来的开发计划主要是围绕如何保障 CubeFS 在太空环境有限的物理资源限制下和异常场景中依旧能够稳定运行展开，为了进一步提升系统的可观测性和故障排查能力，我们将开发一套完善的文件系统监控体系，实时监控文件系统的运行状态，并将关键状态数据回传至地面控制中心，便于地面团队进行远程诊断和故障处理。
参考资料
- 一箭十二星！太空计算卫星星座成功发射（ https://mp.weixin.qq.com/s/knL2KOR_RTg72LJZb7AEdw ）
- 之江实验室聚焦智能计算（ https://kjt.zj.gov.cn/art/2025/2/18/art_1228971345_59012623.html ）
- CubeFS 开源项目（ https://github.com/cubefs/cubefs ）
- CubeFS 官网（ https://cubefs.io/ ）