直击PTG|Cinder项目重要变化纪要

原创 2017年09月29日 00:00:00

由 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 发回的报道!


阅读推荐:

OpenStack能拯救混合云吗?

容器管理:如何防止容器蔓延与成本蔓延


投稿邮箱:openstackcn@sina.cn

版权声明:

相关文章推荐

黑马程序员_学习日记82_811图书商城项目纪要

1.GetPay.ashx接收支付宝返回的数据 //判断支付宝返回的各种key不为空 if(!string.IsNullOrEmpty(context.Request.QueryString["ou...

黑马程序员_学习日记81_810图书商城项目纪要

一、购物车(购物表) Cart表(Id UserId BookId Count) 1.新建BuyMaster.Master+Cart.aspx 2.在BookDetail.aspx中添加“购买”...

值得你关注的Android8.0(Android O)上的重要变化

刚适配完Android7.0还没多久,就看到Android8.0(Android O)已经推出开发者预览版的新闻,我的心情你是可以想到的。这次趁早刷到最新版,运行示例代码,看看Google又做了哪些新...

值得你关注的Android7.0上的重要变化

Android7.0系统为我们带来很多新功能,应用开发带来的很多新变化需要注意。值得高兴的是,现在Android新版变化有了中文说明,虽然翻译还有欠缺,但了胜于无(而且英文版的内容会更多些,可能中文翻...

值得关注的Android6.0上的重要变化

伴随着众多新特性和新功能,Android6.0(API level 23)在系统和API上都有着诸多的改变。本文着重介绍几个关键变化,以帮助你理解这些改变对你的APP产生的影响。 一、运行时权限...

值得你关注的Android6.0上的重要变化(二)

十 Android KeyStore变化 十一 Wi-Fi和网络变化Wi-Fi and Networking Changes 十二 相机服务变化Camera Service Changes 十三 运行...

Android之6.0上的重要变化(二)

十、Android KeyStore变化   此版本上Android Keystore provider不再支持DSA,仍旧支持ECDSA。   锁屏密码在(如用户或设备管理器)禁用或重置的情况下...

管理者如何面对不确定性,环境变化的这几个重要特征你知道么

如何面对不确定性是我最近一直关注的主要话题之一,因为管理者在今天需要拥有的最重要的能力是:管理不确定性。以下是有关不确定性问题的几个主要的视角和解决之道。

值得你关注的Android6.0上的重要变化(一)

一 运行时权限检查Runtime Permisssions 二 休眠和应用待机模式Doze and App Standby 三 移除Appache的HTTP ClientApache HTTP Cli...

Android之6.0上的重要变化(一)

伴随着众多新特性和新功能,Android6.0(API level 23)在系统和API上都有着诸多的改变。本文着重介绍几个关键变化,以帮助你理解这些改变对你的APP产生的影响。 一、运行时权限检查...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)