OpenStack用戶是否須要升級版本？

一、OpenStack升級問題

OpenStack正逐漸被接受爲企業級框架，用於自動化數據中心基礎設施，並使企業可以運營各類各樣的應用程序和服務。

2010年，該平臺做爲託管服務提供商Rackspace和NASA的聯合項目出如今市場上。目前，它已經發展成爲迄今爲止最大的開放源碼項目之一，其版本發佈由OpenStack社區一年兩次的會議推進，每次會議通常會公佈下一個版本的優先事項。

市場研究代表，愈來愈多的企業OpenStack部署正在從試點項目（測試和開發平臺）轉向全面的生產狀態，但還有一些待解決的問題——其中最主要的是確保在升級到最新版本時能平滑更新構成OpenStack的無數組件。OpenStack早期版本的升級老是有問題的，部分緣由是那時候大部分開發工做側重於保證其做爲IaaS平臺充分運行所需的功能。

早期採用者常常發現本身面臨着難以置信的選擇——要麼在安裝新代碼的同時將OpenStack基礎設施脫機，要麼簡單地將工做負載遷移到基於新代碼的、徹底獨立的部署。這樣的升級使得整個原有的平臺在升級過程當中須要花費大量時間中斷業務，並升級相關軟件包，並考慮軟件包的相互依賴問題。在升級完成後，還須要通過大量的測試，確保不會影響其餘原有的OpenStack組件，這樣的升級常常使得用戶「苦不堪言」。

二、OpenStack產品升級支持度

而隨着OpenStack社區的努力和產品的進步，和運維人員素質的提升，升級變得愈來愈可控，對業務的影響也變得更小了。特別是OpenStack產品在推出Kolla容器化部署後，因爲容器的特性，可使得每一個組件能夠解耦，對每一個組件能夠實現「原子化」的升級，令以前被一直詬病的升級問題變得易於處理。

較新的OpenStack版本，例現在年早些時候公佈的Queen版本，更側重於穩定性和可靠性，強調全部模塊在升級時儘量接近零停機時間。OpenStack社區也在經過對產品的不斷提升功能性和穩定性，吸引用戶來升級Openstack產品，也使得用戶有興趣升級已經部署在機房而且運行着的OpenStack。

然而，最新用戶調查結果顯示，有一半以上的OpenStack用戶仍然運行着比最新版本老兩個以上版本的平臺。這意味着按照OpenStack官方的生命週期，這些用戶的版本「不受支持」。打包和分發OpenStack構建的公司一般會提供更長時間（一般是三到五年）的商業支持。更重要的是，這可能意味着他們正在使用自發布以來就被認爲具備安全漏洞和問題的OpenStack軟件模塊。

三、OpenStack升級變得簡易化

Openstack迭代很快，半年一次的更新每每會引入新的特性，及原有功能的完善。每一個新版本都包含了大量的新特性以及性能穩定性的提高。

版本升級成爲了一個不可避免的問題。因爲openstack升級的複雜性許多公司和團隊採用直接遷移至新版本雲的方案，這是不失爲一種可行的方案。

在某些狀況下，升級OpenStack也意味着更新操做系統層， OpenStack的價值主張在很大程度上圍繞着它很容易定製和高度可插拔的。OpenStack的一個優勢在於它有一套全面的應用程序編程接口（API）服務，能夠將不一樣的存儲技術和不一樣的網絡技術插入其中，而且圍繞OpenStack和發行版有一個很是健康的生態系統。

實際上，「純淨的」OpenStack （即未通過定製化修改的原版OpenStack）並不難升級，由於每一個OpenStack版本都是爲無縫滾動更新（rollover）設計的，並經受大量的社區測試，確保升級過程儘量順暢無阻。在升級過程當中，應該儘可能減小生產環境的中斷時間，所以須要優化升級過程，平滑升級。

