[[126669]]

Packet是一家成立不久的公司，他們主要是為用戶提供基于裸機服務(wù)器的IaaS，本文的作者是Packet平臺的VP，作者在文中講述了他們構(gòu)建Packet平臺的動機以及在構(gòu)建過程中遇到了哪些問題。他們通過借鑒OpenStack已有的服務(wù)，如Neutron、Ironic，將OpenStack對于虛擬機集群的管理策略遷移到對物理機集群的管理上，同時作者還分享了在整個平臺構(gòu)建過程中的經(jīng)驗教訓(xùn)。

在去年夏天， Zac 找到了我，他當(dāng)時正在籌劃從頭開始構(gòu)建一個新式的、基于裸機服務(wù)器的云服務(wù)平臺。由于之前我所做的絕大部分的工作都是在構(gòu)建、支持維護或者使用可擴展性的基礎(chǔ)設(shè)施服務(wù)，在這個領(lǐng)域已經(jīng)有了一定經(jīng)驗。我開始的時候確實很好奇：我們到底是否需要一個這樣的服務(wù)？難道不是已經(jīng)有了許多現(xiàn)成的、優(yōu)秀的IaaS平臺了嗎？

隨著我們交談的不斷深入，我最終認(rèn)同了Zac的觀點，目前許多共有的云服務(wù)并非是用戶友好的，并且使用起來有過高的門檻。此外，由于我還是一個早期的Docker使用者，我可以感受到基于容器的服務(wù)部署即將給相關(guān)領(lǐng)域帶來的浪潮。容器技術(shù)以指數(shù)的方式提高服務(wù)器的質(zhì)量，這比使用DevOps 工具箱的效率更高。此外，針對特定底層設(shè)施進行虛擬化的公有云服務(wù)，以及針對遺留問題的主機提供商（legacy dedicated hosting providers），都無法靈活地滿足不同物理硬件的需求。所以我們認(rèn)為，在這個領(lǐng)域仍然有許多工作值得我們?nèi)プ?，我們?gòu)建Packet的旅程就此開始。

在任務(wù)開始之前……

在項目開發(fā)前期，我花了一些時間來調(diào)研已有的，提供自動化云服務(wù)和自動化部署功能的產(chǎn)品，我還查看了一些定制的安裝包（bespoke installers），幾乎所有的開源云平臺，以及我們需要重新構(gòu)建自己的服務(wù)時可能用到的工具。

在Voxel工作期間，我們曾經(jīng)開發(fā)過一個云主機平臺，這個平臺后來被 Internap所收購。我們當(dāng)時還構(gòu)建了自己的軟件堆棧，并且我們對于自己平臺的各種優(yōu)勢和使用平臺可能帶來的影響都掌握得一清二楚。我們天真的認(rèn)為，憑借我們之前的經(jīng)驗，安裝服務(wù)器集群的工作看起來應(yīng)該很容易。你以為自己曾經(jīng)做過一次，自己就是老手了嗎？錯！實時上，在安裝的過程中，我們遇到了無數(shù)網(wǎng)絡(luò)方面的問題，硬件方面不斷的變化也經(jīng)常困擾著我們，此外我們還需要解決由于操作系統(tǒng)的差異所導(dǎo)致的許多問題……不得不說，想要給客戶提供一個真正自動化的服務(wù)層，并非易事。按照Zac所提出的要求，我們要安裝、管理上千臺規(guī)模的物理服務(wù)器集群，同時還要對集群的安全提供保障，每次對集群進行配置，這些工作到要在5分鐘之內(nèi)完成，對于我來說，這并不簡單。

