使用OpenStack構建Packet平臺的經驗總結

【編者的話】Packet是一家成立不久的公司，他們主要是為使用者提供基於裸機伺服器的IaaS，本文的作者是Packet平臺的VP，作者在文中講述了他們構建Packet平臺的動機以及在構建過程中遇到了哪些問題。他們通過借鑑OpenStack已有的服務，如Neutron、Ironic，將OpenStack對於虛擬機器叢集的管理策略遷移到對物理機叢集的管理上，同時作者還分享了在整個平臺構建過程中的經驗教訓。

在去年夏天， Zac 找到了我，他當時正在籌劃從頭開始構建一個新式的、基於裸機伺服器的雲服務平臺。由於之前我所做的絕大部分的工作都是在構建、支援維護或者使用可擴充套件性的基礎設施服務，在這個領域已經有了一定經驗。我開始的時候確實很好奇：我們到底是否需要一個這樣的服務？難道不是已經有了許多現成的、優秀的IaaS平臺了嗎？

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

在任務開始之前……

在專案開發前期，我花了一些時間來調研已有的，提供自動化雲服務和自動化部署功能的產品，我還檢視了一些定製的安裝包（bespoke installers），幾乎所有的開源雲平臺，以及我們需要重新構建自己的服務時可能用到的工具。

在Voxel工作期間，我們曾經開發過一個雲主機平臺，這個平臺後來被 Internap所收購。我們當時還構建了自己的軟體堆疊，並且我們對於自己平臺的各種優勢和使用平臺可能帶來的影響都掌握得一清二楚。我們天真的認為，憑藉我們之前的經驗，安裝伺服器叢集的工作看起來應該很容易。你以為自己曾經做過一次，自己就是老手了嗎？錯！實時上，在安裝的過程中，我們遇到了無數網路方面的問題，硬體方面不斷的變化也經常困擾著我們，此外我們還需要解決由於作業系統的差異所導致的許多問題……不得不說，想要給客戶提供一個真正自動化的服務層，並非易事。按照Zac所提出的要求，我們要安裝、管理上千臺規模的物理伺服器叢集，同時還要對叢集的安全提供保障，每次對叢集進行配置，這些工作到要在5分鐘之內完成，對於我來說，這並不簡單。

如何才能幫助Packet 滿足其目標：在24/7 秒的時間內執行上千次的安裝服務，並且讓這些服務啟動，還要執行數月之久？經過之前的調研，我們開始對OpenStack產生興趣。我們希望借鑑OpenStack在基礎設施管理方面的經驗，並結合其已有的OpenStack元件，來構建我們自己的服務，我們的服務可能包括：網路自動化、IP管理、流程化安裝、硬體生命週期監控、以及產品安裝等幾部分。如果我們可以依賴OpenStack已有的核心元件，我們的服務就不需要再從頭開始構建，我的團隊就可以將更多的經歷集中於可以給使用者帶來更多價值的工作上：比如增強平臺對底層硬體分析並且新增平臺對容器技術的支援等等。

我也曾經被警告過，OpenStack中可能確實存在許多“陷阱”。但我還是花了幾周的時間來閱讀OpenStack最新提交的程式碼，我還在官方的IRC頻道中與其他開發者交流，並且還嘗試執行DevStack。無論是OpenStack已有的核心專案，還是在過去2年之內突然成熟起來的新專案，我對它們都非常熟悉。此外，對於我們構建Packet專案而言，似乎時機剛好：Rackspace最近推出了OneMetal服務，他們還通過部落格公開了他們是如何在裸機雲伺服器上執行 Ironic服務的，此外，他們將要推出一個新的、重要的發行版：Juno ，這一系列舉措似乎與我們的想法不謀而合，這看起來正是我們開發Packet專案的黃金時間。所以我和我的團隊堅信，我們應該借鑑OpenStack的已有服務來完成我們對裸機伺服器的部署。

故事是這樣的……

