讨论：Openstack 使用Evacuate来实现HA

问题导读：
1、Openstack组件间的HA有哪几种模式？
2、Openstack VM的HA实现方式是什么？



背景
在云服务中HA(High Available)有着非常重要的意义。通常把正在执行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。


Openstack组件间的HA
官方提供了2种配置方案主从模式（Active/Passive）和双活(Active/Active)。
实现（Active/Passive）需要借助于pacemaker来实现自身服务的HA机制 ，（即通过注册成为pacemaker的一个resource，然后将自身的行为交由pacemaker来进行管理），用来提高可靠性。而(Active/Active)模式则是使用了HAproxy来进行负载均衡的管理，用来提高性能。而在实际部署过程中，通常需要将两种模式根据实际业务的情况来进行考量配置。例如，对于访问比较密集的api服务配置为(Active/Active)来实现负载均衡，但是需要用第三方工具来保证服务的可靠。而对数据库等数据重要组件则使用（Active/Passive）来保证数据的高可靠性。


Openstack VM的HA
到目前为止并没有一个完整的使用说明。但是从目前实现的功能来看，Openstack自身已经具备了一些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不能进行准确的判断。因此需要通过其他方式来确保准确获得节点的状态。
2.Openstack没有对VM进行加锁，因此在进行Evacuate命令时，会出现脑裂（同一个disk启动多个VM的情况）。
3.对于需要保护的虚拟机需要提供一个列表，用来表明哪些VM是用来保护的。目前的Evacuate命令会奖失败主机上的所有虚拟机无差别进行rebuild这样的实现也是不太合理的。


总结
Openstack的HA机制并不完善，还有很大的空间来提升。虽然并不需要像VMware那样对待虚拟机进行精细化的管理，但是对于使用云服务的用户来说，对于VM好的HA机制还是必不可少的。


个人观点了：
其实，我自己长久以来，也在思考和寻求答案，即Openstack有什么有效的具体技术机制，来保障其高可用性、高可靠性和高安全性，
基于高可用性，如何保障在机器宕机情况下，实现业务的实时迁移，而业务不中断。
高可靠性，即当我的实例如果出现问题，人为的误操作，如何快速的恢复过来。
最后，就是高安全性，Openstack以及外部网络安全设备，如何协调工作，抵御外部黑客攻击、内部人员恶意操作，有什么明确的机制吗？
最后，欢迎大家一起来讨论，分享观点

Evacuate实现vm ha具体怎么实施的？是不是还是需要在检测到物理机宕机后再通过执行Evacuate命令实现宕机迁移？有无自动实现方案？