OpenStack已经成为管理企业数据中心的首选平台，因为它能够提供基础架构即服务环境，并在私有云（内部部署）部署的基础上运行可扩展的高可用性（HA）应用程序。在计算术语中，可用性是指特定服务在给定时间段内在功能上可用的时间。随着组织在私有云上运行越来越多的关键系统，对可靠，高度可用的基础架构的需求比以往任何时候都大。VM高可用性允许在云中运行时获得最大的正常运行时间，同时保护用户免受基础架构的任何意外停机。

到目前为止OpenStack社区并没有一个完整的虚拟机HA解决方案。起初社区认为虚拟机的HA不是云平台层次的特性，不应该在云平台层面来实现，虚拟机的HA应该通过应用层面的HA来实现。但是很多应用不是默认做了应用层面的HA，OpenStack又缺少这样一个重要的特性。所以很多公司针对虚拟机的HA提出了自己的解决方案。Masakari是当前解决方案之一。

从广义上讲，Cloud Native应用程序和传统应用程序都依赖于高可用性来维持最长的正常运行时间。但是，虽然Cloud Native应用程序旨在通过自动扩展到区域内的另一台服务器来容忍可用区域的故障，但传统应用程序无法容忍此类基础架构故障，因为它们假设底层基础架构完全正常运行。 OpenStackMasakari通过从计算主机故障事件中自动恢复VM，为这些应用程序提供VM高可用性。

通过结合Corosync和Pacemaker，OpenStack Masakari创建了一个服务器集群，可以检测和报告集群中主机的故障。在此方案中，云管理员需要使用Corosync和Pacemaker部署，监控和管理集群。云管理员还需要部署和监控Masakari的监控服务，该服务在发生主机故障时查询Corosync并触发VM疏散。检测到主机故障后，如果必须删除主机，管理员需要确保主机再次运行正常。

一、Masakari介绍

Masakaris是日本电信NTT的开源项目。当前masakari已经成为了Openstack的一个独立项目，该项目就是是专门做openstack compute node ha的。

masakari的日文是まさかり，斧头的意思。准确说是板斧。就是周星驰电影斧头帮用的板斧。不知道，项目的发起人，几个日本人是否受此影响。

Masakari通过自动恢复失败的实例为OpenStack云提供实例高可用性服务。目前，Masakari可以从故障事件中恢复基于KVM的虚拟机（VM），例如VM进程关闭，配置进程关闭和nova-compute主机故障。Masakari还提供API服务来管理和控制自动救援机制。其主要的工作特性如下：

1）虚拟机进程挂了→通过虚拟机的API关闭和启动虚拟机。

2）虚拟化进程挂了->通过Nova-computeAPI设置Nova-compute服务为down状态。

3） Nova-compute进程挂了->疏散计算节点上的虚拟机。

二、Masakari的架构与原理

Masakari由controller服务与monitor服务组成，controller服务运行在控制节点，monitor服务则运行在计算节点。

masakari-api: 运行在控制节，提供服务api。通过RPC它将发送到的处理API请求交由masakari-engine处理。
masakari-engine: 运行在控制节点，通过以异步方式执行恢复工作流来处理收到的masakari-api发送的通知。
masakari-instancemonitor : 运行在计算节点，属于masakari-monitor，检测虚拟机进程是否挂掉了。
masakari-processmonitor : 运行在计算节点，属于masakari-monitor，检测Nova-compute是否挂了。
masakari-hostmonitor : 运行在计算节点，属于masakari-monitor，检测计算节点是否挂了。
masakari-introspectiveinstancemonitor：运行在计算节点，属于masakari-monitor，当虚拟机安装了qemu-ga，可用于检测以及启动回复故障进程或服务。
pacemaker-remote：运行在计算节点，解决corosync/pacemaker的16个节点的限制。

