1 驅(qū)散目的

當(dāng)云主機(jī)所在節(jié)點(diǎn)宕機(jī)或者節(jié)點(diǎn)網(wǎng)絡(luò)異常時(shí)可以觸發(fā)驅(qū)散操作，可以將宕機(jī)節(jié)點(diǎn)上的云主機(jī)驅(qū)散到其他節(jié)點(diǎn)，從而可以繼續(xù)訪問(wèn)這些云主機(jī)。

這里有必要說(shuō)明一點(diǎn)，驅(qū)散和遷移的關(guān)聯(lián)與區(qū)別，關(guān)聯(lián)在于驅(qū)散操作可以使用遷移命令來(lái)查看驅(qū)散的信息，而區(qū)別在于遷移時(shí)源節(jié)點(diǎn)和目標(biāo)節(jié)點(diǎn)都是正常的，節(jié)點(diǎn)上的nova-compute服務(wù)也是正常的，這說(shuō)明在沒(méi)有共享存儲(chǔ)的情況下也是可以進(jìn)行遷移的；而驅(qū)散時(shí)源節(jié)點(diǎn)是宕機(jī)的狀態(tài)或者nova-compute服務(wù)不正常，所以驅(qū)散無(wú)法訪問(wèn)源節(jié)點(diǎn)必須訪問(wèn)共享存儲(chǔ)獲取云主機(jī)磁盤數(shù)據(jù)。這是二者的本質(zhì)區(qū)別。

2 簡(jiǎn)要流程

1、nova-api接受驅(qū)散操作，校驗(yàn)云主機(jī)所在節(jié)點(diǎn)狀態(tài)為down，并且云主機(jī)狀態(tài)為active，stopped，error才能執(zhí)行 evacuate并創(chuàng)建該云主機(jī)的遷移任務(wù)，這里的遷移類型為evacuation，可以通過(guò)nova migration-list命令查看驅(qū)散執(zhí)行情況。

2、之后nova-api發(fā)送rpc到nova-condu ctor進(jìn)行云主機(jī)重建rebuild_instance。

3、然后nova-conductor接收到rebuild_i nstance的rpc請(qǐng)求后，調(diào)用nova-scheduler選擇資源足夠的可用節(jié)點(diǎn)，并獲取該云主機(jī)的遷移任務(wù)，從該任務(wù)中，獲取云主機(jī)相關(guān)的配置信息。

4、nova-conductor使用被選中的可用節(jié)點(diǎn)進(jìn)行rebuild_instance

5、可用節(jié)點(diǎn)的nova-compute接收到rebuild_instance的rpc消息后重新設(shè)置該云主機(jī)對(duì)應(yīng)的網(wǎng)絡(luò)端口，直接使用云主機(jī)的云硬盤，最終啟動(dòng)云主機(jī)。

6、宕機(jī)節(jié)點(diǎn)恢復(fù)后，nova-compute服務(wù)會(huì)自動(dòng)檢測(cè)執(zhí)行驅(qū)散操作成功的云主機(jī)，并對(duì)應(yīng)云主機(jī)在本機(jī)的信息，而對(duì)于驅(qū)散操作失敗的云主機(jī)不做任何操作。

3 代碼分析

3.1? 驅(qū)散api接口代碼，nova-api接收驅(qū)散操作請(qǐng)求，代碼位于nova/api/compute/evacuate.py

之后會(huì)調(diào)用nova/compute/api.py，并在調(diào)用時(shí)校驗(yàn)云主機(jī)狀態(tài)，處于ACTIVE，STOPPED以及ERROR狀態(tài)的云主機(jī)才能進(jìn)行驅(qū)散操作。

這里調(diào)用了rebuild_instance函數(shù)，并且沒(méi)有指定鏡像，而是根據(jù)原有信息重建云主機(jī)。一般對(duì)于重建云主機(jī)功能是指定鏡像進(jìn)行重建，而驅(qū)散是利用原云主機(jī)的數(shù)據(jù)進(jìn)行重建，這是驅(qū)散功能和重建功能的區(qū)別。

3.2?驅(qū)散conductor部分代碼

之后調(diào)用到nova/conductor/api.py

然后nova/conductor/rpcapi.py

這里的cast調(diào)用是異步的，是在nova-api進(jìn)程里面調(diào)用的，實(shí)際在此之前的調(diào)用都是在nova-api的進(jìn)程里面，而將rebuild_instance調(diào)用發(fā)送到nova-conductor后，此時(shí)nova-api的處理才告一段落，nova-conductor服務(wù)才真正接手處理。最后會(huì)調(diào)用到nova/conductor/manager.py

這里的cast調(diào)用是異步的，是在nova-api進(jìn)程里面調(diào)用的，實(shí)際在此之前的調(diào)用都是在nova-api的進(jìn)程里面，而將rebuild_instance調(diào)用發(fā)送到nova-conductor后，此時(shí)nova-api的處理才告一段落，nova-conductor服務(wù)才真正接手處理。最后會(huì)調(diào)用到nova/conductor/manager.py

這里沒(méi)有將涉及nova-scheduler部分代碼列出，實(shí)際這里的調(diào)度主要是通過(guò)過(guò)濾filter來(lái)實(shí)現(xiàn)的，檢查節(jié)點(diǎn)是否有可用的CPU和內(nèi)存等。

