> 作者：楊賽 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驅動。