Masakari与masakari-monitors和Pacemaker一起使用时，提供检测虚拟机或者整个计算节点的故障，并尝试将其重新恢复。Masakari服务提供了一个api和执行程序，它可以对失败的通知作出反应。Masakari-monitor，顾名思义，可以检测到失败并告诉masakari。它用于检测故障的一种机制是pacemaker，当pacemaker报告同伴计算节点发生故障时，masakari-monitor会向Masakari进行报告。

Masakari还提供了另外两种恢复机制。一种机制用于检测单个虚拟机的故障并在原节点重新启动该虚拟机。最后，另外一种机制用于在操作系统进程停止时然后重新启动该进程，本文未涵盖此机制，并且已配置为禁用。

三． Pacemaker-remote介绍

pacemaker-remote服务允许将没有在corosync中运行的节点整合到该集群，并让该集群如管理真正集群节点一样管理这些资源。就是说Pacemaker集群现在可以管理虚拟环境以及处于虚拟环境中的资源，而无需该虚拟环境真的在pacemaker或corosync中运行。

为何需要pacemaker-remote了？

如上所述，Masakari-monitor通过查询本地运行的集群软件来检测计算节点故障。一个hacluster高可用集群，将会部署corosync和pacemaker服务，该集群往往是一个比较小的集群环境。遗憾的是，corosync/pacemaker的设计目的不是为了扩展超过16个节点。但是一个私有云环境无法去控制并且去限制为16个计算节点，这在还不包括控制节点的情况下。

这就是pacemaker-remote的用武之地。pacemaker-remote可以作为pacemaker/corosync可用集群的延伸，在这种情况下，corosync未安装在远程remote节点上，虽然pacemaker-remote节点不参与集群XML的定义，但是在节点之间依然是保持一致的。

pacemaker-remote实际上不运行任何资源，它们仅用作查询pacemaker/corosync群集中所有节点的状态。

不幸的是由于Bug原因，当前版本的masakari-monitors无法正确查询到pacemaker-remote节点的状态（只能显示pacemaker-remote状态为none）。补丁已经提出了。该补丁目前应用于Ubuntu系统上的OpenStack Stein版本中的masakari-monitors软件包。预计在下一个OpenStack版本可完全修复。

四、STONITH介绍

STONITH 是Shoot-The-Other-Node-In-The-Head 的首字母缩写，该工具可保护数据，以防其被恶意节点或并行访问破坏。

如果某个节点没有反应，并不代表没有数据访问。能够100% 确定数据安全的唯一方法是使用 SNOITH 隔离该节点，这样我们才能确定在允许从另一个节点访问数据前，该节点已确实离线。

SNOITH 还可在无法停止集群的服务时起作用。在这种情况下，集群使用STONITH 强制整个节点离线，以便在其他位置安全地启动该服务

对于要故障转移到另一个计算主机的guest虚拟机，它必须使用某种类型的共享存储，该共享存储可以是ceph，nfs，glusterfs等。因此，必须考虑当计算节点已丢失（并未宕机），管理网络不可达，但是计算节点的业务网络正常，存储网络仍可以继续访问共享存储的情况。在这种情况下，正常的Masakari-monitor服务发现故障计算节点后通知立刻masakari-api服务。然后触发masakari-engine通过nova发起该客户虚拟机的故障转移。假设nova确认计算节点已失联，它将尝试将其疏散到其他正常的节点上。此时原计算节点上依然会存在旧客户虚拟机，此时会有两个客户虚拟机都试图写入相同的后端共享存储，这可能会导致数据的损坏。

解决方案是在pacemaker/corosync集群中启用stonith。当群集检测到某个节点已失联时，它会运行一个stonith插件来关闭计算节点。Masakari推荐使用IPMI的方式去关闭计算节点。这样避免了后端同样的存储资源双写的问题。

五、Masakari控制节点安装

1. Masakari-api与Masakari-engine安装

1）创建masakari用户

openstack user create --password-promptmasakari
(give password as masakari)

2）将管理员角色添加到masakari用户

openstack role add --project service--user masakari admin

3）创建新服务

openstack service create --name masakari--description “masakari high availability” instance-ha

4）为masakari服务创建endpoint

