為了使OpenStack部署更平穩(wěn)安全運(yùn)行，更新和打補(bǔ)丁是非常關(guān)鍵的工作。但是要執(zhí)行這些更新任務(wù)，IT團(tuán)隊(duì)要投入的時(shí)間精力遠(yuǎn)不只是按按開關(guān)就可以的。

OpenStack平臺(tái)由大約30個(gè)不同的模塊組成，其中每個(gè)模塊都有著相當(dāng)復(fù)雜的功能和要求。OpenStack的開發(fā)團(tuán)隊(duì)也是基于開源的，這有可能導(dǎo)致不平衡的測(cè)試、文檔和代碼質(zhì)量。

這就要求IT團(tuán)隊(duì)必須定期執(zhí)行OpenStack更新以避免影響系統(tǒng)運(yùn)行的穩(wěn)定性。在很多方面，那就如同是維護(hù)一個(gè)操作系統(tǒng)(如Windows)一樣，需要將bug修復(fù)更新保持至最新和確保安全性處于最佳水平。

但是，Windows和OpenStack之間的區(qū)別在于后者仍然處于變化較快的發(fā)展期，尤其是不同模塊的成熟度水平有著較大差異。OpenStack的重要版本發(fā)布頻率大約為六個(gè)月，而微軟的發(fā)布周期為2-4年。此外，由于OpenStack整體軟件成熟度水平不高，功能集在不斷發(fā)展，所以在重要版本之間的小版本發(fā)布也是非常頻繁且復(fù)雜。

直到近來(lái)，用于執(zhí)行OpenStack更新的首選方法都是使用命令行界面(CLI)，這種方法對(duì)于單個(gè)服務(wù)器是很好的，但對(duì)于大型節(jié)點(diǎn)集群則顯得效率低下。對(duì)于大型集群執(zhí)行更新來(lái)說(shuō)，出現(xiàn)錯(cuò)誤和更新失敗的幾率則會(huì)顯著提高。

執(zhí)行OpenStack更新的最佳做法

在理想的OpenStack更新中，IT人員應(yīng)體用所有節(jié)點(diǎn)，打補(bǔ)丁，然后重新啟動(dòng)整個(gè)配置——但這種方法會(huì)導(dǎo)致大量的停機(jī)時(shí)間。在實(shí)施具體更新之前仔細(xì)分析更新內(nèi)容可以提供一種替代解決方案。

尋找那些不對(duì)其他模塊有依賴性且不會(huì)實(shí)質(zhì)性改變存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)的模塊。Bug修復(fù)是最常見的OpenStack更新，這類更新可滾動(dòng)應(yīng)用于所有節(jié)點(diǎn)。

如果OpenStack更新影響了跨模塊的交互，那么IT團(tuán)隊(duì)就需要一起更新這兩個(gè)模塊。但是，難題在于任何節(jié)點(diǎn)都可能與其他任何節(jié)點(diǎn)進(jìn)行交互。最安全的打補(bǔ)丁方法就是關(guān)閉所有節(jié)點(diǎn)。但是，如果跨模塊更新涉及了可以關(guān)閉的功能，那么就可以安全地重新啟動(dòng)系統(tǒng)。然后，當(dāng)集群更新時(shí)，可再次打開功能。

一般來(lái)說(shuō)，最好是一次更新一個(gè)OpenStack模塊，然后確定集群是否穩(wěn)定和無(wú)錯(cuò)誤。當(dāng)錯(cuò)誤修復(fù)出錯(cuò)時(shí)，區(qū)域化方法可實(shí)現(xiàn)更為簡(jiǎn)便的調(diào)試。

務(wù)必始終從已知和安全的來(lái)源獲取更新代碼包。這一原則也同樣適用于實(shí)例與容器鏡像、實(shí)例與容器中的應(yīng)用程序和數(shù)據(jù)，以及OpenStack代碼等。當(dāng)OpenStack集群擴(kuò)展規(guī)模并鏈接至公共云時(shí)，從安全黑客中識(shí)別和恢復(fù)可能是非常耗時(shí)的。

OpenStack更新的自動(dòng)化選項(xiàng)

OpenStack社區(qū)牢記了Windows中的教訓(xùn)。例如，實(shí)現(xiàn)OpenStack更新過(guò)程自動(dòng)化是非常有意義的，因?yàn)榇伺e將有助于實(shí)現(xiàn)停機(jī)時(shí)間和風(fēng)險(xiǎn)的最小化。而相關(guān)的實(shí)現(xiàn)工具在一些OpenStack發(fā)布版本中。

Red Hat公司的OpenStack平臺(tái)軟件包就是一個(gè)典型的例子。這個(gè)軟件包可處理所有主要的升級(jí)任務(wù)，以及一些次要的更新。Red Hat試圖避免在非重要發(fā)布版本中進(jìn)行功能變更，例如可能具有跨模塊影響的API。

其他的供應(yīng)商也正在解決這個(gè)自動(dòng)化問(wèn)題。Platform9可實(shí)現(xiàn)OpenStack升級(jí)的自動(dòng)化，而惠普企業(yè)、戴爾科技以及IBM也紛紛加入此行列。其他的軟件供應(yīng)商則包括Stratoscale、NephoScale 和 Mirantis。考慮到通過(guò)CLI方式手工實(shí)現(xiàn)OpenStack升級(jí)這一方式的復(fù)雜性，管理員應(yīng)當(dāng)使用這些軟件包中的一種來(lái)控制升級(jí)過(guò)程，從而進(jìn)一步降低風(fēng)險(xiǎn)。雖然它們還不夠完美，因?yàn)榭缒K的依賴性仍然會(huì)是這一過(guò)程復(fù)雜化，但是它們確實(shí)有助于主要版本的升級(jí)和發(fā)布。