【问题描述】
OpenStack云平台底层存储与Ceph对接，发现1台Windows云主机挂载了1个数据盘，在虚拟机系统里面执行压缩文件时，出现虚机卡死现象，数据盘无法进行正常的读写操作
【问题分析】
1、登录OpenStack控制节点，通过IP地址获取云主机的UUID以及其它相关信息
nova list --all | grep 虚拟机IP
nova show 虚拟机UUID
获取到对应的数据盘ID信息:
os-extended-volumes:volumes_attached | [{“id”:”aaaaaa”}]
该虚拟机所在的宿主机：
OS-EXT-SRV-ATTR:host | compute-node-AA
2、尝试直接卸载虚拟机上挂载的数据盘，结果卸载失败
3、尝试先关掉该虚拟机之后，在去卸载虚拟机的数据盘
关闭虚拟机：
nova stop 虚拟机UUID
卸载虚拟机上上挂载的数据盘：
nova volume-detach 虚拟机UUID 数据盘ID
4、卸载完数据盘之后，启动虚拟机，登录虚拟机，进行文件读写测试，未出现卡顿现象
nova start 虚拟机UUID
5、将数据盘重新挂载到虚拟机上，然后在Windows系统里压缩存放于该数据卷上的文件，再次出现虚机卡顿现象
nova volume-attach 虚拟机UUID 数据盘ID
6、由于该数据盘中有数据，为防止排查过程中丢失数据，对该数据盘进行备份，将虚机再次关机，卸载数据卷，对数据卷做快照，然后从快照创建一个卷，创建的卷一直卡在creating状态
使用rbd命令创建flatten克隆卷，源卷used为59272M，flatten克隆卷used大小达到832M就不再继续上升了，且rbd flatten命令一直无返回值
检查Linux内核是否支持rbd块设备
modprobe rbd
斜杠 / 前面的是这个块设备建立在的pool的名字volumes，后面是这个块设备的名字（自己定义的）
rbd info volumes/$i@$i-snapshot
rbd snap create --snap volumes/$i@$i-snapshot
查看该块设备支不支持创建快照模板，image-format 必须为2
rbd info volumes/$i@$i-snapshot
把该块做成模板，首先要把做成模板的快照做成protect
rbd snap protect volumes/$i@$i-snapshot
可以利用这个快照来当模板来克隆了，克隆一个叫$i-clone的块 出来试试
rbd clone volumes/$i@$i-snapshot volumes/$i-clone
这个时候的$i-clone还是依赖$i@$i-snapshot的镜像，如果$i@$i-snapshot的镜像被删除或者损坏，$i-clone也不能够使用了，要想独立出去，就必须将父镜像的信息合并flattern到子镜像中
rbd flatten volumes/$i-clone
通过rbd snap unprotect volumes/xx1@xxsnap可以去掉这个保护，但是这样的话就不能克隆了
rbd snap unprotect
查看数据盘大小：
rbd du volumes/vloume-id
rbd du volumes/volume-id-clone
6、Rbd和cinder snapshot方式恢复数据卷均不成功，尝试使用qemu-img方式导出数据卷，然后将.raw文件挂载
qemu-img convert -O raw rbd:volumes/volume-idxx:conf=/etc/ceph/ceph.conf /var/test/test.raw
若volume有fast-diff新特性，可以使用rbd du -c /etc/ceph/cephxx.conf volumes/volume-xxx查看卷的数据实际大小
7、计算节点 compute-node-AA 到ceph集群的某个osd节点上有丢包
icmp_seq=1
icmp_seq=3
icmp_seq=7
检查bond状态：
cat /proc/net/bonding/bond1
Bonding Mode:IEEE 802.3ad Dynamic link aggregation
8、登录到存储节点osd-node-BB 带外上查看对应的硬件是否有问题
报：网口故障，网口链路断开
9、登录到存储节点 osd-node-BB 系统上，查看message日志
Kernel : ixgbe 00xx:01:01.1 eth0 :NIC Link is Down
Kernel : bond1: link status definitely down for interface eth0 , disableing it
Kernel :ixgbe 00xx:01:01.1 eth0:NIC Link is Up 10 Gbps ,Flow Control : RX/TX
该存储节点eth0的网卡链路异常
10、查看 网卡链路
ethtool eth0
Link detected： no
存储节点网卡或链路不稳定，导致网络抖动，当虚机用户数据读写操作访问到该存储osd节点上的数据时，由于网络中断，导致请求无法完成，引起虚机读写数据卡死的现象
【排查恢复】
1、初步判断是存储节点osd-node-BB的网卡问题，通知硬件厂商尽快恢复该节点的网卡
2、避免影响其它虚机，在基础网络修复好之前，先停掉该osd节点，停掉该节点osd服务后，虚拟机验证恢复读写数据正常
3、优先恢复业务，对ceph集群中网络故障的存储osd节点 osd-node-BB 执行osd退出操作，保证虚拟机的读写卷操作不再访问该osd-node-BB节点的数据，再次执行osd进程退出操作，之后验证虚拟机读写正常
4、虽然将执行了osd-node-BB节点退出，但是仍是in状态（虽然osd退出，但是未将osd-noed-BB该节点踢出ceph集群），且有一个pg处于inactive状态，peering过程
Peering：互为副本的三个(此处为设置的副本个数，通常设置为3)pg的元数据达到一致的过程。在这个状态的pg暂停处理IO请求，在生产环境中表现为集群部分IO不响应，甚至某些云主机因为等待IO造成应用无法正常处理。Peering时间的长短并不可控，主要是在于请求的osd是否能够及时响应；如果这个阶段某个osd down掉，很可能导致部分pg一直处在peering状态，即所有分布到这个pg上的IO都会阻塞
虽然osd.007的服务已停止，然而他仍然被标记为IN（集群中）状态。只要他的状态还是IN，Ceph集群就不会为他触发数据恢复。默认情况下，ceph集群需要5分钟来将一个DOWN状态的磁盘标记为OUT状态，然后开始数据恢复。我们可以手工将故障OSD标记为OUT。一旦该OSD被标记为OUT，ceph集群会为该OSD上的PG启动恢复过程
当某个PG对应的OSD set中有一个OSD被标记为down时(假如是Primary被标记为down，则某个Replica会成为新的Primary，并处理所有读写 object请求)，则该PG处于active+degraded状态，也就是当前PG有效的副本数是N-1。
过了5秒之后，假如还是无法连接该OSD，则它被标记为out，Ceph会重新计算PG到OSD set的映射(当有新的OSD加入到集群时，也会重新计算所有PG到OSD set的映射)，以此保证PG的有效副本数是N
5、ceph -s查询，期待ceph -s达到ok再对虚拟机进行读写测试
重构结束后，并未达到理想的ok状态
问题PG如下：
ceph health detail
HEALTH_ERR 1 pgs are stuck inactive for more than 300 seconds; 1 pgs peering ; 1 pgs stuck inactive
Pg xxx is stuck inactive for xxxx ,current state peering ,last acting [77,88,99]
Pg xxx is peering , acting [77,88,99]
对应PG的三副本所在osd [77,88,99]
ceph osd find 77
ceph osd find 88
ceph osd find 99
解决思路：重启主primary osd.77后，ceph -s查询集群状态恢复ok
ceph -s
ceph集群恢复ok后，虚机卡住的状态即刻恢复，此时将虚机的卷全部挂载，测试读写压缩文件都正常
6、后期，若是恢复该osd-node-BB节点网络后，再次将该对应的osd加入ceph集群
配置eth0和eth1两个网卡ifcfg-enoXX配置文件，修改mac地址为新更换网卡的mac地址（带外上查看新网卡的mac地址），并重启网络服务，查看网卡bond正常，ceph集群OK
写在最后：
最平凡的人，也得要为他那个世界的存在而战斗
你应该在短暂的岁月里，真正活得不负众爱
活得明白的人，往往都有一个好心态
孤立有时候不会让人变得脆弱，甚至可以使人的精神更强大
社会在变化，生活在变化，人在变化，没有什么是一成不变的，包括人的关系
我们会遇到很多人，有的人是来教会你成长，有的人是用来离别
生活不能等别人来安排，要自己去争取和奋斗
不论其结果是喜是悲，但可以慰藉的是，你总不枉在这世界上活了一场
详情请见：