openstack endpoint create --regionRegionOne masakari public http://controller:15868/v1/%(tenant_id)s
openstack endpoint create --regionRegionOne masakari admin http://controller:15868/v1/%(tenant_id)s
openstack endpoint create --regionRegionOne masakari internal http://controller:15868/v1/%(tenant_id)s

5）下载对应版本的Masakari安装包

git clone -b stable/steinhttps://github.com/openstack/masakari.git

6）从masakari运行setup.py

sudo python setup.py install

7）创建对应目录

useradd -r -d/var/lib/masakari -c "Masakari instance-ha" -m -s /sbin/nologinmasakari
mkdir -pv /etc/masakari
mkdir -pv /var/log/masakari
chown masakari:masakari -R/var/log/masakari
chown masakari:masakari -R /etc/masakari

8）生成配置文件模板

tox -egenconfig

9）复制配置文件

从目录masakari/etc/复制配置文件masakari.conf，api-paste.ini，policy.json到/etc/masakari文件夹。

10）生成system配置文件

本次以root用户运行，实际生产环境建议使用masakari用户运行。

cat/usr/lib/systemd/system/masakari-api.service
[Unit]
Description=Masakari Api
 
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/bin/masakari-api
[Install]
WantedBy=multi-user.target
 
Cat /usr/lib/systemd/system/masakari-engine.service
[Unit]
Description=Masakari engine
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/bin/masakari-engine
[Install]
WantedBy=multi-user.target

11）修改配置文件

cat /etc/masakari/masakari.conf 
[DEFAULT]
auth_strategy = keystone
masakari_topic = ha_engine
notification_driver = taskflow_driver
nova_catalog_admin_info = compute:nova:adminURL
os_region_name = RegionOne
os_privileged_user_name = masakari
os_privileged_user_password = tyun123
os_privileged_user_tenant = services
os_privileged_user_auth_url = http://10.0.5.210:35357
os_user_domain_name = default
os_project_domain_name = default
periodic_enable = true
use_ssl = false
masakari_api_listen = 10.0.5.201
masakari_api_listen_port = 15868
masakari_api_workers = 3
log_dir = /var/log/masakari
transport_url=rabbit://guest:guest@controller201:5672,guest:guest@controller202:5672,guest:guest@controller203:5672
rpc_backend = rabbit
control_exchange = openstack
api_paste_config = /etc/masakari/api-paste.ini
[database]
connection = mysql+pymysql://masakari:tyun123@10.0.5.210/masakari?charset=utf8
[host_failure]
evacuate_all_instances = True
ignore_instances_in_error_state = false
add_reserved_host_to_aggregate = false
[instance_failure]
process_all_instances = true
[keystone_authtoken]
memcache_security_strategy = ENCRYPT
memcache_secret_key = I2Ws13eKT0cQIJJQzX2AtI2aQW6x4vSQdmsqCuBf
memcached_servers = controller201:11211,controller202:11211,controller203:11211
www_authenticate_uri = http://10.0.5.210:5000
auth_url=http://10.0.5.210:35357
auth_uri=http://10.0.5.210:5000
auth_type = password
project_domain_id = default
user_domain_id = default
project_name = service
username = masakari
password = tyun123
user_domain_name=Default
project_domain_name=Default
auth_version = 3
service_token_roles = service
[oslo_messaging_notifications]
transport_url=rabbit://guest:guest@controller201:5672,guest:guest@controller202:5672,guest:guest@controller203:5672

12）启动masakari

chown masakari:masakari -R/var/log/masakari
chown masakari:masakari -R /etc/masakari
systemctl start masakar-api masakari-engine
systemctl enable masakar-api masakari-engine

2. python-masakariclient安装

1）下载python-masakariclient

https://github.com/openstack/python-masakariclient.git

2）安装依赖

cd python-masakariclient/
pip install -r requirements.txt

3）python-masakariclient安装

python setup.py install

3. masakari-dashboard安装

1）下载masakari-dashboard

git clonehttps://github.com/openstack/masakari-dashboard

2）Masakari安装

