David Laube：使用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系統的安裝(這也是在考