公有云依赖于应用程序自身的高可用，在一定程度上容忍物理机的宕机，私有云依赖于服务器的高可用
由于OpenStack的初衷是面向公有云，因此OpenStack在“基因”里便缺乏虚机高可用设计，这也是到目前为止OpenStack的计算服务Nova一直没有完善的虚机高可用功能的原因。在公有云环境中，用户业务系统的高可用性应该更多地依赖于分布在集群中的应用程序本身，即公有云上运行的应用程序有自己的集群和负载均衡系统，能在一定程度上容忍物理计算节点宕机所带来的虚机不可用，并能通过负载均衡系统实现故障计算节点上的负载自动转移。随着越来越多传统IT架构下的用户转入云计算，OpenStack的私有云用户不断增加，由于传统集中式应用系统的非中断运行几乎完全依赖于服务器的高可用性，因此在私有云环境下，OpenStack Nova服务的虚拟机高可用性变得极为迫切(如果虚机是主备的，倒没有那么迫切，如果是负荷分担或者应用本身没有高可用再或者实现虚拟机层面的高可用会减少宕机时间)，也是众多OpenStack私有云用户所急需的功能。
为了兼顾和确保传统应用系统向云计算平滑过渡，虽然OpenStack社区并没有提供完整的虚机高可用解决方案，但也提供了部分配合外部监控服务的工作机制让用户可以自己实现虚机高可用。此外，在Liberty版本中，OpenStack实现并改进了相关的NovaAPI接口，以便更好地配合外部高可用系统对Nova服务状态改变的监控和对虚机故障转移。例如红帽的RDO便实现了基于Pacemaker-remote的虚机高可用，同时社区也有基于Zookeeper对nova-compute服务进行监控以实现虚机高可用。
虚机高可用概述
在OpenStack中，所谓虚机高可用，指在物理计算节点发生硬件故障时(如磁盘损坏、CPU或内存故障导致宕机、物理网络故障和电源故障)，自动将该节点关闭，该节点上的虚机在集群中其它健康的计算节点上重启，如果能实现虚机的动态迁移，便是最佳的高可用方案。在实现OpenStack虚机高可用方案中，虽然所使用的软件不同，但通常都是基于三个步骤来实现：监控(Monitoring)、隔离(Fencing)和恢复(Recovery)。
1) 监控的目的在于判断Hypervisor是否故障，并为隔离操作提供执行依据。监控功能由两部分构成，一是检测主机故障情况，二是触发主机故障后的自动响应任务(隔离和恢复)。关于监控功能是否应该集成到Nova中，社区一直存在争论：认为计算节点服务的监控应该集成到Nova项目中，主要是基于Nova服务一定程度上已获取其自身运行所依赖基础架构的健康状况，或者说Nova本身已经可以跟踪活动的计算节点。但Nova对计算节点的跟踪监控只能探测Nova-compute服务的故障与否，而Nova-compute服务的故障并不意味着虚拟机也出现故障，即计算节点Nova-compute服务正常与否和该节点上虚机故障与否并无必然联系。社区也有将监控功能集成到Heat项目的建议，但是此方案需要OpenStack终端用户在虚机故障时使用Heat模板来重启虚机(但这应该是云管理员的任务，而不是要求用户来执行)。当前的OpenStack高可用环境中，Pacemaker结合Corosync是使用最多的服务高可用监控工具，但是由于历史原因，Corosync对计算节点的支持数目有限，不过Redhat提出的Pacemaker_remote解决了这种限制。
2) 隔离在高可用集群中是个非常关键的操作，所谓的集群“脑裂”通常是由不完善的隔离操作引起的。在OpenStack集群的Nova服务高可用中，隔离就是将故障计算节点与集群完全隔离，使其成为孤立节点。在实例高可用环境中，计算节点可能因各种原因出现故障情况，在其他健康节点上重启故障计算节点的虚机之前，必须确保此虚机确实已经不存在，否则可能在一个OpenStack集群中同时出现两个相同虚机的情况。更糟糕的是，如果虚机部署在共享存储上，则会出现两个相同虚机同时运行的情况，两个虚机同写一份数据通常会导致数据损坏，而且还会导致同一网络中出现两个相同的IP地址。因此，在高可用软件对故障虚机进行恢复之前，监控程序必须对有故障的计算节点进行隔离，否则必然会对虚机造成各种破坏。Pacemaker提供了对集群节点的隔离功能，如果采用其他集群工具，则需要自己实现隔离功能。
3) 监控到计算节点故障之后，对该节点进行隔离完成之后，便可对用户的虚机进行恢复。在Nova中，实现虚机恢复的功能主要是Nova提供的Evacuate命令。当Evacuate被调用时，故障计算节点上的虚机会被自动撤离，并在新的节点上恢复虚机。为了完成虚机的恢复，虚机应该创建在共享存储上，作为替代方案，也可以将虚机创建在Cinder提供的Volume上(SAN BOOT)。不过，共享存储或者Volume并非Evacuate执行成功的前提，如果未采用上述两种方案创建虚机，Evacuate也会在其他节点上恢复虚机，但这是一种有损恢复(因为Evacuate仅是采用原虚机相同的基础镜像在其他节点上重新创建一个相同的虚机，但是原虚机中相对基础镜像做过变更的数据却不能恢复)。
目前，OpenStack没有一套完成的监控、隔离和恢复方案，因此，用户必须自己实现服务监控和节点隔离，同时触发故障计算节点上的Evacuate操作。如果使用Pacemaker集群资源管理器，则需要在计算节点上实现一个Evacuate的资源代理，从而允许Pacemaker触发节点上的Evacuate操作。
虚拟机高可用之Evacuate/Rebuild
Nova提供了Evacuate API来恢复故障计算节点上的虚机，这是实现计算节点虚机高可用的基础。在监控到计算节点故障并将其隔离之后，便可触发Evacuate操作以对该节点上的虚机进行恢复。本质上来说，Evacuate是对Rebuild功能的扩展，或者说基于虚机HA的需求对Rebuild功能进行了扩展，而Rebuild功能仍然具有其实用性。Rebuild与Evacuate的区别主要在于：Rebuild会刷新虚拟机镜像磁盘，即使用新的镜像重新创建具有相同ID的虚机，因此Rebuild无须共享存储，其功能更像是相同的硬件重新安装另外的操作系统(如windows系统换成Linux系统)；而Evacuate是真正的原样复原，包括系统和用户数据。此外，Evacuate和Rebuild仅支持Active和Stopped状态的虚机，而不支持Paused、Suspend和Shut down等状态的虚机。
Evacuate的具体操作过程取决于虚机的配置和底层存储架构。如果虚机基于计算节点本地文件系统的“临时(ephemeral)”存储，则Evacuate操作采用与原虚机相同的镜像在其他节点创建，新老虚机具有相同的配置，如相同的实例ID、镜像ID、Attached Volumes 、Flavor、IP等。如果虚机位于共享存储上，则Evacuate将在其他节点上基于相同的虚机文件重启虚机，并保持虚机的配置不变。如果虚机是基于Volume后端的，则Evacuate将重建虚机并从相同的Volume上启动。因此，基于共享存储和Volume后端的虚机可以原样恢复，而基于本地临时存储的虚机不能恢复用户数据(位于临时存储上的数据)。
1．Rebuild操作验证
1）Rebuild前查看虚机信息(nova show vmid)。记录UUID、IP地址、主机名和Volume挂载情况。
2）执行Rebuild操作。这里仍然使用原镜像cirros-image-name对vm-name进行Rebuild操作，用户可以选择任意其他镜像进行Rebuild操作。nova rebuild vm_name cirros-image-name
3）Rebuild之后检查虚机信息(nova show vmid)。注意观察主机名、UUID、IP地址和Volume挂载情况是否改变，正常情况下Rebuild后这些参数应该保持不变。
2．Evacuate操作
1）Evacuate之前在虚机操作系统中保存用户数据，以备Evacuate后验证。
[root@nfs-server ~]# echo "This data should be recovery after evacuate"> /root/test.txt
2）Evacuate之前检查虚机信息(nova show vmid)。核实虚机的宿主机并确认Evacuate操作的目标主机，Evacuate要求使用共享存储或者基于Volume的虚机，此处的nfs-server为基于NFS共享存储的虚机。nova hypervisor-servers compute2
3）计算节点正常运行时执行Evacuate操作。Evacuate操作要求虚机所在宿主机的计算服务不能处于Active状态，否则不允许执行。//compute1节点正常运行，不允许执行Evacuate
[root@controller1~]# nova evacuate nfs_server compute2
ERROR (BadRequest): Compute service of compute1 is still in use. (HTTP 400)
4）计算节点故障时执行Evacuate操作。通过shut down计算节点compute1来模拟节点故障，注意观察Evacuate执行过程中虚机状态的变化。
//shutdown compute1节点
[root@compute1~]# poweroff
//执行evacuate，目标节点为compute2
[root@controller1~]# nova evacuate nfs_server compute2
5）Evacuate之后查看虚机的变化情况(nova show vmid)。虚机所在宿主机应该由compute1漂移到compute2。
6）验证Evacuate之后用户数据是否可用。有两个方法可以验证：Evacuate前更改过虚机root用户密码，现在检查root密码是否仍然可用；Evacuate前在/root/test.txt中保存有用户数据，现在检查数据是否仍然存在。
[root@nfs-server ~]# more /root/test.txt
This data should be recovery after evacuate
7）启动compute1节点，检查compute1节点上的虚机是否还会自动恢复。正常情况下，执行Evacuate操作的虚机不会在原计算节点上被恢复，在原计算节点恢复过程中会自动清除虚机相关信息。
总结
公有云依赖于应用程序自身的高可用，在一定程度上容忍物理机的宕机，私有云依赖于服务器的高可用。为了兼顾和确保传统应用系统向云计算平滑过渡，提供了部分配合外部监控服务的工作机制让用户可以自己实现虚机高可用。虚机高可用通常是基于三个步骤来实现：监控(Monitoring)、隔离(Fencing)和恢复(Recovery)。Nova对计算节点的跟踪监控通过探测Nova-compute服务的故障与否来进行隔离，Pacemaker提供了对集群节点的隔离功能，需要在计算节点上实现一个Evacuate的资源代理，从而允许Pacemaker触发节点上的Evacuate恢复操作。Pacemaker和Corosync是使用最多的服务高可用监控工具，但Corosync对计算节点的支持数目有限，另外Redhat提出的Pacemaker_remote解决了这种限制，要知如何解决请下回分解。
笔记整理来自山金孝的《OpenStack高可用集群（上册）：原理与架构》8.8.1和8.8.2章节，如有侵权请通知删除
