關(guān)于openstack計算節(jié)點宕機時，vms自動撤離問題，官方在新版的openstack版本中，加入了新的項目專門解決該場景，但是判斷還是依然存在問題，虛機容易出現(xiàn)雙寫問題。

一、場景分析

1、計算節(jié)點宕機-共享存儲

openstack 后端對接比較流行的存儲，也是生產(chǎn)環(huán)境下使用最多的，便是ceph,或者glusterfs，目前接觸最多的是ceph，基于這種分布式共享存儲，
可友好支持虛機熱遷移，跨集群遷移等使用場景，但是宕機后，如果操作不當(dāng)，也會出現(xiàn)故障。

記得19年在當(dāng)前公司實習(xí)的時候，有一次凌晨，有臺openstack生產(chǎn)集群(使用ceph)的計算節(jié)點出現(xiàn)宕機，迷迷糊糊，起來人工執(zhí)行撤離操作（我們是有oncall告警電話的），但是宕機的計算節(jié)點忘記關(guān)機，導(dǎo)致撤離后的虛機在ceph存儲端出現(xiàn)兩個watcher，還是到早上上班時用戶反饋過來的，因沒有及時處理，造成二十來臺虛機系統(tǒng)盤數(shù)據(jù)盤均損壞，修了整整三天。。還有部分無法修復(fù)，想辦法彌補用戶。。。。。。。

回歸正題，過后我就在想，難道不能做自動撤離嗎？既然都能自動告警打電話了，那為啥不連貫起來，當(dāng)時想搞webhook，由于技術(shù)和時間人力成本問題，便暫時放棄了這個方向，其實生產(chǎn)環(huán)境是相當(dāng)復(fù)雜的，我第一次接觸生產(chǎn)環(huán)境時，在一個計算節(jié)點執(zhí)行了ip a 命令，輸出一堆網(wǎng)口(不包括vm的tab)，瞬間蒙圈，又加上各種路由，當(dāng)然現(xiàn)在看來在基礎(chǔ)不過。

說明下生產(chǎn)環(huán)境，存儲網(wǎng)絡(luò)、管理網(wǎng)絡(luò)、隧道網(wǎng)絡(luò)，一個計算節(jié)點上主要有這三種網(wǎng)絡(luò)，當(dāng)時使用的架構(gòu)可以說純?nèi)龑拥?，虛機存在跨leaf不通問題(這個原因?qū)е?，宕機撤離過于麻煩)，計算節(jié)點上是比較傳統(tǒng)的方案，兩個PF,各srov虛擬出兩個VF, 共4個vf，兩個交叉綁定，一個是存儲，一個是隧道，千兆做管理，這也是為啥執(zhí)行ip a后看到一堆網(wǎng)口。

這樣架構(gòu)的計算節(jié)點宕機，要想更快的恢復(fù)虛機，還是比較麻煩（因為歷史遺留原因，虛機的metadata中部分元數(shù)據(jù)缺失，就導(dǎo)致撤離后，虛機存在飄逸到其他leaf問題），而且還會出現(xiàn)大規(guī)格的虛機撤離失敗問題，需要重置狀態(tài)，再次撤離。。。。這就造成宕機恢復(fù)的時間變長。

2、自動撤離方案一

根據(jù)各種缺陷，最終在20年初 開發(fā)了一套撤離功能（仍需要人工介入），計算節(jié)點宕機后，人工在頁面上點擊撤離，這樣的撤離便非?？焖伲珳?zhǔn)。

快速： 首先是通過強改nova.instance數(shù)據(jù)庫，修改虛機所在的節(jié)點，來完成虛機撤離，這個已經(jīng)自動化了，只需要點擊一下，便批量修改虛機信息，同步更新port所在的host，之后硬重啟，完成撤離，整個執(zhí)行時間不超過5分鐘。

精準(zhǔn)： 精準(zhǔn)主要是 每個計算預(yù)留一臺同配置（如內(nèi)存大?。┑挠嬎愎?jié)點，宕機時，點擊撤離，直接選中改節(jié)點，所有受影響的虛機都會撤到該節(jié)點。

3、自動撤離方案二

