云知声从一家专一于语音及语言解决的技术公司，当初技术栈曾经倒退到具备图像、自然语言解决、信号等全栈式的 AI 能力，是国内头部人工智能独角兽企业。公司拥抱云计算，在智慧医疗、智慧酒店、智慧教育等方面都有相应的解决方案。
Atlas 是云知声的底层根底技术平台，撑持着云知声所有模型的迭代：
第一层是业务层，次要是公司的业务如语音解决、图像处理、自然语言解决等。
第二层是控制中心，从数据生产、数据接入到模型公布都能够一站式实现。
第三层是外围的计算层，次要反对深度学习，以及数据预处理。
最底层是基础架构层，次要是由 GPU 集群、CPU 集群以及分布式存储形成，所有的机器都是用 100Gbps 的 InfiniBand 高速网互联。
存储场景与需要
云知声初期的建设指标就是要建成一站式的 AI 平台，蕴含 AI 模型的生产，数据预处理，模型开发，模型训练以及最初模型的上线。
如上图所示， 每个步骤都须要跟数据交互，其中数据预处理和模型训练须要比拟大的 IO。
• 数据预处理，次要是语音解决会提取语音特色，会把语音特色转成 numpy 格局的文件；图像处理的过程中，会对图像做预处理，做训练数据的格局转换；
• 模型开发，次要是算法工程师做代码的编辑，模型算法的调试；
• 模型训练，途中会须要做多轮数据读取，以及模型会输入到相应的存储上，这个步骤所须要的 IO 十分大；在模型上线的时候，服务会去读取存储系统中的模型文件。总结一下咱们对存储的需要：
- 可能对接整个模型开发的的全链路，在几个比拟外围的功能块中都要可能反对；
- 反对 CPU、GPU 的数据读取的工作；
- 咱们的场景次要是语音、文本和图像数据，这些场景的特点是文件大小都比拟小，所以要反对小文件场景下的高性能解决。
- 咱们的业务场景次要是读多入写少，模型训练的时候大部分是在读取数据，根本不会写入数据。
基于以上这些需要点，咱们须要一套高性能牢靠的分布式存储系统。
云知声存储建设历程
晚期的时候，咱们的 GPU 只有十几台左右，过后应用 NFS 做了一个小规模的集群。同时在 2016 年引入了 CephFS 的测试环境，过后那个版本的 CephFS 在小文件场景下性能不太好，所以就没有把 CephFS 带入到生产环境。
起初咱们持续做了调研，发现 Lustre 在 HPC 畛域是最为罕用的高性能文件系统。测试表明 Lustre 在规模化的构建以及性能方面体现都不错，于是从 2017 年到 2022 年，咱们全副是用 Lustre 来承载所有的数据业务。
然而随着应用的 GPU 越来越多，当初有 5.7 亿亿次 / 秒左右的浮点解决能力，底层存储的 IO 曾经跟不上下层计算能力 。于是，咱们开始摸索新的存储，为后续的存储扩容做降级，同时在应用 Lustre 的过程中也遇到了一些问题。
第一：运维形式 ，Lustre 次要是基于内核的，间接嵌在内核，有时候定位问题会波及到机器的重启之类的操作；
第二：技术栈 ，因为咱们的云平台的开发次要是以 golang 为主，所以比拟偏差于应用与开发语言比拟符合的存储。Lustre 应用的是 C 语言，在定制优化方面须要有较多人力精力。
第三：数据的可靠性 ，Lustre 次要依赖硬件可靠性（比方 RAID 技术），软件层面次要是实现元数据节点和对象跟数据节点的 HA 计划。相比这些，咱们还是更心愿应用三正本或者是纠删码这类更牢靠的软件计划。
第四：多级缓存的性能的需要 ，在 2021 年的时候，咱们用了 Fluid + Alluxio 来作为 Lustre 的分布式减速，Alluxio 可能较好的为咱们的集群做计算提速，加重底层存储的压力。然而咱们始终在摸索心愿间接从存储系统来进行客户端缓存，这样操作对用户来说可能更加通明一点。
在 2021 年的时候 JuiceFS 刚开源时，咱们就对它的个性做了调研。
第一，产品个性 ：JuiceFS 反对 POSIX 接口，可能以 HostPath 的形式去挂载，这种形式跟咱们在应用 NAS 的形式是截然不同的，用户在应用时根本不必做任何扭转；JuiceFS 元数据以及对象存储，都有比拟多的可选计划，像 Redis、TiKV 在 AI 畛域是比拟适合的。底层 Ceph、MinIO 还有一些私有云的对象存储用户都能够自行抉择。
第二，下层调度 ：JuiceFS 除了反对 HostPath，同时也是反对 CSI 驱动形式，可能以更加云原生的形式让用户去接入相应的存储。
第三，业务框架适配 ：POSIX 接口适配深度学习框架。第四，运维：元数据引擎以及对象存储，业界计划都比拟成熟，抉择也比拟多，而且 JuiceFS 有元数据主动备份以及回收站性能。JuiceFS 与业务比拟符合，因而咱们进行了 POC 测试。
测试环境如上图所示，后果发现 Lustre 跟 JuiceFS 来相比，因为 JuiceFS 间接用到了内核页缓存，相比 Lustre 间接拜访机械盘，性能有很大晋升（如下图所示，越小越好）。
通过了 POC 测试，咱们决定把 JuiceFS 带入生产环境。目前整个 Atlas 的集群所有 GPU 的计算节点，以及所有的开发调试节点，都装置了 JuiceFS 客户端。
JuiceFS 间接对接 redis 集群和 ceph，计算节点大部分用的 HostPath 形式接入。同时 Atlas 集群也部署了 JuiceFS CSI Driver，用户能够以云原生的形式接入。
JuiceFS 在 Atlas 的应用形式
为了保证数据的安全性，超算平台上的每个组归属于不同的目录， 每个目录下是各自组内或者部门内的成员，不同组之间的目录是不可见的 。
目录的权限是基于 Linux 的权限管控机制。用户在 Atlas 集群提交训练任务的时候，集群的工作提交工具会主动读取零碎上用户的 UID 与 GID 信息，而后将其注入用户提交的工作 Pod 的 SecurityContext 字段，则 Atlas 集群上运行的容器 Pod 内所有容器的过程运行的 UID 与存储系统上的信息统一，保障权限不越界。
节点拜访 JuiceFS，实现了多级缓存：
- 第一级：缓存就是内存的页缓存。
- 第二级：所有的计算节点的多块 SSD，提供二级的减速能力。
- 第三级：应用 Ceph。如果 3 块 1t 的 SSD 还是不能撑持用户的数据，那它会从 Ceph 读取。
2021 年初的时候，云知声和 JuiceFS 团队一起把 JuiceFSRuntime 集成到 Fluid 下面。因为以裸机的形式去用缓存，咱们发现用户对缓存的可见性比拟不好，缓存的清理全副是零碎主动做的，用户的可控性没那么高，所以才会把 JuiceFS 集成到 Fluid。
Fluid 会启动 JuiceFS 相干的组件，包含 FUSE 和 Worker Pod。其中 FUSE Pod 提供了 JuiceFS 客户端的缓存能力，Worker Pod 则实现了对缓存生命周期的治理，Atlas 平台的 AI 离线训练任务通过与 FUSE Pod 客户端交互，进行 AI 训练数据的读取。
通过 Fluid 提供的缓存调度能力以及数据集的可观测性，平台的用户能够通过亲和调度将缓存部署在特定的计算节点上，同时用户可能直观的看到缓存的应用状况（例如缓存数据集的大小、缓存的百分比、缓存的容量等）。
JuiceFS 的建设实际
目前 Atlas 不能拜访公网，是在专用的隔离网内，因而咱们全部都是私有化部署。
咱们生产环境的元数据引擎采纳 Redis，2020 年的时候，TiKV 对接到 JuiceFS 还不是很成熟，咱们打算首先用 Redis 来做过渡，对象存储的是用 Ceph。Redis 节点的系统盘做了 RAID1，同时 Redis 长久化的数据会定期同步到另一台备份节点上。Redis 的数据长久化咱们采纳 AOF + RDB 的计划，每秒进行一次数据长久化。
对象存储采纳自建的 Ceph 集群，Ceph 集群采纳 Cephadm 进行部署，目前生产环境用的是 Octopus 版本。咱们过后借鉴了很多业界的计划，对存储器在存储器层面做了一些优化，以及在软件层面也做了相应的调优，次要如下：
服务器层面（参考）：
• 42 Cores 256GB 24*18T HDD
• 系统盘: 2* 960G SAS SSD
• BlueStore
• 敞开 NUMA
• 降级 kernel: 5.4.146 开启 io_uring
• Kernel pid max，批改 /proc/sys/kernel/pid_max
Ceph 配置方面 ：
• Ceph RADOS：间接调用 librados 接口，不走 S3 协定
• Bucket shard
• 敞开 pg 的主动调整性能
• OSD 日志存储（采纳 bluestore，倡议裸容量配比—— block : block.db : block.wal = 100:1:1，后两者倡议采纳 SSD 或 NVMe SSD）
• 3 正本
重点提下，要把 Ceph 集群的内核升到比拟新的版本，而后开启 io_uring 性能，这样性能会有比拟大的晋升。在软件方面咱们是间接调用了 rados 的接口，就不走 S3 协定了，效率会略微高一点，所有的节点用 100G 的 InfiniBand 高速网络去做互联。
云知声环境中 JuiceFS 对接的对象存储是 Ceph RADOS，JuiceFS 采纳 librados 与 Ceph 进行交互，因而须要从新编译 JuiceFS 客户端，倡议 librados 的版本要跟 Ceph 的对应，这点要留神一下。如果用 CSI Driver 的时候, 在 PV/PVC 的创立，会读取 /etc/ceph/ceph.conf 也要留神版本的反对。
欠缺的监控体系
当初整个链路比拟长了，底层有元数据引擎集群、Ceph 对象存储集群，还有下层的客户端以及业务，每层都要有相应的监控计划。
客户端节点，咱们次要是做日志的收集，须要留神的是各个挂载点 JuiceFS 客户端日志要做汇聚，error 告警，防止日志将零碎磁盘打爆或者节点无奈写。
各个 JuiceFS 客户端也要有相应的监控伎俩，比方查看各挂载点的 .stat 文件和日志察看指标是否失常，而后看看 Redis 跟 Ceph 集群的 IO 与日志，要保障整个链路都是可控的，这样定位问题就比拟不便。
上图是 Ceph 的监控图，因为咱们的客户端节点用的是 SSD 的缓存，当初数据根本不会读取到 Ceph，大部分是缓存在读取，所以 Ceph 的流量不大。
上图是 JuiceFS 监控上截取的数据，能够看到节点的根本百分百至百分之九十几都可能命中，缓存命中率还是比拟高的，大部分数据还是在走缓存的。
参加 JuiceFS 社区建设
云知声在应用 JuiceFS 社区版的过程中，始终积极参与社区建设。在 2021 年和 JuiceData 团队合作开发了上文中提到的 Fluid JuiceFS Runtime。近期，咱们发现社区版基于目录的配额还没有开发，于是在前几个月咱们开发了一个版本，对目录的文件数跟文件大小做了限度，PR 目前曾经提交，当初也正在跟 JuiceFS 社区一起进行合并的工作。
JuiceFS 在 Atlas 的应用场景与收益
JuiceFS 客户端多级缓存目前次要利用在咱们的文字辨认、语音降噪以及语音辨认场景。因为 AI 模型训练的数据读取特点是读多写少，咱们充分利用 JuiceFS 客户端的缓存带来 IO 读取的减速收益。
收益一：减速 AI 模型训练
1）语音降噪测试
降噪场景模型的测试中应用的是散文件，每个数据都是 wav 格局，小于 100k 的语音小文件，在降噪场景咱们测试了数据 dataload 阶段的 I/O 数据，JuiceFS 客户端节点的内存缓存为 512G，在 500h 规模的数据下、以 40 的 batch size 进行测试。
从测试后果来看，单从数据读取效率上，在 wav 小文件方面，JuiceFS 为 6.45 it/s，而 Lustre 为 5.15 it/s，性能晋升 25%。JuiceFS 无效减速了咱们端到端的模型训练，整体缩短了模型的产出工夫。
2）文字辨认场景
在文字辨认场景中，模型为 CRNN backbone 为 MobileNet v2，测试环境如下：
生成了一个 LMDB 的大数据文件，这时候 IO 对带宽的要求比拟高，而不是对小文件的性能要求。200G 内存缓存是能撑持整个数据的，所以咱们没有走底层的存储，而是间接从客户端读取，整体性能也有比拟大的晋升。
在这个测试中，次要做了 JuiceFS 跟 Lustre 的速度比照，从试验的后果来看从 Lustre 读每个 batch 耗时 1.5s，从 JuiceFS 读每个 batch 耗时为 1.1s，晋升 36%。从模型收敛的工夫来看，从 Lustre 的 96 小时降落到 JuiceFS 的 86 小时，应用 JuiceFS 可能将 CRNN 模型的产出工夫缩短 10 小时。
模型调试与数据处理
做代码调试时，多个用户会同时在一台调试机上去运行模型测试，以及代码的遍历，过后统计了大部分用户是会应用一些近程的 IDE，连贯到调试节点，而后构建本人的虚拟环境，会把大量的安装包提前装置在 Lustre 上。
大部分都是几十 k 或者几百 k 的小文件，要把这些包导入在咱们内存上。之前应用 Lustre 时，因为用户太多了所以需要吞吐较高，同时对小文件性能要求比拟高，发现成果不是很好，在 import 包时会比拟卡，导致代码调试的时候比较慢，整体效率比拟低。
起初应用了 JuiceFS 客户端的缓存，在第一次编译时也比较慢，但第二次的编译时因为数据曾经全副落在缓存上，速度和效率就比拟高了，代码跳转也就比拟快，代码提醒 import 也比拟快。用户测试后大略有 2~4 倍的速度晋升。
## 结语
从 Lustre 到 JuiceFS
从 2017 年到 2021 的时候，咱们用 Lustre 也是比较稳定的，集群存储量少于 50% 的时候，软件的稳定性都是比拟高的。
Lustre 作为老牌 HPC 畛域的存储系统，为许多寰球最大的超算零碎提供能源，具备多年的生产环境教训。其具备合乎 POSIX 规范、反对各种高性能低时延的网络，容许 RDMA 拜访的长处，实用于传统 HPC 畛域的高性能计算，跟深度学习的接口是符合的，所有的业务都是不须要做代码批改。然而也有一些毛病：
第一，Lustre 无奈反对云原生 CSI Driver。
第二，Lustre 对运维人员的要求比拟高，因为全副是以 C 语言写的，有时候出一些 Bug 无奈疾速解决，整体社区的开放性和活跃度不是很高。
JuiceFS 有这样一些特点：
第一，JuiceFS 是一款云原生畛域的分布式存储系统产品 ，提供了 CSI Driver 以及 Fluid 等形式应用可能更好地与 Kubernetes 进行联合。
第二，JuiceFS 的部署计划比拟灵便 ，元数据引擎可选性高，对象存储如果用户网络容许，其实对接到私有云的对象存储会更好。
第三，在存储扩容运维方面较为简单 。齐全兼容 POSIX 规范使得深度学习的利用能够无缝迁徙，然而因为后端对象存储的特点, 使得 JuiceFS 在随机写方面会有较高的提早。
第四，JuiceFS 反对本地缓存、内核页缓存，实现了冷热数据的分层和减速 。这一点是咱们比拟看重的，在咱们的业务场景是比拟适合的，然而在随机写的时候就不太适合。社区版本目前分布式缓存的性能也还不提供。
后续布局
• 元数据引擎降级，TiKV 适宜在 1 亿以上文件数量（最多能够撑持到百亿级文件），对性能以及数据安全都有较高要求的场景，目前咱们曾经实现了 TiKV 的内部测试也在踊跃跟进社区的停顿，后续要将元数据引擎迁徙到 TiKV。
• 目录配额优化，目前曾经把根底版本的性能合入到了 JuiceFS 社区版本，也跟 JuiceFS 社区进行了探讨，在一些场景上有些性能还须要优化。
• 心愿去做一些 Nonroot 的性能，当初所有的节点都是 root 权限能拜访所有的数据，权限太大咱们心愿只在特定节点去凋谢 root 的权限。
• 最初也会去看看社区这边的话是否有 QoS 的计划，比方基于 UID 或者 GID 的限速。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)