转载

David Laube：使用OpenStack的失败记

【编者按】David Laube，充满热情的互联网基础设施构建者，工作涉及托管服务、基础设施自动化和可扩展平台的部署。目前担任packet.net主管平台系统的副总裁。OpenStack是一个开源的IaaS实现，目前在企业得到越来越多的应用，本文分享了packet.net利用 OpenStack开发的一套云计算管理平台的实战经验，以及在开发、运营、维护过程中遇到的问题和经验分享。

以下为原文：

去年初夏，我的同事 Zac ，也是公司的CEO，向我求助如何构建一个现代化且任何东西都不安装的云托管平台。我回想自己以往的主要从业经历，包括构建，支持和使用可扩展的基础设施的经历，不禁犯起了嘀咕。我问自己，真的需要这样做吗？不是有很多不错的基础设施即服务（Infrastructure as a Service，IaaS）可以拿来用吗？

随着沟通的深入，我最终意识到现在很多云服务不是用户友好型的，使用起来存在很大的困难。另外，我是Docker的早期用户，Docker是应用容器引擎，这种容器支持的部署方案会使高质量的物理裸机在运维工作方面更加给力。但某些公有云的虚拟化情况，还有一些托管服务商存在的问题，都没能与复杂多变的物理硬件发展的需求相匹配。于是我觉得需要为此做一些工作。接下来咱们随着packet.net的部署旅程一起过把瘾吧！

开始安装之旅

我一头扎进了部署packet.net的工作。还同时忙着关注部署策略和云自动化的相关动态，从头到尾地检查特定安装程序，还有所有的开源云平台，以及我们已经安装的那些服务。

Voxel是被Internap收购的一款云主机托管平台，我们在使用的时候部署了很多自己的程序，在这过程中既看到了带来的好处，又体验了自己拥有软件平台的感觉。服务器的安装工作看起来似乎特别容易，好像一旦完成，一劳永逸，对吧？但这是绝对的错觉！因为安装完成后会出现数不清的网络问题，还有随时发生的硬件调整，以及各种操作系统存在的差异。在这样的情况下为用户提供不折不扣的自动化服务，安装并管理数千台服务器，并确保这些服务器正常工作，在五分钟之内还能响应Zac做出的决定。这对我来说可不是件轻松的事情。

为了使 packet.net到达预期的目标，数千台服务器7x24小时不断地安装和启动，并要在数月后上线。我开始关注 OpenStack 在互联网基础设施方面的独特之处，它可以被当作我们构建服务的手段。这包括联网业务的自动化，IP地址的管理，安装过程的监控，以及硬件的调换和安装。如果我能依靠OpenStack这些核心项目完成工作的话，那么我的团队就可以更加专注于能给用户带来更多价值的事情，像硬件分析，还有对容器机制的应用引擎提供技术支持。

别人提醒过我OpenStack存在的一些隐患，但我还是自己花了数周时间去阅读近期的版本记录，混迹于好几个维基的IRC官方聊天频道，并且玩了一下OpenStack的安装脚本 DevStack 。我开始对OpenStack的核心项目不再那么陌生。在过去的两年中，DevStack已经发展得非常成熟，而且所逢时机也刚刚好。全球领先的托管服务器及云计算提供商Rackspace最近发布了OnMetal物理裸机服务器部署方案，并公开撰写博客指出如何在其物理机上使用 Ironic 进行部署。而美国时间2014年10月16日，OpenStack的一个重要的版本，Juno版也正式发布了。

所以我觉得应该使用OpenStack来为公司的物理服务器进行部署。

部署的过程

我知道学习OpenStack的过程不会平坦，并且明白这需要拼命努力学习其中的每一个项目，而不只是安装。我细致深入地研究OpenStack每一个项目，尽力去了解Nova的动态，还有Ironic的驱动程序，特别是Neutron。我们不仅要在物理服务器上安装Ironic，还要支持packet.net托管服务的网络模型，特别是要用Layer3取代Layer2和VLAN层主机的功能。

这个时候你可能说：“喂，要阅读和学习的文档那么多啊”！在过去的一个月里，我明显能感觉到我们所接触到的文档不是过时的就是有错误的。这让我不得不去从以前优质的文档中去删选内容，比如从维基上的文章，IRC（一种聊天工具）的日志，还有版本提交记录，从这些地方去寻找最新的正确信息。这些基础工作完成后，我要用python去做大量的调试工作，去验证各种与文档描述不一致的功能。比如这个是否工作，那个是否正确，这是很漫长的过程。

值得一提的是，存在着那么一群人和公司，他们依靠OpenStack生存，组成一个很大的共生系统，特别是OpenStack的Nova和标准的Neutron项目相关的部分。尽管从规模上这个群体可以与其他开源项目进行匹敌，但其实对于Ironic来说，他们很难有人能够达到产品级的使用水平。我就碰到过这样的情况，我向其核心开发人员咨询了一些实施的问题，他们居然答不上来。并且我从Google搜索这些问题，也仅能得屈指可数的几条与问题有关的信息。

