OpenStack Nova如何支持Live Upgrade

作者：Hongliang 2015-04-27 13:34:03

OpenStack半年一個(gè)版本，升級(jí)是一個(gè)怎么也躲不開的問題，總是在想如何在復(fù)雜的OpenStack部署環(huán)境中做到業(yè)務(wù)平滑升級(jí)，同時(shí)又不影響到用戶，當(dāng)前的OpenStack中又有那些特性支持live-upgrade，今天以Nova作為一個(gè)開端，看看Nova中是怎么做的。

寫在最前面：

代碼基線：Kilo

官方文檔

如今的OpenStack官方文檔已經(jīng)相對(duì)比較全面了，Operations Guide中就有一個(gè)章節(jié)專門描述了升級(jí)相關(guān)的指導(dǎo)，并舉了幾個(gè)版本升級(jí)的例子，雖然比較簡(jiǎn)單，但是大體的框架和步驟都已經(jīng)有了。基本的思路就是：小規(guī)模驗(yàn)證 -> 備份配置文件和數(shù)據(jù)庫 -> 更新配置文件 -> 利用包管理器升級(jí)安裝包 -> 停止進(jìn)程 -> 更新數(shù)據(jù)庫 -> 啟動(dòng)進(jìn)程 -> 再次驗(yàn)證。推薦大家都仔細(xì)閱讀一下。

upgrade levels

官方文檔中專門提到了一個(gè)概念 upgrade levels，這里涉及到Nova的***個(gè)live-upgrade特性。

先稍微繞開一點(diǎn)，當(dāng)前由于對(duì)象化的引入，nova中的api, scheduler, conductor, compute四個(gè)進(jìn)程都存在循環(huán)依賴，所以不可能簡(jiǎn)單的劃分出一個(gè)依賴樹，從樹的葉子節(jié)點(diǎn)開始升級(jí)，從而保證API兼容性，這種升級(jí)的方式在nova中不可行。有循環(huán)依賴也就是說，從任何一端開始升級(jí)，都有可能發(fā)生高版本client向低版本server發(fā)送消息的可能。這里就需要用到upgrade levels。

簡(jiǎn)單來說就是一個(gè)rpcapi端的版本控制機(jī)制，在升級(jí)之前，rpc client端設(shè)置一個(gè)版本閥值，當(dāng)rpcapi需要發(fā)送消息時(shí)，通過can_send_version方法判斷，如果超過閥值就做自動(dòng)降級(jí)處理，沒有做降級(jí)處理的消息，會(huì)被禁止發(fā)送，具體實(shí)現(xiàn)可以參考o(jì)slo_messaging的代碼。例子如下：

def shelve_offload_instance(self, ctxt, instance, 
 
clean_shutdown=True): 
 
msg_args = {‘instance’: instance} 
 
if self.client.can_send_version(’3.37′): 
 
version = ’3.37′ 
 
msg_args['clean_shutdown'] = clean_shutdown 
 
else: 
 
version = ’3.0′ 
 
cctxt = self.client.prepare(server=_compute_host(None, instance), 
 
version=version) 
 
cctxt.cast(ctxt, ‘shelve_offload_instance’, **msg_args)

如果我們計(jì)劃從juno升級(jí)到kilo，首先需要設(shè)置所有rpcapi的upgrade levels為juno，這樣當(dāng)我們升級(jí)的過程中，如果一個(gè)已經(jīng)升到kilo版本的conductor向juno版本的compute發(fā)送rpc消息，還是會(huì)使用和juno版本rpcapi接口兼容的消息。

#p#

API序列化

每一個(gè)rpcapi的都有版本號(hào)，每次的api修改都需要調(diào)整版本號(hào)，nova通過版本號(hào)來判斷client側(cè)和server側(cè)是否兼容。

整個(gè)rpc調(diào)用分為兩個(gè)步驟，rpcapi側(cè)將整個(gè)rpc調(diào)用序列化，然后在rpc server也就是manager側(cè)收到消息，再反序列化執(zhí)行。整個(gè)rpc message除了context之外，message字典結(jié)構(gòu)體中還包括四個(gè)部分：

