OpenStack Cinder特性之image volume cache介绍

Openstack cinder有一个可选的功能：镜像盘缓存，可以明显提升从镜像创建云盘的性能。这个改进依赖很多因素，主要看存储后端克隆云盘的速度有多快。

一 简介

对于Cinder来说，保存镜像显然并不是它该做的事情，但是保存了镜像的云盘管理起来就游刃有余了。而且由于云盘大小是可以任意扩展的，只要缓存一份刚好满足镜像virtual size的云盘，然后在需要时扩展成所需的大小。当第一次从镜像创建云盘时，cinder的内部租户会创建一个镜像盘缓存(image-volume-cache)。如果再从这个镜像创建云盘，就直接克隆这个镜像盘缓存，不需要再走下载镜像内容进行格式转换后拷贝数据到云盘这个流程了。在新创建镜像盘时，要想知道当前镜像是否被缓存过，需要借助数据库记录：只需要在创建镜像盘缓存时，将镜像与缓存的关联保存到表中。当请求再次来到时，查询当前镜像是不是存在表中即可（数据库中增加表image_volume_cache_entries用来记录image-volume-cache 的host, image_id, volume_id, size等信息）。

二 配置

Mitaka版本默认不启用镜像盘缓存功能，需要另外配置。

1. 设置内部租户：
镜像盘缓存需要配置cinder的内部租户。这个租户拥有这些缓存并且可以进行管理。这可以保护用户不必看到这些缓存，但是也没有全局隐藏。为内部租户配置的用户和项目不需要特殊的额权限。可以使用cinder服务的租户或者是其他任何的项目和用户。
cinder.conf配置：

cinder_internal_tenant_project_id = PROJECT_ID
cinder_internal_tenant_user_id = USER_ID

2. 配置image-volume cache
每个存储后端可以独立定义或者在默认项里定义。

image_volume_cache_enabled = True
image_volume_cache_max_size_gb = SIZE_GB
image_volume_cache_max_count = MAX_COUNT

三 过程

1. 通知：
缓存操作会触发Telemetry消息，这几种消息会被发送：
image_volume_cache.miss - 创建云盘时，没有从缓存中找到相应的镜像，这意味着一个新的缓存会被创建 ；
image_volume_cache.hit - 从镜像创建云盘时，在缓存中找到了相应的镜像并将被使用；
image_volume_cache.evict - 一个镜像盘缓存被删除。

2. 数据库中新建image_volume_cache_entries表，用以保存云盘和镜像的关联
当由镜像创建云盘时，根据数据库记录判断是否由该镜像创建过镜像盘：
若未创建过(或之前的云盘不在当前主机上)则向glance请求下载镜像，将镜像数据格式转换后拷贝到云盘中，然后由该云盘克隆一个缓存盘(归属于所配置的Service项目)；同时更新数据库表中的缓存记录；
若创建过(并且云盘在当前主机上)，则由缓存盘克隆出新的云盘(该克隆功能直接由存储后端提供)，若新云盘与请求的云盘大小不一致，则扩展(Extend)该云盘。

3. 管理image-volume缓存
通常来说，缓存都是自动管理的，不需要手动干预。如果需要，可以手动删除缓存。通过标准的云盘删除API，cinder服务会执行删除云盘的操作。若缓存盘被删除，再由该镜像创建云盘会回到“下载镜像->创建云盘->创建镜像盘缓存”的过程。

4. 关于缓存的总容量：
若当前镜像的大小超过总容量大小，则不缓存镜像；
若当前镜像大小未超过总容量大小，但是超过当前可用的缓存容量大小，则按照“最久未使用”的方式删除已经缓存的镜像盘，直至可用容量满足当前镜像大小；
若当前镜像大小未超过总容量大小，并且当前可用的缓存容量大小能够满足当前镜像，则直接创建镜像缓存。

5. 除了配置缓存容量和个数，镜像盘缓存的创建还会受到service项目volume配额的限制。

四 总结

缓存机制将创建镜像盘的流程从glance下载镜像拷贝数据到云盘的操作改为在后端存储上克隆。如果后端存储的克隆性能比较好，将极大的提升创建镜像盘的速度。

OpenStack Cinder特性之image volume cache功能测试

参考：
https://docs.openstack.org/admin-guide/blockstorage-image-volume-cache.html