深挖Openstack Compute HA（2）

================================= 紧接着上篇 HA（1） ====================================

 

接下来继续讲第二大模块：

[实例疏散]

       在PING模块中如果获取到计算节点中只要有任何一个网Ping不通，就会根据不同的网络状态进行组合，执行相应的疏散操作，让出故障的计算节点上的实例能够快速在另外一个计算节点上恢复且正常提供服务。

       如下图所示，节点A发生故障，通过疏散，节点A的四个实例调度到另外的节点B和节点C，重新在新节点上运行。

                                                 

在真正做疏散操作时，需要对一些前置条件做判断：

1. 判断当前是否已经有控制节点在处理节点A的故障，不能重复执行，上篇已说过，这是为了控制同一时间只有一个控制节点去执行HA操作。

2. 判断节点A上有没有实例，如果没有实例，则没有做疏散的必要了。

                                                               

执行实际的疏散工作是调用了evacuate函数，假设计算节点A有三种网络a/b/c，此时判定网络a和b不通，则需要：

1. 通过网络c进行SSH连接到节点A上执行命令。当然，如果连SSH连接都出现了异常，此时要另外做兜底处理。

2. 最坏情况，所有网络都不通，无法通过SSH连接，只能人工介入，等网络恢复后执行SSH连接。

3. 执行命令停掉nova-compute进程，由于该操作需要消耗较长时间，所以要另起一个线程（大概执行60s）去检测节点A的状态。如果60s后节点A状态仍为up，则做兜底处理。如果状态变为了down，则执行kill kvm进程。

4. 获取节点A的所有实例，首先要判断实例的状态是否满足要求，比如实例状态应为active或者stopped，且power_state等于0。如果不满足这些条件，执行evacuate命令就会出错，则排除掉这些不满足的实例。如果满足条件，则对实例执行evacuate命令，同时加上on_shared_storage=True参数表示使用了共享存储。

5. 如果执行evacuate命令也发生了异常，则做兜底处理。

6. 最后，疏散结束后要做一些实例的残余信息清理工作。

整体的处理流程，如下图：

                                 

       另外，由于evacuate函数只是简单发消息去执行该命令，没有返回结果，也不能保证执行的成功性，因此不能实时得知实例是否真正的疏散成功，需要我们另外用进程去获取实例的最终状态来判断疏散的效果。

      在效果监测中，我们除了看实例的status是否为ACTIVE（正常运行中）外，还需判断其hypervisor_hostname是否还等于原节点A。如果是，表示实例并没有疏散到其他新节点（这种情况可能是因为没有合适的节点去调度），疏散不成功。

 

      至此，计算节点HA的简单方案就介绍于此，很多地方并没有很深入的去探讨，希望以后有机会再来完善。

 

================================ 另外附上 HA常用命令 ======================================