关于存储:JuiceFS-在火山引擎边缘计算的应用实践

火山引擎边缘云是以云计算根底技术和边缘异构算力联合网络为根底，构建在边缘大规模基础设施之上的云计算服务，造成以边缘地位的计算、网络、存储、平安、智能为外围能力的新一代分布式云计算解决方案。

边缘存储次要面向适配边缘计算的典型业务场景，如边缘渲染。火山引擎边缘渲染依靠底层海量算力资源，可助力用户实现百万渲染帧队列轻松编排、渲染工作就近调度、多任务多节点并行渲染，极大晋升渲染效率。

边缘场景存储挑战

这里简略介绍一下在边缘渲染中遇到的存储问题：须要对象存储与文件系统的元数据对立，实现数据通过对象存储接口上传当前，能够通过 POSIX 接口间接进行操作；满足高吞吐量的场景需要，尤其是在读的时候；齐全实现 S3 接口和 POSIX 接口。

为了解决在边缘渲染中遇到的存储问题，团队花了将近半年的工夫发展了存储选型测试。

最后，团队抉择了公司外部的存储组件，从可持续性和性能上来说，都能比拟好的满足咱们的需要。然而落地到边缘场景，有两个具体的问题：

• 首先，公司外部组件是为了核心机房设计的，对于物理机资源和数量是有要求的，边缘某些机房很难满足；
• 其次，整个公司的存储组件都打包在一起，包含：对象存储、块存储、分布式存储、文件存储等，而边缘侧次要须要文件存储和对象存储，须要进行裁剪和革新，上线稳固也须要一个过程。

团队探讨后，造成了一个可行的计划：CephFS + MinIO 网关。MinIO 提供对象存储服务，最终的后果写入 CephFS，渲染引擎挂载 CephFS，进行渲染操作。测试验证过程中，文件到千万级时，CephFS 的性能开始降落，偶然会卡顿，业务方反馈不合乎需要。

同样的，基于 Ceph 还有一个计划，就是应用 Ceph RGW + S3FS。这个计划根本能满足要求，然而写入和批改文件的性能不合乎场景要求。

通过三个多月的测试之后，咱们明确了边缘渲染中对于存储的几个外围诉求:

• 运维不能太简单 ：存储的研发人员可能通过运维文档上手操作；前期扩容以及解决线上故障的运维工作须要足够简略。
• 数据可靠性 ：因为是间接给用户提供存储服务，因而对于写入胜利的数据不容许失落，或者呈现跟写入的数据不统一的状况。
• 应用一套元数据，同时反对对象存储和文件存储 ：这样业务方在应用的时候，不须要屡次上传和下载文件，升高业务方的应用复杂度。
• 针对读有比拟好的性能 ：团队须要解决的是读多写少的场景，因而心愿有比拟好的读性能。
• 社区活跃度 ：在解决现有问题以及踊跃推动新性能的迭代时，一个沉闷的社区能有更快的响应。

明确外围诉求之后，咱们发现后期的三个计划都不太满足需要。

初识 JuiceFS

火山引擎边缘存储团队在 2021 年 9 月理解到了 JuiceFS，并跟 Juicedata 团队进行了一些交换。通过交换咱们决定在边缘云场景尝试一下。JuiceFS 的官网文档十分丰盛，可读性很高，通过看文档就能够理解比拟多的细节。

于是，咱们就开始在测试环境做 PoC 测试，次要关注的点是可行性验证，运维和部署的复杂度，以及跟上游业务的适配，是否合乎上游业务的需要。

咱们部署了 2 套环境，一个环境是基于单节点的 Redis + Ceph 搭建 ，另一个环境是基于单实例的 MySQL + Ceph 搭建 。

在整个环境搭建方面因为 Redis、MySQL 和 Ceph（通过 Rook 部署）都比拟成熟，部署运维计划能够参考的材料也比拟全面，同时 JuiceFS 客户端也可能简略和不便地对接这些数据库和 Ceph，因而整体的部署流程十分晦涩。

业务适配方面，边缘云是基于云原生开发和部署的，JuiceFS 反对 S3 API，同时齐全兼容 POSIX 协定，还反对 CSI 的形式挂载，齐全满足咱们的业务需要。

综合测试后，咱们发现 JuiceFS 齐全符合业务方的需要，能够在生产上进行部署运行，满足业务方的线上需要。

