人們對OpenStack是否認同?這一開源云技術又是否易于使用?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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