cd masakari-dashboard && pipinstall -r requirements.txt python setup.py install

3）复制dashboard模块文件

cp../masakari-dashboard/masakaridashboard/local/enabled/_50_masakaridashboard.pyopenstack_dashboard/local/enabled
cp../masakari-dashboard/masakaridashboard/local/local_settings.d/_50_masakari.pyopenstack_dashboard/local/local_settings.d
cp../masakari-dashboard/masakaridashboard/conf/masakari_policy.json/etc/openstack-dashboard

4）重启httpd服务

systemctl restart httpd

六、Masakari计算节点安装

1. pacemaker-remote安装

1）安装pacemaker-remote

yum install pacemaker-remote resource-agents fence-agents-all pcsd

2）pacemaker authkey复制

将控制节点的/etc/pacemaker/authkey复制到计算节点/etc/pacemaker/authkey。

3）启动pacemaker-remote服务

systemctl startpcsd 
Systemctl enable pcsd

4）克隆masakari使用：

$ git clonehttps://github.com/openstack/masakari-monitors.git

5）创建相应的目录

useradd -r -d /var/lib/masakarimonitors-c "Masakari instance-ha" -m -s /sbin/nologin masakarimonitors
mkdir -pv /etc/masakarimonitors
mkdir -pv /var/log/masakarimonitors
chown masakarimonitors:masakarimonitors -R /etc/masakarimonitors
chown masakarimonitors:masakarimonitors -R /var/log/masakarimonitors

6）从masakari-monitors运行setup.py：

sudo python setup.py install

当前版本的masakari-monitors无法正确查询到pacemaker-remote节点的状态（只能显示pacemaker-remote状态为none）。补丁已经提出了。该补丁目前应用于Ubuntu系统上的OpenStack Stein版本中的masakari-monitors软件包。如果计算节点使用的是centos7的话，可以把ubuntu 软件包中/usr/lib/python3/dist-packages/masakarimonitors包替换到centos7的/usr/lib/python2.7/site-packages/masakarimonitors。虽然一个python2.7一个是Python3的，但是替换后完全可用。

7）配置文件生成

将masakarimonitors.conf和process_list.yaml文件从masakari-monitors/etc/复制到/etc/masakarimonitors文件夹，并对masakarimonitors.conf和process_list.yaml文件进行必要的更改。要生成示例masakarimonitors.conf文件，请从masakari-monitors目录的顶级运行以下命令：

tox -egenconfig

8）要运行masakari-processmonitor，masakari-hostmonitor和masakari-instancemonitor只需使用以下二进制文件：

masakari-processmonitor
masakari-hostmonitor
masakari-instancemonitor

9）生成system配置文件本次以root用户运行，实际生产环境建议使用masakari用户运行。

cat/usr/lib/systemd/system/masakari-hostmonitor.service
[Unit]
Description=Masakari Hostmonitor
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/bin/masakari-hostmonitor
[Install]
WantedBy=multi-user.target
 
cat /usr/lib/systemd/system/masakari-instancemonitor.service
[Unit]
Description=Masakari Instancemonitor
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/bin/masakari-instancemonitor
[Install]
WantedBy=multi-user.target
# /usr/lib/systemd/system/masakari-processmonitor.service
[Unit]
Description=Masakari Processmonitor
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/bin/masakari-processmonitor
[Install]
WantedBy=multi-user.target

10）Masakari-monitor相信配置文件

（1）cat/etc/masakarimonitors/masakarimonitors.conf

[DEFAULT]
host = compute205
log_dir = /var/log/masakarimonitors
[api]
region = RegionOne
api_version = v1
api_interface = public
www_authenticate_uri = http://10.0.5.210:5000
auth_url = http://10.0.5.210:35357
auth_uri = http://10.0.5.210:5000
auth_type = password
domain_name=Default
project_domain_id = default
user_domain_id = default
project_name = service
username = masakari
password = tyun123
project_domain_name = Default
user_domain_name = Default
[host]
monitoring_driver = default
monitoring_interval = 120
disable_ipmi_check = False
restrict_to_remotes = True
corosync_multicast_interfaces = eth0
corosync_multicast_ports = 5405
[process]
process_list_path = /etc/masakarimonitors/process_list.yaml

