文章目录
[隐藏]

一、概述

最近用户的机房重启了多次,云平台也因此暂停,云平台自启动脚本的需求随之提上日程。Openstack云平台采用了HA架构部署,底层依赖的服务比较多,云平台重启时所做的工作比较多,故障场景也繁杂,这里先撰写一版比较简单的重启脚本,能够应对一般的服务器重启场景(断电重启、集群正常关闭),主要工作包括连通性检测、消息队列集群启动、Galera数据库集群启动、Openstack服务启动(主要由Pacemaker集群管理)、Ceph集群状态检测和Rest-api服务启动、虚拟机状态恢复、管理系统Web服务器启动等等。当然,实际故障场景比较多,相应的运维流程需要不断总结,本脚本也将会持续更新。

二、详细介绍

1、管理集群连通性检测

check-nodes-connectity.sh,这里主要检测控制节点和网络节点集群是否都已经全部正常启动,直到所有节点都能正常ping通后才进行云平台服务的启动,避免因其他节点比当前节点晚启动时而带来的服务启动错误。这里设置控制节点和网络节点存在一个节点无法连通时,该检测会直接退出。

2、消息队列集群启动

check-or-restart-rabbitmq-cluster.sh,当前主要检测Rabbitmq集群运行节点个数和Partitions的情况,三个控制节点全部加入集群并且无partitions的情况下,恢复集群正常。

3、Galera数据库集群的启动

Galera集群的恢复脚本check-or-recover-galera.sh,该脚本应对的场景已经在《Galera集群恢复的常见七种场景》和《MariaDB Galera集群自动恢复脚本》这两篇博客中详细介绍,这里不再赘述。

4、Openstack服务启动

  4.1 控制节点集群上服务启动

check-or-restart-controller-pcs-cluster.sh,启动pacemaker集群,随之会逐渐启动Haproxy、Mongodb、Redis和Openstack各服务,但所有服务全部启动需要等待一段时间,这里设置了最长等待时间为2min(20*6s),正常情况下,除了haproxy-clone资源存在Stopped状态,如下图,其余资源全部都是Started状态,这里就是通过检查Stopped状态的资源检查controller节点上openstack服务是否正常启动。

  4.2 网络节点集群上服务启动

check-or-restart-networker-pcs-cluster.sh,同控制节点Packemaker集群,不同的是,正常情况下,网络节点集群上所有资源都会正常启动,不存在Stopped状态的资源,如图:

  4.3 计算节点上服务启动

check-or-restart-compute-services.sh,其实计算节点上服务都是开始开机自启动的,这里也做了一遍启动操作。

5、Ceph集群状态检测及Rest-api服务启动

  5.1 Ceph统一存储集群状态检测

check-ceph-health.sh,检测ceph健康状态是否存在ERROR,如果存在ERROR状态,将无法通过检测。

  5.2 Ceph-rest-api服务启动

启动ceph-rest-api服务,这里是通过检测ceph-rest-api所绑定的端口进行检测服务是否启动,端口是通过ceph配置文件中配置项动态获取的。

6、恢复虚拟机的状态

resume_instances_status.sh,利用openstack CLI命令更新虚拟机的状态,主要更新之前状态为“运行中”现在状态为“关机”的虚拟机。

retrieve_instances_status.py,python脚本,获取管理系统中虚拟机原来的启动状态。

7、云管理系统Web服务器启动

start-cloud-portal.sh,启动tomcat,检测服务状态。

8、一键启动脚本

start-all.sh将上面操作全部汇总(这里使用了绝对路径),如果Rabbitmq、Galera、Pcs Cluster、Ceph等无法完成启动,将无法进行后续的VM状态恢复、管理Portal启动的操作。

9、设置开机自启动

Centos7.x设置开机执行脚本

三、其他说明

源码:https://github.com/zjmeixinyanzhi/CloudPlatformOperations/