OpenStack发布Essex-3版本

zdc253212956

　　本文转自InfoQ，原文地址：http://www.infoq.com/cn/news/2012/02/openstack_e3  
　　作者信息：程辉 新浪云计算技术经理，擅长系统架构、Web性能优化，目前负责新浪SAE整体运维和新浪云计算虚拟化平台

　　
　　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的同时，旧有认证功能将被弃用，相关代码也即将删除。
  
• 更加友好的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社区的开发中来。