如何才能幫助Packet 滿足其目標(biāo)：在24/7 秒的時間內(nèi)執(zhí)行上千次的安裝服務(wù)，并且讓這些服務(wù)啟動，還要運行數(shù)月之久？經(jīng)過之前的調(diào)研，我們開始對OpenStack產(chǎn)生興趣。我們希望借鑒OpenStack在基礎(chǔ)設(shè)施管理方面的經(jīng)驗，并結(jié)合其已有的OpenStack組件，來構(gòu)建我們自己的服務(wù)，我們的服務(wù)可能包括：網(wǎng)絡(luò)自動化、IP管理、流程化安裝、硬件生命周期監(jiān)控、以及產(chǎn)品安裝等幾部分。如果我們可以依賴OpenStack已有的核心組件，我們的服務(wù)就不需要再從頭開始構(gòu)建，我的團隊就可以將更多的經(jīng)歷集中于可以給用戶帶來更多價值的工作上：比如增強平臺對底層硬件分析并且添加平臺對容器技術(shù)的支持等等。

我也曾經(jīng)被警告過，OpenStack中可能確實存在許多“陷阱”。但我還是花了幾周的時間來閱讀OpenStack***提交的代碼，我還在官方的IRC頻道中與其他開發(fā)者交流，并且還嘗試運行DevStack。無論是OpenStack已有的核心項目，還是在過去2年之內(nèi)突然成熟起來的新項目，我對它們都非常熟悉。此外，對于我們構(gòu)建Packet項目而言，似乎時機剛好：Rackspace最近推出了OneMetal服務(wù)，他們還通過博客公開了他們是如何在裸機云服務(wù)器上運行 Ironic服務(wù)的，此外，他們將要推出一個新的、重要的發(fā)行版：Juno ，這一系列舉措似乎與我們的想法不謀而合，這看起來正是我們開發(fā)Packet項目的黃金時間。所以我和我的團隊堅信，我們應(yīng)該借鑒OpenStack的已有服務(wù)來完成我們對裸機服務(wù)器的部署。

故事是這樣的……

我知道 OpenStack的學(xué)習(xí)曲線很陡峭，并且我需要掌握的是每一個項目的核心原理，并非僅僅是對項目進行簡單的安裝部署，于是我挨個地鉆研OpenStack的項目，對于某些特別的項目，我需要通過反復(fù)使用來對它們有更好的理解，比如：Nova、 Ironic 驅(qū)動，以及 Neutron。我們不僅僅想要借鑒Ironic在裸機上安裝提供的便利，我們還需要支持 Packet的主機級別的網(wǎng)絡(luò)模型，特別是要避免通過兩層網(wǎng)絡(luò)或者是VlAN的方式，我們要將三層的網(wǎng)絡(luò)模型直接構(gòu)建在每個主機上。

對于我上面所提到的經(jīng)歷，你的***反應(yīng)可能是：“喔！相對于需要學(xué)習(xí)的內(nèi)容而言，目前可以參考的文檔是在是少之又少!”然而經(jīng)過了一個多月的學(xué)習(xí)，我***的感受就是，我所閱讀的文檔之中，許多文檔都是過期的，有的文檔內(nèi)容甚至完全不準(zhǔn)確！這強迫我不斷地篩選質(zhì)量更好的文檔，文檔的來源從 wiki百科到IRC上的日志，再到開源項目中***提交的信息。我不斷地從中篩選出“真實可靠的信息”。 除了經(jīng)過初步的信息篩選，我還需要花費許多時間進行python debug，只是為了驗證不同文章中對于功能可用性的互相矛盾的表述。比如，“到底XXX功能有沒有作用？” 等等，整個過程進展得很慢。

值得注意的是，有許多開發(fā)者和公司有豐富的OpenStack使用經(jīng)驗。特別是針對Nova組件和標(biāo)準(zhǔn)的Neutron組件的實現(xiàn)方面。然而，幾乎很少人對于Ironic在生產(chǎn)環(huán)境中使用有實際經(jīng)驗。雖然與其他的開源項目相比，OpenStack的開發(fā)者社區(qū)規(guī)模很大，但是我在對OpenStack組件研究的過程中仍然會遇到一些問題，甚至是一些項目的核心的開發(fā)者都無法幫助我們解決，在Google上搜索相關(guān)的錯誤結(jié)果，所能找到的相關(guān)錯誤信息也很少。

