OpenStack计算节点宕机自动撤离

节点宕机自动撤离"/>

OpenStack计算节点宕机自动撤离

关于openstack计算节点宕机时，vms自动撤离问题，官方在新版的openstack版本中，加入了新的项目专门解决该场景，但是判断还是依然存在问题，虚机容易出现双写问题。

一、场景分析

1、计算节点宕机-共享存储

openstack 后端对接比较流行的存储，也是生产环境下使用最多的，便是ceph,或者glusterfs，目前接触最多的是ceph，基于这种分布式共享存储，
可友好支持虚机热迁移，跨集群迁移等使用场景，但是宕机后，如果操作不当，也会出现故障。

记得19年在当前公司实习的时候，有一次凌晨，有台openstack生产集群(使用ceph)的计算节点出现宕机，迷迷糊糊，起来人工执行撤离操作（我们是有oncall告警电话的），但是宕机的计算节点忘记关机，导致撤离后的虚机在ceph存储端出现两个watcher，还是到早上上班时用户反馈过来的，因没有及时处理，造成二十来台虚机系统盘数据盘均损坏，修了整整三天。。还有部分无法修复，想办法弥补用户。。。。。。。

回归正题，过后我就在想，难道不能做自动撤离吗？既然都能自动告警打电话了，那为啥不连贯起来，当时想搞webhook，由于技术和时间人力成本问题，便暂时放弃了这个方向，其实生产环境是相当复杂的，我第一次接触生产环境时，在一个计算节点执行了ip a 命令，输出一堆网口(不包括vm的tab)，瞬间蒙圈，又加上各种路由，当然现在看来在基础不过。

说明下生产环境，存储网络、管理网络、隧道网络，一个计算节点上主要有这三种网络，当时使用的架构可以说纯三层的，虚机存在跨leaf不通问题(这个原因导致，宕机撤离过于麻烦)，计算节点上是比较传统的方案，两个PF,各srov虚拟出两个VF, 共4个vf，两个交叉绑定，一个是存储，一个是隧道，千兆做管理，这也是为啥执行ip a后看到一堆网口。

这样架构的计算节点宕机，要想更快的恢复虚机，还是比较麻烦（因为历史遗留原因，虚机的metadata中部分元数据缺失，就导致撤离后，虚机存在飘逸到其他leaf问题），而且还会出现大规格的虚机撤离失败问题，需要重置状态，再次撤离。。。。这就造成宕机恢复的时间变长。

2、自动撤离方案一

根据各种缺陷，最终在20年初 开发了一套撤离功能（仍需要人工介入），计算节点宕机后，人工在页面上点击撤离，这样的撤离便非常快速，精准。

快速： 首先是通过强改nova.instance数据库，修改虚机所在的节点，来完成虚机撤离，这个已经自动化了，只需要点击一下，便批量修改虚机信息，同步更新port所在的host，之后硬重启，完成撤离，整个执行时间不超过5分钟。

精准： 精准主要是 每个计算预留一台同配置（如内存大小）的计算节点，宕机时，点击撤离，直接选中改节点，所有受影响的虚机都会撤到该节点。

3、自动撤离方案二

第一种方案跑了一年，年终总结时，发现还是需要人工介入，凌晨宕机时，起来，打开电脑，连网等较为耗时，整个过程甚至超过10分钟，觉得不完美。。。。
便开发了新的撤离方案，自动检测宕机，自动撤离，主要是通过nova-compute 的state,以及计算节点网络联通性，异常计算节点上的虚机的联通性来判断是否真的宕机，事实上生产环境场景是非常复杂的，特别是一些不可抗力因素，如服务器磁盘背板异常，会导致系统夯死，但是不影响运行的虚机，或者docker夯死，内存故障等。
这种方案也不用考虑存储网络联通性、隧道、管理等，因为21年新集群换了架构，三网合一，所以便定制般思考出如下解决方案，该程序整个撤离过程不超过2分钟，期间包括自动给管理员、用户发送短信，邮件，存储宕机记录等操作，以及虚机撤离恢复后的信息通知，如果撤离失败再打电话给管理员。
该方案已经稳定在生产集群跑了1年多，从未出现过误判问题，且执行次数超过30次（生产集群服务器规模较大，且异地集群数量较多 ），现在分享给大家，即使大家是存储、管理、计算分开的网络，稍微思考改动也是支持的。

4、方案二 细节

直通车：github
mail: 1300042631@qq

代码中的一些细节，因涉及敏感，我直接屏蔽了，如自动打电话接口，发短信接口，关机接口，这些都是非常容易实现的。
后面会分享。ironic对接ceph-iscsi-gw。及裸金属云物理机 无盘启动方案。可以解决云物理机横向扩展及交付效率，特别是数据盘（本地磁盘）改配，因涉及到价格问题，每改动一次就很耗人力。

在这里插入图片描述

### 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 downtimeelse :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 probe2. 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.03. Or another way to do itUse linux systemctl managerment cmpha service
configuration cmpha.serviceUsage: /etc/init.d/$DAEMON_NAME {start|stop|restart|status}
# systemctl start cmpha.service
# systemctl stop cmpha.service
# ststemctl restart cmpha.service

# 1) 首先auto_evacuate容器运行后，相关的日志可参考 /var/log/cmpha.log
# 2）检测流程：
# ① 第一步先检测nova_compute服务的状态，如果该服务处于维护(disable)状态，则忽略，不会对其进行监控
# ② 第二步检测处于为enable的nova_compute的服务状态，如果状态为up,则仍会忽略，不会对其监控
# ③ 第三步若检测nova_compute状态为down，则获取其节点上的所有虚机的IP以及宿主机的管理IP
# ④ 第四步通过fping操作，检测其获取到的IP是否全部不通，如果有一个alive状态的，则忽略，不会对其监控
# ⑤ 第五步若发现获取到的ip均不通，则判断该机器未宕机状态，将该机器禁用(disable)，将预留节点enable
# ⑥ 第六步通过ipmitool接口关闭宿主机
# ⑦ 第七步发送宕机短信、邮件至虚机用户、使用人，讯飞云管理员，并将宕机信息记录。
# ⑧ 第八步开始自动撤离，确保每台虚机均被执行了撤离操作(仅对状态为ACTIVE和ERROR的虚机)
# ⑨ 第九步判断撤离是否成功，通过判断撤离后的虚机当前所在的节点host是否和宕机前的host一致：
#    若一致，则自动撤离失败，通过发短信和打电话告知管理员人工介入处理;
#    若不一致，则自动撤离成功，通过发短信告知管理员撤离成功。