[故障]ceph存储池权限修改错误，导致存储池的业务hang住

描述：#

记录一次重大事故：根据IaaS资源业务要求，需要增加某些功能，所以要修改部署代码。修改后重推部署代码，检查发现没有什么异常。
但是一段时间后就收到用户的报障反馈，接连一个电话、2个电话、3个电话。。。。慌了。。。。

业务故障表现，如下图

处理流程

1. 首先查看ceph集群状态正常，排除ceph集群问题，如下图：

2. 检查iaas平台nova、cinder、neutron服务均为正常。

3. [回顾变更修改的操作]. 虚拟机在进行数据读写的时候通过public network（也就是平台的bondmg网络）流先到monitor节点然后和osd节点通信，如果期间端口被阻塞，会导致io error，本次变更操作里有改变节点的iptables规则，因此首先查看高性能存储节点上的iptables规则，查看并没有涉及到ceph服务的端口。

4. [回顾变更修改的操作]. 确认存储的tcp连接是否正常，在Control01用public网卡,ping storage-osdnode10 -I bondmg 的public地址，确认连通性正常；利用telnet storage-osdnode10的osd端口，确认tcp连接正常。

5. [回顾变更修改的操作]. 该环境存在两个存储池，确认受影响的范围，分别查看两个池跑的业务虚拟机的情况。确认sata池的虚拟机正常，定位问题影响范围在ssd高性能池。

6. [确认故障问题] 尝试选择ssd高性能后端创建测试虚拟机，创建失败，虚拟机状态为error，直接创建type为ssd类型的卷，状态也显示error，怀疑cinder没有高性能存储池的权限。

7. 查看storage-osdnode10节点cinder-volume容器，执行rbd -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.client.cinder.keyring --user cinder -p volumes_ssd ls命令，提示没有权限。

8. 进入ceph，查看cinder用户权限，发现client.cinder里缺少volume_ssd pool的权限，如下图，确认本次故障根本原因，客户端cinder缺少访问高性能池的权限

根本问题原因：这个可能涉及到修改kolla-ansibel部署代码的时候不小心修改到了存储池的权限，重新推的时候ceph集群权限变更了

10. 临时解决方案：通过ceph auth import方式为client.cinder用户增加volumes_ssd 的rwx权限

永久解决方案：修改kolla-ansible代码增加该pool的权限。

11. 重启高性能业务虚拟机，发生启动正常。

12. 验证volume类型为高性能池创建卷成功。

13. 开始恢复业务虚拟机，业务虚拟机重启后均恢复正常。