2012-01-27 13:28:00
来 源
中存储
Openstack
OpenStack社区于1月26日号顺利发布Essex-3(E3),在去年9月22日发布Diablo之后,OpenStack社区随即开始着手新版本的设计和开发,新版本开发代号为Essex。

OpenStack社区于1月26日号顺利发布Essex-3(E3)。此次发布包含云计算控制中心Nova、镜像服务Glance、认证服务Keystone和Dashboard项目Horizon,也包括对象存储项目Swift,Swift1.4.5版本是1月12日发布的。目前OpenStack旗下主要就是以上五大项目,其中Keystone和Horizon是自Essex开始成为OpenStack核心项目的。

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的同时,旧有认证功能将被弃用,相关代码也即将删除。

  • 更加友好的Dashboard

    Essex版本的Dashboard在用户体验上下了不少功夫,实现了由设计师Paul Tashima设计的原型:http://speakerdeck.com/u/paultashima/p/openstack-dashboard-wireframes-10142011

  • 安全性改进
    • API默认支持https
    • 对OpenStack中组件之间的消息通讯加密
    • 数据库权限分离,每个API Server使用自己的数据库账号,并且只能管理自己API所关心的数据表。
  • 支持Volume的快照备份API

    AWS的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社区的开发中来。

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。