OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目。它的社区拥有超过130
家企业及1350位开发人员，这些机构与个人都将OpenStack作为基础设施即服务（IaaS）资源的通用前端。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性。做为云计算IAAS层事实标准。OpenStack广泛的应用与各行各业。到眼下为止OpenStack社区并没有一个完整的虚拟机HA解决方式。起初社区觉得虚拟机的HA不是云平台层次的特性，不应该在云平台层面来实现，虚拟机的HA应该通过应用层面的HA来实现。可是非常多应用不是默认做了应用层面的HA，OpenStack又缺少这样一个重要的特性。所以非常多公司针对虚拟机的HA提出了自己的解决方式。近期社区也開始关注虚拟机的HA的是实现。这篇文章针对OpenStack中的虚拟机HA的进展和几个公司的虚拟机HA实现进行介绍。
最后在结合各种方案的长处的基础上，介绍了一个虚拟机的HA的实现方案。
一、OpenStack中虚拟机HA的历史和现状
OpenStack中虚拟机的HA的最初讨论能够见这篇文章, 作为Nova项目的重要贡献者。他的文章对虚拟机的HA的实现有着广泛的影响。
这篇文章也给出了虚拟机HA实现的基本思路。解决问题须要一些关键的部件：
监控(Monitoring)- 系统检測到虚拟化层的故障
隔离(或是围栏。Fencing) - 系统隔离故障计算节点
恢复(Recovery) - 从故障的虚拟化上恢复虚拟机
下边是OpenStack中针对虚拟机HA的一些解决方式；
1. Nova中的支持
Nova已经具备了一些HA的功能。
1) 在nova中提供了Evacuate命令来实现，将VM从失败的Compute节点在目标节点上rebuild。
这一功能的实现须要依赖源节点和目标节点间有共享存储。
2) 在VM的HA其中，对于Compute节点是否故障的推断须要很的精细，眼下在Openstack中每一个nova-compute服务启动时都会启动一个定时器。定期的将心跳写入到数据库中，这样能够从控制节点方便的知道Compute节点的状态。
可是Openstack只拥有这些功能还不足以完毕对VM HA功能的完美支持。
1) 仅仅是通过nova-compute服务来确定Compute节点的状态时不可靠的。比如仅仅是nova-compute服务失效，或者网络闪断时，也会造成心跳的过期，从而对是否进行HA不能进行准确的推断。因此须要通过其它方式来确保准确获得节点的状态。
最主要是OpenStack的最佳实践部署。一般是管理、业务和存储网段是单独的网段，这时Nova Service的服务状态仅仅能反映出管理网段的状态，不能反映出存储和业务网段的nova-compute节点的状态。
2) Openstack没有对VM进行加锁，因此在进行Evacuate命令时，会出现脑裂（同一个disk启动多个VM的情况）。
3) 对于须要保护的虚拟机须要提供一个列表，用来表明哪些VM是用来保护的。
眼下的Evacuate命令会奖失败主机上的全部虚拟机无区别进行rebuild这种实现也是不太合理的。
2. neutron+VRRP
为了防止防止arp欺骗。Neutron是不同意一个port上边绑定多个IP地址的。
Neutron在Havana Release添加了一个 “Allowed-Address-Pairs”的功能，同意虚拟机的一个port绑定附加的IP作为浮动IP。
这样在虚拟机中能够安装VRRP实现软件，比Keepalived等，浮动IP配置为额外添加的IP，多个虚拟机绑定的port都绑定这个额外的浮动IP。两个虚拟机通过VRRP能够选出一个主对外提供服务。
这个方法首先配置复杂，须要在Neutron中为须要參与HA的port绑定额外的IP。还要在虚拟机中配置VRRP支持软件，配置复杂。这个方法不能算是一个完整的方案，相当于为应用层的HA实现方案做了一个Neutron中的支持功能。
详细參考这篇文章。
3. Heat Restarter
Heat的HA特性是OpenStack多模块配合实现的，当中涉及到Nova，Ceilometer，Heat-cfn-api，Heat-cloudwatch。Heat-cfntools等。
Nova->提供虚拟机
Ceilometer->发送告警
Heat-cfntools->监控虚拟机状态
当虚拟机上的应用进程down了。首先通过重新启动应用进程尝试解决。假设解决不了。重新启动或者重建虚拟机。假设还是解决不了，重建整个stack。从这一点上来看Heat HA的功能要比单纯的虚拟机HA的功能强大非常多。
可是对于普通的Web无状态应用，通过OS::Heat::HARestarter删除原有虚拟机，然后又一次创建或许适合的。可是假设是数据库之类的有状态应用呢？怎么保证原有数据库中数据的不丢失。后端卷虚拟机？那又怎么保证使用原来的fixed-ip？
正式因为HARestarter是通过删除原有虚拟机的方式和虚拟机的一些依赖资源，Openstack社区已经在Kilo版本号废弃了HARestarter。
4. OpenStack中的虚拟机HA方案的设想
二、各大公司的实现方案
1. Masakari
Masakari 是日本NTT公司提供的一套虚拟HA方案。 Masakari支持虚拟机进程，虚拟化进程和计算节点进程的监控。通过shell脚本监控虚拟机进程，Nova-compute服务和计算节点状态。
虚拟机进程挂了->通过虚拟机的API关闭和启动虚拟机。
虚拟化进程挂了->通过Nova-compute API设置Nova-compute服务为down状态。
Nova-compute进程挂了->疏散计算节点上的虚拟机。
Masakari的架构：
masakari-controller : 这个HA服务的控制器。
masakari-instancemonitor : 检測虚拟机进程是否挂掉了。
masakari-processmonitor : 检測Nova-compute是否挂了。
masakari-hostmonitor : 检測计算节点是否挂了。
该方案可取之处在于：对于虚拟机HA的解决方式中考虑了三个不同层次的故障。可是没有考虑虚拟机脑裂和计算节点的隔离。对于通常的OpenStack部署，都会存在管理、业务和存储三个网段的状态，简单的通过一个网段去监控计算节点的状态是不够的。
2. Redhat 方案
部署方式例如以下：
使用 Pacemaker 集群作为控制平面
将计算节点做为 Partial members 增加到 Pacemaker 集群中，受其管理和监控。
这时候，其数目不受 Corosync 集群内节点总数的限制。
HA 实现细节：
Pacemaker通过pacemaker_remote依照顺序（neutron-ovs-agent -> ceilometer-compute ->nova-compute) 来启动计算节点上的各种服务。前面的服务启动失败，后面的服务不会被启动。
Pacemaker 监控和每一个计算节点上的 pacemaker_remote 的连接，来检查该节点是否处于活动状态。
发现它不能够连接的话，启动恢复（recovery）过程。
Pacemaker 监控每一个服务的状态，假设状态失效，该服务会被重新启动。重新启动失败则触发防护行为（fencing action）；当全部服务都被启动后，虚机的网络会被恢复，因此，网络仅仅会短时间受影响。
当一个节点失效时，恢复（recovery）过程会被触发，Pacemaker 会依次：
1) 执行nova service-disable
2) 将该节点关机
3) 等待 nova 发现该节点失效了
4) 将该节点开机
5) 假设节点启动成功。运行novaservice-enable
6) 假设节点启动失败。则运行 novaevacuate把该节点上的虚机移到别的可用计算节点上。
当中：
l 步骤（1）和 （5）是可选的，其主要目的是防止 nova-scheduler 将新的虚机分配到该节点。
l 步骤（2）保证机器肯定会关机。
l 步骤（3）中眼下 nova 须要等待一段较长的超时时间才干推断节点 down 了。
Liberty 中有个 Blueprint 来加入一个 Nova API 将节点状态直接设置为 down。
l 其余一些前提条件：
l 虚机必须部署在 cinder-volume 或者共享的暂时存储比方 RBD 或者 NFS 上，这样虚机evaculation 将不会造成数据丢失。
l 假设虚机不使用共享存储。则必须周期性地创建虚机的快照并保存到 Glance 中。在虚机损坏后，能够从 Glance 快照上恢复。可是。这可能会导致状态或者数据丢失。
l 控制和计算节点须要安装 RHEL7.1+
l 计算节点须要有防护机制，比方 IPMI，硬件狗等
详细參考这里。
3. 海云捷迅的方案
海云捷迅的分布式健康检查方案是我比較认同的一种监控计算节点是否挂掉的方案，考虑了管理、业务和存储三个网段的监控。
同一时候支持应用层的自己定义监控方式。详细參考这里。
该方案引入了consul监控工具。通过consul集群在管理、业务和存储三个网段监控计算节点的状态。依据不同的组合情况，做出不同的处理方式。
我觉得是对虚拟机HA方案中的监控部分的深入和精细的控制，能够做到虚拟机的精准恢复，有效的防止虚拟机脑裂情况。
四、总结
鉴于各个公司都在为OpenStack做虚拟机的HA方案，社区也開始考虑实现虚拟机的HA方案。能够參考这里。
集成各家方案的长处。尽可能的处理各种虚拟机的异常情况，保证云上应用的高可用。构想的例如以下的虚拟机HA方案，
服务框架：借鉴https://github.com/gryf/mistral-evacuate这个工作的思想，虚拟机HA的服务框架应该是一个相对通用的框架，用来处理各种用户的不同应用场景。
一个通用框架，要能处理不同的用户场景，服务框架还是要有一定的抽象和通用性。这里是HA服务的服务处理流程。
因为隔离和恢复部分基本没有太多的选择，各个公司的虚拟机HA方案中基本差异都在于监控部分，怎样做到精细的监控计算节点的状态。鉴于OpenStack环境基本都是管理、业务和存储网三网分开的部署方式。所以我觉得上边海云捷迅的分布式健康检查方式是比較有用的一种监控方式，再加上Ovirt 中的虚拟机磁盘加锁机制。
我觉得能够比較好的解决虚拟机HA的问题。參考下图：
虚拟机HA看似一个简单的需求，可是从上边的各种实现方式来看，都有着各自的有点和缺点。所以这个问题事实上还是挺复杂。欢迎大家就这个问题和我交流。
三、參考文档
https://review.openstack.org/#/c/257809/2
https://etherpad.openstack.org/p/automatic-evacuation
https://www.youtube.com/watch?
v=yq5nYPKxBCo&feature=youtu.be&t=23m22s
https://review.openstack.org/#/c/270015/7/user-stories/draft/ha_vm.rst
https://github.com/gryf/mistral-evacuate
http://blog.clusterlabs.org/blog/2015/openstack-ha-compute/
https://blueprints.launchpad.net/nova/+spec/vm-auto-ha-when-host-broken
Openstack相关技术交流请加群：314889201