Chinaunix首页 | 论坛 | 博客
  • 博客访问: 110278
  • 博文数量: 15
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 210
  • 用 户 组: 普通用户
  • 注册时间: 2014-06-21 11:44
文章分类

全部博文(15)

文章存档

2016年(3)

2015年(1)

2014年(11)

我的朋友

分类: 虚拟化

2014-07-09 13:10:00

      当使能了image cache manager后,nova compute会周期性执行该服务,检查并清理不再被使用的基础镜像,同时,如果打开了

checksum_base_images选项,还会周期性为这些基础镜像计算校验和,并与之前的校验和进行比较,防止基础镜像被异常修改。不过,
该选项也会带来IO性能的损耗。大家可以参考这个链接: 。虽然使用了新的sha1sum库函数进行加速,
但我认为开启该选项仍然会带来一定的IO损耗。所以建议在现场环境中,即使我们开启了image cache manager服务,也不要开启该选项
 
        下面我们继续分析检验代码的实现,主要是在handle_base_image函数中实现的,该函数实现对每个基础镜像的具体检查动作,我们可以看到
在该函数的最后,当检查到该基础镜像正在被使用时,会执行一句os.utime(base_file, None)。就是该条代码,同步更新了基础镜像的访问时间及
修改时间。
 
       为什么会修改基础镜像的访问时间及修改时间呢,原来image cache manager决定是否删除一个不用的基础镜像,是通过:
        当前时间 - 基础镜像的最后修改时间 > 设定的移除时间
        这个公式来判断的。
        具体代码大家可以参看_remove_base_file这个函数开头部分。
       
        所以,每当image cache manager发现基础镜像正在被使用时,就会更新该基础镜像的最后修改时间,通过这样来保证,当该基础镜像未被使用时间超出
设定的移除时间,才会被删除。
 
       对于这种实现方式,我认为有两个主要的问题:
       1. 通过修改基础镜像文件的时间属性,而不自己保存时间,这种编码方式是较为投机的,举例来说,如果外部有人手动更新了文件的时间属性,则会造成文件可能被
           提前删除;
 
       2. 这种定时轮询更新使用时间的机制本身就有问题,保存的时间并不能代表基础镜像被释放使用的最后时间,这样也会造成文件被提前删除的风险;
 
       基于以上分析,建议现场尽量不要开启image cache manager,以避免基础镜像被误删的风险,同时保证基础镜像时间属性不变,不会影响我们以后追查磁盘相关问题。
阅读(1492) | 评论(0) | 转发(0) |
0

上一篇:没有了

下一篇:openstack.live_snapshot的实现方法存在竞态

给主人留下些什么吧!~~