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上搜索相關的錯誤結果，所能找到的相關錯誤信息也很少。
云計算頻道導航熱點推薦
Android開發應用詳解
那些性感的讓人尖叫的程序員
高性能WEB開發應用指南
Ubuntu開源技術交流頻道
[page]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上的安裝已經完成）。產品的簡潔、快速、的文件的系統可以允許我們支持許多更高級的功能并且提供更高程度的可用性，同時還不會使我們的用戶體驗打折扣，對于這一點我確實很興奮。請容我這樣概括整個開發過程：“收獲教訓，完成任務（基本上完成）！”
京公網安備 11010502049343號