应用 JuiceFS 的收益

业务流程优化在应用

JuiceFS 之前，边缘渲染次要利用字节跳动外部的对象存储服务（TOS），用户上传数据到 TOS 中，渲染引擎再从 TOS 上将用户上传的文件下载到本地，渲染引擎读取本地的文件，生成渲染后果，再将渲染后果上传回 TOS，最初用户从 TOS 中下载渲染后果。整体的交互流程有好几个环节，而且两头波及到比拟多的网络以及数据拷贝，所以在这个过程中会存在网络抖动或者时延偏高的状况，影响用户体验。

应用 JuiceFS 后的简化流程应用 JuiceFS 之后，流程变成了用户通过 JuiceFS S3 网关进行上传，因为 JuiceFS 实现了对象存储和文件系统的元数据的对立，能够间接将 JuiceFS 挂载到渲染引擎中，渲染引擎以 POSIX 接口对文件进行读写，最终用户间接从 JuiceFS S3 网关中下载渲染后果，整体的流程更加简洁和高效，同时也更稳固。

读文件减速，大文件程序写减速

得益于 JuiceFS 的客户端缓存机制，咱们能够将频繁读取的文件缓存到渲染引擎本地，极大减速了文件的读取速度。 咱们针对是否关上缓存做了比照测试，发现应用缓存后能够晋升大概 3-5 倍的吞吐量。

同样，因为 JuiceFS 的写模型是先写内存，当一个 chunk（默认 64M）被写满，或者利用调用强制写入接口（close 和 fsync 接口）时，才会将数据上传到对象存储，数据上传胜利后，再更新元数据引擎。所以，在写入大文件时，都是先写内存，再落盘，能够大大晋升大文件的写入速度。

目前边缘的应用场景次要以渲染类为主，文件系统读多写少，文件写入也是以大文件为主。这些业务场景的需要和 JuiceFS 的实用场景十分吻合，业务方在存储替换为 JuiceFS 后，整体评估也很高。

在边缘存储中如何应用 JuiceFS

JuiceFS 次要是在 Kubernetes 上部署，每个节点都有一个 DaemonSet 容器负责挂载 JuiceFS 文件系统，而后以 HostPath 的形式挂载到渲染引擎的 pod 中。如果挂载点呈现故障，DaemonSet 会负责主动复原挂载点。

在权限管制上，边缘存储是通过 LDAP 服务来认证 JuiceFS 集群节点的身份，JuiceFS 集群的每个节点都通过 LDAP 的客户端与 LDAP 服务进行验证。

咱们目前利用的场景次要还是以渲染为主，前期会扩大到更多业务场景。在数据拜访上，边缘存储目前次要通过 HostPath 的形式进行拜访，前期如果波及到弹性扩容的需要，会思考应用 JuiceFS CSI Driver 来部署。

JuiceFS 存储生产环境实际

教训元数据引擎 JuiceFS 反对了十分多的元数据引擎（如 MySQL、Redis），火山引擎边缘存储生产环境采纳的是 MySQL。咱们在评估了数据量与文件数的规模（文件数在千万级，大略几千万，读多写少场景），以及写入与读取性能当前，发现 MySQL 在运维、数据可靠性，以及事务方面都做得比拟好。

MySQL 目前采纳的是单实例和多实例（一主二从）两种部署计划，针对边缘不同的场景灵便抉择。在资源偏少的环境，能够采纳单实例的形式来进行部署，MySQL 的吞吐在给定的范畴之内还是比较稳定的。这两种部署计划都应用高性能云盘（由 Ceph 集群提供）作为 MySQL 的数据盘，即便是单实例部署，也能保障 MySQL 的数据不会失落。

在资源比拟丰盛的场景，能够采纳多实例的形式来进行部署。多实例的主从同步通过 MySQL Operator 提供的 orchestrator 组件实现，两个从实例全副同步胜利才认为是 OK 的，然而也设置了超时工夫，如果超时工夫到了还没有同步实现，则会返回胜利，并打出报警。待前期的容灾计划健全后，可能会采纳本地盘作为 MySQL 的数据盘，进一步晋升读写性能，升高时延以及晋升吞吐。

MySQL 单实例配置

容器资源：

