本文概述 HotCloud ’18 中的一篇讲云原生文件系统的论文，来回顾下存储领域大佬 Arpaci-Dusseau 在 6 年前对云原生文件系统的想法。论文链接 hotcloud18-paper-arpaci-dusseau.pdf (usenix.org)
文章的贡献主要有两点：
- 提出一些云原生文件系统所应该遵循的设计原则；
- 提出一种云原生文件系统 CNFS 的大概设计。
云原生文件系统的设计原则
作者把设计的原则分为存储和计算两个层次，但总体来讲都聚焦于成本和性能的权衡。这种权衡是云环境相对传统环境更容易做到的，也是云原生文件系统设计的核心。
存储原则
- 可靠性已经通过更底层的云存储服务得到保障。云存储比如对象存储 S3 或者块存储 EBS，已经提供了多副本等可靠性功能，因此云原生文件系统可以把这部分功能卸载到更底层的云存储。
- 云存储空间便宜且可以无限扩展。云原生文件系统的设计应该尽量利用这些便宜的存储空间对数据建立索引，用空间换时间。
- 云存储与本地存储有很大差异：带宽通常较高；延迟根据服务分级不同差异明显；更快分级的云存储访问成本反而更低。因此云原生文件系统应该按冷热层次化地放置数据，来兼顾成本和高性能。
CPU 原则
- 云上 A 个 CPU 计算 B 秒和 B 个 CPU 计算 A 秒（A * B = B * A）的成本相同。因此，云原生文件系统的计算任务应该尽量并行起来，这样可以在尽可能短的时间内完成任务。
- 类似于云存储的空间，云上的 CPU 数量也很容易扩展。云原生文件系统应该按需地使用 CPU，但也需要注意根据负载的变化对之前扩容的 CPU 数进行缩容，来控制成本。
- 由于云存储可以在计算节点间共享，可以适当的将与文件系统相关后台任务从计算节点分离出来，让计算节点的 CPU 资源更多地用于计算任务。
- 云服务中 CPU 同样也存在不同的服务分级，应该根据需求进行选择。比如是更多的低性能核好，还是少一些的高性能核好。
提出 CNFS
假设
- CNFS 可以使用 AWS EBS 等块存储云服务；
- 这些块存储服务可以夸节点（共享）访问；
- 这些块存储提供不同的性能/成本选择。
设计
- CNFS 尽量将文件系统的具体工作卸载到远端；
- CNFS 中包含一个性能-成本算法的框架，根据用户的请求或者需求来进行对 CPU、云存储的服务级别进行调节。
- CNFS 是一个 copy-on-write 文件系统，所有的数据和元数据更改都不在原位置进行，这样远程的 CNFS worker 就可以直接操作某个只读快照，避免与计算节点的 CNFS client 进行复杂的同步；
- CNFS 是一个分级文件系统，主动将文件和目录在不同服务分级的云存储间移动；
- CNFS 尽量进行去重和压缩，来节省存储成本和传输带宽。
架构
- CNFS 同时使用高性能 SSD 和低层本 HDD；
- 实际使用的 CNFS 的计算节点上有 CNFS client 组件；
- 远程的 CNFS worker 组件利用云的 CPU 无限扩展来进行压缩、冷热搬移等工作；
- CNFS manager 对所有的 CNFS 组件进行编排，与它们通信，来保证整体的同步，同时也对数据的放置进行决策。
研究现状和展望
作者提到 CNFS 只是在设计的早期阶段，有很多问题值得继续研究：
- 性能/成本控制的 API 应该如何设计？怎么找到合适的用户-系统交互粒度？
- 怎么建立模拟和优化框架来更好的预测性能和成本？
- CNFS manager 怎么更好的进行 client 和 workers 之间的同步和错误检测处理？
- 如何进行访问追踪，并利用这些数据进行性能/成本相关的决策？
- copy-on-write 系统通常对经常通过刷盘保证持久化的应用（比如数据库系统）不友好，CNFS 怎么保证这种工作负载的高性能？ZFS 通过 intent log 来提升性能，CNFS 是否也可以采用这种设计，内存副本是否可以同时保证持久化和高性能？
论文评述
首先，“云原生文件系统”的概念非常广泛，作者也是一家之言，这篇论文讨论的是：
- Linux 内核文件系统，而非用户态文件系统；
- 基于云服务(如 EBS)的文件系统，而非文件系统云服务。
论文作者所提出的 CNFS 设计是一个非常 high-level 的设计，有许多实际应用中诸多问题需要解决。然而，这种不完整的设计并非本文的缺点，反而让我们更聚焦于“云原生”文件系统不同于传统文件系统的设计要点。