OpenStack发展的同时切勿重演Neutron

ZDNet至顶网服务器频道 11月06日 编译：OpenStack有点像个早熟的孩子—— 开源数据中心管理（open-source data center management）和服务层（service layer）不断地做一些了不起的事，而同时又让人伤透脑筋。

这个开源云控制狂本周在香港召开峰会。我们来看一下OpenStack这个雄心勃勃的软件的方方面面：

OpenStack于2010年中诞生，计算源码是美国航空航天局捐的，而存储源码则是Rackspace捐的。

OpenStack是设计用来管理共有云和私有云的。很多公司认为OpenStack有希望让他们能拥有一些单一专有云的功能，一些如谷歌、亚马逊及微软经营的云那样的功能。

一路走来，有数百个公司对 OpenStack感兴趣，其中包括英特尔、红帽、AT&T、Brocade 和F5。OpenStack现在是一些公有云的基础，如惠普云和IBM即将面世的SoftLayer-revamp。

尽管很多人称OpenStack是“云之Linux”，OpenStack技术到目前为止并没有像Linux那样在可用性和兼容性上达到人们的期望，不过正在迅速改善之中。

截止这个月，OpenStack的很多核心组件已达到可用水平，并可以在具规模的系统上应用。不少人对OpenStack的Cinder块存储组件（Cinder block storage component）、Horizon网站前端（Horizon web front-end）和Keystone身份服务（Keystone identity service）称赞不已。OpenStack的一些新功能也做得不错，甲骨文公司在自己的云里用上了新的Swift object-cum-blob存储。

但是，OpenStack技术在一个关键领域里碰到问题，它的Neutron网络组件问题多多。这已经引起OpenStack社区的关注，也有不少人私下在一些IRC（Internet Relay Chat“因特网中继聊天”的缩写）聊天室中就此问题大谈特谈。

这些挑战的出现可以说是能够预见的。因为尽管开源在过去二十年强劲地攻占了储存和计算系统，网络系统到目前为止却仍然是专有供应商的坚固领地。可以看到，这一块变化不大，在这一块的开源码和开源专业人员也不多。

Neutron网络噩梦

Neutron（中子）是所谓的“网络即服务”（"network-as-a-service"）组件，以前名为Quantum（量子），2012年9月与Folsom系统版一起发布。名字引起Quantum公司的争议，后来在最近的Havana 发布中改名为Neutron。

在IRC上的OpenStack网络聊天室记录中，记者看到OpenStack社区在Neutron里找到一些bug，并不得不在发布Havana 前急急忙忙地打上补丁。尽管这些bug已经得到修补，但其出现充分说明了要为规模达数千个服务器的一个系统开发稳定的网络组件是十分困难的。

Hernan Alvarez是Bluebox（OpenStack寄存公司） 的运营与产品副总裁。他说：“如果你只待在Neutron的基础应用区内，不会有什么问题。但是一旦你想要更深入，就会相当地冒险。”

OpenStack公共电邮群里9月27号有个贴子询问有没有人在产品里使用Quantum或Neutron，至今尚未获得任何公开答复。

发帖者特别提到Neutron技术上的几个方面“不能尽如人意”，包括：不支持简洁地拆解网络，更新子网困难，不支持多主机部署，“Neutron开发人员很少或没有在IRC上提供技术支持”以及在网络管理文件中出现的“部署上混乱和不切实际的假设”。

这名用户写道，“我们是由于Nova网有遭弃用的危险才被迫考虑Neutron的。”

当然，一个人的经验明显不能代表整体，有可能很多人在私底下玩Neutron并将其用在私有和秘密项目上。但是，贴子中提到的问题记者在过去几个月里不止一次听人说起过。

另外一个问题同时涉及到含计算网络组件(Nova)和独立发展网络组件(Neutron)，两个组件里的单机和简单网络、IP地址分配、IP路由、NAT、DHCP和OpenStack元数据服务的源码都处于一个单一的码块里，因而造成接口困难。另一方面，多主机格式里的服务分布在虚拟机管理程序里，会出现攻击面过大的问题。

OpenStack专业公司CloudScaling的主管Randy Bias说，“从构造上来说，如果因为OpenStack的默认网络模式在大规模使用时不给力而不得不在产品里使用默认网络模式，这真是最槽糕的事情。”

Neutron还在开发中。据我们所知，很多公司在努力提高此关键组件的稳定性。但是，这也导致了社区的分化。这有点像Linux和Android社区的分化。OpenStack社区有必要弄清楚分化的存在，否则会出现一堆独立的版本，而且各版本间不能相互转移。

Bluebox的Alvarez指出：“大家用到很多不同的方法使得Nova的Neutron具有高可用性。这里没有最好的做法——每一个解决方法都像是独特的手工作品。”

Alvarez说的“手工作品”特点很精彩地说出了OpenStack在另一个方面的问题：OpenStack的可用组件多数在应用中都需要大量地调整，各个公司都调整安装自己的系统，最后OpenStack社区发布下一个版本时，一些改良的功能很难融合在一起。

CloudScaling 的Randy Bias指，“下载一个OpenStack部署是一件复杂的事，有不少隐患。OpenStack是一个很灵活的系统，但也有不少挑战，原因是有些设计上的决策会导致升级困难。”

OpenStack软件供应商Metacloud应同以上的说法。Metacloud的系统架构主管Chet Burgess最近告诉记者，设置OpenStack软件对新手管理员来说是一件困难的事，因此会吸引一些机构对OpenStack作出调整以处理相关的问题。

Burgess说：“部署OpenStack不是件简单的事，给OpenStack排除故障和运行OpenStack也很复杂。像OpenStack这样的系统有很多功能和选项，所以要保证一切都顺利也不是件容易的事。”

CloudScaling、Metacloud和Bluebox都提了一条建议，各个公司不应该过多地插手自己用到的发行版本（指代那些受益于外包OpenStack部署的公司。但是，我们相信他们说的是为OpenStack社区的利益着想的，然后才是他们自己少少的利益，而不是反过来。）

Bias说道：“我觉得主要问题是……大家都是一副‘去下个OpenStack，想用来做什么就做吧’的姿态，没有看到事情的另一面。另一面是：这样做了以后就意味着要做好维护一个定制系统的准备。有些类似‘你为什么不去建一个定制的Linux版本，’因为这样做的话要做出各种不同的奇怪决定。”

我们认为，OpenStack更多需要的是一个小范围的版本及社区一致的努力，以期待可以让所有的核心功能得到强化。

Hadoop用的就是类似的方法，包括因特尔公司、Hortonworks和微软在内的不少公司汇集在Apache Hadoop项目的周围，再加上有几个公司制造如MapR 或Cloudera的极为专有的“开源核心”发行版本。

Bias说，“大家应该用基于OpenStack的产品，而不是采用DIY（自己动手做）。你要么是去买辆车，要么是改装车，没必要两样都做。要确定自己的策略。”

Icehouse版定于6个月左右后发布。社区不少人期待网络问题届时会得到解决以及其他核心功能会得到加强。

Metacloud 的Burgess说：“前面道路是崎岖的。但过去两年我们一路走来，证明了它不仅是可行的，而且还相当的不错。” Bluebox的Alvarez认同这个说法，他补充说，“过去一年半内的发展绝对是惊人的。”

只要OpenStack社区保持技术上不断创新，同时又在基本原理上做足功夫，OpenStack就会进一步发展。但是Neutron的开发是一个值得警惕的例子。这个例子说明，要为每个不同大小的数据中心建造管理系统不可避免地会出现各种困难。