從軟件的進化的原則來講，在不斷的bug修復過程當中，才能提升軟件產品的高可用性和魯棒性，從早期版本到最新版本過程當中，中間有多個大版本的進步，那麼OpenStack不管是從功能性、易用性或者是從穩定性來講都是有了質變的提高，在不斷修復bug的同時，社區的開發人員也從用戶反饋的問題進行思考，而不是脫離實際用戶。另外，社區也建議，使用比最新一版（Rocky）更低一級的版本（Queens）版本，這樣即增長了社區的功能和穩定性，也下降了最新版本可能存在的風險。

四、功能的多樣性

OpenStack的產品每一個版本都有新的項目加入，特別是社區實行了big tent策略以後，新的項目更是層出不窮，特別是新的項目如cinder multi-attach解決了共享存儲的問題、cyborg對GPU有了更好的支持、也引進了Plecement API，給用戶更好的可見性、cellv2模塊支撐了更大的部署規模、octavia模塊提供了一種全新的解決LB的思路、 keystone增長了多因素身份驗證規則提升了雲平臺的安全性、界面上也把各個版本增長的功能體如今Horizon組件上、容器化也新增了kuryr和zun等組件來融合容器平臺、OpenStack-Helm用於在Kubernetes之上管理 OpenStack的生命週期……還有不少精彩的新增功能來契合用戶的痛點。

五、一些僞報道

因爲一些Vmware廠商和支持在裸機上直接部署容器的廠商的競爭，一些報道爲了誇大OpenStack的缺點，所以可能用了一些修飾手法，從OpenStack社區開發人員「大量減小」或者是bug數「指數級增長」，都是比較片面的說法。從Mikata版本到Queens版本OpenStack社區的resolved bug數目來看，每一個組件都有一些不一樣程度的增長和減小，而不是單純的bug數量增長，更不是「指數性」增長。

六、OpenStack升級的優點

OpenStack 是軟件，是軟件就會有 bug。 OpenStack 包含了不少組件，結構很鬆散，每一個組件能夠單獨更新，只要保證各個組件都屬於同一個大版本（好比 kilo, liberty）就不會有問題。在舊版本遇到了 bug，若是社區已經有 fix，只須要更新包含該 fix 的組件就能夠了，其餘組件保持不變。

6.1高效性。升級完成後，具有高效性。這一目標主要體如今：一是資源，時間資源、空間資源的高效利用，充分挖掘服務器的可利用價值，因爲新的組件具有了資源佔用更少、計算更加高效的特性，知足了升級的高效性；二是操做，OpenStack升級爲用戶提供便捷式操做，在原有功能基礎上提供程序修改、軟件組裝、指令調整等新型功能。

6.2經濟性。一項新軟件產品成功研發需消耗大量的人力、物力、財力。從成本耗資角度考慮，新軟件產品需符合持久應用的標準。而OpenStack藉助了社區的力量，不須要在OpenStack軟件開發上投入，使得產品的升級不須要耗費太多的成本，創造了良好的經濟收益。並且社區一年發佈2個版本，所以不會致使更新很是頻繁。

6.3安全性。OpenStack產品升級配備了更高的安全防護功能，對常見的功能缺陷及時補充改進，加強雲產品抗***的能力。如：用戶認證開啓了更強的安全防護功能，對網絡的安全協議有了更好的支持，從而提升了軟件工程系統的抗侵襲性能。

6.4穩定性。因爲OpenStack社區具備龐大的開發者，而代碼質量參差不齊，每一個版本都有不少明顯或者不明顯的Bug，那麼在升級過程當中，能夠將已知的Bug進行修復，提升了OpenStack雲產品的穩定性，以避免在生產中發現問題，致使更大的損失。也符合軟件升級螺旋式上升的特性。

6.5鬆耦合性。鬆耦合性是升級的一個重要目標，極大的下降了升級的成本投入，因爲OpenStack組件都是鬆耦合的特色，只須要更改一個模塊便可，實現合理的「即插即用」能夠實現單一組件的升級，而沒必要對OpenStack雲產品作大的更改。縮短了從新編程消耗的時間，這是升級的必然趨勢，提升了軟件產品工做的效率，縮短了從新編譯時間，也更符合無痛升級的特色。