（2）cat /etc/masakarimonitors/hostmonitor.conf

MONITOR_INTERVAL=120
NOTICE_TIMEOUT=30
NOTICE_RETRY_COUNT=3
NOTICE_RETRY_INTERVAL=3
STONITH_WAIT=30
STONITH_TYPE=ipmi
MAX_CHILD_PROCESS=3
TCPDUMP_TIMEOUT=10
IPMI_TIMEOUT=5
IPMI_RETRY_MAX=3
IPMI_RETRY_INTERVAL=30
HA_CONF="/etc/corosync/corosync.conf"
LOG_LEVEL="debug"
DOMAIN="Default"
ADMIN_USER="masakari"
ADMIN_PASS="tyun123"
PROJECT="service"
REGION="RegionOne"
AUTH_URL="http://10.0.5.210:5000/"
IGNORE_RESOURCE_GROUP_NAME_PATTERN="stonith"

（3）cat /etc/masakarimonitors/proc.list

01,/usr/sbin/libvirtd,sudo service libvirtd start,sudo servicelibvirtd start,,,,
02,/usr/bin/python /usr/bin/masakari-instancemonitor,sudo servicemasakari-instancemonitor start,sudo service masakari-instancemonitor start,,,,

（4）cat/etc/masakarimonitors/processmonitor.conf

PROCESS_CHECK_INTERVAL=5
PROCESS_REBOOT_RETRY=3
REBOOT_INTERVAL=5
MASAKARI_API_SEND_TIMEOUT=10
MASAKARI_API_SEND_RETRY=12
MASAKARI_API_SEND_DELAY=10
LOG_LEVEL="debug"
DOMAIN="Default"
PROJECT="service"
ADMIN_USER="masakari"
ADMIN_PASS="tyun123"
AUTH_URL="http://10.0.5.210:5000/"
REGION="RegionOne"

（5）cat/etc/masakarimonitors/process_list.yaml

# libvirt-bin
process_name: /usr/sbin/libvirtd
start_command: systemctl start libvirtd
pre_start_command:
post_start_command:
restart_command: systemctl restart libvirtd
pre_restart_command:
post_restart_command:
run_as_root: True
-
# nova-compute
process_name: /usr/bin/nova-compute
start_command: systemctl start openstack-nova-compute
pre_start_command:
post_start_command:
restart_command: systemctl restart openstack-nova-compute
pre_restart_command:
post_restart_command:
run_as_root: True
-
# instancemonitor
process_name: /usr/bin/python /usr/bin/masakari-instancemonitor
start_command: systemctl start masakari-instancemonitor
pre_start_command:
post_start_command:
restart_command: systemctl restart masakari-instancemonitor
pre_restart_command:
post_restart_command:
run_as_root: True
-
# hostmonitor
process_name: /usr/bin/python /usr/bin/masakari-hostmonitor
start_command: systemctl start masakari-hostmonitor
pre_start_command:
post_start_command:
restart_command: systemctl restart masakari-hostmonitor
pre_restart_command:
post_restart_command:
run_as_root: True
-
# sshd
process_name: /usr/sbin/sshd
start_command: systemctl start sshd
pre_start_command:
post_start_command:
restart_command: systemctl restart sshd
pre_restart_command:
post_restart_command:
run_as_root: True

11）启动masakari-monitor服务

systemctl start masakari-hostmonitor.service masakari-instancemonitor.servicemasakari-processmonitor.service
systemctl enable masakari-hostmonitor.servicemasakari-instancemonitor.service masakari-processmonitor.service

七、Pacemaker 配置

Masakari依赖于pacemaker，所以需要提前安装好pacemaker相关服务，配置好集群。Pacemaker是OpenStack官方推荐的资源管理工具，群集基础架构利用Coresync提供的信息和成员管理功能来检测和恢复云端资源级别的故障，达到集群高可用性。Corosync在云端环境中提供集群通讯，主要负责为控制节点提供传递心跳信息的作用。

