OpenStack虚拟机高度可用
为了兼顾和保证传统应用系统向云计算的平稳过渡，OpenStack社区虽然没有提供完整的虚拟机高可用解决方案，但也提供了一些带有外部监控服务的工作机制，以便用户自行实现虚拟机高可用。此外，在Liberty版本中，OpenStack实现并改进了相关的NovaAPI接口，以便更好地配合外部高可用系统监控Nova服务状态的变化，并对虚拟机进行故障转移。比如红帽的RDO基于Pacemaker-remote实现虚拟机高可用，社区也基于Zookeeper监控nova-compute服务实现虚拟机高可用。
在OpenStack中，所谓的虚拟机高可用是指当一个物理计算节点出现硬件故障(如磁盘损坏、CPU或内存故障导致的停机、物理网络故障、电源故障等)时，该节点自动关闭，该节点上的虚拟机在集群中其他健康的计算节点上重启。如果虚拟机可以动态迁移，这就是最佳的高可用性方案。在OpenStack虚拟机的高可用方案中，虽然使用的软件不同，但通常都是基于监控、隔离、恢复三个步骤。
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提供的卷上创建虚拟机。但是，* * *共享存储或卷不是成功实施虚拟机的先决条件。如果不是以上两种方案创建的虚拟机，那么会在其他节点上恢复虚拟机，但这是一种有损恢复(因为虚拟机只是用原虚拟机相同的基本镜像在其他节点上重新创建相同的虚拟机，而原虚拟机中从基本镜像改变的数据无法恢复)。
目前OpenStack还没有完整的监控、隔离和恢复方案。因此，用户必须自己实现服务监控和节点隔离，同时在故障计算节点上触发撤离操作。如果您使用Pacemaker集群资源管理器，您需要在计算节点上实现一个疏散资源代理，从而允许Pacemaker在节点上触发疏散操作。
Nova提供了Evacuate API来恢复故障计算节点上的虚拟机，这是实现计算节点上虚拟机高可用的基础。在监控并隔离计算节点的故障后，可以触发撤离操作来恢复节点上的虚拟机。本质上，Evacuate是Rebuild功能的扩展，或者说是基于虚拟机HA的需求，但Rebuild功能还是有其实用性的。Rebuild和Evacuate的主要区别在于，Rebuild会刷新虚拟机镜像磁盘，也就是用新的镜像重新创建一个相同ID的虚拟机，所以Rebuild不需要享受存储，它的功能更像是用相同的硬件重新安装另一个操作系统(比如用Linux系统替换windows系统)；疏散是真正的恢复，包括系统和用户数据。此外，迁移和重建仅支持处于活动和停止状态的虚拟机，但不支持处于暂停、挂起和关闭状态的虚拟机。
Evacuate的具体操作流程取决于虚拟机的配置和底层存储架构。如果虚拟机基于计算节点的本地文件系统的“短暂”存储，则在具有与原始虚拟机相同的映像的其他节点中创建撤离操作，并且新的和旧的虚拟机具有相同的配置，例如相同的实例ID、映像ID、附加卷、风格、IP等。如果虚拟机位于* * *共享存储上，Evacuate将基于相同的虚拟机文件在其他节点上重新启动虚拟机，并保持虚拟机的配置不变。如果虚拟机基于卷的后端，则Evacuate将重建虚拟机并从同一卷启动它。因此，基于* * *共享存储和卷后端的虚拟机可以按原样恢复，而基于本地临时存储的虚拟机无法恢复用户数据(位于临时存储上的数据)。
1)重建前检查虚拟机信息(nova show？vmid).记录UUID、IP地址、主机名和卷安装。
2)执行重建操作。在这里，仍然使用原始映像cirros-image-name来重建vm-name，用户可以选择任何其他映像来重建。新星？重建？虚拟机名称cirros映像名称
3)检查3)重建后的虚拟机信息(nova显示？vmid).观察主机名、UUID、IP地址和卷装载是否已更改。正常情况下，这些参数在重建后应该保持不变。
1)撤离前将用户数据保存在虚拟机操作系统中，以备撤离后验证。
[root@nfs-server ~]#？echo "该数据应该在撤离后恢复" >；？/root/test.txt
2)撤离前检查虚拟机信息(nova show？vmid).验证虚拟机的主机，并确认撤离操作的目标主机。疏散需要使用* * *共享存储或基于卷的虚拟机，其中nfs服务器是基于NFS***的虚拟机。新星？虚拟机管理程序-服务器计算2
3)当计算节点正常运行时，执行撤离操作。撤离操作要求虚拟机所在主机的计算服务不能处于活动状态，否则不允许执行。//compute1节点运行正常，不允许撤离。
[root@controller1~]# nova撤离nfs _ server compute2
错误？(BadRequest):计算？服务？的？compute1？是吗？还是？在？使用。？(HTTP？400)
4)计算节点故障时执行撤离操作。Compute1用于模拟关机故障，观察撤离执行过程中虚拟机状态的变化。
//关闭计算机1节点
[root@compute1~]#关机
//执行evacuate，目标节点为compute2。
[root@controller1~]# nova撤离nfs _ server compute2
5)检查撤离后虚拟机的变化(nova show vmid)。虚拟机所在的主机应该从compute1漂移到compute2。
6)验证撤离后用户数据是否可用。有两种方法可以验证这一点:疏散前更改虚拟机root密码，现在检查root密码是否仍然可用；撤离前，用户数据存储在/root/test.txt中。现在检查数据是否仍然存在。
[root@nfs-server ~]#？more /root/test.txt
该数据应该在撤离后恢复
7)启动compute1节点，检查compute1节点上的虚拟机是否会自动恢复。正常情况下，执行撤离操作的虚拟机不会在原计算节点上恢复，在原计算节点恢复过程中，虚拟机的相关信息会被自动清除。
公有云依赖于应用本身的高可用性，在一定程度上容忍了物理机的宕机，而私有云依赖于服务器的高可用性。为了兼顾和保证从传统应用系统到云计算的平稳过渡，提供了一些带有外部监控服务的工作机制，以便用户自己实现虚拟机的高可用性。虚拟机高可用性通常基于三个步骤来实现:监控、隔离和恢复。Nova对计算节点的跟踪和监控是通过检测Nova-compute服务的故障来隔离的。Pacemaker提供了集群节点的隔离功能，需要在计算节点上实现一个疏散资源代理，从而允许Pacemaker在节点上触发疏散恢复操作。Pacemaker和Corosync是最广泛使用的高可用性服务监控工具，但Corosync支持的计算节点数量有限。另外，Redhat提出的Pacemaker_remote解决了这个限制。要知道这个问题怎么解决，请下次分解。