cephcsi客户端断连问题

2023-05-06 约 1721 字预计阅读 4 分钟

概述

CephFS CSI 使用过程中，会出现偶发的 Kubernetes 节点挂载的目录提示 Permission denied 的问题，这个问题会一直持续到节点重启为止。为了避免遇到这种情况下，需要重启节点，影响节点上的业务 Pod 运行，需要排查具体的原因，然后采取合适的手段尽量避免或者至少将影响面降到最低。

测试条件

因为涉及到 Ceph 和 Kubernetes 节点的网络测试，因此需要谨慎测试，建议在测试环境的集群中进行，下面是本人用于测试的环境，主要是一个用 Docker 启动的单节点 Ceph 集群，以及另外一台测试服务器，作为客户端检验挂载 Ceph 集群出现各种问题下的处理。

测试思路

单节点的Ceph集群IP是192.168.1.203
测试的k8s节点为192.168.201

操作流程

需要在 Ceph 集群上进行一些网络的配置作为测试的条件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# 网络阻隔
iptables -A INPUT -s 192.168.1.201 -j DROP
# 网络恢复
iptables -D INPUT -s 192.168.1.201 -j DROP

ceph osd blacklist ls
ceph osd blacklist add 192.168.1.201:0/1308721908
ceph osd blacklist rm 192.168.1.201:0/1308721908

# 默认是false
ceph config get mds mds_session_blocklist_on_timeout
ceph config set mds mds_session_blocklist_on_timeout true
ceph config set mds mds_session_blocklist_on_timeout false

# 流程1
ceph config set mds mds_session_blocklist_on_timeout false
iptables -A INPUT -s 192.168.1.201 -j DROP
dmesg -T -w
iptables -D INPUT -s 192.168.1.201 -j DROP
ceph config set client client_reconnect_stale true
ceph config set client client_reconnect_stale false
ceph config get client client_reconnect_stale

目前我们的 CSI 的配置上，针对内核挂载，没有提供其他参数。

1

kernelmountoptions: ""

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 正常
debug 2024-06-15T02:07:47.288+0000 7f989f7ed700  0 log_channel(cluster) log [WRN] : evicting unresponsive client node1 (14275), after 311.594 seconds
debug 2024-06-15T02:07:47.288+0000 7f989f7ed700  1 mds.0.4 Evicting (and blocklisting) client session 14275 (v1:192.168.1.201:0/4003029088)
debug 2024-06-15T02:07:47.288+0000 7f989f7ed700  0 log_channel(cluster) log [INF] : Evicting (and blocklisting) client session 14275 (v1:192.168.1.201:0/4003029088)
debug 2024-06-15T02:07:48.845+0000 7f98a47f7700  0 --1- [v2:192.168.1.203:6812/984712839,v1:192.168.1.203:6813/984712839] >> v1:192.168.1.201:0/4003029088 conn(0x5636ad3e9400 0x5636ad27f800 :6813 s=ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=0 cs=0 l=0).handle_connect_message_2 accept we reset (peer sent cseq 1), sending RESETSESSION
debug 2024-06-15T02:07:48.852+0000 7f98a0ff0700  0 mds.0.server  ignoring msg from not-open sessionclient_reconnect(4 caps 3 realms ) v3
debug 2024-06-15T02:07:48.853+0000 7f98a47f7700  0 --1- [v2:192.168.1.203:6812/984712839,v1:192.168.1.203:6813/984712839] >> v1:192.168.1.201:0/4003029088 conn(0x5636ad460400 0x5636ad27f000 :6813 s=OPENED pgs=9 cs=1 l=0).fault server, going to standby
debug 2024-06-15T02:07:48.858+0000 7f98a3ff6700  0 --1- [v2:192.168.1.203:6812/984712839,v1:192.168.1.203:6813/984712839] >> v1:192.168.1.201:0/4003029088 conn(0x5636ad460000 0x5636ad280000 :6813 s=ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=0 cs=0 l=0).handle_connect_message_2 accept peer reset, then tried to connect to us, replacing