#p#

Lesson 1：OpenStack是一個龐大的、年輕的、發(fā)展迅速的項目，如果之前沒有一定的知識儲備，文檔看起來可能會有很多“陷阱”。

我強迫自己對于Ironic的研究更深入一點，于是我把Neutron留給我的一個同事來研究（通過之前的教訓(xùn)得到的啟示）。事實上，對于OpenStack的每一個組件，我們都需要安排一個專門的開發(fā)人員來負(fù)責(zé)研究。開發(fā)人員不僅要理解該組件的核心代碼庫，同時還要能跟上整個項目的發(fā)展進度。此外開發(fā)人員還要靈活地將對應(yīng)組件進行調(diào)整并且運用到我們自己的項目的開發(fā)中。把Neutron的研究任務(wù)交給其他同事之后，我就可以更加專注于Ironic的研究工作，我花費了許多時間，通過IRC、郵件、并且在OpenStack開發(fā)者論壇上，同 Rackspace的OnMetal團隊成員進行了很多的交流。我還閱讀了許多相關(guān)的文檔，我確定自己在論壇中發(fā)的每個帖子，以及通過Google可以搜索到的，我通過debug得到的每個結(jié)果，都會幫助Ironic構(gòu)建其新的版本。

從Nova 的baremetal驅(qū)動逐步發(fā)展成為***的Ironic項目，這整個過程中，社區(qū)的工作功不可沒。雖然社區(qū)已經(jīng)做了許多工作，但是OpenStack在整體的設(shè)計上，仍然保持著以虛擬化為中心的理念。如果拿Nova的 baremetal驅(qū)動和Ironic相比，很多特性都發(fā)生了改變。其中一個變化就是Ironic對網(wǎng)絡(luò)方面的支持有限。通過Ironic 網(wǎng)絡(luò)會根據(jù)modular layer 2 （ML2）插件被分成 openvswitch以及l(fā)inuxbridge 兩種代理模式。而我們的網(wǎng)絡(luò)模型與這個分類有著很嚴(yán)重的沖突，我還發(fā)現(xiàn)，Neutron不僅缺乏對特定廠商的交換機的支持而且擴展到不同的網(wǎng)絡(luò)模型的能力也有限。

相關(guān)領(lǐng)域的大公司(比如Rackspace) 對Openstack的核心代碼有著更深刻的理解，它們可以將OpenStack中的大部分組件進行很高程度的定制化，以使得這些組件部署在物理服務(wù)器或者是真是的物理網(wǎng)絡(luò)環(huán)境中。雖然其中一些用于定制的補丁項目已經(jīng)開源，但是許多重要的補丁還沒有開源。 對于一些重要的補丁，可能還需要重新開始構(gòu)建，并且可能在新的OpenStack發(fā)行版本中對其進行維護。

Lesson2： OpenStack的項目全是基于虛擬機的，如果你的情況不是這樣，那么祝你好運！

在這一點上，我也認(rèn)真考慮了很多，怎么在我們的產(chǎn)品上改善OpenStack的安裝過程。 這個過程中，需要操作的資源數(shù)量很龐大，并且保持每個服務(wù)之間的同步也需要很大的工作量。我開始感覺到我們需要對與Nova和Ironic項目的定制化工作絕非是簡單的修修補補。巨大的工作量可能會抵消開源項目自身所特有的優(yōu)勢，同時也可能會減弱開發(fā)者的動力動力。

然而我任務(wù)全部理解Neutron中的細(xì)節(jié)是很重要的，在我的個人計劃中，這也是一個最關(guān)鍵部分。