具体步骤如下：

1）在三个节点上安装以下安装包

yum install -y lvm2 cifs-utils quota psmisc
yum install -y pcs pacemaker corosync fence-agents-all resource-agentscrmsh

2）在计算节点上安装以下安装包

yum install -y pacemaker-remote pcsd fence-agents-all resource-agents

3）在所有节点上设置pcs服务开机启动

systemctl enable pcsd.service
systemctl start pcsd.service

4）在三个节点上设置hacluster用户密码

passwd hacluster 
New password ####设置密码为yjscloud
Retry new password
pcs cluster auth controller201 controller202 controller203 compute205 compute206 compute207

5）创建并启动名为my_cluster的集群，其中controller201，controller202，controller203为集群成员

pcs cluster setup --start --name openstack controller1 controller2controller3

6）置集群自启动

pcs cluster enable --all

7）查看集群状态

pcs cluster status
ps aux | grep pacemaker

8）检验Corosync的安装及当前corosync状态：

corosync-cfgtool -s
corosync-cmapctl| grep members
pcs status corosync

9）检查配置是否正确（假若没有输出任何则配置正确）：

crm_verify -L -V

10）错误可暂时禁用STONITH：

pcs property set stonith-enabled=false

11）无法仲裁时候，选择忽略：

pcs property set no-quorum-policy=ignore

12）添加pacemaker-remote 节点

pcs cluster node add-remote compute205compute205
pcs cluster node add-remote compute206compute206
pcs cluster node add-remote compute207compute207

13）如果OpenStack 使用pacemaker作为高可用方式，可以设置如下：

# 标注节点属性，区分计算节点于控制节点
pcs property set --node controller201node_role=controller
pcs property set --node controller202node_role=controller
pcs property set --node controller203node_role=controller
pcs property set --node compute205node_role=compute
pcs property set --node compute206node_role=compute
pcs property set --node compute206node_role=compute
# 创建VIP资源
pcs resource create vipocf:heartbeat:IPaddr2 ip=10.0.5.210 cidr_netmask=24 nic=eth0 op monitorinterval=30s
# 绑定VIP到controller节点
pcs constraint location vip ruleresource-discovery=exclusive score=0
node_role eq controller --force
# 创建haproxy资源
pcs resource create lb-haproxysystemd:haproxy --clone
# 绑定haproxy到controller节点
pcs constraint location lb-haproxy-clonerule resource-discovery=exclusive score=0 node_role eq controller --force
# 设置资源绑定到同一节点与设置启动顺序
pcs constraint colocation addlb-haproxy-clone with vip
pcs constraint order start vip thenlb-haproxy-clone kind=Optional

14）配置基于IPMI的stonith

本处的stonithaction为off关机，默认为reboot。
pcs property set stonith-enabled=true
pcs stonith create ipmi-fence-compute205fence_ipmilan lanplus='true' pcmk_host_list='compute205'pcmk_host_check='static-list'
pcmk_off_action=off pcmk_reboot_action=offipaddr='10.0.5.18' ipport=15205 login='admin' passwd='password' lanplus=truepower_wait=4 op monitor interval=60s
 
pcs stonith create ipmi-fence-compute206fence_ipmilan lanplus='true' pcmk_host_list='compute206'pcmk_host_check='static-list'
pcmk_off_action=off pcmk_reboot_action=offipaddr='10.0.5.18' ipport=15206 login='admin' passwd='password' lanplus=truepower_wait=4 op monitor interval=60s
 
pcs stonith create ipmi-fence-compute207fence_ipmilan lanplus='true' pcmk_host_list='compute207'pcmk_host_check='static-list'
pcmk_off_action=off pcmk_reboot_action=offipaddr='10.0.5.18' ipport=15207 login='admin' passwd='password' lanplus=truepower_wait=4 op monitor interval=60s

15）pcs 状态查看

