OpenStack 发布 Essex-3 版本

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