深度学习后端分布式存储ceph技术建议书

深度学习后端分布式存储

ceph技术建议书-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KIIAI平台分布式存储(ceph)技术建议书目录TOC\o"1-5"\h\z\o"CurrentDocument"前言 3\o"CurrentDocument"现状 4\o"CurrentDocument"技术调研 5要求 5\o"CurrentDocument"技术选型 5分布式存储分类 5\o"CurrentDocument"特性对比 6\o"CurrentDocument"ceph 技术原理 6\o"CurrentDocument"基本组成 6逻辑架构 8\o"CurrentDocument"4.3.数据流程 9\o"CurrentDocument"资源要求 9\o"CurrentDocument"硬件指标 9cpu 10内存 10硬盘 10日志盘 11osd节点密度 11分配方式 11\o"CurrentDocument"网络结构 12\o"CurrentDocument"软件兼容性 13快速配置参考 14\o"CurrentDocument"数据安全 15\o"CurrentDocument"用户 15\o"CurrentDocument"认证机制 15\o"CurrentDocument"用户分类 16\o"CurrentDocument"授权类型 17\o"CurrentDocument"存储割接 18其他 181.前言目前公司AI平台所用后端数据存储包含三种方式，对象存储（0SS）：冷数据，备份数据，共享存储（NFS）:热数据，训练任务用数据，节点存储（DEV）:服务器自身磁盘，除了节点存储，其他两类在迁移容器云后依然保留，节点存储则不再使用。由于nfs服务的局限性，建议使用分布式共享存储替换当前的nfs方式，以满足后续的因业务增长，对存储的容量和性能更高要求。2.现状目前物理服务器5台，借用其他业务测试用主机构建NFS高可用，单机磁盘裸容量36T,为了增加磁盘的读写效率，同时保障数据安全性，做了RAID5+RAID0组合方式，该架构目前提供共计20T共享热数据文件存储。由于nfs容易上手，部署方便且快速，维护十分简单，在项目前期可以作为简单的共享存储使用，伴随着用户训练任务的增长，nfs方式的短板日趋明显，扩容受限，已不能够支撑后续多任务，多用户对数据的大批量、高性能读写请求。当前存在问题：容易发生单点故障，虽然采用keepalived高可用，但增加了维护的复杂度，同时更拔高了其他短板的表现，尤其在连接管理，效率性能方面，并且在两节点切换期间不可避免存在数据丢失情况；扩容受限，在高并发下NFS效率/性能有限；客户端没用用户认证机制，且数据是通过明文传送，无安全保障;e.多台机器挂载NFS服务器时，连接管理维护麻烦；3.技术调研要求目前公司提供的存储，能够和AI当前架构对接的仅限于OSS对象存储，其他的hdfs,hive、hbase均无法采用，公司的NAS资源有限，目前支撑其他项目，无扩容计划，不借用，在无资源和资金支撑下，分布式存储选择需要以下要求：✓文件存储：支持POSIX接口，可以像普通文件系统（如ext4）那样访问✓开源性：不采用第三方公司产品，或二次封装方式；✓安全性：能够满足最基本的用户接入控制，并不限于此；✓去中心化：高可用，能够纵向升级和横向扩展，即分布式需求；✓通用性：普通硬件，即能够正常运行Linux服务器即可；技术选型分布式存储已经研究很多年，但直到近年来，伴随着谷歌、亚马逊和阿里等互联网公司云计算和大数据应用的兴起，它才大规模应用到工程实践中。如谷歌的分布式文件系统GFS、分布式表格系统googleBigtable，亚马逊的对象存储AWS，阿里的TFS等都是很好的代表，同时也催生了一大批优秀的开源分布式存储系统，包括ceph、swift、Lustre和glusterfs等。3.2.1,分布式存储分类分布式存储按其存储接口分为三种：文件存储、块存储和对象存储。在主流的分布式存储技术中，HDFS/GPFS/GFS属于文件存储，Swift属于对象存储，而Ceph可支持块存储、对象存储和文件存储，故称为统一存储。文件存储通常支持POSIX接口（如glusterfs，但GFS、HDFS是非POSIX接口的），可以像普通文件系统（如ext4）那样访问，但又比普通文件系统多了并行化访问的能力和冗余机制。主要的分布式文件存储系统有TFS、cephfs、glusterfs和HDFS等。主要存储非结构化数据，如普通文件、图片、音视频等。可以采用NFS和CIFS等协议访问，共享方便。块存储这种接口通常以QEMUDriver或者KernelModule的方式存在，主要通过qemu或iscsi协议访问。主要的块存储系统有ceph块存储、sheepdog等。主要用来存储结构化数据，如数据库数据。数据共享不方便。DAS和SAN都是块存储类型。对象存储对象存储系统综合了NAS和SAN的优点，同时具有SAN的高速直接访问和NAS的数据共享等优势。以对象作为基本的存储单元，向外提供RESTful数据读写接口，常以网络服务的形式提供数据访问。主要的对象存储系统有AWS、swift和ceph对象存储。主要用来存储非结构化数据。3.2.2,特性对比按照选型要求和各技术特性对比，规划采用ceph方式的文件系统。CephGFSHDFSSwiftLustrefrlusterfs平台属性开源开源开晅开源开源系统架构云中心化中心化中心化去中心化口心化去中心化教据存赭方式块、立件、对象玄件文件文件文件、对象元勘据节点数里咨个1个1个（主卜）多个1个天教据冗窠参副本参副本多副本参副本无数据一致性强一致性最终一致性过程一致性弱—致性无弱—玫性分块大小（默认）4MB64MB128MB现对象大小1MB适用场晨小文件颁繁读写大文件连续读与大教据场景云对象存储大文件连续读写（HPC超算）大文件读写4.ceph技术原理4.1.基本组成Ceph支持三种存储接口：对象存储RGW（radosgateway）、块存储RBD（radosblockdevice）和文件存储CephFS，这三个接口只是在客户端的封装库不同，到服务端了都是对象存储；

