由 OpenStack 基金会举办的 Project Teams Gathering（以下简称 PTG ）会议已于9月11-15日在 Denver 举行，共计420名开发者参加，踊跃讨论有关 OpenStack 下一个版本 Queens cycle 的开发工作，积极推动OpenStack各项能力的提升，甚至许多开发工作也在 PTG 过程中实际展开。
Cinder 是 OpenStack Block Storage 的项目名称，它为虚拟机 （VM） 提供了持久块存储。对于可扩展的文件系统、最大性能、与企业存储服务的集成以及需要访问原生块级存储的应用程序而言，块存储通常是必需的。它类似于 Amazon 的 EBS 块存储服务，OpenStack 中的实例是不能持久化的，需要挂载 volume，在 volume 中实现持久化。Cinder 就是提供对 volume 实际需要的存储块单元的实现管理功能。
Cinder Team 合影
本次 PTG 为期5天，在 PTG 举办期间，OpenStack基金会组织了 Cinder sessions 进行讨论与现场开发。Cinder sessions 是从13日到15日，包括不少重要项目改进和重要功能热点，有些话题是从巴塞罗那峰会遗留下来的。
Team会议讨论情景
EasyStack派出多名工程师参与了本届PTG，并应开源云中文社区邀请做前方报道。EasyStack研发工程师Apolloliuhx参与了 Cinder sessions。
以下是来自Apolloliuhx带来的会议纪要：
笔者第一次参加 PTG，所以不能与之前的会议进行比较，但总的来说感觉这是一次较为成功的会议。
以下涉及的所有讨论详见：https://etherpad.openstack.org/p/cinder-ptg-queens
Day 1
1.Replication Failback
比较让人激动的一个 feature ，将实现完整的容灾恢复功能。之前 Cinder 项目的一些驱动已经支持 failover api，但是 failover 之后实现 failback 是尚未实现完成，因此 PTG 会议上重点讨论了该问题。Failback 之后可能原来的 primary system 就不再是原来的系统，但很难跟用户解释实现这个得有多困难，比如RBD可以实现这个功能，但其他 Drivers 呢？这些 Drivers 有很多需要考虑的问题。
这是一个怎么样的过程呢？用简短的话来说就是：从 primary cluster failover 到secondary cluster，promote 这个集群到 primary 让其正常运行，这个过程中需要添加一个状态“ promoting ”，这样我们可以看到整个 promotion 过程，并且可以看到这个过程需要很长时间完成，完成之后状态会修改为“ replicated ”。现在对于 replication 这个功能并未完成，因此用户没有使用。Cinder team 在此次PTG 会议上重点讨论了该功能，不过需要进一步讨论，不光得考虑对其他 drivers 的影响，还有 active/active HA 影响。
BP链接：
https://blueprints.launchpad.net/cinder/+spec/replication-backend-promotion
2.Micro version设置constraints
为 micro vision 设置 constants 。为了避免 rebase 的时候起冲突，比较好的方式是给 micro vision 设置 constants ，比如 GROUP_REPLICATION=3.35，这样在之后使用到改版本的功能代码会比较方便的直接 rebase 。
3.最小功能集文档化
Cinder 准备对每个 divers 进行文档化归类，并指出某些 driver 不提供某个功能或者某个值。
Cinder为每个driver实现基本的功能，包括：
-
Volume Create/Delete
-
Volume Attach/Detach
-
Snapshot Create/Delete
-
Create Volume from Snapshot
-
Get Volume Stats
-
Copy Image to Volume
-
Copy Volume to Image
-
Clone Volume
-
Extend Volume
-
每个driver为scheduler服务提供调度的状态值
-
driver_version
-
free_capacity_gb
-
storage_protocol
-
total_capacity_gb
-
vendor_name
-
volume_backend_name
4.自动配置项生成
为方便直接生成配置项文件，cinder使用oslo库来实现新的配置项生成。Oslo config and oslo policy 提供了sphinxconfiggen and sphinxpolicygen 插件来使用产生ini格式的文档，还有 sphinxext plugins可以生成漂亮的表格格式的文档，利用这些工具来提取 cinder 项目所有配置项，最终生成配置项文档。
5.浓缩/标准化基本配置项集合
很多 drivers 的配置项是一样的或者说是重复的，比如 SAN 驱动的很多选项其他一些 driver 可以共用，需要浓缩一下配置项集合，弃用那些多余的部分。对于弃用某个配置项， nova 的做法是在选项中加入信息说明该选项已经弃用，请用新的选项代替，保证至少一个版本以上才可考虑删除，每次弃用或者删除都要加入 releasenote ，并且写入相应的驱动文档。
Day 2 & Day 3
以下是 Cinder 第二天和第三天的会议纪要，其中 1、2、3 是 Nova 和 cinder 跨项目综合讨论。
1.Multi-attach
这个无疑是本次PTG跨项目 （ nova/cinder ） 讨论里的重头戏。Cinder 项目为了支持 multi-attach 功能将引入新的 attach/detach api 。启用该功能的主要的问题是怎么处理共享连接。Nova 调用 create_attachment（没有 connector ），cinder 的配置项 is_using_shareable_backend_connection_thingy 设置为True；如果 is_using_shareable_backend_connection_thingy 设置为 True，nova 调用 delete_attachment（有 connector ）时会有一个 host 锁，这个锁将影响所有和挂载有关系的操作，比如 create_attachment 。从 Policy 控制的角度，通过 nova 的 policy 可以允许 multi-attach 从 volume 启动虚机，通过 cinder 的 policy ，cinder 需要后端允许的前提下才能实现 multi-attach ，并且只允许 read-only 的卷 multi-attach 。能否从一个 multi-attach 卷起虚机，还需要看操作系统是否能实现。os-brick 实现 host 的共享连接，必须提的是锁只用在使用了共享连接的 host 上，且基于 IQN 。最后还讨论了升级连接调用的问题，针对旧的 attachment 升级，但是具体尚无结论。
2.Cinder 和 Nova 关联的 API 更新
会上提到关于 Cinder 和 Nova 存在关联的 API 更新的问题，以保证两边 API 调用时功能的正常使用。
下面是新旧 API 的列表：
1）新 API 包括：attachment_create， attachment_update， attachment_complete， attachment_delete。信息并返回该信息。
2）旧 API 包括：reserve， os-initialize_connection， os-attach， begin_detaching， os-terminate_connection， os-detach。
Attachment create/attachment delete 更新之后，使用了新的工作流，如果想使用原来的 api，只需要使用 Attachment create 保留卷，新的 API 可以通过 attachment update 更新 connector 。Multi-attach 功能正在实现，需要提供接口来显示一个卷是否是可共享的，nova 可以根据返回的 volume 状态来抉择是否能挂载。
3.API之刷新卷 connection info
不得不考虑cinder后端修改之后，nova 能够及时修改连接后端的信息。在某些连接信息修改之后，比如后端 ceph 集群 ip 修改后能够上报新的 ip，不中断用户使用的情况下能够刷新cinder连接信息，这里的连接信息是指 Nova的block_device_mappings 表，cinder 上报的 os-initialize_connection 信息会被记录到这张表上，然后根据这张表更新连接。如果要刷新信息重启并不能实现，很多 API 多不提供刷新，比如 cold migrate/resize， stop/start， suspend/resume， and rebuild，可能需要将现有 API 改进一下，目前建议使用热迁移和 hard reboot，利用 attachment_delete/create 来更新存储后端。
BP链接：
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/cinder-new-attach-apis.html
4.Volume 加密
加密分前端和后端两种，目前我们实现的大都是前端加密，后端加密支持的不多。据华为反映，客户有对后端加密的需求，比如能对每个 volume 进行加密。Cinder 已经支持加密机制，比如GPFS driver（闲置状态时的加密），但是一些后端只支持加密整个后端。Barbican 提供加密，诸如华为并没有使用其来加密，并且在加密的时候能够指定 key ，现在的 key 一般都是自动创建好的。接下来 Cinder 将考虑更新旧的key manager，使其能够获取静态 key，在创建 volume 并加载的过程中使用Barbican来做加密处理。这里还要提一下对 volume 数据的加密和对 volume 的加密是有区别的。LUKS 是对数据的加密，不管 volume 是在进行数据传输过程还是限制状态，数据均是加密的。
5.Quota管理性能提升
这个讨论主要涉及批量创建/删除资源，一次对多个资源进行操作，有一种情况是在两个人同时创建多个资源的时候，一个成功，另一个可能会不成功，这个问题还没有具体结论，需要进一步讨论，可能需要结构化查询来处理这种批量操作，可以借鉴 nova cell 的 quota 管理实现 【1】，详见 cinder 的BP链接：【2】。
BP链接：
【1】https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/cells-count-resources-to-check-quota-in-api.html
【2】https://review.openstack.org/#/c/496562/
6.卷的Qos实现
Cinder 要讨论的 Qos 具体来说就是对卷的流量控制。Cinder 对流量的控制有两种方式，一种是使用卷 metadata 来标记，另一种就是与卷类型绑定的 qos spec 。公有云的应用场景比较多见，创建每个卷资源是和具体的流量绑定好的，这需要创建不同的卷类型，用户创建卷时候根据需要来选择合适的卷类型，如果需要改变挂载卷的流量，可以通过更改卷类型来实现，但是疑虑就是对一个使用中的卷修改类型，一些后端可能会遇到麻烦。因此建议使用 metadata 的方式来限制卷流量大小。
7.Generic backup实现
这个是本次 PTG 讨论中较大的功能变动之一，作为从巴塞罗那峰会就开始讨论的话题。为什么这么说呢？将把 backup 服务融合到 cinder scheduler 中。具体部署 backup 服务器有两种方式：1. 耦合方式，运行 volume 服务的服务器上，用于备份该服务器上的卷；2.非耦合方式，通过 rabbitmq 的 Robin 循环和其他的 backup 服务进行通信。Cinder scheduler 融合 backup 服务，考虑实现第二种方式，将更新现有的 scheduler 功能相关代码。
8.利用Backup创建卷
考虑到端用户的需求，会上决定新加了从备份来创建卷的功能。讨论是因为 restore 卷，不能指定 volume 的大小、类型、卷名以及一些特征。Cinder 目前支持从快照、镜像创建卷。这次添加从备份创建，简单地理解就是 restore+resize ，因此当创建小于源备份大小的卷会报错，只能创建更大或者一样大小的卷。
9.Active/Active HA 测试
Cinder 将实现一个 library ，该库可以用在所有服务里进行各种测试。引入这个测试框架来进行 HA 的测试，vendor 可以通过给出输入来测试每个 Driver ，包括输入一些错误信息来测试服务结果是否正常，并且提供相应的指南和 RBD 测试样例。
10.验证安装文档
由于 doc team 不能顾及到项目文档，需要实践并验证安装文档（ install guide ）是否有错，包括 RedHat and Ubuntu 的文档，如果有错开发者包括社区贡献者可以及时提出 bug 作更新。
11.关于bulk create volume
简单来说，就是一次创建多个 volume 。为什么着重提出这个问题呢，因为客户需要在部署一个虚机的时间里把需要的 volumes 创建出来，从 nova 的角度需要执行一个 bulk attach 请求。但是具体怎么实现呢？一个解决方案就是利用 group API ，按 group 来处理，包括创建、删除等。cinder create 一次创建多个 volume，如果有失败的 volume，可以不管，选择最后创建成功的那些。但是问题是创建 volume 的这个 pool 究竟需要多大的的 size ，实际管理起来会存在很多问题。具体实践起来，还得考虑 scheduler、quotas 等。
再次特别感谢EasyStack的工程师们从 Denver 发回的报道！
阅读推荐：
投稿邮箱：openstackcn@sina.cn
882
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
