惠普：对OpenStack的网络噩梦Neutron负责

ZDNet至顶网服务器频道 05月14日 编译：惠普公司已经坦言OpenStack项目中的网络组件相当差劲，因此整个技术社区都需要认真反思如何在未来的工作中推动其发展完善。

作为一家企业级IT厂商，惠普公司云业务首席运营官Saar Gillai在本周二接受采访时指出，OpenStack的“Neutron”系统之所以引发诸多问题，是因为“我们将归结于社区的失误”。

Neutron是OpenStack项目中的“网络即服务”技术，它的作用在于帮助管理员创建、配置并管理软件定义网络体系。

该技术属于核心项目，其稳定性对于以OpenStack为基础构建大型基础设施即服务云而言无疑起到了至关重要的作用。

Neutron以Quantum技术为基础，后者则源自Nicira的开发项目。随着Nicira被VMware所收购，该公司的员工们也在新环境下继续对这项技术开展研发。

Quantum项目的很多早期用户将其与Nicira的“NSX”插件配合使用，二者共同构建起了Nicira公司的软件定义网络技术方案。

遗憾的是，一旦抛开NSX插件而独立运作，Neutron就会带来多种严重问题。

“这是惟一一个我们要求配合第三方组件共同使用的项目，”红帽公司虚拟化业务部门产品管理负责人Andrew Cathrow解释道。“真正的挑战在于，Neutron的发展过程紧紧围绕着同一家供应商，因此当人们谈论Neutron时、他们在谈论的实际上也正是Nicira。”

惠普在利用OpenStack技术构建自家公有云服务时也遭遇了同样的困局。经过Gillai的证实，由于问题太过严重、惠普不得不被迫对OpenStack的网络组件进行重新编写以保证其云方案能够正常运作。“我们在公有云体系中遭遇Neutron难题，为此我们只能在很长一段时间内与OpenStack主干保持距离，”他解释道。时至今日，在惠普Helion项目的帮助下，该公司正尝试以主社区品牌为核心开发出一套对网络组件进行过修复的OpenStack发行版。

Neutron最令人抓狂的问题在于，惠普所碰到的阻碍只在大型规模环境中才会出现，因此很多仅把OpenStack用于小规模生产部署环境的使用者对这一切毫无察觉。不过随着这一技术方案越来越多地融入到生产部署流程当中，Neutron的弊端也将变得愈发明显，这也正是用户在本周一OpenStack峰会用户交流环节中不断发出抱怨之声的根本原因。

“其实我们每个人对此都负有责任，”Gillai指出。“我认为社区的每一位参与者都很清楚，在未来十二个月中将有大量针对这一问题的修复努力陆续展开。我们在自己的公有云方案中着实被Neutron难题困扰了好一阵子。这是个有理由也有必要被解决的问题。供应商必须作出妥协，转而从OpenStack的角度出发并遵循其处理方式。”

Neutron的问题一方面源自其自身设计思路，另一方面也与它所接入的软件定义网络系统密不可分。

“我们尝试在Neutron中为大量商用软件定义网络方案提供支持，”Piston Cloud Computing公司首席技术官Joshua McKenty在接受采访时解释称。“从理论角度讲，‘难道单单只有Neutron中的开放vSwitch表现得糟糕透顶？’——事实上，即使是那些商用方案也并没有达到原本的预期效果。”

问题在于，目前社区“主要着眼于网络技术七层基础结构中最为光鲜显眼的四层”，McKenty表示。

“我认为在未来十二个月中，Neutron将变得越来越好，”Gillai断言。“没错，我也同意Neutron存在巨大问题。从某种程度上讲，大家甚至可以将其视为危害项目使用的罪魁祸首。经过一整天的讨论，客户已经提供了充足的反馈意见，而我们的任务则是将其修复。”

Gillai的观点与红帽的意见可谓不谋而合。“我们已经收集到生态系统内各家供应商对此作出的反馈，”红帽公司的Cathrow指出。“我认为Neutron的未来发展形势还是比较乐观的。”

从各个角度来看，Neutron的失败与复苏计划需要一大前提作为配合，即OpenStack项目必须被视为一个整体。由于该项目在起步阶段作出了太多承诺，发展时期又高度依赖供应商的实际表现，因此只有当各主导方正视其薄弱环节时、问题才有可能得到解决。随着OpenStack社区从实践活动中逐步吸取经验教训，他们在技术方案中犯下的失误也将越来越少，这一切最终将帮助各供应商拿出一套真正能够吸引电信及其它企业用户、且具备可行性的云操作系统。

“我们必须重新审视过去，并从项目发展轨道中积累经验，我相信这些结论已经为各供应商所理解与采纳，”Cathrow表示。“毕竟我们每个人都是决策后果的承担者。”