深度学习后端分布式存储ceph技术建议书.docx
- 文档编号:30505165
- 上传时间:2023-08-16
- 格式:DOCX
- 页数:17
- 大小:943.47KB
深度学习后端分布式存储ceph技术建议书.docx
《深度学习后端分布式存储ceph技术建议书.docx》由会员分享,可在线阅读,更多相关《深度学习后端分布式存储ceph技术建议书.docx(17页珍藏版)》请在冰豆网上搜索。
深度学习后端分布式存储ceph技术建议书
本页仅作为文档封面,使用时可以删除Thisdocumentisforreferenceonly-rar21year.March
深度学习后端分布式存储ceph技术建议书
AI平台分布式存储
(ceph)
技术建议书
1.前言
目前公司AI平台所用后端数据存储包含三种方式,对象存储(OSS):
冷数据,备份数据,共享存储(NFS):
热数据,训练任务用数据,节点存储(DEV):
服务器自身磁盘,除了节点存储,其他两类在迁移容器云后依然保留,节点存储则不再使用。
由于nfs服务的局限性,建议使用分布式共享存储替换当前的nfs方式,以满足后续的因业务增长,对存储的容量和性能更高要求。
2.现状
目前物理服务器5台,借用其他业务测试用主机构建NFS高可用,单机磁盘裸容量36T,为了增加磁盘的读写效率,同时保障数据安全性,做了RAID5+RAID0组合方式,该架构目前提供共计20T共享热数据文件存储。
由于nfs容易上手,部署方便且快速,维护十分简单,在项目前期可以作为简单的共享存储使用,伴随着用户训练任务的增长,nfs方式的短板日趋明显,扩容受限,已不能够支撑后续多任务,多用户对数据的大批量、高性能读写请求。
当前存在问题:
a.容易发生单点故障,虽然采用keepalived高可用,但增加了维护的复杂度,同时更拔高了其他短板的表现,尤其在连接管理,效率性能方面,并且在两节点切换期间不可避免存在数据丢失情况;
b.扩容受限,在高并发下NFS效率/性能有限;
c.客户端没用用户认证机制,且数据是通过明文传送,无安全保障;
e.多台机器挂载NFS服务器时,连接管理维护麻烦;
3.技术调研
3.1.要求
目前公司提供的存储,能够和AI当前架构对接的仅限于OSS对象存储,其他的hdfs,hive、hbase均无法采用,公司的NAS资源有限,目前支撑其他项目,无扩容计划,不借用,在无资源和资金支撑下,分布式存储选择需要以下要求:
✓文件存储:
支持POSIX接口,可以像普通文件系统(如ext4)那样访问
✓开源性:
不采用第三方公司产品,或二次封装方式;
✓安全性:
能够满足最基本的用户接入控制,并不限于此;
✓去中心化:
高可用,能够纵向升级和横向扩展,即分布式需求;
✓通用性:
普通硬件,即能够正常运行Linux服务器即可;
3.2.技术选型
分布式存储已经研究很多年,但直到近年来,伴随着谷歌、亚马逊和阿里等互联网公司云计算和大数据应用的兴起,它才大规模应用到工程实践中。
如谷歌的分布式文件系统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方式的文件系统。
4.ceph技术原理
4.1.基本组成
Ceph支持三种存储接口:
对象存储RGW(radosgateway)、块存储RBD(radosblockdevice)和文件存储CephFS,这三个接口只是在客户端的封装库不同,到服务端了都是对象存储;
对象存储(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的文件;
4.2.逻辑架构
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 寻址过程
1.file---object映射, 把file分割成N个相同的对象
2. object-PG 映射, 利用静态hash得到objectID的伪随机值,在"位与"mask 上使得object获取属于自己的PG
3. pg-- osd 映射, 将pg映射到实际的存储单元osd, RADOS 利用 crush 算法, 由pgid得到一组n个osd,再由osd daemon 执行映射到本地的object在本地系统中存储,访问,数据维护, 此次映射功能直接受到crush map 以及rule限制,只有cluster map 和 rule不发生改变时,pg 和osd的映射关系才固定。
5.资源要求
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.25
IterXeonProcessorE5-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数据和OSD日志
5.1.4.日志盘
在sata/sasssd上获取高性能,ssd和osd的比例应该为1:
4,也就是说4个OSD数据硬盘可共享一个ssd
PCIe或者NVMe闪存设备的情况取决也设备性能,ssd和osd壁垒可以达到1:
12或者1:
18
5.1.5.osd节点密度
osd数据分区Cephosd节点的密度也是影响集群性能、可用容量和TCO的一个重要因素,一般来说大量的小容量量节点比少量的大容量节点要好,但这不是定论,应该选择适当的cephosd节点的密度,是单个节点容量小于总集群容量的10%。
例如:
在一个1PB的ceph集群,你应该避免使用4个250Tb的osd节点,因为每个几点占用了25%的集群容量,相反,你可以使用13个80TB的osd节点,每个节点容量小于集群容量的10%,但是这回增加你的TCO,具体实施期间依赖存储容量需求评估,依照该评估规划适宜的节点密度。
5.1.6.分配方式
按照ceph逻辑组件构成,分布式集群需要承载4类进程,组网方式有两种:
精简型,完全型,为了达到资源利用最大化,采用精简型,即OSD进程和其他进程合设。
完全型方式:
对于物理资源充裕情况下,采用该模式,管理节点和数据节点分开部署,架构清晰,便于维护、减少进程干扰。
节点
节点类型
进程
备注
node01
管理节点
mon、mgr、mds
node02
管理节点
mon、mgr、mds
node03
管理节点
mon、mgr、mds
node04
数据节点
osd
…
数据节点
osd
node0N
数据节点
osd
精简型方式:
由于管理进程和数据进程在资源耗用上各有偏重,影响不大,在资源受限情况下可以采用该模式,所有节点均为数据节点,按照规划把管理进程合设到指定数据节点即可。
节点
节点类型
进程
备注
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小时。
但每个流量路径都代表了潜在的容量、吞吐量和/或性能瓶颈,在部署大规模数据集群之前,您应该仔细考量,建议双明面,或者三网规划。
(1)提高性能:
消除副本创建、数据恢复和再平衡对publicnetwork的压力;增强OSD心跳网络的可靠性。
(2)安全性:
使用一个彻底与外网分离的内部网络作为clusternetwork,可以防止比如DDOS这样的网络攻击。
5.3.软件兼容性
按常规来说,我们建议在较新的Linux发行版上部署Ceph;同样,要选择长期支持的版本,当前我们推荐:
✓4.1.4orlater
✓3.16.3orlater(rbddeadlockregressionin3.16.[0-2])
✓NOTv3.15.*(rbddeadlockregression)
✓3.14.*
如果您坚持用很旧的,可以考虑这些:
✓3.10.*
更详尽的操作系统版本和内核请参考:
5.4.快速配置参考
6.数据安全
6.1.用户
Cephstoragecluster的认证和授权默认是启用的。
Ceph的客户端用户要么是独立的个体用户,要么是系统中的一个应用,他们都使用ceph的客户端与ceph存储集群交互。
Ceph的用户可以是一个具体的人或系统角色(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文件,此文件不仅说明了用户名,还标记了用户所具备的权限。
1.用户通过客户端向MON发起请求。
2.客户端将用户名传递到MON。
3.MON对用户名进行检查,若用户存在,则通过加密用户密钥生成一个sessionkey并返回客户端。
4.客户端通过共享密钥解密sessionkey,只有拥有相同用户密钥环文件的客户端可以完成解密。
5.客户端得到sessionkey后,客户端持有sessionkey再次向MON发起请求
6.MON生成一个ticket,同样使用用户密钥进行加密,然后发送给客户端。
7.客户端同样通过共享密钥解密得到ticket。
8.往后,客户端持有ticket向MON、OSD发起请求。
6.3.用户分类
Ceph的用户类型可以分为以下几类:
客户端用户
操作用户(e.g.client.admin)
应用程序用户(e.g.client.cinder)
其他用户
Ceph守护进程用户(e.g.mds.ceph-node1、osd.0)
用户命名遵循
NOTE:
为Ceph守护进程创建用户,是因为MON、OSD、MDS等守护进程同样遵守CephX协议,但它们不能属于真正意义上的客户端。
6.4.授权类型
Ceph用能力(capabilities,caps)这个术语来描述给认证用户的授权,这样才能使用监视器、OSD、和元数据服务器的功能。
能力也用于限制对一存储池内的数据或某个名字空间的访问。
Ceph的管理用户可在创建或更新某用户时赋予他能力。
allow:
在守护进程进行访问设置之前就已经具有特定权限,常见于管理员和守护进程用户。
r:
授予用户读的权限,读取集群各个组件(MON/OSD/MDS/CRUSH/PG)的状态,但是不能修改。
w:
授予用户写对象的权限,与r配合使用,修改集群的各个组件的状态,可以执行组件的各个动作指令。
x:
授予用户调用类方法的能力,仅仅和cephauth操作相关。
class-read:
授予用户调用类读取方法的能力,是x的子集。
class-write:
授予用户调用类写入方法的能力,是x的子集。
*:
授予用户rwx权限。
profileosd:
授权用户以OSD身份连接到其它OSD或MON,使得OSD能够处理副本心跳和状态汇报。
profilemds:
授权用户以MDS身份连接其它MDS或MON。
profilebootstrap-osd:
授权用户引导OSD守护进程的能力,通常授予部署工具(e.g.ceph-deploy),让它们在引导OSD时就有增加密钥的权限了。
profilebootstrap-mds:
授权用户引导MDS守护进程的能力。
同上。
NOTE:
Ceph客户端不直接访问Objects,而是必须要经过OSD守护进程的交互。
7.存储割接
由于ceph提供基于POSIX接口的文件系统方式挂载,在业务服务器安装cpeh客户端,使用基本的mount即可进行挂载,所以数据迁移和系统割接不会存在特殊要求,在数据迁移完毕后,即可进行目录挂载源切换即可。
8.其他
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 深度 学习 后端 分布式 存储 ceph 技术 建议书