1 驅(qū)散目的

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

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

2 簡要流程

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

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

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

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

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

6、宕機節(jié)點恢復后，nova-compute服務會自動檢測執(zhí)行驅(qū)散操作成功的云主機，并對應云主機在本機的信息，而對于驅(qū)散操作失敗的云主機不做任何操作。

3 代碼分析

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

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

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

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

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

然后nova/conductor/rpcapi.py

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

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

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

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

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

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

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

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

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

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

4 故障

4.1 故障說明

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

4.2 故障恢復

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

4.3 重置云主機

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

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

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

mysqldump -u nova -p nova > nova.sql

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

fqj