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

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

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

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

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

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

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

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

故事是這樣的……

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

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

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

云計(jì)算頻道導(dǎo)航熱點(diǎn)推薦

Android開(kāi)發(fā)應(yīng)用詳解

那些性感的讓人尖叫的程序員

高性能WEB開(kāi)發(fā)應(yīng)用指南

Ubuntu開(kāi)源技術(shù)交流頻道

Lesson 1：OpenStack是一個(gè)龐大的、年輕的、發(fā)展迅速的項(xiàng)目，如果之前沒(méi)有一定的知識(shí)儲(chǔ)備，文檔看起來(lái)可能會(huì)有很多“陷阱”。

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

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

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

Lesson2： OpenStack的項(xiàng)目全是基于虛擬機(jī)的，如果你的情況不是這樣，那么祝你好運(yùn)！

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

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

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

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

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

我們到底是怎么做的？

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

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

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