有一段时间没有更新了,最近几周节奏有些断档。
写在前面
松鼠哥的ceph专业课程上线啦!
面向新手同学,从0实战,全面入门ceph安装部署与运维,有需要的同学赶紧扫码订购吧:
开始前先说个事,半个月前有读者通过本博客的收款码进行打赏,数额不多,却是这个博客开通将近一年收到的第一笔打赏,在此表示感谢,很多读者反馈这个博客干货很多,看了有收获,这是我莫大的荣幸,接下来我也会一如既往地走干货路线,希望大家继续多多支持,也希望多点赠人玫瑰手有余香的行动,让我更有动力坚持下去
遇到的问题
ceph的部署是使用ceph的第一步,在社区讨论群不时有网友抛出各种安装问题求解答,实际上ceph的安装是极少会遇到问题的,我们使用了自定义的规范方式安装基本是没出现过问题,都非常顺利,部署使用的难题在于集群的规划和附属问题的考虑,这里专门讲一下PB级生产环境部署中会涉及的几个问题及本人的几点浅薄看法
上线前的部署及测试阶段,在这个阶段我们可以开始考虑这个集群上线前的若干问题
- 部署安装模式 ?
- 副本数 / EC 模式 ?
- 故障域 ?
- 业务场景需求对集群划分的影响 ?
- 扩容计划 ?
部署安装模式
先简单讲下部署安装的模式,很多网友在初次接触ceph的时候会选择官方的安装教程,其中使用ceph-deploy的方式进行部署是最简单快捷的,按照官方步骤下去很容易成功,在实际操作的时候,尤其是很多准生产环境是不允许集群环境直通公网,我们一般的做法是这样的:
- 1、使用一台刚安装完centos7.x minimal的设备,通过yum install –downloadonly的方式,将环境中所需要的所有包,例如htop、iotop之类的,只要是用得上的,都下载下来,做成一个内部yum源,常用的是ceph、ceph-radosgw、ceph-deploy、smartctl、htop、iotop、vim,后续所有内部节点的安装都指向这个源
- 2、在指定的节点上使用yum安装服务,例如osd节点就安装ceph,RGW节点就安装ceph-radosgw,使用yum先安装好所需要的全部包
- 3、使用ceph-deploy进行部署,起osd、创建mon、mgr、rgw等
- 4、如果是测试环境,需要经常重装ceph,可以将整个部署安装过程自动化,shell或者ansible都可以,一键部署集群,一键销毁集群,想想都觉得省事
副本 or EC的问题
出于成本考虑,尤其是一些中小企业,成本很敏感,调研ceph的时候会首先考虑单位GB的成本,自己做ceph划算不划算,干嘛不用云,等等,围绕方案选型可以考虑一下的问题:
1、可靠性要求?挂一个故障域,例如一台osd节点,如果是2副本,就等着中断业务吧,如果是三副本,也会出现明显的缓慢,或者坏盘的情况,一台osd节点中坏了几个盘,2副本等着集群卡出*吧,三副本感知没有那么明显,通过参数可以一定程度控制影响,请问业务可以接受吗?
2、性能要求?如果是副本,那么经过性能调优,并发、延时提升一波,业务指标符合就上线,不符合,加机器!EC?据说不理想,对象存储用EC的话值得认真调一下,过段时间更新一下EC的标准设备调优
3、设备数量?是的,跟手头准备投入的设备、磁盘数有一定关系,如果只有三台设备,2副本就别用了,故障域osd?挂一台机丢数据这种事还是别搞,3副本几乎是唯一选择,EC 2+1也算了吧,测试环境玩玩就行
故障域
故障域与副本、EC选择其实是不可分的,这里我们关注一下故障域涉及的crushmap问题
故障域考虑的是,不丢失数据的情况下最坏的情况,故障域的设计关乎数据可靠性,几个基本考虑面:
- 1、考虑到机柜可能的掉电,不同的节点尽可能位于不同的机柜
别说机房很可靠,功率跑太满整个机柜掉电是有可能的,特别是机柜上有其他业务的大功率机器,10卡服务器2000W一个柜子放它三四台了解一下?在相同机柜放置多台节点不是不行,故障域提升一个级别,rack级别,这样整个rack掉了也不心疼,噢,不是,不丢数据~
- 2、使用磁盘柜子的话,不同的磁盘柜子放在不同的机柜
原来做2副本,一个磁盘柜子放84个盘,柜子支持区域划分,我们就将一个柜子划分为两个区域,各42盘,故障域为box(有点搞笑的名字),一个柜子的两个区域位于不同的box,柜子掉电了也不心疼,就是业务不能用而已~
业务场景需求
有时候,一个集群需要承担不同的存储场景,比如块存储和对象存储同时存在,或者是一个集群面向多种客户,普通客户读写慢点,VIP客户读写快点,又或者数据可靠性要求不一致等等,都需要针对特定场景进行方案考虑,有网友说网上没有什么标准方案参考,每家公司有自己的场景和业务要求,很难说某些方案就是通用的,或者人家有,也不一定就给你说,所以这块资料少一些
首先,业务场景考虑的一般基本点有:
- 1、数据可靠性要求
有些核心数据要用三副本甚至跨机房同步,这部分要求高的数据要么单独一个集群,不差钱可以上,要么单独设计存储池,让存储池分布在高可靠的节点上,在对象存储中,可以通过创建zone之后,指定不同的业务使用不同的存储池的方式来实现,还能使用multi-site的功能实现跨机房的同步,实现更高的数据可靠保障
- 2、性能要求
有些业务,如原来做神经网络训练集群设计,GPU集群的场景要求高并发、低延时的读写,其他业务如商业智能截图的读写则只需要高并发,高容量,这种情况下为了更好利用节点性能,安排上一套集群的话,考虑在集群osd节点中加入一定数量的ssd磁盘,将低延时应用放置在这些高速设备上,从而满足要求,不差钱?全ssd集群安排上!
- 3、其他
其他的,例如cache池,读写分离等,都是特定业务要求下的具体实现,玩法也各不相同,具体碰到了,实践过来,再写上来分享
扩容计划
扩容是常见操作,也是ceph的一个设计优点,嗯~~也是缺点吧。优点呢,是因为ceph理论上是可以线性扩容,没有上限,当然理论上是这样,实际上集群到一定程度就要拆分了,几十台还是没啥问题的。说是缺点,扩容会带来明显的集群震荡,对线上业务有一定影响,另外,扩容要求也是有的,想加几台就加几台,想买什么盘就买什么盘是不切实际的,在可预见的未来,扩容计划如果有,应该及早打算,基于实线考虑扩容的基本点有这么几个:
- 1、磁盘型号、容量等
磁盘型号或者接口会一定程度体现磁盘的性能差异,集群中相同存储池的磁盘,差异越小越好,早期我们测试500G和2T的磁盘同一集群同一存储池,有时pg会计算不成功,一直卡住,容量差异实在太大,另外,磁盘性能差异大明显的会有木桶效应
- 2、扩容规模
扩容前加入多少的设备呢?磁盘数量、节点数量?基于故障域扩容是常见操作,例如故障域是host,直接加机器就行,故障域是rack的话,扩容时是往所有rack中加入相同数量的节点和osd,避免出现不同rack中数量、权重不相同的情况,也就是,故障域越高,扩容规模就越大
- 3、扩容方式
加入新设备后,我们遇到的扩容的方式会有两种情况:
第一种是对原有存储池的扩展,让这部分存储池的pg迁移到新的设备上,通过设置reweight之类的操作,控制新的平衡,或者,在新版本支持下使用balance进行更平滑的迁移,优点是数据分布趋于更均匀,集群乃至上层逻辑无需改动就可完成扩容,缺点很明显是业务容易感知,需要在低峰期进行
第二种是直接扩展新的存储池,在新设备上创建新的存储池,这样的话没有数据迁移,也定义了新数据的分布,另外,因为故障带来的震荡也有很好的抵抗作用,只影响了单个池子,好处很明显,缺点呢,池子会随着扩容的增加变多,而且业务上会不会需要改动也要针对场景进行分析
聊聊新环境
结合最近部署的一套环境,这里实践一下整个过程
设备环境
手上有的环境是这样的:
- 7台osd节点,36*6T,每台2个ssd,编号为osd-node0 -> osd-node6
- 3台mon/mgr节点,编号为mon-node7 -> mon-node9
- 2台rgw节点,编号为rgw-node10 -> rgw-node11
业务要求是既有RGW,也有RBD,网络是万兆 ,所有设备的机柜分布是
机柜1:
osd-node0 osd-node1 rgw-node10 mon-node7
机柜2:
osd-node2 osd-node3 osd-node4 rgw-node11 mon-node8
机柜3:
osd-node5 osd-node6 mon-node9
副本规划
考虑到数据的可靠性要求,我们划分是三副本,EC暂时没有考虑
故障域和业务场景
故障域没啥好说的,host,考虑到节点的位置和业务,划分如下:
RBD:使用osd-node0、osd-node2、osd-node5三台位于不同的机柜的节点
RGW:使用剩下的四台节点,副本数+1个故障域安排是高可用考虑,也是环境考虑,挂了一台节点,数据还能忘其他节点跑,那RBD怎么说?还不是设备不够….
另外,RGW的index池分布在四台设备的8个ssd上面,作为性能的优化
扩容相关
机器扩容,hosta故障域的话可以以节点为单位进行扩容,为什么不高一层,使用rack呢?理论上是能提升可靠性,但是扩容计划在短时间内没法确定,我们也没法要求客户买多少台节点,买多少个硬盘,所以暂时采取保守一点的做法
RBD准备采用存储池扩容的方式,因为只有在创建RBD的时候存储池相关,导出使用是存储池无关的,业务无需改动
RGW准备采用扩充原存储池的方式进行,参数控制或者balance实现,因为有业务低峰期,深夜可以加快扩容速度,最重要的是,平时写入并发、延时要求也不高,小规模缓慢扩容不容易被业务感知
osd tree情况,因为osd太多所以进行了部分省略,同时因为所有osd是并行创建的,osd id有点错位,但是不影响.
1 | [root@mon-node7 ~]# sudo ceph osd tree |
osd df的情况,在部署完成之后,进行了手动的reweight,所以pg分布很均匀
1 | [root@mon-node7 ~]# ceph osd df |
- 本文作者: 奋斗的松鼠
- 本文链接: http://www.strugglesquirrel.com/2019/03/26/谈谈几点ceph部署的看法/
- 版权声明: 本博客所有文章除特别声明外,创作版权均为作者个人所有,未经允许禁止转载!