本站以分享各种运维经验和运维所需要的技能为主
《python零基础入门》:python零基础入门学习
《python运维脚本》: python运维脚本实践
《shell》:shell学习
《terraform》持续更新中:terraform_Aws学习零基础入门到最佳实战
《k8》暂未更新
《docker学习》暂未更新
《ceph学习》ceph日常问题解决分享
《日志收集》ELK+各种中间件
《运维日常》运维日常
《linux》运维面试100问
一、扩容条件
a. 一般可用容量达到70%,就要开始考虑进行物理扩容,部分由于部署不合理导致的问题,可通过调节pg和weight进行调整。
**b.**扩容时需尽可能的评估当前业务规模,因为当集群达到一定规模后,累计的数据量是十分巨大的,所以尽可能的减少迁移操作。
c. 通过 ceph df 查看 %USED 是否已经达到70%,并通过ceph osd df 查看osd 使用率最高的和最低的使用率。 %USED 是按照使用率最高的osd算出来的,而ceph在一个osd满的情况下(阈值一般为0.95,告警为0.85),集群就不可用了。
例如,通过 ceph osd df | sort -k 8 查看到最低osd使用率40%,最高osd使用率为72%,误差32,这种情况很可能就是osd之间数据不均衡。
**d.**导出osd 的pg分布,查看到部分池的数据很少(几乎没有),但给予了1024pg,data数据量多的池在每个osd内分布的不均匀,例如在osd 1 中,总pg数为120,但data池的pg只占用60pg,其他池meta池占用30pg,但实际上meta池数据量远远少于data池。查看osd 181,发现data池pg为90,而且其容量只剩剩余2T,而osd 1剩余3.6T。从而导致可用容量按osd 181的显示,随着业务持续写入,很快就接近阈值,导致集群空间的浪费。
此时,应该调整池pg分布的均衡或者调节部分峰值的osd。
e. 若pg分布均衡且数据分布均衡,则考虑 物理扩容 。
二、扩容流程
扩容的过程主要是添加osd的过程,添加完osd后,还需看情况是否调节pg,具体可查看文档后面 计算需要调节pg
扩容过程主要分为4步(文档有具体描述):
(1)业务规模的评估
(2)扩容前的准备工作(包括环境的检查,pg数的计算,pg分布的统计)
(3)扩容过程中的故障处理(mon、osd进程故障,pg状态异常故障)
(4)扩容完的收尾动作(统计pg的分布图,调节迁移的速度等)
扩容时候出现的故障主要从 现网组网 系统 集群 进程的这几个维度进行排查
例如出现mon down时候,可通过mon进程所提示的err进行定位,从而转到集群的规模是否部分参数未放开限制,再到系统的内存不足或者网口负载太高,需调节系统参数,再到组网环境搭建进行排查,如交换机环路等。
(1)由于pg不均衡或者weight权重不相等的,可以通过调节osd的pg数,或者 weight值进行初步腾出容量。
|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| # 调节osd weight值 ceph osd reweight <osdname (id|osd.id)> <float[0.0-1.0]> # 调节pg数目 ceph osd pool set <poolname> pg_num|pgp_num <int> #int为最接近2的幂次方 |
若是由于池的pg不均衡导致,采用ceph balancer进行调整
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| # 查看集群得分 ceph balancer eval # 设置均衡策略(crush-compat) ceph balancer mode <upmap/crush-compat/none> None:表示什么都不做 Upmap:通过重新映射pg来平衡pg crush-compat: 通过重新设置osd的weight值触发pg的重新分布 # 设置均衡任务 ceph balancer optimize tune <pool_name> ceph balancer execute tune # 这时,在查看集群得分 ceph balancer eval |
(2)通过增加osd进行物理扩容
处理流程可在web上操作,这里提供添加osd的命令
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| # bluestore: ceph-deploy --overwrite-conf osd create node66 --data /dev/sdb --block-db /dev/sdd2 --block-wal /dev/sdd1 ceph-deploy --overwrite-conf osd create node66 --data /dev/sdc --block-db /dev/sde2 --block-wal /dev/sde1 ... # filestore ceph-deploy osd create --filestore --fs-type xfs --data /dev/sdb1 --journal /dev/sde1 node66ceph-deploy osd create --filestore --fs-type xfs --data /dev/sdc1 --journal /dev/sde2 node66 |
(3)扩容后,看情况是否需要增加pg,或者均衡池pg。pg均衡情况可通过脚本《pg均衡查询脚本》查看,脚本可私信获取。
pg的计算公式:
1、输出的值取舍到最接近的2的幂(最接近的2的幂提供了CRUSH算法效率的少量提高)
2、如果最接近的2的幂比原始值低25%以上,则使用下一个更高的2的幂
3、每个osd pg数目,建议值:
100 如果在可预见的将来,群集OSD的数量预计不会增加。
200 如果在可预见的将来,群集OSD的数量预计会增加(最多增加一倍)。
算法:
(每个OSD的目标PG)x(OSd总数)x(数据量百分比)/ (副本数)
ps:
如果以上计算的值小于(osd总数)/(副本数)的值,则该值将更新为(osd总数)/(副本数)的值。这是通过为每个池为每个OSD分配至少一个主或辅助PG来确保均匀的负载/数据分配
数据量(普通生产环境):
项 | .rgw.root | rgw.control | rgw.meta | rgw.log | rgw.buckets.index | rgw.buckets.data | rgw.buckets.non-ec |
---|---|---|---|---|---|---|---|
数据量占用率(%) | 0.2 | 0.1 | 0.3 | 0.6 | 1 | 94.8 | 3 |
三、扩容期间
(1)观察pg的状态(相关故障处理可根据《pg异常处理》处理)
Peering
peering的作用主要是在PG及其副本所在的OSD之间建立互联,并使得OSD之间就这些PG中的object及其元数据达成一致
Remapped
当负责维护某个PG的acting set变更时,PG需要从原来的acting set迁移至新的acting set。这个过程需要一段时间,所以在此期间,相关PG的状态便会标记为remapped
Backfills
当有新的OSD加入集群时,CRUSH会把现有集群内的部分PG分配给它。这些被重新分配到新OSD的PG状态便处于backfilling
Recovering
当某个OSD因为某些原因down了,该OSD内PG的object会落后于它所对应的PG副本。而在该OSD重新up之后,该OSD中的内容
必须更新到当前状态,处于此过程中的PG状态便是recovering
Degraded
当某个PG的副本数未达到规定个数时,该PG便处于degraded状态,例如:
在客户端向主OSD写入object的过程,object的副本是由主OSD负责向副本OSD写入的,直到副本OSD在创建object副本完成,并向主OSD发出完成信息前,该PG的状态都会一直处于degraded状态。又或者是某个OSD的状态变成了down,那么该OSD上的所有PG都会被标记为degraded。
当Ceph因为某些原因无法找到某个PG内的一个或多个object时,该PG也会被标记为degraded状态。此时客户端不能读写找不到的对象,但是仍然能访问位于该PG内的其他object
Active
处于该状态意味着数据已经完好的保存到了主PG及副本PG中,并且Ceph已经完成了peering工作
Clean
当某个PG处于clean状态时,则说明对应的主OSD及副本OSD已经成功互联,并且没有偏离的PG。也意味着Ceph已经将该PG中的对象按照规定的副本数进行了复制操作
(2)迁移参数调整
数据的迁移的相关参数,可根据业务数据流量的时间分布,进行适当的调整,加快迁移:
这个值存在平衡点:具体可看:https://blog.csdn.net/tony_vip/article/details/100122104
|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 思科参考值,具体视集群情况而定 osd recovery max active = 3 (default : 15) osd recovery op priority = 3 (default : 10) osd max backfills = 1 (default : 10) 参数注意事项: osd max backfills设置为10时,假如一个pg 50G数据 需要迁移10个,那么基本是迁移500G左右的数据的时候开始删除而 backfill为1的时候,就是迁移50G,开始删除一个,迁移50G删除一个,加大backfill反而阻碍了空间的释放。 osd_recovery_sleep = 0 在luminous版本已经设置成ssd是0,sata变成0.1,相当于增加了一个延时的过程 #不在意空间释放的话,也可以调大backfill sudo ceph tell osd.* injectargs '--osd_recovery_max_single_start 16 --osd_recovery_sleep_hdd 0 --osd_recovery_max_active 16 --osd_max_backfills 16' 【ceph】设置恢复数据速度之pg recover限流_ceph recovery速度_向往风的男子的博客-CSDN博客 |
(3)slow request
若迁移过程中出现slow request的情况,一般为集群过载了。主要可能有以下原因导致。
a. 池的pg数太少,导致某个池阻塞osd的情况
通过mon log日志,获取到阻塞osd的信息:
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 2021-01-12 00:04:05.257239 osd.3 osd.3 172.168.30.103:6801/908686 2976 : cluster [WRN] slow request 31.493678 seconds old, received at 2021-01-12 00:03:33.763381: osd_op(client.137288303.0:1137363 7.1a 7:590 |
这里可以看到osd.3阻塞了,pg序号为7.1a,查看对应的池(ceph df):
可查看到是default.rgw.log,在查看对应pg数目:
|--------------------------------------------------|
| ceph pg dump pgs|grep ^7.|awk '{print $1,$2}' |
环境上有80个osd,而pg只有32个,均摊到每个osd,平均一个都没有,并没有充分散列,假如维持单个osd承载10个相关pg,那么计算下来:
10*80/2=400 取最接近幂是512
512*2/80=12.8
平均每个osd上的为12.8个相关的pg,因为对象是207个,平坦下去每个pg只需要承担一个对象,平均每个osd承担不到3个对象,比现在的设置情况要好很多
b. 业务在某段时间突然触发增长
例如项目在凌晨12点时,业务方进行批量删除过期文件的操作,这无疑增加扩容时候的压力,而且其中穿插着设备的批量遍历操作和ceph生命周期操作。
故可结合现场环境进行调节:
a. 将ceph生命周期的迁移时间设置为:01:00 - 23:00,避开峰值时间段
|---------------------------------------|
| rgw_lifecycle_work_time = 01:00-23:00 |
b. 降低backfill修复对磁盘的压力
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ceph tell osd.* injectargs --osd_recovery_sleep_hdd 0.5 #默认为0.1# 效果recovery: 16.1MiB/s, 6objects/s ceph tell osd.* injectargs --osd_recovery_sleep_hdd 0.1 # 效果recovery: 82.1MiB/s, 32objects/s |
c. 将池后端使用SSD代替
若集群osd数目不能抗住大量元数据的操作,可将池使用SSD进行代替,缓解SSD的更新的时延,加大并发量。
(4)盘容量接近阈值
若存在扩容不及时,导致osd的容量还未释放,逐渐逼近设置盘满的阈值0.95,此时需手动操作,将阈值高的osd进行优先迁移。
|----------------------------------------------------------------------------|
| # 查看满盘osd 所需迁移的pg ceph pg dump pgs | grep <osd.x> | grep backfill_wait |
主要看UP 和 ACTING 列,可通过awk 过滤出来。
迁移流程为: ACTING[0,1] ---> UP[3,4] 尽量选取UP 为新加入的osd进行迁移。
尽量将 ACTING 中存在该osd 的pg进行优先迁移,同时设置该osd的backfill 为1,相当于加快迁移出去的数据,减慢迁移进来的数据。
|----------------------------------------------------------------------------------------|
| ceph pg force-backfill <pg_id>ceph tell <osd.x> injectargs "--osd_max_backfills 1" |
(5)迁移所需时间
迁移所需时间可通过下面脚本进行大致评估,ceph版本不同可能截取需要数据位置不同,需适当更改下脚本。
#! /bin/sh
while ( 2>1 )
do
start=`ceph -s|grep pgs|grep mis|awk '{print $2}'|cut -d / -f 1`
sleep 5
end=`ceph -s|grep pgs|grep mis|awk '{print $2}'|cut -d / -f 1`
speed=$((start-end))
#echo $end
#echo $speed
second=$((end/speed*5))
hour=$(( $second/3600 ))
min=$(( ($second-${hour}*3600)/60 ))
sec=$(( $second-${hour}*3600-${min}*60 ))
echo 当前时间:`date`
echo 迁移剩余:$end
echo 迁移速度:$((speed/5))
echo 迁移还需要:${hour}小时${min}分${sec}秒
echo "-------------------------------------"
done