在物理交換機和服務(wù)器的世界中，安裝服務(wù)并不是很非常的困難。這樣可以提供可靠的服務(wù)，但在另一方面，這個工作做起來也并不容器，你需要一系列的工具來幫助你完成自動化的操作。并且根據(jù)我的經(jīng)驗，對于大多數(shù)基礎(chǔ)設(shè)置的部署來說，最容易出錯的地方就是網(wǎng)絡(luò)方面的配置。你可以看到，就支持***的自動化操作和API交互而言，物理交換機操作系統(tǒng)還有很多地方需要被加強（Juniper的即將到來的 14.2 JUNOS加強了對REST API的支持）事實上，在使用其他的網(wǎng)絡(luò)自動化工具時，有許多令人沮喪的經(jīng)歷，這也是一個促使我調(diào)研OpenStack的一個主要原因。并且Neutron項目有一個很吸引人的標(biāo)題 ：“通過已實現(xiàn)服務(wù)及其綁定的函數(shù)庫，來提供給你即時的、可擴展的、以及技術(shù)不受限（technology-agnostic）的網(wǎng)絡(luò)抽象能力”當(dāng)時看到這個標(biāo)題，我就毫不猶豫加入進來。

然而，實時并非像他們所許諾的那樣。之前討論的大多數(shù)關(guān)于軟件自定義網(wǎng)絡(luò)的問題，它們大部分都需要在虛擬網(wǎng)絡(luò)的環(huán)境下才能解決。這需要將網(wǎng)絡(luò)建立在 hypervisor之上，而并非是使用真實的物理交換機。不僅僅是我們交換機的提供方（Juniper）對于Neutron的驅(qū)動已經(jīng)完全過時，當(dāng)我們使用***的OpenStack的Juno發(fā)行版本后，相關(guān)支持仍然只是很小一部分。此外 Neutron 僅實現(xiàn)了一個網(wǎng)絡(luò)間的、初級的 IP地址管理器（IPAM）。并且沒有考慮對于從外部接入進來的IP進行行分配、報告、或者對指定的IP地址提供權(quán)限許可。如果讓我們通過降低用戶體驗，來滿足Neutron所提供的有限的特性，這對我們來說是不可接受的。

Lesson3 ：Neutron對物理網(wǎng)絡(luò)的支持要具體情況具體分析，使用之前先要檢查你的交換機。

我們到底是怎么做的？

長話短說，我們在圣誕節(jié)之前我們又花了整整一周時間對OpenStack進行研究，之后我們用了接下來的三周時間來開發(fā)一個定制發(fā)布的自動化的平臺。在去年12月份的早些時候，再構(gòu)建了我們自己的IP Manager之后， 團隊被鼓勵在已經(jīng)定制好的工具的基礎(chǔ)上進行開發(fā)。我們是一個100%向前看的公司，并且我們感覺到，在探索和部署OpenStack的過程中，我們已經(jīng)把大多數(shù)的陷阱都填平了，我們構(gòu)建了一個靈活的服務(wù)提供級別的（service-provider grade）IPAM(我們稱它為***IP) ，一個用戶和權(quán)限模型（在我們自己的SWITCH OSS基礎(chǔ)上構(gòu)建），并且在我們的設(shè)備管理平臺和我們的物理基礎(chǔ)設(shè)施之間有很好的結(jié)合。

有些時候，存在的不一定就是足夠好，或者完全適合我們的需求。我們通過Packet項目對OpenStack進行改進，就是一個很好的例子。我們也期望在社區(qū)中發(fā)行我們自己的Neutron插件，并且緊隨OpenStack項目的發(fā)展，現(xiàn)在我們也在繼續(xù)前進。

我們會在最近完成對于CoreOS的安裝過程步驟（在Ubuntu、Debian 以及CentOS上的安裝已經(jīng)完成）。產(chǎn)品的簡潔、快速、的文件的系統(tǒng)可以允許我們支持許多更高級的功能并且提供更高程度的可用性，同時還不會使我們的用戶體驗打折扣，對于這一點我確實很興奮。請容我這樣概括整個開發(fā)過程：“收獲教訓(xùn)，完成任務(wù)（基本上完成）！”

原文鏈接：http://dockerone.com/article/153