经验一：OpenStack规模不小，新兴并发展迅速，但要了解一些过去的基本信息，会感到相关的文档良莠不齐。

我把Neutron部分交给了我的同事去处理，而自己又深入地了解了Ironic。但实际的情况是，我们需要OpenStack每个部分特定的开发人员，让他们帮助我们去理解代码库，才能跟上OpenStack每个项目更新的脚步。那我们又怎么去恰如其分地满足自己的需要呢？于是我就通过IRC和来自Rackspace的OnMetal团队成员接触，还通过邮件联系。去逛OpenStack开发者论坛。我敢打保票，自己阅读了每一个相关文档，还有论坛里的每个帖子，而且还通过Google搜索出的相关信息去调试Ironic，这些我都做到了!

尽管对于先前那种Ironic项目来说OpenStack Nova版的物理服务器部署方案取得了突破性进展，但是OpenStack还是以虚拟化技术为核心进行设计的。仍然存在很多功能和文档的修改还介于Nova的物理机部署方案和带有驱动的Ironic部署方案之间。我把这种情况反馈给了力量有限的Ironic技术支持部门，却硬被要求使用与虚拟技术相关的openvswitch和linuxbridge。我们的网络模型与此存在严重的冲突。于是我发现，OpenStack的Neutron项目不仅缺乏针对特定网络产品厂商的技术支持，也缺乏对不同网络模型的扩展能力。

对OpenStack的核心代码有更深了解的大用户（最典型的就是Rackspace公司），依靠将OpenStack的那些项目高度定制化后，使之能够在实际的物理网络上部署物理机。其中有几个补丁是已经发布了的，但很多重要的补丁都没有公开，需要用户自己重新编写，同时还要对以后新发布的版本进行维护。

经验二：OpenStack是基于虚拟化技术的平台，如果你用的不是虚拟技术，那就要再考虑了！

到了这份儿上，我已经对使用OpenStack部署公司服务产生了严重的怀疑。这么多需要了解的东西，还有要做与每个项目保持同步的工作，这样的情况令人望而生畏。并且，我开始认识到要对Nova和Ironic所做的定制化工作并不是小事一桩，这会抵消掉OpenStack在开源方面所带给我们的好处。

但我还是觉得完全了解Neutron的细节非常重要，这是我目前唯一的念想儿。

对于物理交换机和服务器来说，安装部署服务器并不太困难，而且解决方案十分成熟可靠。而自动化工作却需要很多工具配合工作才能完成。从我的经历来看，大多数基础设置部署工作最容易出错的部分就是网络部分的自动化。你看，物理交换机的操作系统还存在很多不足之处。对当前的自动化工作和API的交互的支持显得捉襟见肘。其实，我用过的另外一款网络自动化工具的蹩脚表现是让我考虑使用OpenStack的主要原因。Neutron项目有非常令人振奋的使命：可以按照需求提供可扩展，不受制于任意一项技术的服务，包括相关的库。我也希望是这样呀！

但现实并不像所承诺的那样。根据软件定义网络（SDN，Software Defined Networking）的说法，大多数在基于虚拟机监视器（hypervisor）的虚拟网络下工作的项目并不是真实的交换机。不仅是因为对于交换机厂商来说严重过时的Neutron驱动，而且OpenStack最新的Juno版本的支持工作也力量有限。另外，Neutron使用了自身并不完善的IP地址管理器（IPAM），根本没有任何自己分配外部访问方式的概念，也没有提供关于IP地址管理方面的书面说法和权限。牺牲用户体验来适应Neutron这些不足，这是不能接受的。

经验三：OpenStack的Neutron项目支持工作并不那么完备、系统。使用之前要先看看自己的交换机能否适应。

这样一来，我们要如何应对？

长话短说。在圣诞节的前一周，我们丢掉了OpenStack，然后又花了三周的时间开发了一套定制化的自动化部署平台。在十二月初搭建好自己的IP管理系统后，团队就卯足了劲要将系统搭建自己定制工具上。而每个新项目都会有自身的使命。作为一家公司，我们的愿景是不断进取，并且我们觉得，在调查和部署OpenStack的过程中，解决了存在的大部分问题：构建了一个灵活且能提供服务功能的IPAM系统（我们管它叫Magnum IP）。在设施管理平台和物理基础设施之间，我们还建立了用户和权限模型。

有时现存的东西并不一定是最好的，也不一定能满足自己的需要。我们使用OpenStack部署packet.net的过程就完全说明了这个道理。同时，我们也会努力发布自己的Neutron插件，与OpenStack项目的发展相适应，我们现在正在做。

之后的一周时间，我们最终完成了CoreOS系统的安装（这也是在考察了Ubuntu，Debian和CentOS后做出的决定）。工作精益高效，对变化反应迅速，对系统记录详尽，这样我们可以做一些高级功能和高可用性工作，而又不会影响到用户体验，这让我感到激动不已。我能说自己工作学习两不误吗？

原文链接： Why We Threw 4 Months of Work in the Trash; or How we Failed at OpenStack （译者：白华责编/钱曙光）

正文到此结束