第一種方案跑了一年，年終總結(jié)時，發(fā)現(xiàn)還是需要人工介入，凌晨宕機時，起來，打開電腦，連網(wǎng)等較為耗時，整個過程甚至超過10分鐘，覺得不完美。。。。
便開發(fā)了新的撤離方案，自動檢測宕機，自動撤離，主要是通過nova-compute 的state,以及計算節(jié)點網(wǎng)絡(luò)聯(lián)通性，異常計算節(jié)點上的虛機的聯(lián)通性來判斷是否真的宕機，事實上生產(chǎn)環(huán)境場景是非常復(fù)雜的，特別是一些不可抗力因素，如服務(wù)器磁盤背板異常，會導(dǎo)致系統(tǒng)夯死，但是不影響運行的虛機，或者docker夯死，內(nèi)存故障等。
這種方案也不用考慮存儲網(wǎng)絡(luò)聯(lián)通性、隧道、管理等，因為21年新集群換了架構(gòu)，三網(wǎng)合一，所以便定制般思考出如下解決方案，該程序整個撤離過程不超過2分鐘，期間包括自動給管理員、用戶發(fā)送短信，郵件，存儲宕機記錄等操作，以及虛機撤離恢復(fù)后的信息通知，如果撤離失敗再打電話給管理員。
該方案已經(jīng)穩(wěn)定在生產(chǎn)集群跑了1年多，從未出現(xiàn)過誤判問題，且執(zhí)行次數(shù)超過30次（生產(chǎn)集群服務(wù)器規(guī)模較大，且異地集群數(shù)量較多 ），現(xiàn)在分享給大家，即使大家是存儲、管理、計算分開的網(wǎng)絡(luò)，稍微思考改動也是支持的。

4、方案二 細節(jié)

直通車：github
mail: 1300042631@qq.com

代碼中的一些細節(jié)，因涉及敏感，我直接屏蔽了，如自動打電話接口，發(fā)短信接口，關(guān)機接口，這些都是非常容易實現(xiàn)的。
后面會分享。ironic對接ceph-iscsi-gw。及裸金屬云物理機 無盤啟動方案?？梢越鉀Q云物理機橫向擴展及交付效率，特別是數(shù)據(jù)盤（本地磁盤）改配，因涉及到價格問題，每改動一次就很耗人力。

在這里插入圖片描述

### auto_check_compute_down
#### author: mmwei3
#### date: 2021/12/12

#### Instructions
```angular2html
This is openstack compute node ha!
func: 
1. auto check compute nodes health state, down or up, 

2. if check first down and Compute Status is disable:
   The compute node management network detected for fping tools.
       Start check vms for the down state compute node:
           if compute nodes management network and vms is Unreachable:
              Start an evacuation task for all active status vms on the compute node.
              And auto Send SMS and email notifications to all affected users about vms downtime
           else :
               Do nothing

Install

1. Configuration cmpha.conf

[ser]
OS_TENANT_NAME=admin
OS_PROJECT_NAME=admin
OS_USERNAME=admin
OS_PASSWORD=
OS_AUTH_URL=http://x.x.x.x:35357/v3
OS_DEFAULT_DOMAIN=Default
INTERVAL=20  # Interval of each probe

2. Run Docker
docker run -d --tty=true \
--net=host --restart=always \
-v /etc/localtime:/etc/localtime:ro \
--name=auto_evacuate  pwxwmm/openstack_compute_evacuate:v1.0.0


3. Or another way to do it

Use linux systemctl managerment cmpha service
configuration cmpha.service

Usage: /etc/init.d/$DAEMON_NAME {start|stop|restart|status}
# systemctl start cmpha.service
# systemctl stop cmpha.service
# ststemctl restart cmpha.service

文章來源地址http://www.zghlxwxcb.cn/news/detail-496848.html

# 1) 首先auto_evacuate容器運行后，相關(guān)的日志可參考 /var/log/cmpha.log
# 2）檢測流程：
# ① 第一步先檢測nova_compute服務(wù)的狀態(tài)，如果該服務(wù)處于維護(disable)狀態(tài)，則忽略，不會對其進行監(jiān)控
# ② 第二步檢測處于為enable的nova_compute的服務(wù)狀態(tài)，如果狀態(tài)為up,則仍會忽略，不會對其監(jiān)控
# ③ 第三步若檢測nova_compute狀態(tài)為down，則獲取其節(jié)點上的所有虛機的IP以及宿主機的管理IP
# ④ 第四步通過fping操作，檢測其獲取到的IP是否全部不通，如果有一個alive狀態(tài)的，則忽略，不會對其監(jiān)控
# ⑤ 第五步若發(fā)現(xiàn)獲取到的ip均不通，則判斷該機器未宕機狀態(tài)，將該機器禁用(disable)，將預(yù)留節(jié)點enable
# ⑥ 第六步通過ipmitool接口關(guān)閉宿主機
# ⑦ 第七步發(fā)送宕機短信、郵件至虛機用戶、使用人，訊飛云管理員，并將宕機信息記錄。
# ⑧ 第八步開始自動撤離，確保每臺虛機均被執(zhí)行了撤離操作(僅對狀態(tài)為ACTIVE和ERROR的虛機)
# ⑨ 第九步判斷撤離是否成功，通過判斷撤離后的虛機當(dāng)前所在的節(jié)點host是否和宕機前的host一致：
#    若一致，則自動撤離失敗，通過發(fā)短信和打電話告知管理員人工介入處理;
#    若不一致，則自動撤離成功，通過發(fā)短信告知管理員撤離成功。

到了這里，關(guān)于OpenStack計算節(jié)點宕機自動撤離的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！