八、Masakari配置与测试

在Masakari中，计算节点被分组为故障转移segment。如果发生故障，客户将被移动到同一segment内的其他节点上。选择哪个计算节点来容纳撤离的客人，取决于该段的恢复方法。

Masakari主机的恢复方法有多种:

auto：Nova选择新的计算主机，用于疏散在失败的计算主机上运行的实例
reserved_host：segment中配置的其中一个保留主机将用于疏散在失败的计算主机上运行的实例
auto_priority：首先它会尝试'自动'恢复方法，如果它失败了，那么它会尝试使用'reserved_host'恢复方法。
rh_priority：它与'auto_priority'恢复方法完全相反。

请注意：Masakari目前不使用服务类型，但它是必填字段，因此默认值设置为'compute'且无法更改。

以下以自动恢复为列子，通过自动恢复，guest虚拟机将重定位到同一段中的任何可用节点。此方法的问题在于无法保证资源可用于容纳来自失败的计算节点的guest虚拟机。

要配置一组计算主机以进行自动恢复，请首先创建一个恢复方法设置为auto的segment：

openstack segment createsegment1 auto COMPUTE
+-----------------+--------------------------------------+
| Field | Value |
+-----------------+--------------------------------------+
| created_at |2019-07-24T01:45:04.000000 |
| updated_at | None |
| uuid | 0f57ae64-88cc-4193-9aec-1c54c59b2bbd|
| name |segment1 |
| description | None |
| id | 1 |
| service_type |COMPUTE |
| recovery_method | auto |
+-----------------+--------------------------------------+

接下来，需要将计算节点添加到segment中，名称为计算节点的名称：

openstack segment host create compute205 COMPUTE SSH691b8ef3-7481-48b2-afb6-908a98c8a768 
+---------------------+--------------------------------------+
| Field |Value |
+---------------------+--------------------------------------+
| created_at |2019-07-25T12:18:58.000000 |
| updated_at |None |
| uuid |e1fd288c-a545-456e-81d5-64927b8cea04 |
| name |compute205 |
| type |COMPUTE |
| control_attributes |SSH |
| reserved |False |
| on_maintenance |False |
| failover_segment_id | 0f57ae64-88cc-4193-9aec-1c54c59b2bbd |
+---------------------+--------------------------------------+

其他的计算节点安装上述的命令加入到segment中去。

如果使用reserved_host恢复方法，请确保在nova中禁用预留的主机，以便它可用于故障转移。

1. 测试实例恢复

最简单的测试方案是单个实例的恢复。值得注意的是，Masakari很容易擅长检测到故意关机，如果检测到的是正常的实例生命周期活动那就无能为力了。因此，为了测试masakari，需要以无序的方式关闭进程，在这种情况下，向客户qemu进程发送SIGKILL：

[root@compute206 ~]# pgrep -fqemu-kvm
7571

客户机被kill，然后重新启动。检查masakari实例监视器日志以查看发生的情况：

日志显示实例监视器发现guest虚拟机发生故障并通知masakari api服务 - 请注意，实例监视器不会启动guest虚拟机本身。由masakari-engine负责启动恢复虚拟机。

在Masakaridashboard可以看到详细的恢复日志。

2. 测试计算节点故障，主机恢复

如果计算节点发生故障，pacemaker应该发现这一点。Masakari host-monitor定期检查由pacemaker报告的节点状态，并且如果发生故障，则向masakari api发送通知。Pacemaker应该运行stonith资源来关闭节点，然后masakari将在计算节点上运行的guest虚拟机移动到另一个可用的物理节点。

首先要检查guest虚拟机运行的计算书节点，确认当前IPMI电源状态，虚拟机状态：

[root@controller201 ~(keystone_admin)]# openstack server show VM-1-c OS-EXT-SRV-ATTR:host -f value
compute206
[root@controller201 ~(keystone_admin)]# fence_ipmilan -P -A password-a 10.0.5.18 -p password -l admin -u 15206 -o status
Status: ON
[root@compute206 ~]# virsh list --all
Id Name State
----------------------------------------------------
 1 instance-00000059 running

