OpenStack平台虚拟机快照(备份)失败底层镜像上传到Ceph集群失败问题分析

     OpenStack平台虚拟机快照(备份)失败，底层镜像上传到Ceph集群失败问题分析          【问题描述】Glance组件针对虚拟机备份失败，做一次简单的测试验证分析，来判断是什么原因导致云主机的备份失败，这里对虚拟机的备份其实底层就是对虚拟机制作快照【排查分析】在OpenStack控制节点上使用指令novaimage-create 测试云主机备份失败的问题（1）针对本地系统盘虚机主机名为test007 进行 novaimage-create 操作，发现该虚拟机的快照snapshot 一直处于 saving 状态获取虚拟机的UUID：novalist--all|greptest007对test007虚拟机做备份操作：novaimage-create 虚拟机UUID local-vm-snapshot-test007查看镜像的状态并获取备份(快照)的UUID：glanceimage-list|greplocal-vm-snapshot-test007执行结果：saving查看虚拟机的信息，获取OS-EXT-STS：power_state的值：novashow虚拟机UUID执行结果：OS-EXT-STS：power_state |image_uploading（2）备份需要一定的时间，等一段时间过后，再次查询该snapshot，无信息glanceimage-list|greplocal-vm-snapshot-test007执行结果：timeoutwaitingforinput:auto-logout.Connectiontox.x.x.xclosed登录test007虚拟机所在的宿主机计算节点compute-AA上，查看宿主机的 /var/log/nova/nova-compute.log 日志（1）Beggininglivesnapshot获取虚拟机对应的备份请求ID，使用请求ID在日志里查询：nova instance-action-list 虚拟机UUID看到日志中Beggininglivesnapshot 为开始备份qemu-imgcreate-fqcow2/usr/lib......（2）qemu-imgconvert转换格式完成后，开始上传备份到ceph集群beginningimageupload备份(快照)转换格式完成：qemu-imgconvert-fqcow2-Oqcow2/var/lib/nova/instances/snapshots/......Snapshotextracted,beginingimageupload 开始上传快照（3）上传快照到ceph集群一段时间后，报连接glance的brokenpipeERRORnova.image.glance......Errorcontactingglanceserverx.x.x.xforupdate,donetrying......Brokenpipe解析：pipe是管道的意思，管道里面是数据流，通常是从文件或网络套接字读取的数据。当该管道从另一端突然关闭时，会发生数据突然中断，即是broken。对于文件File来说，这可能是文件安装在已断开连接的光盘或远程网络上。对于socket来说，可能是网络被拔出或另一端的进程崩溃。这里初步推断可能是网络不稳定引发的“管道中断”在OpenStack控制节点上，查看glance-api的日志（1）此时镜像的状态为“queued”排队等候状态， 标识该镜像ID已经被保留，但是镜像还未上传。日志目录：/var/log/galnce/glance-api.logAddingimagemetadata......addimagemetadata......Publisher.send:sendingmessagenotifications.infoto{payload:{u`status`:u`queued`}}然后，Glance-Registry服务执行client的add_image函数，向glance数据库中insert一条 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 （2）Glance-API调用Glance-Registry的update_image_metadata函数，更新数据库中该镜像的状态为“saving”，标识镜像正在被上传Settingimage镜像UUIDtostatus‘saving’_upload......Updatingimagemetadataforimage镜像UUID......updateimagemetadata（3）Glance-API调用后端ceph集群存储接口提供的add函数，来上传镜像文件Uploadingimagedataforimage镜像UUIDtorbdstore_uploadWritingchunkWritingchunkatoffset8848add...（4）在正常情况下，rbd上传完成后，Glance-API调用Glance-Registry的update_image_metadata函数，更新数据库中该镜像的状态为 “active”并发通知。“active”标识 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 示镜像在Glance中完全可用。而实际情况情况为，镜像上传完成后， glanceimage-list 查看不到image，从glance-api日志看收到了DELETE请求，该image被自动删除glanceimage-list|greplocal-vm-snapshot-test007Determiningversionofrequest:DELETE /v1/images/镜像UUIDAccept:*/*galnce/api（5）虽然glance-api收到了DELETE的请求，并且glanceimage-list也查询不到该镜像了，但是ceph的名为images的pool里仍然有该镜像：rbdls-c/etc/ceph/ceph.confimages|grep镜像UUID（6）在OpenStack控制节点上，查看glance-api日志中上传的镜像大小1048576000Bit，rbdinfo查看ceph中的镜像大小1000MB，两者镜像大小比对，可以判断“已成功上传至ceph”这个步骤出错了，应该使用rbddu命令或者rbddiff命令查看实际大小。1048576000/1024/1024=1000MBAddingimagemetadata......addimagemetadata......Publisher.send:sendingmessagenotifications.infoto{payload:{u`status`:u`queued`,...,u`size`:1048576000}}......withorderandsize1048576000  add/glance_store/_drivers/rbd.pyrbdinfo-c/etc/ceph/ceph.confimages/镜像UUIDrbdimage‘镜像UUID’：size1000MB4、继续分析1）若是ceph集群存储侧的问题，是否是镜像上传完成后，没有及时返回消息2）若是glance配置问题，是否是glance等待超时，自动删除，从glance-api日志看，上传约10G大小的image，用时多少秒，ceph实际上传该镜像用时开始调用rbd驱动，为开始时间：Uploadingimagedataforimage镜像UUIDtorbdstore_upload/usr/lib/python2.7/site-packages/glance/api/vi/image.py到书写块writingchunk结束时间：writingchunkatoffsetxxxadd/usr/lib/python2.7/site-pachages/glance_store/_drivers/rbd.py5、最终原因是由于glance对接的是ceph集群，ceph集群中的ceph-node001存储服务器节点，当从compute-AA计算节点ping存储节点ceph-node001，发现有丢包现象，ceph集群对于这种网络抖动很敏感，如果该节点直接ping不通，ceph-node001节点上的osd会直接踢出集群，是在ceph集群的容错机制里。但是处于网络时断时续的中间状态，是不在ceph的容错考虑范围内的，在往存储节点ceph-node001上的某个osd上写的时候，如果因为断断续续的丢包，导致osd写不完就断开了，或者数据写完但是没有返回，ceph也不会有返回结果给到glanceapi，这个glance服务未检测到ceph的返回结果，超时后默认上传镜像失败，就会自动将上传失败的镜像删除DELETE掉写在最后：人生有4种态度，相信不盲信、认真不虚伪、执着不执迷、感恩详情请见，微信公众号 -全文完-