1 驅散目的

當云主機所在節點宕機或者節點網絡異常時可以觸發驅散操作，可以將宕機節點上的云主機驅散到其他節點，從而可以繼續訪問這些云主機。

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

2 簡要流程

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

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

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

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

5、可用節點的nova-compute接收到rebuild_instance的rpc消息后重新設置該云主機對應的網絡端口，直接使用云主機的云硬盤，最終啟動云主機。

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

3 代碼分析

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

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

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

3.2?驅散conductor部分代碼

之后調用到nova/conductor/api.py

然后nova/conductor/rpcapi.py

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

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

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

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

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

3.3?驅散compute部分代碼

之后調用nova/compute/rpcapi.py

然后就會調用到nova/compute/manager.py的rebuild_instance函數，最終會調用_do_rebu ild_instance函數，

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

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

4 故障

4.1 故障說明

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

4.2 故障恢復

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

4.3 重置云主機

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

4.4 修改數據庫

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

mysqldump -u nova -p nova > nova.sql

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

fqj