写在前面
许久没更了，最近抽空测试了一下cephfs相关的东西，来更一波
开始
此前，博客有更新一篇关于cephfs的文章 - 小试牛刀，主要是cephfs的一些基本的使用，版本也是比较早期的12版本
此后不少读者和我探讨过cephfs的情况，我给出的建议一律是：cephfs不建议上生产，不稳定
时至今日，cephfs经过了多个版本的迭代开发，据说可以上生产了，这里我们对其进行一些列的测试
测试是这样，先使用了13.2.10版本进行测试，然后使用14.2.20进行相同的测试，测试环境:
data pool 使用ec 4+2
写入大文件(64GiB)
写入大量较小小文件(4MiB+1MiB)
写满pool后进行纯粹的读取
写入时重启某个rank
13版本的情况
写入大文件(64GiB)写满pool，这个没有问题，写满pool也不用多少个文件，读取也顺利
写入大量较小的文件就不行了，读取也不能正常进行
默认配置下，cephfs的根目录下创建10个目录，写入大量的文件
[twj@R03-MTEST-DN-017.xx.cn ~]$ sudo ceph fs status
filecephfs - 3 clients
==========
+------+--------+------------------------+---------------+-------+-------+
| Rank | State | MDS | Activity | dns | inos |
+------+--------+------------------------+---------------+-------+-------+
| 0 | active | R03-MTEST-MN-002.xx.cn | Reqs: 0 s | 19.8M | 19.8M |
+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
| Pool | type | used | avail |
+----------------------+----------+-------+-------+
| cephfs-metadata-pool | metadata | 155M | 794G |
| cephfs-data-pool | data | 957T | 0 |
+----------------------+----------+-------+-------+
+------------------------+
| Standby MDS |
+------------------------+
| R03-MTEST-MN-001.xx.cn |
+------------------------+
MDS version: ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
1.5 PiB 91 TiB 1.4 PiB 94.08
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
cephfs-data-pool 15 957 TiB 100.00 0 B 561286578
cephfs-metadata-pool 17 155 MiB 0.02 795 GiB 98368
此时，mds的内存占用达到了55g
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
47740 ceph 20 0 55.4g 55.0g 10356 S 6.6 21.9 11905:23 ceph-mds
尝试重启这个mds，直接导致fs瘫痪，mds状态一直都是replay，接着mon好几天都起不来，集群也直接没法用了。。。
2021-06-17 10:10:36.352 7f9039544700 1 heartbeat_map is_healthy 'Monitor::cpu_tp thread 0x7f9034ccc700' had timed out after 0
perf top -p 3563473
Samples: 63K of event 'cycles:ppp', Event count (approx.): 49402841395
Overhead Shared Object Symbol
48.92% libceph-common.so.0 [.] crush_hash32_3
24.28% libceph-common.so.0 [.] 0x0000000000647f80
4.35% libceph-common.so.0 [.] 0x0000000000647f59
第二次测试，写入一段时间后，集群报错，mds处于rejoin状态
cluster:
id: 8418d616-979b-46f9-ab95-b8fb20093d1b
health: HEALTH_WARN
1 filesystem is degraded
1 MDSs report oversized cache
1 MDSs report slow metadata IOs
+------+--------+----------------------+----------+-------+-------+
| Rank | State | MDS | Activity | dns | inos |
+------+--------+----------------------+----------+-------+-------+
| 0 | rejoin |R03-MTEST-MN-001.xx.cn| | 59.5M | 59.5M |
+------+--------+----------------------+----------+-------+-------+
此时mds的内存消耗非常大
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
150540 ceph 20 0 224.9g 223.5g 11704 S 100.0 89.0 196:15.69 ceph-mds
使用命令ceph daemon run/ceph/ceph-mds.R03-MTEST-MN-001.xx.cn.asok flush journal
后，降低了一些，但很快又上到了223G
从结果上看，该版本的mds主要是没有解决内存的问题，没写多少文件，内存就直线飙升，而且居高不下，妄想重启mds，那就直接玩完
这里直接给出13.2.10的建议：不行！事实上，14.2.x之前的版本都不建议使用cephfs上生产环境
14版本的表现
在这个版本的测试用，我加入了额外的data pool，并使用了多活mds，直接测试的小文件写入
[twj@R03-MTEST-MN-001.xx.cn test-cephfs]$ sudo ceph fs status
cephfs - 40 clients
======
+------+--------+------------------------+---------------+-------+-------+
| Rank | State | MDS | Activity | dns | inos |
+------+--------+------------------------+---------------+-------+-------+
| 0 | active | R03-MTEST-MN-003.xx.cn | Reqs: 10.3k/s | 391k | 391k |
| 1 | active | R03-MTEST-MN-002.xx.cn | Reqs: 10.5k/s | 385k | 385k |
+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
| Pool | type | used | avail |
+----------------------+----------+-------+-------+
| cephfs.metadata.pool | metadata | 3378M | 797G |
| cephfs.data.pool1 | data | 6085G | 1234T |
| cephfs.data.pool2 | data | 2257G | 1241T |
+----------------------+----------+-------+-------+
+------------------------+
| Standby MDS |
+------------------------+
| R03-MTEST-MN-001.xx.cn |
+------------------------+
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)
其中每个data pool都创建了20个目录，并pin到不同的mds上，性能看还算均衡，连续快速写入，会有告警2 MDSs behind on trimming
但没有什么影响，就没管
随着数据的大量写入，集群开始出现slow
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
RAW STORAGE:
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 3.9 PiB 3.1 PiB 823 TiB 823 TiB 20.79
ssd 16 TiB 3.0 TiB 13 TiB 13 TiB 80.72
TOTAL 3.9 PiB 3.1 PiB 835 TiB 836 TiB 21.03
POOLS:
POOL ID PGS twjD OBJECTS USED %USED MAX AVAIL
cephfs.data.pool1 2 8192 275 TiB 217.81M 413 TiB 23.20 911 TiB
cephfs.data.pool2 3 8192 244 TiB 102.44M 366 TiB 20.53 946 TiB
cephfs.metadata.pool 4 256 127 GiB 115.39k 191 GiB 7.74 760 GiB
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph health detail
HEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
MDS_SLOW_METADATA_IO 1 MDSs report slow metadata IOs
mds.R03-MTEST-MN-002.xx.cn(mds.1): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 87 secs
MDS_SLOW_REQUEST 1 MDSs report slow requests
mds.R03-MTEST-MN-002.xx.cn(mds.1): 11 slow requests are blocked > 30 secs
查看mds的op处理流程
[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph daemon mds.`hostname` dump_historic_ops_by_duration|grep duration
"duration": 600,
"duration": 427.63886984499999,
"duration": 427.62001601499998,
"duration": 409.772382456,
"duration": 409.75990740399999,
"duration": 215.47288510800001,
"duration": 214.47418489699999,
"duration": 203.97045117499999,
"duration": 203.51505527899999,
...
时间都非常久，继续排查，发现大量的op都是卡在failed to rdlock, waiting
这个步骤，关于这种情况的调查和优化，还在努力。。。
看了一眼内存，没有明显的飙升
[twj@R03-MTEST-MN-003.xx.cn ~]$ top
top - 15:34:57 up 9 days, 4:36, 1 user, load average: 0.95, 1.22, 1.28
Tasks: 650 total, 1 running, 649 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.9 us, 0.1 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 26353089+total, 25013656+free, 11907872 used, 1486464 buff/cache
KiB Swap: 16777212 total, 16777212 free, 0 used. 24535932+avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29657 ceph 20 0 7878864 2.5g 14288 S 100.7 1.0 4616:55 ceph-mds
大量数据写入后，先测试一下mds的重启，直接reboot节点，观察集群的情况
[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph fs status
cephfs - 40 clients
======
+------+--------+------------------------+---------------+-------+-------+
| Rank | State | MDS | Activity | dns | inos |
+------+--------+------------------------+---------------+-------+-------+
| 0 | active | R03-MTEST-MN-001.xx.cn | Reqs: 869 s | 445k | 445k |
| 1 | active | R03-MTEST-MN-002.xx.cn | Reqs: 0 s | 365k | 365k |
+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
| Pool | type | used | avail |
+----------------------+----------+-------+-------+
| cephfs.metadata.pool | metadata | 186G | 762G |
| cephfs.data.pool1 | data | 412T | 910T |
| cephfs.data.pool2 | data | 366T | 945T |
+----------------------+----------+-------+-------+
+------------------------+
| Standby MDS |
+------------------------+
| R03-MTEST-MN-003.xx.cn |
+------------------------+
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)
看是备是直接顶上了，mds重启后自动做备，业务侧暂时没有发现有问题，不过，发现写入的流量都打到了同一个mds，不知道是不是因为rank序号变化导致的
测试发现，当单个目录对象数达到千万级时，cephfs的目录出现明显的卡顿，测试读，读取偶尔会有问题，流量不稳定，最大可到1GiB/s，最小只有几百M
io:
client: 240 MiB/s rd, 559 KiB/s wr, 102 op/s rd, 0 op/s wr
结论
cephfs 14.2.20测试结果来看，稳定性可靠性还是可以的，至少内存的问题看来是解决了，没有出现持续大量数据写入时产生的高内存占用问题，同时，重启其中一个rank，备用的mds会自动顶上，业务没有太大影响，而且，目录内的文件数量只要不是太大，小于百万级的话，性能也没有太大的问题，因此，14.2.20及后续版本的cephfs应该是可以上生产的了
反观此前的版本，12、13都比较拉垮，mds不太靠谱，如果client有故障，读写卡住，mds分分钟给你瘫痪，极具危险性，还是不建议上，如果已经有在线的fs，还是强烈建议迁移到14.2.20+的版本
下一步，将继续测试cephfs的其他异常情况和大规模数据写入后slow req的问题，并对代码逻辑方面进行一些分析，敬请期待^_^
文章转载自奋斗的cepher，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