method
args
version
namespace

version標(biāo)識(shí)了rpcapi的版本，在rpc server側(cè)直接通過method名稱查找manager中的函數(shù)，將args參數(shù)反序列化之后，調(diào)用method函數(shù)執(zhí)行。調(diào)用之前也會(huì)在 server側(cè)，檢查rpcapi的version是否和manager的實(shí)現(xiàn)版本兼容，如果不兼容拋出異常。namespace用于區(qū)分 conductor中的ConductorAPI和ConductorTaskAPI。

可以看到如果我們修改代碼，調(diào)整了rpcapi的接口參數(shù)，就一定要同時(shí)更新client/server側(cè)的版本號(hào)，并在rpc server的接口實(shí)現(xiàn)側(cè)提供參數(shù)默認(rèn)值。

在rpcapi的層面，低版本client調(diào)用高版本server，兼容支持;高版本client調(diào)用低版本server，通過upgrade levels自動(dòng)降級(jí)，未做自動(dòng)降級(jí)處理的禁止發(fā)送，拋出異常。

API參數(shù)序列化

除了rpcapi在升級(jí)過程中需要考慮升級(jí)兼容性，args參數(shù)中的NovaObject對(duì)象，也需要考慮升級(jí)兼容性。所有的NovaObject都有版本號(hào)跟蹤每一次的修改。

在rpcapi發(fā)送消息之前，首先對(duì)接口參數(shù)進(jìn)行序列化，如果參數(shù)是NovaObject類型，都通過NovaObject的 obj_to_primitive方法轉(zhuǎn)化成dict類型之后，保存在args，如果是原始類型，直接保存在args中。rpc server接收到消息之后，將args中的接口參數(shù)反序列化，如果是NovaObject對(duì)象，通過obj_from_primitive接口反序列化。

NovaObject類中存在一個(gè)_obj_classes類屬性，其中會(huì)保存一個(gè)NovaObject的多個(gè)版本的實(shí)現(xiàn)，通過版本號(hào)從大到小排序，***版本就是當(dāng)前代碼實(shí)現(xiàn)版本，較小版本由升級(jí)過程中低版本進(jìn)程發(fā)送而來。

NovaObjectSerializer.deserialize_entity用于反序列化對(duì)象，如果server端當(dāng)前實(shí)現(xiàn)版本大于發(fā)送過來的版本，直接兼容，反序列化對(duì)象。如果發(fā)送的版本大于server端實(shí)現(xiàn)版本，忽略最末端版本號(hào)，再次嘗試反序列化，如果仍然不能成功，就需要調(diào)用 conductor.object_backport方法，嘗試降級(jí)處理，將args參數(shù)轉(zhuǎn)化為server端可以處理的object。

#p#

升級(jí)順序

升級(jí)順序可能不同人分析有不同的結(jié)果，我這里提供一個(gè)建議順序和分析過程。

社區(qū)的operation guide中推薦的升級(jí)方式為先controller節(jié)點(diǎn)，然后compute節(jié)點(diǎn)。在我看來，這樣升級(jí)有一個(gè)好處就是可以盡早的發(fā)現(xiàn)問題，降低風(fēng)險(xiǎn)和回退成本。controller節(jié)點(diǎn)進(jìn)程最多也最復(fù)雜，首先升級(jí)可以盡早的發(fā)現(xiàn)問題，這時(shí)回退也只需要回退controller，如果有100個(gè) compute都升級(jí)完成了，再升級(jí)controller，如果升級(jí)失敗，就需要回退100個(gè)compute節(jié)點(diǎn)。

先升級(jí)controller有個(gè)問題，就是client端的版本要大于server端，也就是4.0的conductor可能調(diào)用3.0的 compute，需要用upgrade_levels控制。如果compute進(jìn)行數(shù)據(jù)庫操作，就會(huì)執(zhí)行NovaObject的方法，***調(diào)用到 conductor的object_class_action方法，這個(gè)方法有特殊處理，會(huì)將返回值版本轉(zhuǎn)化為調(diào)用端的版本。

綜合這幾點(diǎn)，推薦的一個(gè)升級(jí)順序?yàn)?