云知声: 基于 JuiceFS 的超算平台存储实践

时间:2022-12-22 14:07:15

云知声从一家专注于语音及语言处理的技术公司,现在技术栈已经发展到具备图像、自然语言处理、信号等全栈式的 AI 能力,是国内头部人工智能独角兽企业。公司拥抱云计算,在智慧医疗、智慧酒店、智慧教育等方面都有相应的解决方案。

云知声: 基于 JuiceFS 的超算平台存储实践

Atlas 是云知声的底层基础技术平台,支撑着云知声所有模型的迭代:

第一层是业务层,主要是公司的业务如语音处理、图像处理、自然语言处理等。

第二层是控制中心,从数据生产、数据接入到模型发布都可以一站式完成。

第三层是核心的计算层,主要支持深度学习,以及数据预处理。

最底层是基础架构层,主要是由 GPU 集群、CPU 集群以及分布式存储构成,所有的机器都是用 100Gbps 的 InfiniBand 高速网互联。

存储场景与需求

云知声初期的建设目标就是要建成一站式的 AI 平台,包含 AI 模型的生产,数据预处理,模型开发,模型训练以及最后模型的上线。

云知声: 基于 JuiceFS 的超算平台存储实践

如上图所示,每个步骤都需要跟数据交互,其中数据预处理和模型训练需要比较大的 IO

• 数据预处理,主要是语音处理会提取语音特征,会把语音特征转成 numpy 格式的文件;图像处理的过程中,会对图像做预处理,做训练数据的格式转换;
• 模型开发,主要是算法工程师做代码的编辑,模型算法的调试;
• 模型训练,途中会需要做多轮数据读取,以及模型会输出到相应的存储上,这个步骤所需要的 IO 非常大;在模型上线的时候,服务会去读取存储系统中的模型文件。总结一下我们对存储的需求:

  1. 能够对接整个模型开发的的全链路,在几个比较核心的功能块中都要能够支持;
  2. 支持 CPU、GPU 的数据读取的任务;
  3. 我们的场景主要是语音、文本和图像数据,这些场景的特点是文件大小都比较小,所以要支持小文件场景下的高性能处理。
  4. 我们的业务场景主要是读多入写少,模型训练的时候大部分是在读取数据,基本不会写入数据。
    基于以上这些需求点,我们需要一套高性能可靠的分布式存储系统。

云知声存储建设历程

早期的时候,我们的 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 能够较好的为我们的集群做计算提速,减轻底层存储的压力。但是我们一直在探索希望直接从存储系统来进行客户端缓存,这样操作对用户来说能够更加透明一点。

云知声: 基于 JuiceFS 的超算平台存储实践

在 2021 年的时候 JuiceFS 刚开源时,我们就对它的特性做了调研。

第一,产品特性:JuiceFS 支持 POSIX 接口,能够以 HostPath 的方式去挂载,这种方式跟我们在使用 NAS 的方式是一模一样的,用户在使用时基本不用做任何改变;JuiceFS 元数据以及对象存储,都有比较多的可选方案,像Redis、 TiKV在AI领域是比较合适的。底层 Ceph、MinIO 还有一些公有云的对象存储用户都可以自行选择。

第二,上层调度:JuiceFS 除了支持 HostPath,同时也是支持CSI 驱动方式,能够以更加云原生的方式让用户去接入相应的存储。

第三,业务框架适配:POSIX 接口适配深度学习框架。第四,运维:元数据引擎以及对象存储,业界方案都比较成熟,选择也比较多,而且 JuiceFS 有元数据自动备份以及回收站功能。JuiceFS 与业务比较契合,因此我们进行了 POC 测试。

云知声: 基于 JuiceFS 的超算平台存储实践

测试环境如上图所示,结果发现 Lustre 跟 JuiceFS 来相比,由于JuiceFS 直接用到了内核页缓存,相比 Lustre 直接访问机械盘,性能有很大提升(如下图所示,越小越好)。

云知声: 基于 JuiceFS 的超算平台存储实践

经过了 POC 测试,我们决定把JuiceFS 带入生产环境。目前整个Atlas 的集群所有 GPU 的计算节点,以及所有的开发调试节点,都安装了 JuiceFS 客户端。

