转载自 http://blog.csdn.net/shatty/article/details/50999677
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