从一个OpenStack的失败案例看Ironic和Neutron组件的现状

> 作者：杨赛 2015年1月12日，[Packet公司](https://www.packet.net/)平台部门VP David Laube在公司官方博客上发布了一篇名为《[谈谈我们把四个月的工作量扔进垃圾堆的经验，或者应该说这是OpenStack的失败案例](https://www.packet.net/blog/how-we-failed-at-openstack)》的文章，介绍他们在尝试OpenStack中遇到的一些挫折。 Packet公司提供裸金属基础架构服务（也就是以前叫做物理机托管的服务），跟Softlayer和RackSpace做的生意差不多，但是做的时间短，是一家创业公司，大约在2014年上半年正式启动，本文作者David就是在去年夏天应邀加入的这家公司。Packet的创始人Zachary Smith在创立Packet之前做过Voxel这家公司，也是做服务器托管服务，后来在2011年卖给了Internap，成为Internap的服务器托管业务的一部分。 David一直以来的经验是在托管行业做系统运维，有十多年的运维经验（前九年都在HostRocket.Com）。2011年的时候他加入Voxel/Internap，成为Zachary的下属。按照David的自述，2014年夏初Zachary去邀请他加入Packet的时候，他一开始觉得当时市场上的IaaS服务已经很多，没有必要再做一个。但是聊着聊着他就觉着市场上的IaaS的确不够好用，再加上他当时已经玩了一段时间的Docker，非常看好在裸金属基础架构上做一套基于容器技术的部署系统的价值，所以就觉得值得做。 Voxel的部署管理系统完全是自己编写的。在Voxel合并入Internap的那一年（2012年），他们遇到的无数网络问题、大量硬件变更和系统变更给这套系统带来了很大压力，这些问题最终体现在了服务稳定性变差，当时在[WHT](http://www.webhostingtalk.com/showthread.php?t=1213599)上有用户表达了强烈的不满。现在有机会重新搭建一套自动化安装管理系统，而且最好在几个月内就能在生产系统上给客户用，David开始考察OpenStack。在David看来，如果OpenStack在网络自动化、IP管理、安装流程、硬件生命周期管理这几个方面的基础足够扎实，那完全可以依赖这套基础快速搭建起他想要的东西。 David做了大量调研，读了当时大部分的IRC讨论，自己也尝试用DevStack做过安装，觉得不错。让他真正做出决定的是来自RackSpace的一篇博客，该博客讲述了[RackSpace是如何用Ironic组件实现他们的裸金属云服务管理体系的](https://developer.rackspace.com/blog/how-we-run-ironic-and-you-can-too/)。于是他们拿着最新的Juno版本提枪上战场了。四个月的努力让他们收获了如下经验： - Nova、Ironic驱动、Neutron是他们最需要关心的三个组件。Ironic是为了实现裸金属管理，而Neutron则是为了避开2层网络和VLAN，让每台主机直接连接3层网络。 - 大部分文档是过时的或者错误的，于是David不得不用大量时间debug以验证哪个文档是正确的。 - OpenStack社区的确很大，人很多，但几乎没人有Ironic组件的生产使用经验，就连项目的核心开发者有时候也解答不了他们的部署问题。 - 一个人同时搞透Ironic和Neutron是一件几乎不可能完成的任务。David决定自己去研究Ironic，让另一位同事去研究Neutron。 - 阅读了每一篇Ironic的文档和讨论后，David的结论是，OpenStack从整体设计上就是为虚拟机准备的。你一旦用Ironic，就只能用openvswitch和linuxbridge。 - Neutron能够支持的厂商交换机有限，而且能够支持的网络模型也有限。 - RackSpace能跑起来是因为他们做了超级多的定制。而他们定制的很多重要补丁是不公开的，你得自己写。而你要能写出来这样的补丁，必须非常非常懂OpenStack的核心代码！发展到这个阶段，David开始觉得自己掉进了一个大坑。花了大量的时间，但项目进展缓慢。不过，他还是决定要把Neutron再仔细了解一下。为何？ > “在物理交换机和物理服务器的体系下，安装系统不难。但是要做到可靠，这就超级难了。自动化是无止尽的持续投入，而最容易出问题的地方就是网络的自动化。” 而Neutron宣称自己是： > “一套服务库，可提供按需使用、可扩展、支持多种技术的网络抽象”。这样一套东西当然不可不看。但是看了之后，以下是David学到的东西： - Neutron的大部分功能是针对虚拟机，而非物理交换机的。 - 他们用的是Juniper的交换机，而Juniper交换机的Neutron驱动已经老掉牙了，对Juno版也没提供多少新的支持。 - Neutron的IP管理体系自己做得很原始，又无法跟外部的IP资产管理体系对接。最终，他们在圣诞前夕决定扔掉了OpenStack，然后用了三个星期开发了一套自己的IP管理系统。至于OpenStack，并不是不好，而是不合适他们的场景。之后他们还会继续关注OpenStack项目，并发布他们的一个Neutron驱动。