我知道 OpenStack的學習曲線很陡峭，並且我需要掌握的是每一個專案的核心原理，並非僅僅是對專案進行簡單的安裝部署，於是我挨個地鑽研OpenStack的專案，對於某些特別的專案，我需要通過反覆使用來對它們有更好的理解，比如：Nova、 Ironic 驅動，以及 Neutron。我們不僅僅想要借鑑Ironic在裸機上安裝提供的便利，我們還需要支援 Packet的主機級別的網路模型，特別是要避免通過兩層網路或者是VlAN的方式，我們要將三層的網路模型直接構建在每個主機上。

對於我上面所提到的經歷，你的第一反應可能是：“喔！相對於需要學習的內容而言，目前可以參考的文件是在是少之又少!”然而經過了一個多月的學習，我最大的感受就是，我所閱讀的文件之中，許多文件都是過期的，有的文件內容甚至完全不準確！這強迫我不斷地篩選質量更好的文件，文件的來源從 wiki百科到IRC上的日誌，再到開源專案中最新提交的資訊。我不斷地從中篩選出“真實可靠的資訊”。 除了經過初步的資訊篩選，我還需要花費許多時間進行python debug，只是為了驗證不同文章中對於功能可用性的互相矛盾的表述。比如，“到底XXX功能有沒有作用？” 等等，整個過程進展得很慢。

值得注意的是，有許多開發者和公司有豐富的OpenStack使用經驗。特別是針對Nova元件和標準的Neutron元件的實現方面。然而，幾乎很少人對於Ironic在生產環境中使用有實際經驗。雖然與其他的開源專案相比，OpenStack的開發者社群規模很大，但是我在對OpenStack元件研究的過程中仍然會遇到一些問題，甚至是一些專案的核心的開發者都無法幫助我們解決，在Google上搜尋相關的錯誤結果，所能找到的相關錯誤資訊也很少。

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

我強迫自己對於Ironic的研究更深入一點，於是我把Neutron留給我的一個同事來研究（通過之前的教訓得到的啟示）。事實上，對於OpenStack的每一個元件，我們都需要安排一個專門的開發人員來負責研究。開發人員不僅要理解該元件的核心程式碼庫，同時還要能跟上整個專案的發展進度。此外開發人員還要靈活地將對應元件進行調整並且運用到我們自己的專案的開發中。把Neutron的研究任務交給其他同事之後，我就可以更加專注於Ironic的研究工作，我花費了許多時間，通過IRC、郵件、並且在OpenStack開發者論壇上，同 Rackspace的OnMetal團隊成員進行了很多的交流。我還閱讀了許多相關的文件，我確定自己在論壇中發的每個帖子，以及通過Google可以搜尋到的，我通過debug得到的每個結果，都會幫助Ironic構建其新的版本。

從Nova 的baremetal驅動逐步發展成為一流的Ironic專案，這整個過程中，社群的工作功不可沒。雖然社群已經做了許多工作，但是OpenStack在整體的設計上，仍然保持著以虛擬化為中心的理念。如果拿Nova的 baremetal驅動和Ironic相比，很多特性都發生了改變。其中一個變化就是Ironic對網路方面的支援有限。通過Ironic 網路會根據modular layer 2 （ML2）外掛被分成 openvswitch以及linuxbridge 兩種代理模式。而我們的網路模型與這個分類有著很嚴重的衝突，我還發現，Neutron不僅缺乏對特定廠商的交換機的支援而且擴充套件到不同的網路模型的能力也有限。

相關領域的大公司(比如Rackspace) 對Openstack的核心程式碼有著更深刻的理解，它們可以將OpenStack中的大部分元件進行很高程度的定製化，以使得這些元件部署在物理伺服器或者是真是的物理網路環境中。雖然其中一些用於定製的補丁專案已經開源，但是許多重要的補丁還沒有開源。 對於一些重要的補丁，可能還需要重新開始構建，並且可能在新的OpenStack發行版本中對其進行維護。

