【51CTO.com快譯】人們對OpenStack是否認同?這一開源云技術又是否易于使用?

[[154619]]

在我們回答上述問題之前，首先不妨看看人們對于OpenStack API的種種爭議。在Praveen Yalagandula本月在OpenStack東京峰會上發(fā)表的主題演講當中，Praveen介紹了Avi Networks公司如何向其客戶提供OpenStack解決方案并引導其從實踐者的角度出發(fā)看待問題。感興趣的朋友不妨點擊此處(英文原文)查看這篇題為《OpenStack API中好的、壞的與丑的：一位應用程序開發(fā)者的觀點》發(fā)言材料，其中包含大量與OpenStack采納以及企業(yè)實踐方面的透徹見解。而接下來，我們將以訪談的形式就其主旨進行探索。

請您介紹一下自己的職能角色以及在OpenStack技術方面的實踐經(jīng)驗。

作為Avi Networks公司工程技術團隊的成員之一，我的一大職能定位在于設計并開發(fā)出對應解決方案，從而將Avi公司的下一代ADC同OpenStack組件加以結合。我們的架構基于SDN原則：以邏輯形式進行集中的Avi Controller能夠快速且高效地對數(shù)據(jù)平面工作單元進行編排，我們將其稱為服務引擎。

OpenStack的固有核心API在與計算及網(wǎng)絡資源配置方案(例如Nova以及Neutron)相對接后能夠為我們帶來非常理想的彈性成效：當工作負載處于高強度水平時，Avi Controller能夠輕松創(chuàng)建出更多數(shù)據(jù)平面虛擬機，并將它們接入對應的網(wǎng)絡當中; 而在負載趨于緩和后，Avi Controller又能夠以規(guī)模伸縮的形式降低資源消耗。OpenStack API的另一大優(yōu)勢在于能夠支持多租戶機制，而這就使我們得以輕松在產(chǎn)品內(nèi)部將不同租戶彼此隔離開來——每位租戶都擁有自己的一套或者多套服務引擎集，而管理員們則允許用戶根據(jù)實際需求對負載均衡機制加以配置。這種效果在基于硬件的負載均衡解決方案當中根本無法實現(xiàn)。

但在另一方面，我們在利用OpenStack技術保障解決方案具備高可用性與高性能表現(xiàn)時則遇到了難題。舉例來說，由于OpenStack服務缺乏通過API實現(xiàn)的良好通知支持能力，因此我們不得不采取定期檢查的方式。與此同時，OpenStack還不具備能夠?qū)μ摂M機管理程序之上網(wǎng)絡堆棧內(nèi)的某些檢查進行關閉的API，這就意味著單純利用參考實現(xiàn)手段很難切實帶來高水平的性能表現(xiàn)。不過隨著OpenStack項目自身的日趨成熟，大多數(shù)上述問題已經(jīng)得到了很好的解決。

您認為OpenStack是否已經(jīng)做好了入駐企業(yè)業(yè)務環(huán)境的準備?您是否能同我們分享目前有哪些企業(yè)已經(jīng)選擇了OpenStack，他們的典型用例又是什么?為什么在擁有眾多易用性拔群的公有云服務的前提之下，仍有一些企業(yè)傾向于優(yōu)先選擇OpenStack呢?

可以說OpenStack距離全面入駐企業(yè)業(yè)務環(huán)境的目標已經(jīng)不遠了，但確實還差那么一點。我們當初開始嘗試OpenStack整合工作是在大約一年半之前，不過很多企業(yè)當時已經(jīng)開始對其進行審視與實驗了，而真正能夠在OpenStack項目中取得成功的是那些切實完成了工程技術團隊向DevOps方向轉型的企業(yè)。除此之外，像我們這樣的企業(yè)需要耗費大量時間對OpenStack部署工作進行調(diào)試，而后才能將Avi Networks解決方案添加到其環(huán)境當中。不過由于OpenStack已經(jīng)擁有相當成熟的穩(wěn)定性，因此我們現(xiàn)在已經(jīng)看到其愈發(fā)廣泛的普及度以及更為穩(wěn)定的運行狀態(tài)，這意味著如今我們可以在一個小時之內(nèi)從零開始啟動一套企業(yè)級LBaaS方案。

這類部署方案所承載的應用程序可謂無處不在——從內(nèi)部IT應用程序到面向公共的網(wǎng)站皆在其中。在這類部署場景當中，最為關鍵的驅(qū)動性因素在于以自助服務方式對整套堆棧進行自動化配置。大多數(shù)企業(yè)希望能夠在內(nèi)部私有云體系中實現(xiàn)與Amazon AWS相對等的彈性水平以及運維簡便性。對于安全以及監(jiān)管的考量正是眾多企業(yè)客戶傾向于選擇OpenStack私有云方案而非公有云服務的主要理由。另一大重要原因在于，企業(yè)客戶在將應用程序向OpenStack進行遷移時，其幾乎不需要對這些遺留應用做出太多變更及調(diào)整，因為他們能夠直接根據(jù)實際情況對OpenStack安裝環(huán)境進行配置——相比之下，面向公有云的遷移則往往會給應用本身造成巨大影響并帶來可觀的調(diào)整工作量。舉例來說，企業(yè)可以利用VLAN作為底層網(wǎng)絡，并以此為基礎在與OpenStack環(huán)境之外的現(xiàn)有DB服務器進行對接的同時，利用OpenStack虛擬機作為應用邏輯。

