[故障]ceph存储池权限修改错误,导致存储池的业务hang住
描述:
记录一次重大事故:根据IaaS资源业务要求,需要增加某些功能,所以要修改部署代码。修改后重推部署代码,检查发现没有什么异常。
但是一段时间后就收到用户的报障反馈,接连一个电话、2个电话、3个电话。。。。慌了。。。。
业务故障表现,如下图
处理流程
- 首先查看ceph集群状态正常,排除ceph集群问题,如下图:
-
检查iaas平台nova、cinder、neutron服务均为正常。
-
[回顾变更修改的操作]. 虚拟机在进行数据读写的时候通过public network(也就是平台的bondmg网络)流先到monitor节点然后和osd节点通信,如果期间端口被阻塞,会导致io error,本次变更操作里有改变节点的iptables规则,因此首先查看高性能存储节点上的iptables规则,查看并没有涉及到ceph服务的端口。
-
[回顾变更修改的操作]. 确认存储的tcp连接是否正常,在Control01用public网卡,ping storage-osdnode10 -I bondmg 的public地址,确认连通性正常;利用telnet storage-osdnode10的osd端口,确认tcp连接正常。
-
[回顾变更修改的操作]. 该环境存在两个存储池,确认受影响的范围,分别查看两个池跑的业务虚拟机的情况。确认sata池的虚拟机正常,定位问题影响范围在ssd高性能池。
-
[确认故障问题] 尝试选择ssd高性能后端创建测试虚拟机,创建失败,虚拟机状态为error,直接创建type为ssd类型的卷,状态也显示error,怀疑cinder没有高性能存储池的权限。
-
查看storage-osdnode10节点cinder-volume容器,执行rbd -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.client.cinder.keyring --user cinder -p volumes_ssd ls命令,提示没有权限。
-
进入ceph,查看cinder用户权限,发现client.cinder里缺少volume_ssd pool的权限,如下图,确认本次故障根本原因,客户端cinder缺少访问高性能池的权限
根本问题原因:这个可能涉及到修改kolla-ansibel部署代码的时候不小心修改到了存储池的权限,重新推的时候ceph集群权限变更了
- 临时解决方案:通过ceph auth import方式为client.cinder用户增加volumes_ssd 的rwx权限
永久解决方案:修改kolla-ansible代码增加该pool的权限。
-
重启高性能业务虚拟机,发生启动正常。
-
验证volume类型为高性能池创建卷成功。
-
开始恢复业务虚拟机,业务虚拟机重启后均恢复正常。