OpenStack 社区于 1 月 26 日号顺利发布 Essex-3(E3)。此次发布包含云计算控制中心 Nova、镜像服务 Glance、 认证服务 Keystone 和 Dashboard 项目 Horizon,也包括对象存储项目 Swift,Swift 1.4.5 版本是 1 月 12 日发布的。目前 OpenStack 旗下主要就是以上五大项目,其中 Keystone 和 Horizon 是自 Essex 开始成为 OpenStack 核心项目的。
在去年 9 月 22 日发布 Diablo 之后,OpenStack 社区随即开始着手新版本的设计和开发,新版本开发代号为 Essex。Essex 版本首次使用 6 个月的发布周期,而此前发布的四个版本: Austin 、 Bexar 、 Cactus 、 Diablo 均是以 3 个月作为周期发布的。
去年 10 月 6 号 OpenStack 社区开始着手开发 Essex 版本以来,每 5 周迭代一个里程碑版本,直到 1 月 26 号顺利完成 Essex-3 的发布,之前已经经历了 Essex-1 和 Essex-2,下一个里程碑 Essex-4(E4)将于 3 月 1 日发布,如果一切顺利,4 月 5 日将正式发布 Essex 版本,具体日程详见 http://wiki.openstack.org/EssexReleaseSchedule 。
从 E3 开始,新特性的开发已被冻结,E4 的主要工作就是 bugfix,确保 Essex 现有功能的稳定。那么现在来回顾一下 Essex 的主要新特性。
- 改进虚拟机状态管理当前虚拟机的状态比较容易出错,尤其是对那些需要长时间执行的任务更是容易导致不确认性的结果。比如创建虚拟机过程中,一个常见的失败将会导致状态异常:因为这一步骤涉及很多操作,比如下载镜像、暂时挂载镜像以插入元数据、准备网络环境、启动虚拟机等等,任何一个步骤阻塞了,虚拟机的状态就始终为 building,直到你手工解除阻塞状态或者去数据库中手工变更该虚拟机状态。新版本通过引入更加完善的有限状态机等措施来解决这个问题。
- 支持主机聚合单元 (host aggregates)熟悉 AWS 的同学知道,AWS EC2 按区域大小分两类:Region 和 Availability zone,前者可以认为是一个地区,后者可以认为是地区中的某个数据中心,而 OpenStack 的主机聚合单元可以认为是比 AZ 更小的单元,可以将同一个 AZ 中的实例分组,同一分组使用同一个网关,同一组存储等资源。这样区分的主要目的是为了保证虚拟机在某个 AZ 中的高可用,比如,单 AZ 中某个 VM 的宿主机需要维护,这时可以通过合适的虚机在线迁移技术迁移到另一个聚合单元中去。“聚合单元”是管理员界面的概念,对普通用户透明。
- 全面支持 Keystone 认证在 Essex 版本之前,Openstack 的各个子项目比如 Nova, Swift 均使用各自独立的认证系统,而 Essex 版本将全面支持 Keystone。Keystone 是一款认证服务,有两大功能:基于 token 的认证 (authentication,即 authN) 与和基于用户 - 服务的授权 (authorization,即 authZ),可以连接外部认证系统如 LDAP。未来还将支持 oAuth, SAML, openID。支持 Keystone 的同时,旧有认证功能将被弃用,相关代码也即将删除。
- 更加友好的 DashboardEssex 版本的 Dashboard 在用户体验上下了不少功夫,实现了由设计师 Paul Tashima 设计的原型: http://speakerdeck.com/u/paultashima/p/openstack-dashboard-wireframes-10142011
- 安全性改进
- API 默认支持 https
- 对 OpenStack 中组件之间的消息通讯加密
- 数据库权限分离,每个 API Server 使用自己的数据库账号,并且只能管理自己 API 所关心的数据表。
- 支持 Volume**** 的快照备份 APIAWS 的 EBS 做快照时会把快照数据增量备份到 S3,而 Nova Volume 目前只支持对存储做快照,快照数据仍然存储在 volume 节点的本地,而 Essex 将新增 API 支持把快照数据保存到 OpenStack 的 S3 实现——Swift 中去。
- 支持从 Volume启动Nova-Volume 是 Amazon EBS 在 OpenStack 中的实现,虽然不如 EBS 功能强大,但具备 EBS 基本功能,如动态分配、虚拟机挂载、快照等。支持从 Volume 启动意味着虚拟机根分区不需要本地存储,为以后的虚拟机迁移提供了方便。
Essex 还做了一个重要决定,删除了对 Windows Hyper-V 支持的相关代码。事情的起因是 OpenStack 开发者在邮件列表一封标题为“ Essex dead wood cutting ”的提议:
考虑到 Nova 即将进入 Feature-Freeze 阶段,是时候清理一些充满 bug 并且没有维护,或者根本没有用到的代码。”
其中就提到两个建议:
Ajaxterm (unmaintained, security issues, replaced by VNC console)
Hyper-V support (known broken and unmaintained)
其中删除 Hyper-V 的建议得到了大多数开发者的讨论和支持。
官方 changelog 中给出了以下原因:
Hyper- V 已经持续多个版本没有维护了,单元测试也很粗糙,几乎没有办法去测试它,也没有人计划进一步维护相关代码。在很长一段时间内,我们没有收到任何反馈表明 它还能正常工作。另外,有许多接口更新已经体现到其它的 Hypervisor 驱动中,只有 Hyper-V 一直没有进展。即使它能够工作,也仍只能是其它驱动功能的一个子集。
另一个原因也许是,目前还没有基于 Windows 的 IaaS 云计算云台采用 OpenStack,Windows 的授权可能也是一个问题。因为 Nova 的的设计非常模块化,所以单一功能的删减不会对其它系统造成影响。
新特性当然令人期待,但是目前 OpenStack 饱受诟病的就是 bug 太多,系统不够稳定,也很让初学者恼怒。针对这种情况,OpenStack 的发行经理 (Release Manager)Thierry Carrez 在他的博文 Making more solid OpenStack releases 中也在呼吁开发者重视维护,而不是一味只管开发新特性。他指出,目前 OpenStack 社区在新版本发行上还存在以下问题:
- 开发者对于 bugfix 缺少关注
- 自动化测试还不够充分,未能有效地捕获异常
- 缺少 bug 分类,只有很少的人在做 bug 整理、分类和制定优化级,导致一些最需要受到关注的 bug 淹没在大量的噪音之中。
OpenStack 于 2 月 2 号举办了一次线下的 Bug 消灭活动——Bug Squashing Day,该活动鼓励大家参与 bug 整理、bug 分类和 bugfix 等工作,效果很明显,当天就消灭了总 bugs 数的 20%~30%。
为了保证 Essex 版本质量,社区也预留的足够的时间——10 周,来做 bugfix 工作,而 Diablo 发行前只有 4 周的时间。 相信 Essex 的发布会给云计算业界带到更加深远的影响,也希望更多的国内有识之士参与到 OpenStack 社区的开发中来。
程辉:新浪云计算技术经理,擅长系统架构、Web 性能优化,目前负责新浪 SAE 整体运维和新浪云计算虚拟化平台。新浪微博: @程辉 邮箱:freedomhui(at)gmail.com
评论