需要注意的是，若是沒(méi)有指定目標(biāo)節(jié)點(diǎn)則scheduler會(huì)自動(dòng)選擇一個(gè)合適的節(jié)點(diǎn)進(jìn)行驅(qū)散，若沒(méi)有找到合適的節(jié)點(diǎn)則驅(qū)散失敗，云主機(jī)狀態(tài)會(huì)出錯(cuò)；注意這里還有一個(gè)異常，不支持的策略異常UnsupportedPolicyException，這個(gè)異常一般是出現(xiàn)親和性策略時(shí)的異常，也就是若云主機(jī)設(shè)置了某些親和性策略則有可能導(dǎo)致驅(qū)散失敗。

上述在調(diào)度節(jié)點(diǎn)出現(xiàn)的兩個(gè)異常無(wú)效主機(jī)和不支持策略，從而導(dǎo)致驅(qū)散失敗后，在節(jié)點(diǎn)恢復(fù)后，不會(huì)做任何操作，重置云主機(jī)狀態(tài)之后，是可以在恢復(fù)后的節(jié)點(diǎn)啟動(dòng)云主機(jī)的。

3.3?驅(qū)散compute部分代碼

之后調(diào)用nova/compute/rpcapi.py

然后就會(huì)調(diào)用到nova/compute/manager.py的rebuild_instance函數(shù)，最終會(huì)調(diào)用_do_rebu ild_instance函數(shù)，

一般到了nova-compute這一側(cè)，云主機(jī)開始重建了，但不能說(shuō)完全沒(méi)有問(wèn)題了，這里在云主機(jī)保存數(shù)據(jù)時(shí)，有可能會(huì)出錯(cuò)，原因就是發(fā)送消息到nova-conductor出錯(cuò)了，從而數(shù)據(jù)庫(kù)里面的該云主機(jī)的數(shù)據(jù)沒(méi)有更新，從而導(dǎo)致云主機(jī)出現(xiàn)錯(cuò)誤狀態(tài)。

需要注意的是，從代碼看如果云主機(jī)已經(jīng)在其他節(jié)點(diǎn)上啟動(dòng)了，但是其顯示為錯(cuò)誤狀態(tài)，查看驅(qū)散為失敗狀態(tài)，若要恢復(fù)云主機(jī)，這個(gè)時(shí)候是不能直接重置云主機(jī)的，需要修改數(shù)據(jù)庫(kù)instances表，將對(duì)應(yīng)云主機(jī)的host和node字段值為啟動(dòng)節(jié)點(diǎn)的名稱，宕機(jī)節(jié)點(diǎn)恢復(fù)后nova-compute服務(wù)啟動(dòng)后會(huì)自動(dòng)刪除本機(jī)節(jié)點(diǎn)上云主機(jī)信息。

4 故障

4.1 故障說(shuō)明

對(duì)于云主機(jī)驅(qū)散操作失敗的，一般存在以下幾個(gè)原因。1.在nova-scheduler調(diào)度時(shí)沒(méi)有找到可用的節(jié)點(diǎn)導(dǎo)致驅(qū)散失敗。2.在nova-scheduler調(diào)度時(shí)若云主機(jī)存在親和性策略可能導(dǎo)致驅(qū)散失敗。3.發(fā)送消息給nova-conductor保存云主機(jī)數(shù)據(jù)時(shí)出錯(cuò)，也即發(fā)送消息時(shí)出現(xiàn)異常，導(dǎo)致驅(qū)散出錯(cuò)。

4.2 故障恢復(fù)

出現(xiàn)的故障如何進(jìn)行修復(fù)，這里有一個(gè)重要的區(qū)分條件，就是云主機(jī)是否在其他節(jié)點(diǎn)上對(duì)應(yīng)的信息，對(duì)于前面兩點(diǎn)，云主機(jī)在其他節(jié)點(diǎn)沒(méi)有對(duì)應(yīng)信息，待宕機(jī)節(jié)點(diǎn)恢復(fù)后重置云主機(jī)狀態(tài)即可；對(duì)于后面一點(diǎn)，如果云主機(jī)在其他節(jié)點(diǎn)上也有對(duì)應(yīng)信息了，就不能直接重置狀態(tài)操作了，目前對(duì)于這樣的問(wèn)題沒(méi)有對(duì)應(yīng)具體的處理命令，所以需要修改數(shù)據(jù)庫(kù)。這里重申一遍在操作數(shù)據(jù)庫(kù)時(shí)請(qǐng)先保存數(shù)據(jù)庫(kù)，也請(qǐng)慎重操作數(shù)據(jù)庫(kù)。

4.3 重置云主機(jī)

如何重置云主機(jī)狀態(tài)，在終端使用如下命令，nova reset-state –active 。如果是使用海云的AWCloud產(chǎn)品的話，可以直接在頁(yè)面上進(jìn)行操作，如下圖

4.4 修改數(shù)據(jù)庫(kù)

對(duì)于驅(qū)散出錯(cuò)的云主機(jī)，先找到云主機(jī)的ID，nova list |grep vm_name，記錄返回的云主機(jī)ID，在修改數(shù)據(jù)庫(kù)時(shí)需要用到這個(gè)ID值。修改數(shù)據(jù)庫(kù)前，請(qǐng)先備份數(shù)據(jù)庫(kù)。

mysqldump -u nova -p nova > nova.sql

之后會(huì)提示輸入密碼，完成備份后，再修改數(shù)據(jù)庫(kù)表。登陸nova數(shù)據(jù)庫(kù)，修改instances表，具體sql語(yǔ)句如下，update instances set host=’node-name’, node=’node-name.node.consul’ where uuid=’ID’。修改后退出數(shù)據(jù)庫(kù)，然后重置云主機(jī)狀態(tài)。

fqj