作者 | 孫琦

來源 |?萬博智云

OpenStack是中國私有云的事實標(biāo)準(zhǔn)

根據(jù)三方統(tǒng)計報告，2020年，中國私有云市場規(guī)模達(dá)到951.8億元，同比增長42.1%，私有云在國內(nèi)IaaS市場占比約45%。私有云提供商有望在云計算市場持續(xù)高速發(fā)展進(jìn)程中持續(xù)受益。

在中國的私有云企業(yè)排名中，以O(shè)penStack為代表的開源技術(shù)占比70%，依然占據(jù)主流。作為全球部署最廣泛的開源云基礎(chǔ)設(shè)施軟件，OpenStack經(jīng)過10年的發(fā)展，在國內(nèi)已經(jīng)形成了穩(wěn)定的以O(shè)penStack為核心的開源云生態(tài)體系。盡管在近年來受到了容器等技術(shù)的沖擊，但是在中國市場中越來越豐富、越來越成熟的用戶實踐案例表明，OpenStack開源云技術(shù)依然保持著足夠的活力。然而隨著產(chǎn)品版本迭代升級，各企業(yè)的私有云平臺運營維護(hù)，升級改造的壓力逐漸增大。

OpenStack為什么升級難？

雖然OpenStack目前已經(jīng)成為大多數(shù)私有云的解決方案，但是做過OpenStack的人都知道，版本升級是OpenStack商業(yè)化應(yīng)用最大的痛。每年兩個新版本不說，隨著版本升級，老舊的操作系統(tǒng)也不再支持，這樣讓用戶更加不敢輕易的進(jìn)行升級。雖然后續(xù)的OpenStack試圖解決這個問題，但是在大多數(shù)情況下，商業(yè)版本OpenStack為了穩(wěn)定，往往選擇一個較為固定的OpenStack版本，持續(xù)進(jìn)行迭代和優(yōu)化，這樣就帶來和社區(qū)版本較大的差異，而無法進(jìn)行升級。

之前看過360公司的一篇《橫跨7個版本的OpenStack無感知熱升級在360的落地與實踐》，洋洋灑灑數(shù)千字描述了OpenStack升級的血淚史。對于一家技術(shù)實力積累雄厚的互聯(lián)網(wǎng)公司尚且花費了如此大的代價，對于傳統(tǒng)企業(yè)客戶來說，這幾乎就成為了心中永遠(yuǎn)的痛。在實際項目中，由于無法實現(xiàn)平滑升級，我們往往看到很多客戶的環(huán)境部署著多套OpenStack不同版本的環(huán)境，而每一套都需要配備相應(yīng)的運維團(tuán)隊，這就造成了客戶和云平臺廠商兩難的尷尬局面。

“不識廬山真面目，只緣身在此山中”，大多數(shù)的解決方案專注于OpenStack本身，而今天這篇文章為大家?guī)硪环N不同視角的解決方案，從根本上解決OpenStack升級問題，無論你跨多少個版本，都可以完美的解決。

如何破局？

OpenStack升不動或者不敢升本質(zhì)是云平臺上有業(yè)務(wù)系統(tǒng)運行，所以我們本質(zhì)上要解決在升級過程中，業(yè)務(wù)系統(tǒng)連續(xù)性的問題，那么最簡單的方案就是將業(yè)務(wù)系統(tǒng)平滑的遷移至新的云平臺上，為了防止大家失去耐心讀完整篇文章，我先說解決方案：

業(yè)務(wù)系統(tǒng)遷移過程中不中斷：利用主機塊級別增量遷移方式（不是OpenStack原生的Live Migration），將主機從原有云平臺遷移至新的云平臺；

無代理方式：市面上90%以上的遷移方案都是需要在源端安裝代理，那么如果用戶云主機數(shù)量過多，一臺臺安裝代理的成本也實在太高了，對于用戶來講需要一種無代理的方式來實現(xiàn)云平臺之間的平滑遷移；

