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

(https://www.packet.net/blog/how-we-failed-at-openstack)

(译者:白云鹏 责编/钱曙光)

原文发布于微信公众号 - CSDN技术头条(CSDN_Tech)

原文发表时间:2015-01-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏阮一峰的网络日志

关于网上论坛

昨天,jQuery的创始人John Resig怒气冲冲地宣布,不再使用Google Groups。 他写了一篇长达2000个单词的文章,详细解释了为什么。请注意...

4058
来自专栏CSDN技术头条

2015谷歌I/O大会综述:Android M、Android Studio、云端测试工具

2015谷歌I/O大会如期在美国旧金山举行,和以往一样,谷歌带来了一系列的产品更新和为开发者提供了更多的开发工具,下面我们以一个简要的形式,为你展现本次开发者大...

2288
来自专栏SDNLAB

Docker安全性不成熟 但在可控范围内

Gartner公司的分析师发表一份声明,指出尽管这款容器化工具已经闯出了响亮的名号,但Docker的安全性仍然不够成熟。 于近期发表的这篇《Docker管理下的...

3394
来自专栏企鹅号快讯

直播、NFC、分包加载……小程序这两次新能力,有哪些开发者们可以玩的东西?

小程序释放的能力一波接一波,对于开发者而言,真的是高潮一波接一波,微信已经越来越像一个移动端的操作系统。 如今,理论上来说,基于微信几乎可以完成所有想完成的开发...

3075
来自专栏编程坑太多

『高级篇』docker之服务编排三大平台扬帆起航(21)

PS: 国内这种公司还是很多的,他们致力于帮助互联网企业来使用docker。让企业不管是传统服务,还是微服务,都可以享受到docker带来的遍历。他们的方案基本...

833
来自专栏云计算D1net

开发漫谈:最受DevOps欢迎的五种工具

DevOps这个词在几年前从欧美流向大陆,主要反映了开发与运维两批人之间的矛盾与磨合。从单词的角度来讲,DevOps是开发(Development)和运维(Op...

3595
来自专栏程序你好

采用微服务和容器架构的五个想法

作为New Relic容器Fabric项目(我们的内部容器编排和运行时平台)的首席站点可靠性工程师(SRE),我花了大量时间与现有和潜在客户一起回答关于我们如何...

973
来自专栏大魏分享(微信公众号:david-share)

从2015年服务器操作系统厂商收入排名谈U2L

2015年服务器操作系统收入排名 Garnter在2016年5月20日发布了服务器操作系统收入分析报告。里面包括Linux、UNIX和Windows三大类操作系...

3503
来自专栏编程坑太多

『高级篇』docker容器来说微服务导学(一)

PS:整体把握微服务,清晰理解微服务的各种概念,如果开发微服务,技术栈之间的微服务通信,怎么样把一个服务运行在docker容器里,服务之间是如何建立连接的,多种...

1875
来自专栏鹅厂网事

软硬件分离趋势及开放网络发展

1. 前言 一直以来,网络设备给人的感觉就一个或大或小的铁盒子,其貌不扬,让人猜不透里面到底是啥。而这种情况将有所改观,在OCP等开放组织、众多芯片商、ODM商...

3317

扫码关注云+社区

领取腾讯云代金券