那么我們再從另一個角度審視這個問題，為什么相當一部分企業(yè)沒有選擇OpenStack?您是否見到過反例或者OpenStack故障?如果OpenStack不足以解決問題，是否還有其它開源工具能夠作為補充?

雖然虛擬化技術能夠在不同操作系統(tǒng)要求之下為不同應用程序提供非常出色的資源復用效果，但必須承認虛擬化本身也會帶來相當可觀的負載強度。最近剛剛興起的一大發(fā)展趨勢正是基于容器的生態(tài)系統(tǒng)，其最為顯著的賣點就是將虛擬化技術的常規(guī)資源開銷控制在極低水平。根據(jù)我的理解，這套環(huán)境對于基于Linux分發(fā)的應用程序來說非常理想，不過尚不能真正服務于OpenStack這類更為復雜的多租戶環(huán)境(特別是在租戶彼此隔離的條件下)。

OpenStack方案的配置工作頗具難度。那么一家企業(yè)該如何正確評估其OpenStack要求，并衡量OpenStack部署所帶來的投資回報水平?

我認同這一點，OpenStack環(huán)境的配置過程確實不太容易，特別是在大家以開源組件作為起步的情況之下。大家可以建立自己的Chef/Puppet工具鏈，但這也會帶來更為高昂的成本支出。大家可以利用第三方免費工具，但它們或多或少都會在我們所能夠選擇的OpenStack版本或者提供的支持能力方面有所局限。企業(yè)需要建立一支專門且擁有大量資源配額的團隊，他們必須同時了解內(nèi)部應用程序要求以及建立OpenStack云體系的復雜因素。我個人的建議是，大家首先構建一套站點/區(qū)域藍圖，而后通過多次復制來將其擴展至所需要的規(guī)模水平。

說到OpenStack API當中好的、壞的與丑的方面，您認為企業(yè)應該采取怎樣的正確方式來解決相關痛點以及API缺失問題?企業(yè)是否應該嘗試自行修復問題，還是應當盡量同社區(qū)配合從而在新的官方版本當中得到解決方案?

在理想情況下，***的答案肯定是同技術社區(qū)開展合作來修復問題，并將其納入官方版本當中。從我的親身經(jīng)歷出發(fā)，我們曾經(jīng)修復過一些bug并提出了能夠提升API質(zhì)量的多面變更建議。不過考慮到我們所構建的應用程序類型——一項高性能網(wǎng)絡服務——我們在API當中所遇到的問題其實非常罕見，因為API中的此類功能在其它應用中幾乎不會被用到。因此技術社區(qū)當然提不起興趣來解決這些不起眼的問題。在這種狀況下，我們的解決思路是親自動手，找到辦法克服這些難關。

那您認為OpenStack技術在說明文檔、技術社區(qū)支持以及客戶變更請求方面是否達到了“企業(yè)友善”這一標準?我們在這方面還能做出哪些努力?

我可以拍著胸脯向你保證，OpenStack提供的面向開發(fā)人員的說明文檔非常差勁。舉例來說，我們很難從中找到不同服務所能夠支持的全部API語義——這也直接導致不同類型的插件隨心所欲地根據(jù)開發(fā)者的具體理解選擇API實現(xiàn)方向，因為API使用指南當中根本就沒有給出充分的說明信息。也許我們可以開發(fā)出一套基準測試套件，在其中納入完整的API選項清單，并確保所有插件都必須在聲明其OpenStack API使用方式后才能在該基準套件的引導下正常運行。事實上，OpenStack基金會完全可以在這方面加大投入(否則很多工程技術人員根本不知道該如何為項目做出貢獻)，同時以認證方式向各廠商收取費用。

關于OpenStack

OpenStack是一個由NASA(美國國家航空航天局)和Rackspace合作研發(fā)并發(fā)起的，是一個開源的云計算管理平臺項目，由幾個主要的組件組合起來完成具體工作。OpenStack支持幾乎所有類型的云環(huán)境，項目目標是提供實施簡單、可大規(guī)模擴展、豐富、標準統(tǒng)一的云計算管理平臺。

OpenStack除了有Rackspace和NASA的大力支持外，還有包括戴爾、Citrix、Cisco、Canonical等重量級公司的貢獻和支持，致力于簡化云的部署過程并為其帶來良好的可擴展性。

原文標題：OpenStack APIs: The good, the bad, and the ugly

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】