Lesson2： OpenStack的專案全是基於虛擬機器的，如果你的情況不是這樣，那麼祝你好運！

在這一點上，我也認真考慮了很多，怎麼在我們的產品上改善OpenStack的安裝過程。 這個過程中，需要操作的資源數量很龐大，並且保持每個服務之間的同步也需要很大的工作量。我開始感覺到我們需要對與Nova和Ironic專案的定製化工作絕非是簡單的修修補補。巨大的工作量可能會抵消開源專案自身所特有的優勢，同時也可能會減弱開發者的動力動力。

然而我任務全部理解Neutron中的細節是很重要的，在我的個人計劃中，這也是一個最關鍵部分。

在物理交換機和伺服器的世界中，安裝服務並不是很非常的困難。這樣可以提供可靠的服務，但在另一方面，這個工作做起來也並不容器，你需要一系列的工具來幫助你完成自動化的操作。並且根據我的經驗，對於大多數基礎設定的部署來說，最容易出錯的地方就是網路方面的配置。你可以看到，就支援最新的自動化操作和API互動而言，物理交換機作業系統還有很多地方需要被加強（Juniper的即將到來的 14.2 JUNOS加強了對REST API的支援）事實上，在使用其他的網路自動化工具時，有許多令人沮喪的經歷，這也是一個促使我調研OpenStack的一個主要原因。並且Neutron專案有一個很吸引人的標題 ：“通過已實現服務及其繫結的函式庫，來提供給你即時的、可擴充套件的、以及技術不受限（technology-agnostic）的網路抽象能力”當時看到這個標題，我就毫不猶豫加入進來。

然而，實時並非像他們所許諾的那樣。之前討論的大多數關於軟體自定義網路的問題，它們大部分都需要在虛擬網路的環境下才能解決。這需要將網路建立在 hypervisor之上，而並非是使用真實的物理交換機。不僅僅是我們交換機的提供方（Juniper）對於Neutron的驅動已經完全過時，當我們使用最新的OpenStack的Juno發行版本後，相關支援仍然只是很小一部分。此外 Neutron 僅實現了一個網路間的、初級的 IP地址管理器（IPAM）。並且沒有考慮對於從外部接入進來的IP進行行分配、報告、或者對指定的IP地址提供許可權許可。如果讓我們通過降低使用者體驗，來滿足Neutron所提供的有限的特性，這對我們來說是不可接受的。

Lesson3 ：Neutron對物理網路的支援要具體情況具體分析，使用之前先要檢查你的交換機。

我們到底是怎麼做的？

長話短說，我們在聖誕節之前我們又花了整整一週時間對OpenStack進行研究，之後我們用了接下來的三週時間來開發一個定製釋出的自動化的平臺。在去年12月份的早些時候，再構建了我們自己的IP Manager之後， 團隊被鼓勵在已經定製好的工具的基礎上進行開發。我們是一個100%向前看的公司，並且我們感覺到，在探索和部署OpenStack的過程中，我們已經把大多數的陷阱都填平了，我們構建了一個靈活的服務提供級別的（service-provider grade）IPAM(我們稱它為萬能IP) ，一個使用者和許可權模型（在我們自己的SWITCH OSS基礎上構建），並且在我們的裝置管理平臺和我們的物理基礎設施之間有很好的結合。

有些時候，存在的不一定就是足夠好，或者完全適合我們的需求。我們通過Packet專案對OpenStack進行改進，就是一個很好的例子。我們也期望在社群中發行我們自己的Neutron外掛，並且緊隨OpenStack專案的發展，現在我們也在繼續前進。

我們會在最近完成對於CoreOS的安裝過程步驟（在Ubuntu、Debian 以及CentOS上的安裝已經完成）。產品的簡潔、快速、的檔案的系統可以允許我們支援許多更高階的功能並且提供更高程度的可用性，同時還不會使我們的使用者體驗打折扣，對於這一點我確實很興奮。請容我這樣概括整個開發過程：“收穫教訓，完成任務（基本上完成）！”