■X应用（仃接访问RADOS）对景存陆接口

■X应用（仃接访问RADOS）对景存陆接口

（SS/S'ivifi）丈件系统接口埃存储接口（物理主机，虚拟机）（libcephfs廊posix接口}数据JibrM元数据元数据服务

器（MDSJlil）iaclo^［访问ILADOS对象存系统的作.支持CO-而诵PyrhmR讷yPHP、RAJg旨对象存朝系统（可辙的.目如织的、国自动惟卖.自捷竹理的分布式对象存慵系统】对象存储（RGW：RADOSgateway）Ceph对象存储服务提供了REST风格的API，它有与AmazonS3和OpenStackSwift兼容的接口。也就是通常意义的键值存储，其接口就是简单的GET、PUT、DEL和其他扩展；块存储（RBD：RADOSblockdevice）RBD是通过librbd库对应用提供块存储，主要面向云平台的虚拟机提供虚拟磁盘；RBD类似传统的SAN存储，提供数据块级别的访问；目前RBD提供了两个接口，一种是直接在用户态实现，通过QEMUDriver供KVM虚拟机使用。另一种是在操作系统内核态实现了一个内核模块。通过该模块可以把块设备映射给物理主机，由物理主机直接访问。文件存储Ceph文件系统服务提供了兼容POSIX的文件系统，可以直接挂载为用户空间文件系统。它跟传统的文件系统如Ext4是一个类型，区别在于分布式存储提供了并行化的能力；原生接口除了以上3种存储接口，还可以直接使用librados的原生接口，直接和RADOS通信；原生接口的优点是是它直接和和应用代码集成，操作文件很方便；但它的问题是它不会主动为上传的数据分片；一个1G的大对象上传，落到Ceph的存储磁盘上就是1G的文件；ceph的组件采用插件的机制，包括后端存储，KV数据库，磁盘管理等。各组件之间可以灵活的组合。ceph的组件采用插件的机制，包括后端存储，KV数据库，磁盘管理等。各组件之间可以灵活的组合。CephMonitor（ceph-mon）维护集群状态的映射，包括监视器映射，管理器映射，OSD映射和CRUSH映射。这些映射是Ceph守护进程相互协调所需的关键集群状态。监视器还负责管理守护进程和客户端之间的身份验证。冗余和高可用性通常至少需要三个监视器。CephManager守护程序（ceph-mgr）负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载。CephManager守护进程还托管基于python的插件来管理和公开Ceph集群信息，包括基于Web的仪表板和RESTAPI。高可用性通常至少需要两名经理。CephOSD（对象存储守护进程ceph-osd）存储数据，处理数据复制，恢复，重新平衡，并通过检查其他CephOSD守护进程来获取心、跳，为Ceph监视器和管理器提供一些监视信息。冗余和高可用性通常至少需要3个CephOSD。Ceph元数据服务器（MDSceph-mds）代表Ceph文件系统存储元数据（即，Ceph块设备和Ceph对象存储不使用MDS）。Ceph的元数据服务器允许POSIX文件系统的用户来执行基本的命令（如ls，find没有放置在一个Ceph存储集群的巨大负担，等等）。4.3.数据流程ceph寻址过程file object映射，把file分割成N个相同的对象object-PG映射，利用静态hash得到objectID的伪随机值，在"位与"mask上使得object获取属于自己的PGpg--osd映射，将pg映射到实际的存储单元osd，RADOS利用crush算法，由pgid得到一组n个osd，再由osddaemon执行映射到本地的object在本地系统中存储，访问，数据维护，此次映射功能直接受到crushmap以及rule限制，只有clustermap和rule不发生改变时，pg和osd的映射关系才固定。散据客户端CRUSHPCilPG-1OSD-1□ND」散据客户端CRUSHPCilPG-1OSD-1□ND」OSD-4资源要求5.1.硬件指标Ceph可以运行在廉价的普通硬件上，小型生产集群和开发集群可以在一般的硬件上，PB级生产集群也可以使用普通硬件，但应该配备更多内存、CPU和数据存储空间来解决流量压力。5.1.1.cpu每一个osd守护进程至少有一个cpu核，计算公式如下：((cpusockets*cpucorespersoket*cpuclockspeedinGHZ)/No.OfOSD)>=1例如：一台服务器拥有一个单插座，6核，2.5Ghz的cpu，就足以支持12个osd，每个osd将大致得到1.25FGhz的计算能力((1*6*2.5)/12)=1.25IterXeonProcessorE5-2620(2.4GHz,6core)1*6*2.40=14.1适合多达14个osd的ceph节点5.1.2.内存moniter和metadata的守护进程，一般会随着集群的大小而变化，cephmds很大程度上取决于数据缓存，需要大量的RAM，RAM越高，cephfs性能越好。osd会要求数量客观的内存，一般每个OSD守护进程1G足以，不过从性能上讲每个守护进程2G是一个更好的选择。5.1.3,硬盘当一个osd接受请求写一个object时，它会首先把object写到pgactingset中的osd对应的日志盘，然后发送一个写确认给客户端，很快日志数据会同步到数据盘，使用ssd做日志盘，可以减少访问时间，降低写延迟，大幅提升吞吐量。OSD应该有足够的硬盘空间来存放对象数据。我们建议硬盘驱动器的最小容量为1T。考虑到较大磁盘的每GB的成本优势。我们建议将硬盘驱动器的价格除以千兆字节，得出每千兆字节的成本，因为较大的驱动器可能会对每千兆字节的成本有很大影响。例如，价格为75美元的1T硬盘，每千兆字节的成本为0.07美元。相比之下，价格为150美元的3T硬盘的成本为每千兆字节0.05美元。在上述例子中，使用1T硬盘通常会使每千兆字节的成本增加40%——使集群的成本效益大大降低。Tips:在一个磁盘上运行多个OSD，无论分区如何，都不是一个好主意Tips：在单一磁盘上运行OSD、写日志、或者元数据服务器，无论分区如何，都不是一个好主意Ceph最佳实践规定，你应该在不同的驱动器上运行操作系统、OSD数据和OS。日志日志盘在sata/sasssd上获取高性能，ssd和osd的比例应该为1:4,也就是说4个OSD数据硬盘可共享一个ssdPCIe或者NVMe闪存设备的情况取决也设备性能，ssd和。sd壁垒可以达到1：12或者1:18osd节点密度osd数据分区Cephosd节点的密度也是影响集群性能、可用容量和TCO的一个重要因素，一般来说大量的小容量量节点比少量的大容量节点要好，但这不是定论，应该选择适当的cephosd节点的密度，是单个节点容量小于总集群容量的10%。例如：在一个1PB的ceph集群，你应该避免使用4个250Tb的osd节点，因为每个几点占用了25%的集群容量，相反，你可以使用13个80TB的osd节点，每个节点容量小于集群容量的10%，但是这回增加你的TCO,具体实施期间依赖存储容量需求评估，依照该评估规划适宜的节点密度。分配方式按照ceph逻辑组件构成，分布式集群需要承载4类进程，组网方式有两种：精简型，完全型，为了达到资源利用最大化，采用精简型，即OSD进程和其他进程合设。完全型方式：对于物理资源充裕情况下，采用该模式，管理节点和数据节点分开部署，架构清晰，便于维护、减少进程干扰。节点节点类型进程备注node01管理节点mon、mgr、mdsnode02管理节点mon、mgr、mds