关闭节点compute206网络eth0网卡，再次确认guest虚拟机状态。

[root@controller201 ~(keystone_admin)]#openstack server show VM-1 -c OS-EXT-SRV-ATTR:host -f value
compute207
[root@controller201 ~(keystone_admin)]#fence_ipmilan -P -A password -a 10.0.5.18 -p password -l admin -u 15206 -ostatus
Status: OFF
[root@compute207 ~]# virsh list --all
Id Name State
----------------------------------------------------
 1 instance-0000005c running
 2 instance-0000005f running
 3 instance-00000059 running

当前compute206虚拟机已经成功疏散到compute207，同时compute206电源已经关闭。详细的progress如下：

实例成功完成疏散。

3. 测试进场故障恢复

计算节点中process_list.yaml定义了那些进程处于故障恢复中。本处以nova-compute为例：

输出日志如下：

当masakari-processmonitor监控到nova-compute异常的时候会自动重启该服务。

九、自定义恢复方式（Customized Recovery Workflow）

新版本（Stein版本）的Masakari支持自定义恢复工作流。

如果想要自定义恢复工作流，那么这里提到了如何将第三方库中的自定义任务与Masakari中的标准恢复工作流相关联的指南：

1. 首先确保Masakari引擎节点上安装了所需的第三方库。以下是示例自定义任务文件。例如：

from oslo_log import log as logging
from taskflow import task
LOG = logging.getLogger(__name__)
 
class Noop(task.Task):
def __init__(self, novaclient):
 self.novaclient = novaclient
 super(Noop, self).__init__()
 
def execute(self, **kwargs):
 LOG.info("Custom task executedsuccessfully..!!")
return

2. 在第三方库的setup.cfg中配置自定义任务，如下所示：

例如，第三方库的setup.cfg将具有以下入口点

masakari.task_flow.tasks =
 custom_pre_task = <custom_task_class_path_from_third_party_library>
 custom_main_task =<custom_task_class_path_from_third_party_library>
 custom_post_task =<custom_task_class_path_from_third_party_library>

注意：第三方库的setup.cfg中的入口点应与Masakari setup.cfg中的相同密钥用于相应的故障恢复。

3. 在Masakari的新conf文件custom-recovery-methods.conf中配置自定义任务，该文件具有相同的名称，该名称在setup.cfg中给出以定位类路径。例如（在主机自动故障配置选项中添加自定义任务）：

host_auto_failure_recovery_tasks = {'pre':['disable_compute_service_task',
'custom_pre_task'],'main':['custom_main_task',
'prepare_HA_enabled_instances_task'],'post':['evacuate_instances_task',
'custom_post_task']}

4. 如果自定义任务需要任何配置参数，则将它们添加到在第三方库中注册的同一组/部分下的custom-recovery-methods.conf中。与恢复方法自定义相关的所有配置参数都应该是新添加的conf文件的一部分。代码将负责自行生成masakari.conf和相关配置文件。

5. 运维人员应确保每个任务的输出应该可用于下一个需要它们的任务。

十、其他

当虚拟机意外停机或者主机意外宕，有时候我们并不想evacuate所有的实例。此时可以将控制节点masakari的配置文件进行如下调整：

[host_failure]
evacuate_all_instances=False
ignore_instances_in_error_state=False
add_reserved_host_to_aggregate=False
[instance_failure]
process_all_instances=True

此时guest虚拟机将不会自动恢复，只有元数据HA_Enabled=True的虚拟机才会进行恢复。

Masakari当前还比较年轻。该方案优点在于，对于虚拟机HA的解决方式中考虑了三个不同层次的故障。可是没有考虑虚拟机脑裂和计算节点的隔离。对于通常的OpenStack部署，都会存在管理、业务和存储三个网段的状态，对于简单的环境而言完全可以满足需求，但是对一个复杂的环境而言，简单的通过一个网段或者两个网段去监控计算节点的状态是不够的。

分享到：