人們對(duì)OpenStack是否認(rèn)同?這一開(kāi)源云技術(shù)又是否易于使用?
在我們回答上述問(wèn)題之前，首先不妨看看人們對(duì)于OpenStack API的種種爭(zhēng)議。在Praveen Yalagandula本月在OpenStack東京峰會(huì)上發(fā)表的主題演講當(dāng)中，Praveen介紹了Avi Networks公司如何向其客戶提供OpenStack解決方案并引導(dǎo)其從實(shí)踐者的角度出發(fā)看待問(wèn)題。感興趣的朋友不妨點(diǎn)擊此處(英文原文)查看這篇題為《OpenStack API中好的、壞的與丑的：一位應(yīng)用程序開(kāi)發(fā)者的觀點(diǎn)》發(fā)言材料，其中包含大量與OpenStack采納以及企業(yè)實(shí)踐方面的透徹見(jiàn)解。而接下來(lái)，我們將以訪談的形式就其主旨進(jìn)行探索。
請(qǐng)您介紹一下自己的職能角色以及在OpenStack技術(shù)方面的實(shí)踐經(jīng)驗(yàn)。
作為Avi Networks公司工程技術(shù)團(tuán)隊(duì)的成員之一，我的一大職能定位在于設(shè)計(jì)并開(kāi)發(fā)出對(duì)應(yīng)解決方案，從而將Avi公司的下一代ADC同OpenStack組件加以結(jié)合。我們的架構(gòu)基于SDN原則：以邏輯形式進(jìn)行集中的Avi Controller能夠快速且高效地對(duì)數(shù)據(jù)平面工作單元進(jìn)行編排，我們將其稱為服務(wù)引擎。
OpenStack的固有核心API在與計(jì)算及網(wǎng)絡(luò)資源配置方案(例如Nova以及Neutron)相對(duì)接后能夠?yàn)槲覀儙?lái)非常理想的彈性成效：當(dāng)工作負(fù)載處于高強(qiáng)度水平時(shí)，Avi Controller能夠輕松創(chuàng)建出更多數(shù)據(jù)平面虛擬機(jī)，并將它們接入對(duì)應(yīng)的網(wǎng)絡(luò)當(dāng)中; 而在負(fù)載趨于緩和后，Avi Controller又能夠以規(guī)模伸縮的形式降低資源消耗。OpenStack API的另一大優(yōu)勢(shì)在于能夠支持多租戶機(jī)制，而這就使我們得以輕松在產(chǎn)品內(nèi)部將不同租戶彼此隔離開(kāi)來(lái)——每位租戶都擁有自己的一套或者多套服務(wù)引擎集，而管理員們則允許用戶根據(jù)實(shí)際需求對(duì)負(fù)載均衡機(jī)制加以配置。這種效果在基于硬件的負(fù)載均衡解決方案當(dāng)中根本無(wú)法實(shí)現(xiàn)。
但在另一方面，我們?cè)诶肙penStack技術(shù)保障解決方案具備高可用性與高性能表現(xiàn)時(shí)則遇到了難題。舉例來(lái)說(shuō)，由于OpenStack服務(wù)缺乏通過(guò)API實(shí)現(xiàn)的良好通知支持能力，因此我們不得不采取定期檢查的方式。與此同時(shí)，OpenStack還不具備能夠?qū)μ摂M機(jī)管理程序之上網(wǎng)絡(luò)堆棧內(nèi)的某些檢查進(jìn)行關(guān)閉的API，這就意味著單純利用參考實(shí)現(xiàn)手段很難切實(shí)帶來(lái)高水平的性能表現(xiàn)。不過(guò)隨著OpenStack項(xiàng)目自身的日趨成熟，大多數(shù)上述問(wèn)題已經(jīng)得到了很好的解決。
您認(rèn)為OpenStack是否已經(jīng)做好了入駐企業(yè)業(yè)務(wù)環(huán)境的準(zhǔn)備?您是否能同我們分享目前有哪些企業(yè)已經(jīng)選擇了OpenStack，他們的典型用例又是什么?為什么在擁有眾多易用性拔群的公有云服務(wù)的前提之下，仍有一些企業(yè)傾向于優(yōu)先選擇OpenStack呢?
可以說(shuō)OpenStack距離全面入駐企業(yè)業(yè)務(wù)環(huán)境的目標(biāo)已經(jīng)不遠(yuǎn)了，但確實(shí)還差那么一點(diǎn)。我們當(dāng)初開(kāi)始嘗試OpenStack整合工作是在大約一年半之前，不過(guò)很多企業(yè)當(dāng)時(shí)已經(jīng)開(kāi)始對(duì)其進(jìn)行審視與實(shí)驗(yàn)了，而真正能夠在OpenStack項(xiàng)目中取得成功的是那些切實(shí)完成了工程技術(shù)團(tuán)隊(duì)向DevOps方向轉(zhuǎn)型的企業(yè)。除此之外，像我們這樣的企業(yè)需要耗費(fèi)大量時(shí)間對(duì)OpenStack部署工作進(jìn)行調(diào)試，而后才能將Avi Networks解決方案添加到其環(huán)境當(dāng)中。不過(guò)由于OpenStack已經(jīng)擁有相當(dāng)成熟的穩(wěn)定性，因此我們現(xiàn)在已經(jīng)看到其愈發(fā)廣泛的普及度以及更為穩(wěn)定的運(yùn)行狀態(tài)，這意味著如今我們可以在一個(gè)小時(shí)之內(nèi)從零開(kāi)始啟動(dòng)一套企業(yè)級(jí)LBaaS方案。
這類部署方案所承載的應(yīng)用程序可謂無(wú)處不在——從內(nèi)部IT應(yīng)用程序到面向公共的網(wǎng)站皆在其中。在這類部署場(chǎng)景當(dāng)中，最為關(guān)鍵的驅(qū)動(dòng)性因素在于以自助服務(wù)方式對(duì)整套堆棧進(jìn)行自動(dòng)化配置。大多數(shù)企業(yè)希望能夠在內(nèi)部私有云體系中實(shí)現(xiàn)與Amazon AWS相對(duì)等的彈性水平以及運(yùn)維簡(jiǎn)便性。對(duì)于安全以及監(jiān)管的考量正是眾多企業(yè)客戶傾向于選擇OpenStack私有云方案而非公有云服務(wù)的主要理由。另一大重要原因在于，企業(yè)客戶在將應(yīng)用程序向OpenStack進(jìn)行遷移時(shí)，其幾乎不需要對(duì)這些遺留應(yīng)用做出太多變更及調(diào)整，因?yàn)樗麄兡軌蛑苯痈鶕?jù)實(shí)際情況對(duì)OpenStack安裝環(huán)境進(jìn)行配置——相比之下，面向公有云的遷移則往往會(huì)給應(yīng)用本身造成巨大影響并帶來(lái)可觀的調(diào)整工作量。舉例來(lái)說(shuō)，企業(yè)可以利用VLAN作為底層網(wǎng)絡(luò)，并以此為基礎(chǔ)在與OpenStack環(huán)境之外的現(xiàn)有DB服務(wù)器進(jìn)行對(duì)接的同時(shí)，利用OpenStack虛擬機(jī)作為應(yīng)用邏輯。
那么我們?cè)購(gòu)牧硪粋€(gè)角度審視這個(gè)問(wèn)題，為什么相當(dāng)一部分企業(yè)沒(méi)有選擇OpenStack?您是否見(jiàn)到過(guò)反例或者OpenStack故障?如果OpenStack不足以解決問(wèn)題，是否還有其它開(kāi)源工具能夠作為補(bǔ)充?
雖然虛擬化技術(shù)能夠在不同操作系統(tǒng)要求之下為不同應(yīng)用程序提供非常出色的資源復(fù)用效果，但必須承認(rèn)虛擬化本身也會(huì)帶來(lái)相當(dāng)可觀的負(fù)載強(qiáng)度。最近剛剛興起的一大發(fā)展趨勢(shì)正是基于容器的生態(tài)系統(tǒng)，其最為顯著的賣(mài)點(diǎn)就是將虛擬化技術(shù)的常規(guī)資源開(kāi)銷控制在極低水平。根據(jù)我的理解，這套環(huán)境對(duì)于基于Linux分發(fā)的應(yīng)用程序來(lái)說(shuō)非常理想，不過(guò)尚不能真正服務(wù)于OpenStack這類更為復(fù)雜的多租戶環(huán)境(特別是在租戶彼此隔離的條件下)。
OpenStack方案的配置工作頗具難度。那么一家企業(yè)該如何正確評(píng)估其OpenStack要求，并衡量OpenStack部署所帶來(lái)的投資回報(bào)水平?
我認(rèn)同這一點(diǎn)，OpenStack環(huán)境的配置過(guò)程確實(shí)不太容易，特別是在大家以開(kāi)源組件作為起步的情況之下。大家可以建立自己的Chef/Puppet工具鏈，但這也會(huì)帶來(lái)更為高昂的成本支出。大家可以利用第三方免費(fèi)工具，但它們或多或少都會(huì)在我們所能夠選擇的OpenStack版本或者提供的支持能力方面有所局限。企業(yè)需要建立一支專門(mén)且擁有大量資源配額的團(tuán)隊(duì)，他們必須同時(shí)了解內(nèi)部應(yīng)用程序要求以及建立OpenStack云體系的復(fù)雜因素。我個(gè)人的建議是，大家首先構(gòu)建一套站點(diǎn)/區(qū)域藍(lán)圖，而后通過(guò)多次復(fù)制來(lái)將其擴(kuò)展至所需要的規(guī)模水平。
說(shuō)到OpenStack API當(dāng)中好的、壞的與丑的方面，您認(rèn)為企業(yè)應(yīng)該采取怎樣的正確方式來(lái)解決相關(guān)痛點(diǎn)以及API缺失問(wèn)題?企業(yè)是否應(yīng)該嘗試自行修復(fù)問(wèn)題，還是應(yīng)當(dāng)盡量同社區(qū)配合從而在新的官方版本當(dāng)中得到解決方案?
在理想情況下，最好的答案肯定是同技術(shù)社區(qū)開(kāi)展合作來(lái)修復(fù)問(wèn)題，并將其納入官方版本當(dāng)中。從我的親身經(jīng)歷出發(fā)，我們?cè)?jīng)修復(fù)過(guò)一些bug并提出了能夠提升API質(zhì)量的多面變更建議。不過(guò)考慮到我們所構(gòu)建的應(yīng)用程序類型——一項(xiàng)高性能網(wǎng)絡(luò)服務(wù)——我們?cè)贏PI當(dāng)中所遇到的問(wèn)題其實(shí)非常罕見(jiàn)，因?yàn)锳PI中的此類功能在其它應(yīng)用中幾乎不會(huì)被用到。因此技術(shù)社區(qū)當(dāng)然提不起興趣來(lái)解決這些不起眼的問(wèn)題。在這種狀況下，我們的解決思路是親自動(dòng)手，找到辦法克服這些難關(guān)。
那您認(rèn)為OpenStack技術(shù)在說(shuō)明文檔、技術(shù)社區(qū)支持以及客戶變更請(qǐng)求方面是否達(dá)到了“企業(yè)友善”這一標(biāo)準(zhǔn)?我們?cè)谶@方面還能做出哪些努力?
我可以拍著胸脯向你保證，OpenStack提供的面向開(kāi)發(fā)人員的說(shuō)明文檔非常差勁。舉例來(lái)說(shuō)，我們很難從中找到不同服務(wù)所能夠支持的全部API語(yǔ)義——這也直接導(dǎo)致不同類型的插件隨心所欲地根據(jù)開(kāi)發(fā)者的具體理解選擇API實(shí)現(xiàn)方向，因?yàn)锳PI使用指南當(dāng)中根本就沒(méi)有給出充分的說(shuō)明信息。也許我們可以開(kāi)發(fā)出一套基準(zhǔn)測(cè)試套件，在其中納入完整的API選項(xiàng)清單，并確保所有插件都必須在聲明其OpenStack API使用方式后才能在該基準(zhǔn)套件的引導(dǎo)下正常運(yùn)行。事實(shí)上，OpenStack基金會(huì)完全可以在這方面加大投入(否則很多工程技術(shù)人員根本不知道該如何為項(xiàng)目做出貢獻(xiàn))，同時(shí)以認(rèn)證方式向各廠商收取費(fèi)用。
京公網(wǎng)安備 11010502049343號(hào)