容災(zāi)漸進(jìn)式遷移：按照最小規(guī)模部署新版本OpenStack，待主機逐步遷移至新平臺后，將閑置計算節(jié)點重新加入回新資源池，同時在正式割接前，業(yè)務(wù)系統(tǒng)可以在新的云平臺上統(tǒng)一演練，確保業(yè)務(wù)可以正常使用，數(shù)據(jù)完整；

重建管理信息：解決了數(shù)據(jù)的問題，云平臺對應(yīng)的租戶、網(wǎng)絡(luò)、安全組等資源可以通過導(dǎo)出導(dǎo)入的方式在新的平臺上重新構(gòu)建即可。

如何解決？

HyperMotion是一款基于云原生的遷移產(chǎn)品，基于塊級別差量復(fù)制實現(xiàn)業(yè)務(wù)級別熱遷移。在我們最初設(shè)計產(chǎn)品時，除了注重對云平臺云原生能力的利用，還在產(chǎn)品中加入了“軟件定義存儲控制器”層，這樣讓HyperMotion不僅僅可以使用自身的數(shù)據(jù)流能力，還能夠輕松使用開放的數(shù)據(jù)接口，從而實現(xiàn)云環(huán)境之間的“數(shù)據(jù)流轉(zhuǎn)”。另外一方面，HyperMotion是從云端反向設(shè)計，不同于傳統(tǒng)的災(zāi)備產(chǎn)品，更符合云平臺管制的需求。

在本場景中，HyperMotion利用OpenStack接口和Ceph RBD接口實現(xiàn)了云主機熱遷移問題，從而解決了OpenStack自身版本的困難，基本的原理如下圖所示：

首先在舊版本OpenStack上，我們利用云主機構(gòu)建一臺源端同步代理節(jié)點，該節(jié)點一方面負(fù)責(zé)調(diào)用源端OpenStack API接口，另外一方面負(fù)責(zé)與Ceph RBD進(jìn)行通訊，讀取塊級別差量數(shù)據(jù)。這種方案下，對于源端的網(wǎng)絡(luò)有一定的要求，需要源端同步代理節(jié)點能夠同時訪問源端同步代理及Ceph存儲網(wǎng)絡(luò)。

每次同步時，為了不破壞OpenStack自有的管理體系，每一次的快照要從OpenStack層面進(jìn)行調(diào)度，之后再去Ceph層讀取數(shù)據(jù)，這樣就不會產(chǎn)生垃圾數(shù)據(jù)。待數(shù)據(jù)讀出后，通過加密、壓縮等手段傳輸?shù)侥繕?biāo)平臺。

在目標(biāo)平臺上，我們需要利用云主機資源再建立一臺同步代理，用于接收數(shù)據(jù)。接收的數(shù)據(jù)并不直接寫入Ceph中，而是利用云主機直接寫入Cinder的磁盤中，這樣做的目的仍然是符合OpenStack管制的需求。

每次寫入完成后，利用Cinder快照機制，固化時間點數(shù)據(jù)，這樣我們可以在正式割接前，進(jìn)行反復(fù)的遷移演練，保證業(yè)務(wù)系統(tǒng)割接后能夠正常使用。

最后，在割接窗口期，將最后的增量補全后，利用HyperMotion與OpenStack API的深度對接，按照指定規(guī)格同時指定IP地址進(jìn)行啟動，完成割接。

一句話總結(jié)一下，通過無代理，漸進(jìn)式遷移，解決OpenStack版本升級過程中的業(yè)務(wù)連續(xù)性問題，是我們在大量私有云遷移實踐中總結(jié)的一條行之有效的路徑，給大家分享。

往期推薦

從 40% 跌至 4%，“糊”了的 Firefox 還能重回巔峰嗎？

Gartner 發(fā)布 2022 年汽車行業(yè)五大技術(shù)趨勢

別再用 Redis List 實現(xiàn)消息隊列了，Stream 專為隊列而生

漫畫：什么是“低代碼”開發(fā)平臺？

點分享

點收藏

點點贊

點在看

總結(jié)

以上是生活随笔為你收集整理的OpenStack 如何跨版本升级的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。