• CPU：8C
• 内存：24G
• 磁盘：100G（基于 Ceph RBD，在存储千万级文件的场景下元数据大概占用 30G 磁盘空间）
• 容器镜像：mysql:5.7

MySQL 的 my.cnf 配置：

ignore-db-dir=lost+found  # 如果应用 MySQL 8.0 及以上版本，须要删除这个配置
max-connections=4000
innodb-buffer-pool-size=12884901888  # 12G 复制代码对象存储 

对象存储

采纳自建的 Ceph 集群，Ceph 集群通过 Rook 部署，目前生产环境用的是 Octopus 版本。借助 Rook，能够以云原生的形式运维 Ceph 集群，通过 Kubernetes 管控 Ceph 组件，极大升高了 Ceph 集群的部署和治理复杂度。
Ceph 服务器硬件配置：

• 128 核 CPU
• 512GB 内存
• 系统盘：2T * 1 NVMe SSD
• 数据盘：8T * 8 NVMe SSDCeph

服务器软件配置：

• 操作系统：Debian 9
• 内核：批改 /proc/sys/kernel/pid_max
• Ceph 版本：Octopus
• Ceph 存储后端：BlueStore
• Ceph 正本数：3
• 敞开 Placement Group 的主动调整性能

边缘渲染主打的就是低时延高性能，所以在服务器的硬件抉择方面，咱们给集群配的都是 NVMe 的 SSD 盘。其它配置次要是基于火山引擎保护的版本，操作系统咱们抉择的是 Debian 9。数据冗余上为 Ceph 配置了三正本，在边缘计算的环境中可能因为资源的起因，用 EC 反而会不稳固。

JuiceFS 客户端

JuiceFS 客户端反对间接对接 Ceph RADOS（性能比对接 Ceph RGW 更好），但这个性能在官网提供的二进制中默认没有开启，因而须要从新编译 JuiceFS 客户端。编译之前须要先装置 librados，倡议 librados 的版本要跟 Ceph 的版本对应，Debian 9 没有自带与 Ceph Octopus（v15.2.）版本匹配的 librados-dev 包，因而须要本人下载安装包。

装置好 librados-dev 之后，就能够开始编译 JuiceFS 客户端。咱们这边应用了 Go 1.19 来编译，1.19 中新增了管制内存调配最大值（https://go.dev/doc/gc-guide#M…）这个个性，能够避免极其状况下 JuiceFS 客户端占用过多内存而呈现 OOM。

make juicefs.ceph

复制代码编译完 JuiceFS 客户端即可创立文件系统，并在计算节点挂载 JuiceFS 文件系统了，具体步骤能够参考 JuiceFS 官网文档。

将来和瞻望

JuiceFS 是一款云原生畛域的分布式存储系统产品，提供了 CSI Driver 组件可能十分好的反对云原生的部署形式，在运维部署方面为用户提供了非常灵活的抉择，用户既能够抉择云上，也能够抉择私有化部署，在存储扩容和运维方面较为简单。齐全兼容 POSIX 规范，以及跟 S3 应用同一套元数据的形式，能够十分不便地进行上传、解决、下载的操作流程。因为其后端存储是对象存储的特点，在随机小文件读写方面有较高的提早，IOPS 也比拟低， 但在只读场景，联合客户端的多级缓存，以及大文件场景，还有读多写少的场景，JuiceFS 有比拟大的劣势，十分符合边缘渲染场景的业务需要。

火山引擎边缘云团队将来与 JuiceFS 相干的布局如下：

• 更加云原生 ：目前是以 HostPath 的形式来应用 JuiceFS，前面咱们思考到一些弹性伸缩的场景，可能会切换到以 CSI Driver 的形式来应用 JuiceFS；
• 元数据引擎降级 ：形象一个元数据引擎的 gRPC 服务，在其中提供基于多级缓存能力，更好地适配读多写少的场景。底层的元数据存储，可能会思考迁徙到 TiKV 上，以反对更多的文件数量，绝对于 MySQL 可能更好地通过横向扩大来减少元数据引擎的性能；
• 新性能及 bug 修复 ：针对以后业务场景，会减少一些性能以及修复一些 bug，并冀望为社区奉献 PR，回馈社区。

对于作者

何兰州，火山引擎边缘计算高级开发工程师 ，负责边缘存储的技术选型，演进和稳定性；钻研畛域次要有分布式存储和分布式缓存；云原生开源社区爱好者。