前言
由于AI训练需要大量的数据，因此forge training作为AI训练平台，需要提供健壮，可伸缩性，高吞吐，高并发，低延迟的存储服务供算法同事使用。
实践准备
1.参考资料
minio官方文档
ceph官方文档
zfs官方文档
zfs ubuntu初始设定
ZFS Raidz Performance, Capacity and Integrity
openstack官方文档
git s3fs
使用s3(minio)为kubernetes提供pv存储
openpai 官方文档
上述资料关于DDD部分，需要反复阅读，并结合git示例源码进行学习
概述
如下所示，就是一个简化版的forge training训练平台存储方案。forge training是基于微软开源训练平台进行定制化改造，而形成的深度学习训练平台。
其中黑色方块代表启动的训练任务（pod）, 用户的训练代码就在相应的pod中执行。
用户有三种方式自由选择如何使用AI训练数据
1.从minio 集群直接拉取数据到本地磁盘，然后k8s将本地磁盘 以bind的方式挂载到pod中，用户因此可以像操作本地磁盘数据一样，操作下载下来的Ai数据。
2.从minio 集群直接拉取数据到ceph rbd 磁盘，然后k8s将ceph rbd存储通过rbd csi插件挂载到pod中，用户因此也可以像操作本地磁盘数据一样，操作下载下来的Ai数据。
3.将minio通过s3fs进行包装，直接将minio与forge training进行集成，用户可以直接在forge training上进行操作，勾选需要的数据。具体操作参考openpai官方文档，如图所示：
我们提供三种存储的原因在于，s3fs对读操作很友好，但是在写功能上有很多限制，例如：不支持随机写，任何文件修改都需要重新上传整个文件。因此使用本地文件作为缓存，然后定期同步到minio对象存储。因为同步会造成大量重复写操作，forge training对写操作做了划分，一类是写大量的小文件操作，一类是模型同步等的大文件操作。小文件使用较短的同步周期，大文件使用较长的同步周期。
简而言之,如果只读就直接使用minio集群数据，如果读写可以拉取到本地磁盘，当本地磁盘大小不够时，考虑使用ceph rbd存储。
minio集群设计
因为我们的机器配置是，3210T hdd+21.8T nvme+万兆网卡。因为minio默认一个硬盘是一个driver,而minio 最大纠删码集是16，因此最多允许8块盘故障，如果单机32个driver,一旦一个机器节点宕机就容易导致数据丢失。为了解决这个问题可以有两个方案：
1.使用多个mino实例，每个实例4个驱动，4台机器，一共使用16个driver组建一个集群。由于我们每个机器有32个盘，因此每个机器需要启动8个实例
2.使用zfs,将多个driver合并成一个driver
由于第一种方案需要管理过多的实例，运维成本大幅增加，第二个方案不仅不用多个实例还可以利用zfs的raidz提升磁盘性能与容灾。所以minio设计方案如下
我们底层使用zfs将30个hdd做成一个存储池，2个ssd作为这个存储池的缓存，同时开启lz4压缩提高写入性能和增加存储空间利用。然后将每个存储池挂载到主机目录，然后minio使用这个目录作为driver,启动minio服务。因为启动的4个minio服务构成一个minio集群，为了统一访问入口和负载均衡，故使用nginx作为统一入口。
同时使用promethues收集minio集群信息，将prometheus和minio dashboard集成，实时展示minio集群信息。
每个minio服务都可以直接提供服务，因此如果对于性能要求比较高的场景，配置客户端访问minio集群时，可以不经过nginx,直接访问任意minio服务
性能与容灾
经测试,minio集群中任意磁盘故障，任意节点故障，都不影响数据完整性。同时还能提供相应的对象存储服务。
性能分为两部分，一是zfs磁盘读写性能，二是minio的读写性能。
zfs性能实践
考虑到系统的容灾能力，我们zfs直接使用raidz2的方式，因为不同数量的磁盘，zfs的读写能力不同，经测试后，发现15块盘左右做vdev性能会比较优异。大概读1.7g/s 写 561m/s 重写 627m/s
于是在15块盘做vdev基础上，又增加了nvme做读写缓存，启用lz4压缩进一步提升性能，最终zfs读写速度为：读2.2g/s 写 635m/s 重写 781m/s
minio性能
首先我们直接采用minio作者，推荐的方式，硬盘+xfs，一个硬盘对应一个driver。参考 minio issue，测试结果。
这个代码结构基本和eshopContainer一致。
