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

[[154619]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

關(guān)于OpenStack

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

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

原文標(biāo)題：OpenStack APIs: The good, the bad, and the ugly

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