| 【编者按】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搜索这些问题，也仅能得屈指可数的几条与问题有关的信息。
我 把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部署公司服务产生了严重的怀疑。这么多需要了解的东西，还有要做与每个项目保持同步的工作，这样的情况令人望 而生畏。并且，我开始认识到要对Nova和Ironic所做的定制化工作并不是小事一桩，这会抵消掉OpenStack在开源方面所带给我们的好处。 但我还是觉得完全了解Neutron的细节非常重要，这是我目前唯一的念想儿。 对 于物理交换机和服务器来说，安装部署服务器并不太困难，而且解决方案十分成熟可靠。而自动化工作却需要很多工具配合工作才能完成。从我的经历来看，大多数 基础设置部署工作最容易出错的部分就是网络部分的自动化。你看，物理交换机的操作系统还存在很多不足之处。对当前的自动化工作和API的交互的支持显得捉 襟见肘。其实，我用过的另外一款网络自动化工具的蹩脚表现是让我考虑使用OpenStack的主要原因。Neutron项目有非常令人振奋的使命：可以按 照需求提供可扩展，不受制于任意一项技术的服务，包括相关的库。我也希望是这样呀！ 但现实并不像所承诺的那样。根据软件定义网络 （SDN，Software Defined Networking）的说法，大多数在基于虚拟机监视器（hypervisor）的虚拟网络下工作的项目 并不是真实的交换机。不仅是因为对于交换机厂商来说严重过时的Neutron驱动，而且OpenStack最新的Juno版本的支持工作也力量有限。另 外，Neutron使用了自身并不完善的IP地址管理器（IPAM），根本没有任何自己分配外部访问方式的概念，也没有提供关于IP地址管理方面的书面说 法和权限。牺牲用户体验来适应Neutron这些不足，这是不能接受的。
这样一来，我们要如何应对？ 长 话短说。在圣诞节的前一周，我们丢掉了OpenStack，然后又花了三周的时间开发了一套定制化的自动化部署平台。在十二月初搭建好自己的IP管理系统 后，团队就卯足了劲要将系统搭建自己定制工具上。而每个新项目都会有自身的使命。作为一家公司，我们的愿景是不断进取，并且我们觉得，在调查和部署 OpenStack的过程中，解决了存在的大部分问题：构建了一个灵活且能提供服务功能的IPAM系统（我们管它叫Magnum IP）。在设施管理平台 和物理基础设施之间，我们还建立了用户和权限模型。 有时现存的东西并不一定是最好的，也不一定能满足自己的需要。我们使用OpenStack部署packet.net的过程就完全说明了这个道理。同时，我们也会努力发布自己的Neutron插件，与OpenStack项目的发展相适应，我们现在正在做。 之 后的一周时间，我们最终完成了CoreOS系统的安装（这也是在考察了Ubuntu，Debian和CentOS后做出的决定）。工作精益高效，对变化反 应迅速，对系统记录详尽，这样我们可以做一些高级功能和高可用性工作，而又不会影响到用户体验，这让我感到激动不已。我能说自己工作学习两不误吗？ |