云知声: 基于 JuiceFS 的超算平台存储实践

JuiceFS 直接对接redis 集群和ceph,计算节点大部分用的 HostPath 方式接入。同时 Atlas 集群也部署了 JuiceFS CSI Driver,用户可以以云原生的方式接入。

JuiceFS 在 Atlas 的使用方式

为了保证数据的安全性,超算平台上的每个组归属于不同的目录,每个目录下是各自组内或者部门内的成员,不同组之间的目录是不可见的

云知声: 基于 JuiceFS 的超算平台存储实践

目录的权限是基于 Linux 的权限管控机制。用户在 Atlas 集群提交训练任务的时候,集群的任务提交工具会自动读取系统上用户的 UID 与 GID 信息,然后将其注入用户提交的任务 Pod 的 SecurityContext 字段,则 Atlas 集群上运行的容器 Pod 内所有容器的进程运行的 UID 与存储系统上的信息一致,保证权限不越界。

云知声: 基于 JuiceFS 的超算平台存储实践

节点访问 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 不能访问公网,是在专用的隔离网内,因此我们全部都是私有化部署。

云知声: 基于 JuiceFS 的超算平台存储实践

我们生产环境的元数据引擎采用 Redis,2020 年的时候,TiKV 对接到 JuiceFS 还不是很成熟,我们计划首先用 Redis 来做过渡,对象存储的是用 Ceph。Redis 节点的系统盘做了 RAID1,同时 Redis 持久化的数据会定期同步到另一台备份节点上。Redis 的数据持久化我们采用 AOF + RDB 的方案,每秒进行一次数据持久化。

对象存储采用自建的 Ceph 集群,Ceph 集群采用 Cephadm 进行部署,目前生产环境用的是 Octopus 版本。我们当时借鉴了很多业界的方案,对存储器在存储器层面做了一些优化,以及在软件层面也做了相应的调优,主要如下:

服务器层面(参考)
• 42 Cores 256GB 2418T 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 与日志,要保证整个链路都是可控的,这样定位问题就比较方便。

云知声: 基于 JuiceFS 的超算平台存储实践

上图是 Ceph 的监控图,因为我们的客户端节点用的是 SSD 的缓存,现在数据基本不会读取到 Ceph,大部分是缓存在读取,所以 Ceph 的流量不大。

云知声: 基于 JuiceFS 的超算平台存储实践

上图是 JuiceFS 监控上截取的数据,可以看到节点的基本百分百至百分之九十几都能够命中,缓存命中率还是比较高的,大部分数据还是在走缓存的。

参与 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 进行测试。

云知声: 基于 JuiceFS 的超算平台存储实践

从测试结果来看,单从数据读取效率上,在 wav 小文件方面,JuiceFS 为 6.45 it/s,而 Lustre 为 5.15 it/s,性能提升 25%。JuiceFS 有效加速了我们端到端的模型训练,整体缩短了模型的产出时间。

2)文字识别场景

在文字识别场景中,模型为 CRNN backbone 为 MobileNet v2 ,测试环境如下:

云知声: 基于 JuiceFS 的超算平台存储实践

生成了一个 LMDB 的大数据文件,这时候 IO 对带宽的要求比较高,而不是对小文件的性能要求。200G 内存缓存是能支撑整个数据的,所以我们没有走底层的存储,而是直接从客户端读取,整体性能也有比较大的提升。

云知声: 基于 JuiceFS 的超算平台存储实践

在这个测试中,主要做了 JuiceFS 跟 Lustre 的速度对比,从实验的结果来看从 Lustre 读每个 batch 耗时 1.5s,从 JuiceFS 读每个 batch 耗时为 1.1s,提升36%。从模型收敛的时间来看,从 Lustre 的 96 小时下降到 JuiceFS 的 86 小时,使用 JuiceFS 能够将 CRNN 模型的产出时间缩短 10 小时。

模型调试与数据处理

云知声: 基于 JuiceFS 的超算平台存储实践

做代码调试时,多个用户会同时在一台调试机上去运行模型测试,以及代码的遍历,当时统计了大部分用户是会使用一些远程的 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 的限速。