mon、mgrmon、mgr、mdsosdosdosdnode04数据节点… 数据节点node0N数据节点精简型方式:由于管理进程和数据进程在资源耗用上各有偏重，影响不大，在资源受限情况下可以采用该模式，所有节点均为数据节点，按照规划把管理进程合设到指定数据节点即可。节点节点类型 ■进程备注node01管理节点、数据节点osd、mon、mgr可以合设其他节点node02管理节点、数据节点osd、mon、mgr可以合设其他节点node03管理节点、数据节点osd、mon、mgr可以合设其他节点node04数据节点osd、mds可以合设其他节点…数据节点osd、mds可以合设其他节点NodeN数据节点osd、mds可以合设其他节点5.2.网络结构少量节点的ceph集群，1Gbps网络速率可以满足正常运行，如果是一个中型或大型的网络（数十个节点），应该考虑使用万兆甚至更高带宽的网络。数据恢复和重新平衡期间，网络很重要，如果有10G的网络会缩短集群恢复的时间。比如：在1Gbps网络上复制1TB的数据需要3个小时，而10TB需要30个小时！相比之下，使用10Gbps网络，复制时间分别需要20分钟和1小时。但每个流量路径都代表了潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前，您应该仔细考量，建议双明面，或者三网规划。IheclusternetwoilkrelievesOSDreplicationandheartbeattrafficfromthepublicnetwork.CephMD5IheclusternetwoilkrelievesOSDreplicationandheartbeattrafficfromthepublicnetwork.CephMD5（1）提高性能：消除副本创建、数据恢复和再平衡对publicnetwork的压力；增强OSD心跳网络的可靠性。(2)安全性：使用一个彻底与外网分离的内部网络作为clusternetwork，可以防止比如DDOS这样的网络攻击。5.3.软件兼容性按常规来说，我们建议在较新的Linux发行版上部署Ceph；同样，要选择长期支持的版本，当前我们推荐：4.1.4orlater3.16.3orlater(rbddeadlockregressionin3.16.[0-2])NOTv3.15.*(rbddeadlockregression)3.14.*如果您坚持用很旧的，可以考虑这些：3.10.*更详尽的操作系统版本和内核请参考：/start/os-recommendations/进程类型硬件类型建议的最低标准ceph-osdProcessor最低一核200-500MB/S单核心1000-3000IOPS单核心结果是复甘之前的结果结果可能会因为小同的LPU型号和区ph切能血木同〔纠环码池、压缩等）ARM处理器可能会蔻更多的核心实际性能取决于许务因表r包括磴盘、网络、春户端吞吐量和延退。我们强烈建丧进行菖准测试RAM每个咨护进程4GB以上（越多越好）2-4GB可以正常工作（可能瓮很慢）低于2GE是不推荐的VolumeStorage每个守护进程对应一块硬盘DB/WAL每个守护进程对应一个SSD分区（可选）hJetwork最少一块千兆以上的网卡C万兆网卡是被推荐的｝ceph-monProcessor最低一核RAM每个进程2GB以上的内有DiskSpace每进程10G日以上的硬盘空间hJetwork最少一块千兆以上的网卡ceph-mdsProcessor最低一核RAM每个进程2GB以上的内存DiskSpace每个进程IMB以上的硬盘空间hJetwork最少一块千兆以上的网卡数据安全6.1.用户Cephstoragecluster的认证和授权默认是启用的。Ceph的客户端用户要么是独立的个体用户，要么是系统中的一个应用，他们都使用ceph的客户端与ceph存储集群交互。usesClientsSei"versusesClientsSei"versCeph的用户可以是一个具体的人或系统角色（e.g.应用程序），Ceph管理员通过创建用户并设置权限来控制谁可以访问、操作CephCluster、Pool或Objects等资源。6.2.认证机制Ceph提供了两种身份认证方式：None和CephX。前者表示客户端不需要通过密钥访问即可访问Ceph存储集群，显然这种方式是不被推荐的。所以我们一般会启用CephX认证系统，通过编辑ceph.conf开启采用cephx验证机制，每个用户操作ceph时均需要一个表达身份的Keyring文件。当我们在ceph-deploy节点上操作ceph命令时，系统隐含的认为我们是管理员，意即在/etc/ceph/目录下有一个ceph.client.admin.keyring，对于其他用户来说，若需要通过cephx验证，必须为每个用户创建不同的代表身份的keyring文件，此文件不仅说明了用户名，还标记了用户所具备的权限。

Client Monitorgeneialeandencryptsessionkeygeneriiteandencryptticketauthenticategeneialeandencryptsessionkeygeneriiteandencryptticketti'anstnitenci-yptedlsessionkey deci-yptsession4 keyreq.ticketrecvilicketdeciyptticket用户通过客户端向MON发起请求。客户端将用户名传递到MON。MON对用户名进行检查，若用户存在，则通过加密用户密钥生成一个 sessionkey并返回客户端。客户端通过共享密钥解密sessionkey，只有拥有相同用户密钥环文件的客户端可以完成解密。客户端得到sessionkey后，客户端持有sessionkey再次向MON发起请求MON生成一个ticket，同样使用用户密钥进行加密，然后发送给客户端。客户端同样通过共享密钥解密得到ticketo往后，客户端持有ticket向MON、