2016-11-07
After upgrading to 10.2.3 we frequently see messages like ‘rm: cannot remove ‘…’: No space left on device The folders we are trying to delete contain approx. 50K files 193 KB each. The cluster state and storage available are both OK: cluster 98d72518-6619-4b5c-b148-9a781ef13bcb health HEALTH_WARN mds0: Client XXX.XXX.XXX.XXX failing to respond to cache pressure mds0: Client XXX.XXX.XXX.XXX failing to respond to cache pressure mds0: Client XXX.XXX.XXX.XXX failing to respond to cache pressure mds0: Client XXX.XXX.XXX.XXX failing to respond to cache pressure mds0: Client XXX.XXX.XXX.XXX failing to respond to cache pressure monmap e1: 1 mons at {000-s-ragnarok=XXX.XXX.XXX.XXX:6789/0} election epoch 11, quorum 0 000-s-ragnarok fsmap e62643: 1/1/1 up {0=000-s-ragnarok=up:active} osdmap e20203: 16 osds: 16 up, 16 in flags sortbitwise pgmap v15284654: 1088 pgs, 2 pools, 11263 GB data, 40801 kobjects 23048 GB used, 6745 GB / 29793 GB avail 1085 active+clean 2 active+clean+scrubbing 1 active+clean+scrubbing+deep
Has anybody experienced this issue so far?
这个问题是作者在升级了一个集群以后(jewel 10.2.3),做删除的时候,发现提示了 No space left on device,按正常的理解做删除不会出现提示空间不足
这个地方的原因是,有一个参数会对目录的entry做一个最大值的控制mds_bal_fragment_size_max
,而这个参数实际上在做删除操作的时候,当文件被unlink的时候,被放入待删除区的时候,这个也是被限制住的,所以需要调整这个参数,如果有上百万的文件被等待删除的时候,可能就会出现这个情况,并且出现 failing to respond to cache pressure
我们根据自己的需要去设置这个值
默认的 mds_bal_fragment_size_max=100000,也就是单个文件10万文件,如果不调整,单目录写入10万文件就能出现上面的问题
这个地方可以用命令来监控mds的当前状态
[root@lab8106 mnt]# ceph daemonperf mds.lab8106
-----mds------ --mds_server-- ---objecter--- -----mds_cache----- ---mds_log----
rlat inos caps|hsr hcs hcr |writ read actv|recd recy stry purg|segs evts subm|
0 163k 5 | 0 0 0 | 0 0 36 | 0 0 145k 0 | 33 29k 0
0 163k 5 | 0 0 0 | 6 0 34 | 0 0 145k 6 | 33 29k 6
0 163k 5 | 0 0 0 | 24 0 32 | 0 0 145k 24 | 32 29k 24
0 163k 5 | 0 0 0 | 42 0 32 | 0 0 145k 42 | 32 29k 42
0 159k 5 | 0 0 0 |972 0 32 | 0 0 144k 970 | 33 27k 971
0 159k 5 | 0 0 0 |905 0 32 | 0 0 143k 905 | 31 28k 906
0 159k 5 | 0 0 0 |969 0 32 | 0 0 142k 969 | 32 29k 970
0 159k 5 | 0 0 0 |601 0 31 | 0 0 141k 601 | 33 29k 602
这个地方还有一个硬链接删除以后没有释放stry的问题,最新版的master里面已经合进去了代码(scan_link)
修复过程如下 执行flush MDS journal
ceph daemon mds.xxx flush journal
停止掉所有mds
stop all mds
执行
cephfs-data-scan scan_links
重启mds
restart mds
执行命令
ceph daemon mds.x scrub_path / recursive repair
执行完了以后去对目录进行一次ll,可以看到mds_cache的stry的就会被清理干净了
这个问题就可以解决了,实际测试中在换了新版本以后,重启后然后进行目录的ll,也能清空stry
Hi all, as it took quite a while until we got our Ceph cache working (and we’re still hit but some unexpected things, see the thread Ceph with cache pool - disk usage / cleanup), I thought it might be good to write a summary of what I (believe) to know up to this point. Any feedback, especially corrections is highly welcome! http://maybebuggy.de/post/ceph-cache-tier/ Greetings -Sascha-
这是一篇分享文,作者因为最近想深入研究下ceph的cache pool,作者写的文章非常的好,这里先直接翻译这篇文章,然后再加入我自己的相关数据
作者想启动blog写下自己的Openstack和Ceph的相关经验,第一个话题就选择了Ceph cache tiering
, 作者的使用场景为短时间的虚拟机,用来跑测试的,这种场景他们准备用Nvme做一个缓冲池来加速的虚拟机
cache 相关的一些参数
target_max_bytes
target_max_objects
cache_target_dirty_ratio
cache_target_full_ratio
cache_min_flush_age
cache_min_evict_age
Jewel版本还新加入了一个参数
cache_target_dirty_high_ratio
作者的想法是先把数据写入到缓冲池当中,等后面某个时刻再写入到真实的存储池的当中
Flushing vs. Evicting Flushing是将缓冲池中的数据刷到真实的存储池当中去,但是并不去删除缓冲池里面缓存的数据,只有clean的数据才能被evic,如果是dirty的数据做evic,那么先要flush到真实存储池,然后再删除掉
Cache 调整
Ceph的是不能够自动确定缓存池的大小,所以这里需要配置一个缓冲池的绝对大小,flush/evic将无法工作。
设置了上限以后,相关的参数就是cache_target_full_ratio和cache_target_dirty_ratio。这些参数是控制什么时候进行flush和evic的
这个dirty ratio是比较难设置的值,需要根据场景进行相关的调整
新版本里面到了dirty_high_ratio才开始下刷
还有cache_min_flush_age和cache_min_evict_age这个控制,这个一般来说到了设定的阀值前,这些对象的留存时间应该是要够老的,能够被触发清理掉的
通过ceph df detail 可以观测你的存储池的数据的情况
里面会有一些0字节对象的,缓冲池的0字节对象是数据已经被删除了,防止刷新的时候又要操作对象。在真实存储池中的0字节对象是数据已经在缓冲池当中,但没有刷新到缓冲池
基于上面的控制,下面我们来具体看下这些参数的实际效果是怎样的,这样我们才能真正在实际场景当中做到精准的控制
首先我们要对参数分类
分好类以后,我们就开始我们的测试,基于对象的数目的控制,比较容易观察,我们就用对象控制来举例子
ceph osd pool create testpool 24 24
ceph osd pool create cachepool 24 24
ceph osd tier add testpool cachepool
ceph osd tier cache-mode cachepool writeback
ceph osd tier set-overlay testpool cachepool
ceph osd pool set cachepool hit_set_type bloom
ceph osd pool set cachepool hit_set_count 1
ceph osd pool set cachepool hit_set_period 3600
上面的操作是基本的一些操作、我们现在做参数相关的调整
ceph osd pool set cachepool target_max_bytes 1000000000000
为了排除干扰,我们把 target_max_bytes设置成了1T,我们的测试数据很少,肯定不会触发这个大小
ceph osd pool set cachepool target_max_objects 1000
设置缓冲池的对象max为1000
ceph osd pool set cachepool cache_target_dirty_ratio 0.4
设置dirty_ratio为0.4,也就是0.4为判断为dirty的阀值
ceph osd pool set cachepool cache_target_full_ratio 0.8
设置cache_target_full_ratio为0.8,即超过80%的时候需要evic
ceph osd pool set cachepool cache_min_flush_age 600
ceph osd pool set cachepool cache_min_evict_age 1800
设置两个flush和evic的时间,这个时间周期比我写入的数据的时间周期大很多,这个等下会调整这个
开启一个终端动态观察存储池的对象变化
[root@lab8106 ~]# watch ceph df
Every 2.0s: ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
834G 833G 958M 0.11
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
rbd 0 0 0 277G 0
metadata 1 61953k 0.01 416G 39
data 2 50500k 0.01 416G 50501
testpool 5 0 0 416G 0
cachepool 6 0 0 416G 0
尝试写入数据并且观察,到了1000左右的时候停止
rados -p testpool bench 100 write -b 4K --no-cleanup
可以观察到cachepool的对象数目大概在1100-1200之间,一直写也会是这个数字,在停止写以后,观察cachepool的对象数目在960左右,我们设置的 target_max_objects 为1000,在超过了这个值以后,并且写停止的情况下,系统会把这个cache pool的对象控制在比target_max少50左右,现在我们修改下cache_min_evict_age
这个参数,看下会发生些什么
我们把这个参数调整为30
ceph osd pool set cachepool cache_min_evict_age 30
设置完了以后,可以看到cache pool的对象数目在 744左右,现在再写入数据,然后等待,看下会是多少,还是756,如果按我们设置的cache_target_full_ratio
0.8就正好是800,我们尝试再次调整大cache_min_evict_age看下情况,对象维持在960左右,根据这个测试,基本上可以看出来是如何控制缓存的数据了,下面用一张图来看下这个问题
来总结一下:
也就是ratio是给定了一个比例,然后时间到了就去将缓存控制到指定的ratio,这个地方就需要根据需要去控制缓冲池数据是留有多少的缓存余地的
使用命令清空缓冲池的数据,会将数据flush到真实存储池,然后将数据evic掉
关于缓冲池的就写这么多了,实际环境是要根据自己的使用场景去制定这些值的,从而能保证缓冲池能真正起到作用,上面的例子是基于对象的控制的,基于大小的控制是一样的,只是将对象数的设置换成了大小即可,然后尽量去放大对象的控制
rados -p cachepool cache-try-flush-evict-all