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

1、OpenStack升級問題

OpenStack正逐漸被接受為企業級框架，用于自動化數據中心基礎設施，并使企業能夠運營各種各樣的應用程序和服務。

2010年，該平臺作為托管服務提供商Rackspace和NASA的聯合項目出現在市場上。目前，它已經發展成為迄今為止最大的開放源碼項目之一，其版本發布由OpenStack社區一年兩次的會議推動，每次會議一般會公布下一個版本的優先事項。

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

早期采用者經常發現自己面臨著難以置信的選擇——要么在安裝新代碼的同時將OpenStack基礎設施脫機，要么簡單地將工作負載遷移到基于新代碼的、完全獨立的部署。這樣的升級使得整個原有的平臺在升級過程中需要花費大量時間中斷業務，并升級相關軟件包，并考慮軟件包的相互依賴問題。在升級完成后，還需要經過大量的測試，確保不會影響其他原有的OpenStack組件，這樣的升級經常使得用戶“苦不堪言”。

2、OpenStack產品升級支持度

而隨著OpenStack社區的努力和產品的進步，和運維人員素質的提高，升級變得越來越可控，對業務的影響也變得更小了。特別是OpenStack產品在推出Kolla容器化部署后，由于容器的特性，可以使得每個組件可以解耦，對每個組件可以實現“原子化”的升級，令之前被一直詬病的升級問題變得易于處理。

較新的OpenStack版本，例如今年早些時候公布的Queen版本，更側重于穩定性和可靠性，強調所有模塊在升級時盡可能接近零停機時間。OpenStack社區也在通過對產品的不斷提高功能性和穩定性，吸引用戶來升級Openstack產品，也使得用戶有興趣升級已經部署在機房并且運行著的OpenStack。

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

3、OpenStack升級變得簡易化

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

版本升級成為了一個不可避免的問題。由于openstack升級的復雜性許多公司和團隊采用直接遷移至新版本云的方案，這是不失為一種可行的方案。

在某些情況下，升級OpenStack也意味著更新操作系統層， OpenStack的價值主張在很大程度上圍繞著它很容易定制和高度可插拔的。OpenStack的一個優點在于它有一套全面的應用程序編程接口（API）服務，可以將不同的存儲技術和不同的網絡技術插入其中，并且圍繞OpenStack和發行版有一個非常健康的生態系統。

實際上，“純凈的”OpenStack （即未經過定制化修改的原版OpenStack）并不難升級，因為每個OpenStack版本都是為無縫滾動更新（rollover）設計的，并經受大量的社區測試，確保升級過程盡可能順暢無阻。在升級過程中，應該盡量減少生產環境的中斷時間，因此需要優化升級過程，平滑升級。

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

4、功能的多樣性

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

5、一些偽報道

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

6、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云產品做大的更改。縮短了重新編程消耗的時間，這是升級的必然趨勢，提高了軟件產品工作的效率，縮短了重新編譯時間，也更符合無痛升級的特點。