我从2020年进入人工智能行业,开始为AI训练提供存储解决方案及技术支持,随着这几年行业以及公司的发展,采用的存储方案经历了几次大的演变 ,最开始使用的是分布式并行文件系统Lustre,接着是BeeGFS+Ceph,再到最近的分布式异步对象存储DAOS,本文结合自己的经历,将历次存储架构/方案选型的背景,考量及部署,思考记录如下(保密要求,略过了部分配置及拓扑细节),供参考。
在2020年之前,国内AI还是以计算机视觉为主,如:AI四小龙,聚焦在计算机视觉,语音识别等方向的算法优化,以提高人脸,图形,物体的识别率,主要用于智能安防,智慧城市,智慧教育等行业。主要的训练数据类型是图片,音频。
AI与HPC有相似的地方,比如:都能用于科学技术,都需要高效的计算能力,都需要处理不断增长的数据集等,TensorFlow,PyTorch等机器学习框架对posix文件系统接口支持也更友好,因此在这个时期我们直接选用了HPC领域使用最广泛的文件系统Lustre作为AI存储基础设施。Lustre是一个Linux集群并行文件系统,提供了符合POSIX标准的UNIX文件系统接口,这对于不熟悉/没有存储背景的科研人员/Ai研究员非常友好,可以像访问本地文件数据一样访问Lustre文件系统上的数据。
与现在流行的分布式存储系统不同,Lustre没有实现原生的数据可靠性机制,服务的可用性也需要借助外部机制实现。为提供可靠的存储服务,综合考虑性价比,对于容量集群:在硬件层面,我们提供2节点MDS+2(2+)节点OSD的Lustre集群,采用IP-SAN盘阵作为Lustre系统的后端持久化介质,典型的配置:每个机头节点包含2颗62xx系列的CPU+512GB DDR4内存+100Gbps RoCE网络,24盘位的SATA-SSD盘阵组成RAID10作为Lustre MDT通过多路径挂载到两个MDS节点,80盘位的SAS-HDD盘阵组成RAID6作为Lustre OST通过多路径挂载到两个OSD节点;在系统和软件层面,2.10.x/2.12.x版本的Lustre部署在CentOS7.6/7.9系统上,2节点MDS组成Active-standy模式,通过crosync+pacemaker实现故障时的MDT和OST资源转移,提供5分钟级的故障恢复能力。
Lustre缓存集群没有强可靠性要求,因此直接使用存储节点上的本地NVMe SSD来搭建,6节点组成100TB的高性能集群,典型的硬件配置:每个节点包含2颗62xx系列的CPU+512GB DDR4内存+100Gbps RoCE网络+若干4TB的 NVMe SSD,在系统和软件层面,2.10.x/2.12.x版本的Lustre部署在CentOS7.6/7.9系统上。MemCache缓存集群使用各计算节点上的内存构成分布式缓存(提供对小于1MB图片的缓存)。
得益于Lustre系统良好的稳定性及性能,该存储方案较好的支持了公司的Ai训练业务及工作负载,截止2021年底,我们上线了数十套容量在500TB~3PB不等的Lustre容量集群以及数十套容量在100TB的Lustre缓存集群,总计存放了数十PB的数据集。在每个Ai训练(Slurm计算)分区,我们提供一套Lustre容量集群、一套Lustre缓存集群以及一套MemCache缓存集群作为整套存储方案,Lustre容量集群用于存储本分区的所有数据集,Lustre缓存集群作为用户家目录,主要用于存放训练代码,MemCache缓存集群用于加速训练中的图片访问。
从2021年初开始,随着积累的训练数据越来越多,每套集群数十亿平均几十KB的小图片以及单次Ai训练数据集规模从数十万~ 数百万增长到数千万~亿级小图片,运营Lustre集群过程中遇到的问题越来越多:
于是我们启动了Lustre的替代计划,首先我们分析了Ai训练过程及对存储的要求,如下表
数据采集 | 预处理 | 模型训练 | 推理 | ||
是指通过网络爬虫,数据采购等方式收集模型训练所需要的原始数据并储存起来(主要是图片) | 对采集的原始数据进行清洗和处理,如:去重,填充缺失值、删除异常值,(人工)标注等 | 主要是根据预定的目标和要求,选择合适的机器学习算法或构建深度学习网络(主要是CNN,RNN等),对预处理后的数据进行训练,建模 | 利用训练好的模型对新的数据进行预测,并将预测结果应用到实际场景中,例如分类、回归、聚类等 | ||
存储需求 | 具备处理高度多变数据格式的灵活性 | 减少数据准备时间 | 缩短训练时间 | 具备处理高度多变数据格式的灵活性 | |
对存储系统的要求 | 访问模式 | 随机写 | 随机 | 随机 | 随机 |
工作负载 | 写密集型 | 读写混合 | 读密集型(某些写入来自checkpoint) | 读密集型 | |
I/O大小 | 小 | 小 | 小 | 小 | |
服务质量 | 高 | 高 | 非常高 | 非常高 | |
IOPS | 非常高 | 非常高 | 非常高 | 中等 |
厘清需求后,我们分析调研了IO 500榜单中及各流行的开源存储系统,如:Ceph,BeeGFS,Glusterfs,SeaweedFS,JuiceFS,CubeFS,DAOS等,结合上述的存储需求及自身的研发能力,从存储系统的可靠性,可用性,可维护性,可扩展性,社区支持能力,性能等11个指标对主流的系统进行了评估以及测试,鉴于BeeGFS对Posix的良好支持、优秀的扩展能力及优异的性能表现等,Ceph优秀的稳定性及活跃的社区支持等,最终我们选择了BeeGFS+Ceph OSS作为我们新的Ai存储技术方案。
BeeGFS可以看作是应用态实现的增强型的Lustre版本,其除私有客户端在内核态实现,服务端组件都在应用态实现,相比Lustre极大的简化了维护成本以及降低了开发难度,相比Lustre,BeeGFS的增强主要体现在:分布式的MDS集群,可以轻松扩展到数十组节点,支持数PB的容量以及基于副本的可靠性,BeeGFS也有不足的地方,如:单节点MGS,不支持QoS,依赖本地文件系统(Ext4、XFS、ZFS)的Quota,单目录文件数受限等,因此在上线前,我们也对这些方面进行了增强:实现了基于Raft的MGS,多副本的可靠性,基于目录的QoS,基于目录/用户/用户组的Quota等。在我们的方案中,BeeGFS用作用户家目录,存放代码仓库以及训练数据缓存,因此,我们采用高配置部署,每套集群包含数十台节点,提供数PB容量,千万级IOPS:每个节点包含2颗63xx系列的CPU+512GB DDR4内存+100Gbps RoCE网络+若干7.68TB的 NVMe SSD。
Ceph OSS得益于其优秀的稳定性,在国内被大规模的使用,是用作数据湖的不错选项。在我们的方案中,Ceph OSS用作原始数据仓,提供HDD存储池以及SSD存储池,HDD存储池用于存放采集的原始数据,鉴于数据量较大,我们采用了大容量HDD磁盘,每套集群包含近百台节点,提供数十PB容量:每台节点包含2颗63xx系列的CPU+256GB DDR4内存+100Gbps RoCE网络+数十块18TB的SATA HDD,SSD用于存放处理后的数据以及checkpoint,兼具容量和性能,每套集群包含数十个节点,提供数PB容量:每个节点包含2颗63xx系列的CPU+512GB DDR4内存+100Gbps RoCE网络+若干7.68TB的 NVMe SSD。
为方便系统的运营管理,我们开发了一套数据管理系统,用于上线后的系统运维和运营,实现资源的可视化发放,用户数据的可视化管理,数据迁移等。
随着新采集数据的存入以及Lustre数据逐步迁移到新集群,截止2022年下旬,我们在两个机房分别上线了一套新架构存储集群: 2PB的BeeGFS+30PB的Ceph OSS HDD+4PB的Ceph OSS SSD,支撑了公司绝大部分的Ai训练任务及工作负载(少部分在Lustre上),存储网络示意图如下:
随着Lustre数据逐步迁移,新存储架构成为公司主要Ai存储设施,Lustre系统面临的升级问题,数据孤岛问题,性能问题以及管理问题等都得到了极大的缓解及改善。
上线以来,基于BeeGFS+Ceph OSS的Ai存储系统整体运行良好,目前仍然是我们线上的主存储系统,使用率已超过60%,随着大模型的火爆也带来了一些挑战。2022年11月OpenAI发布ChatGPT3.5后,国内也掀起了“LLM百团大战”。与计算机视觉以图片,音频,视频为训练数据不同,大模型的训练数据为文本,多模态则包含了文本,图片,后面可能还会包含音频,视频等。采集的文本,通常是数GB的文本文件,生成的tokenize文件也在数(十)MB,与计算机视觉的处理过程相同,大模型训练也包含4个阶段:
数据采集 | 预处理 | 模型训练 | 推理 | ||
是指通过网络爬虫,数据采购等方式收集模型训练所需要的原始数据并储存起来(主要是文本) | 对采集的原始数据进行清洗和处理,如:去重,去广告,格式化,tokenize等 | 主要是根据预定的目标和要求,选择合适的机器学习算法或构建深度学习网络(主要是Transformer),对预处理后的数据进行训练,建模 | 利用训练好的模型对新的数据进行预测,并将预测结果应用到实际场景中,例如问答,生图等 | ||
存储需求 | 具备处理高度多变数据格式的灵活性 | 减少数据准备时间 | 缩短训练时间 | 具备处理高度多变数据格式的灵活性 | |
对存储系统的要求 | 访问模式 | 顺序写 | 随机 | 随机 | 随机 |
工作负载 | 写密集型 | 读写混合(可能达到50/50) | 读密集型(某些写入来自checkpoint) | 读密集型 | |
I/O大小 | 大 | 大 | 小 | 小 | |
服务质量 | 高 | 高 | 非常高 | 非常高 | |
吞吐量 | 非常高 | 非常高 | 非常高 | 中等 |
对比上述的两个表格,可以发现大模型对存储系统的要求比计算机视觉更高。计算机视觉训练更多的是随机小I/O,对IOPS和延迟更敏感,大模型训练则是混合I/O,对IOPS,吞吐及延迟都提出了很高的要求。
2023以来,随着大模型参数的急剧增长,以及新热点的出现,如:长文本处理,文图多模态训练等,当前BeeGFS+Ceph OSS的存储方案也面临挑战,主要表现在:
鉴于此,Intel Daos再次进入了我们的视线,在此前考虑到产品的成熟度,稳定性以及Intel Optane停产风险等因素后,Daos被排除出第二阶段的候选方案。经过两年多的发展,基于(intel Optane)的Daos版本开始成熟,商业及云方案也开始出现,如:Google Cloud和IBM Cloud上的DAOS方案, Metadata-on-SSD的技术落地社区也在如火如荼的推进中(第一版已经发布),根据社区计划,预计24年Q1发布完整的Metadata-on-SSD的功能,考虑到DAOS对新型硬件的支持能力及未来CXL技术的发展和应用,和存储的发展趋势,我们认为:用DAOS方案替代BeeGFS+Ceph OSS方案是个值得尝试的选项,目前已经在内部测试及验证DAOS Metadata-on-SSD版本替代BeeGFS的可行性,第一阶段计划24年H1线上试点,取代新增的BeeGFS需求。
注:据观察了解,现在Ai项目还处于不计成本阶段,Ai基础设施的成本大头在计算(GPU)和高性能网络,而Ai的绝对数据量还不大(PB级),千亿级参数
Ai训练的数据集规模通常在数TB级别,就当下的实践而言,采用基于NVMe SSD的高性能分布式文件系统就能满足Ai工作负载要求。我们方案中采用的
BeeGFS是为HPC专门设计的并行文件系统,经过优化后也能很好的满足当前的需求。
AI存储应该是怎么样的?
AI存储专为满足AI独特的工作负载而设计和优化,这些工作负载通常包括大规模数据集、高吞吐低延迟数据访问以及复杂的数据处理。结合自身实践经验及观察,AI存储应在以下方面对AI工作负载进行优化: