為了使OpenStack部署更平穩(wěn)安全運行，更新和打補丁是非常關(guān)鍵的工作。但是要執(zhí)行這些更新任務(wù)，IT團隊要投入的時間精力遠(yuǎn)不只是按按開關(guān)就可以的。
OpenStack平臺由大約30個不同的模塊組成，其中每個模塊都有著相當(dāng)復(fù)雜的功能和要求。OpenStack的開發(fā)團隊也是基于開源的，這有可能導(dǎo)致不平衡的測試、文檔和代碼質(zhì)量。
這就要求IT團隊必須定期執(zhí)行OpenStack更新以避免影響系統(tǒng)運行的穩(wěn)定性。在很多方面，那就如同是維護一個操作系統(tǒng)（如Windows）一樣，需要將bug修復(fù)更新保持至最新和確保安全性處于最佳水平。
但是，Windows和OpenStack之間的區(qū)別在于后者仍然處于變化較快的發(fā)展期，尤其是不同模塊的成熟度水平有著較大差異。OpenStack的重要版本發(fā)布頻率大約為六個月，而微軟的發(fā)布周期為2-4年。此外，由于OpenStack整體軟件成熟度水平不高，功能集在不斷發(fā)展，所以在重要版本之間的小版本發(fā)布也是非常頻繁且復(fù)雜。
直到近來，用于執(zhí)行OpenStack更新的首選方法都是使用命令行界面（CLI），這種方法對于單個服務(wù)器是很好的，但對于大型節(jié)點集群則顯得效率低下。對于大型集群執(zhí)行更新來說，出現(xiàn)錯誤和更新失敗的幾率則會顯著提高。
執(zhí)行OpenStack更新的最佳做法
在理想的OpenStack更新中，IT人員應(yīng)體用所有節(jié)點，打補丁，然后重新啟動整個配置——但這種方法會導(dǎo)致大量的停機時間。在實施具體更新之前仔細(xì)分析更新內(nèi)容可以提供一種替代解決方案。
尋找那些不對其他模塊有依賴性且不會實質(zhì)性改變存儲數(shù)據(jù)結(jié)構(gòu)的模塊。Bug修復(fù)是最常見的OpenStack更新，這類更新可滾動應(yīng)用于所有節(jié)點。
如果OpenStack更新影響了跨模塊的交互，那么IT團隊就需要一起更新這兩個模塊。但是，難題在于任何節(jié)點都可能與其他任何節(jié)點進行交互。最安全的打補丁方法就是關(guān)閉所有節(jié)點。但是，如果跨模塊更新涉及了可以關(guān)閉的功能，那么就可以安全地重新啟動系統(tǒng)。然后，當(dāng)集群更新時，可再次打開功能。
一般來說，最好是一次更新一個OpenStack模塊，然后確定集群是否穩(wěn)定和無錯誤。當(dāng)錯誤修復(fù)出錯時，區(qū)域化方法可實現(xiàn)更為簡便的調(diào)試。
務(wù)必始終從已知和安全的來源獲取更新代碼包。這一原則也同樣適用于實例與容器鏡像、實例與容器中的應(yīng)用程序和數(shù)據(jù)，以及OpenStack代碼等。當(dāng)OpenStack集群擴展規(guī)模并鏈接至公共云時，從安全黑客中識別和恢復(fù)可能是非常耗時的。
OpenStack更新的自動化選項
OpenStack社區(qū)牢記了Windows中的教訓(xùn)。例如，實現(xiàn)OpenStack更新過程自動化是非常有意義的，因為此舉將有助于實現(xiàn)停機時間和風(fēng)險的最小化。而相關(guān)的實現(xiàn)工具在一些OpenStack發(fā)布版本中。
Red Hat公司的OpenStack平臺軟件包就是一個典型的例子。這個軟件包可處理所有主要的升級任務(wù)，以及一些次要的更新。Red Hat試圖避免在非重要發(fā)布版本中進行功能變更，例如可能具有跨模塊影響的API。
其他的供應(yīng)商也正在解決這個自動化問題。Platform9可實現(xiàn)OpenStack升級的自動化，而惠普企業(yè)、戴爾科技以及IBM也紛紛加入此行列。其他的軟件供應(yīng)商則包括Stratoscale、NephoScale 和 Mirantis。考慮到通過CLI方式手工實現(xiàn)OpenStack升級這一方式的復(fù)雜性，管理員應(yīng)當(dāng)使用這些軟件包中的一種來控制升級過程，從而進一步降低風(fēng)險。雖然它們還不夠完美，因為跨模塊的依賴性仍然會是這一過程復(fù)雜化，但是它們確實有助于主要版本的升級和發(fā)布。
京公網(wǎng)安備 11010502049343號