使用OpenStack建構Packet平台過程中的經驗和教訓

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

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

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

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

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

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

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

相關領域的大公司(比如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對實體網絡的支援要具體情況具體分析，使用之前先要檢查你的交換機。

有些時候，存在的不一定就是足夠好，或者完全适合我們的需求。我們通過Packet項目對OpenStack進行改進，就是一個很好的例子。我們也期望在社群中發行我們自己的Neutron插件，并且緊随OpenStack項目的發展，現在我們也在繼續前進。

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

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

譯者介紹

原文釋出時間為：2015-01-22

本文作者：hessen

本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。

原文标題：使用OpenStack建構Packet平台過程中的經驗和教訓