深挖Openstack Compute HA（1）

       OpenStack在计算节点HA（High Available，高可用）上一直没有成熟且可靠的方案，碰巧项目中有遇到这种HA的功能需求，故尝试着做一个这种方案，以便能够实时保障用户的实例安全、持续可用，当节点发生故障时，影响情况对用户透明。

       所以我们的方案是，及时监测计算节点的状态，当节点发生故障时将实例进行疏散，将原节点的实例转移到另外一个新节点上重新运行，保证实例的持续可用。

 

[方案背景]

由于我们底层数据存储用的是共享存储（Ceph），所以在实例迁移时对于数据的拷贝相对简单，相当于镜像的复制。疏散的核心函数用的是nova模块的evacuate方法，由此函数来决定选择新的节点。在实际运行环境中，存在多种网络，故需要对所有网络的正常情况来判定原节点是否有问题。

 

[总体架构]
计算节点HA方案主要分为两大模块：节点监测和实例疏散。其中，节点监测模块负责实时监测计算节点的状态，当发生故障时，及时获取状态信息；实例疏散模块负责在节点确定故障时，将故障节点的实例疏散到其他节点上。

 

接下来细说这两大模块的具体设计：

[节点监测]

在判断节点健康性上，我们采用比较简单的Ping心跳检测，在控制节点上不停地对计算节点的多个网络进行Ping操作，以此检测网络连通性，从而作为是否执行HA的依据。如下图：

                                          

1. 在Ping操作中，我们使用的命令是“ping -c 3 -w 10 ip”，其中-c参数表示一次发送的包数，-w参数表示执行的最大等待时间，单位为秒。

2. 在HA中，我们对网络状态监测的要求应是“懒响应”，不需要太敏感。等监测的网络状态真正满足我们设定的控制阈值时，才判断该网络出故障，避免因网络抖动等一系列问题造成误判误操作。

3. 在实践中，需要调整ping的-w参数，和ping操作的重试次数，这两个指标相乘的结果作为判断网络异常的临界值。

4. ping的-w参数为最大等待时间，测试发现，当网卡刚出故障时，ping等待返回的时间比较长，基本都是w值。而一段时间后，网络稳定（确定故障）时ping的等待返回时间很短，ping一下就确定不通而返回了。

 

在流程上，由于有多个控制节点，需要限制同一时间内只有一个控制节点去Ping同一个节点，减少重复的Ping工作和性能消耗。这里可以用数据库行锁或者常规的分布式锁（redis、zk）去做。如果基于数据表做控制的，需要做超时释放资源的工作。我们的简单做法的流程图如下：

                                       

 

 

 

=========================== 未完待续，想看下篇 ===================================