debug 2024-06-15T11:07:08.439+0000 7f989f7ed700  0 log_channel(cluster) log [WRN] : evicting unresponsive client node1 (14399), after 302.569 seconds
debug 2024-06-15T12:30:13.794+0000 7f98a47f7700  0 --1- [v2:192.168.1.203:6812/984712839,v1:192.168.1.203:6813/984712839] >> v1:192.168.1.201:0/1518428409 conn(0x5636ad3d5c00 0x5636ad280800 :6813 s=ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=0 cs=0 l=0).handle_connect_message_2 accept we reset (peer sent cseq 1), sending RESETSESSION
debug 2024-06-15T12:30:13.804+0000 7f98a0ff0700  0 mds.0.server  ignoring msg from not-open sessionclient_reconnect(1 caps 3 realms ) v3
debug 2024-06-15T12:30:13.805+0000 7f98a47f7700  0 --1- [v2:192.168.1.203:6812/984712839,v1:192.168.1.203:6813/984712839] >> v1:192.168.1.201:0/1518428409 conn(0x5636ad1dd000 0x5636acfdb800 :6813 s=OPENED pgs=14 cs=1 l=0).fault server, going to standby
debug 2024-06-15T12:30:13.807+0000 7f98a3ff6700  0 --1- [v2:192.168.1.203:6812/984712839,v1:192.168.1.203:6813/984712839] >> v1:192.168.1.201:0/1518428409 conn(0x5636ad45d400 0x5636ad281800 :6813 s=ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=0 cs=0 l=0).handle_connect_message_2 accept peer reset, then tried to connect to us, replacing

# dmesg
[Sat Jun 15 19:02:39 2024] libceph: mon0 (1)192.168.1.203:6789 session lost, hunting for new mon
[Sat Jun 15 19:03:09 2024] ceph: mds0 caps stale

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


ceph fs get mycephfs
# 更快生效
ceph fs set mycephfs session_autoclose 60
ceph fs get mycephfs
iptables -A INPUT -s 192.168.1.201 -j DROP
date
ceph osd blacklist ls
iptables -D INPUT -s 192.168.1.201 -j DROP

debug 2024-06-16T00:54:44.708+0000 7fc48f83d700  0 log_channel(cluster) log [WRN] : evicting unresponsive client node1 (14355), after 60.8512 seconds
debug 2024-06-16T00:54:44.708+0000 7fc48f83d700  1 mds.0.3 Evicting (and blocklisting) client session 14355 (v1:192.168.1.201:0/293851794)
debug 2024-06-16T00:54:44.708+0000 7fc48f83d700  0 log_channel(cluster) log [INF] : Evicting (and blocklisting) client session 14355 (v1:192.168.1.201:0/293851794)

为什么是Permission denied

这个报错乍一看是挺无厘头的，只是网络有问题，甚至只是几分钟的抖动，怎么会报权限问题呢？这个就要从 Ceph 的 Kernel Mount 方式说起了。简单说就是作为文件系统，用户态对文件的操作，都会用 stat 这个方法，而 CephFS 作为远程文件系统，需要从 mds 获取 stat 的数据，而 Kernel Mount 中，如果无法访问到文件的元数据（大部分是网络问题），那么就会报错 -EACCESS，这个错误码在用户态里，就会报 Permission denied。

用户态程序访问文件，先查询权限 inode_permission，通过用户态的程序调用系统调用 statx，内核 VFS 接收到 statx，根据路径解析对应的文件系统，当发现是 Ceph 的时候，就会想 inode_permission 的具体请求给到 Ceph 的实现里执行，而 Ceph 的 Kernel Mount 实现里，需要通过网络访问 mds，因为网络问题，Mount Point 虽然在，但已经无法取得 inode_permission 的结果了，就会返回 -EACCESS，这个错误码传到用户态，就会返回 Permission denied。

总结

kernel mount 报 Permission denied 复现的方法如下。

Ceph和CephCSI都是默认参数部署
客户端和服务端因为网络问题中断5分钟，Ceph日志可见客户端session被evicting和blocklisting，此时客户端hang住
恢复网络客户端不hang了，变成Permission denined
将客户端session从blacklist移除，也无法恢复
将所有Pod移除，客户端Mount Point移除重新创建Pod即可

从上面的总结看，节点这个时候是可以不用重启，只要清理了 global mountpoint，并且将客户端 session 从 blacklist 移除（否则需要等待默认1h），再重新调度 Pod 就可以恢复。

运维手段

问题查明之后，就要思考怎么避免或者是减小这个问题给业务带来的影响。

CephFS日志需要监控客户端驱逐/拉黑的情况，一旦发生，需要引起警惕
CephFS CSI针对globalmount的健康情况
自动化处理应该是先cordon节点，避免新的Pod调度到这个节点，然后再驱逐业务容器，通过Kubernetes的能力重新调度

参考资料

警告

本文最后更新于 2023年5月6日，文中内容可能已过时，请谨慎参考。

💡赞赏支持

微信打赏

支付宝打赏