基于FCSAN心跳的电力云平台虚拟机HA实现
时间：2021-02-06 10:01:28 来源：达达文档网 本文已影响 人 
田富强 佘文魁 胡波
摘 要：随着业务系统上云规模的不断扩大，云平台对虚拟机可用性要求越来越高。为了进一步提升虚拟机的可用性，减少业务停机时间，平台需要在短时间内将虚拟机及业务恢复运行，同时必须防止因判定条件不充分导致虚拟机脑裂。这依赖于HA（High Availability）对资源池中众多计算节点的状态进行实时准确的判定。针对电力云平台虚拟机HA，本文全新提出通过FCSAN的逻辑卷心跳信号来增强对主机状态感知的方案。经测试，该方案相比仅通过以太网络来确认主机心跳信号的方式要更可靠。
关键词：基础设施及服务 高可用 虚拟机 心跳 光纤存储
中图分类号：TP302 文献标识码：A 文章编号：1674-098X（2020）07（a）-0117-04
Abstract：
With the continuous expansion of cloud scale on business systems， cloud platforms have increasingly higher requirements on the availability of virtual machines. In order to further improve the availability of virtual machines and reduce business downtime， the platform needs to resume the virtual machines and services within a short period of time. At the same time， it must prevent the virtual machine from being split due to insufficient judgment conditions. This relies on HA （High Availability） to accurately determine the state of many computing nodes in the resource pool in real time. For the power cloud platform virtual machine HA， this paper proposes a new solution to enhance the host state awareness through the FCSAN logical volume heartbeat signal. After testing， this scheme is more reliable than the way to confirm the host heartbeat signal only through the Ethernet network.
Key Words：
Infrastructure and services; High availability; Virtual machines; Heartbeat; Fiber storage
在大型云平臺中，往往以数千台设备来承载数万个虚拟机运行，任意一台物理设备和环境的故障都可能导致多个虚拟机承载业务的中断。虚拟机HA的任务是在短时间内将所有故障虚拟机恢复运行。目前，各种云平台虚拟机HA的方案大同小异，主要还是采用心跳机制，IPMI在本场景上仅可用于识别物理机电源状态，信息不充分。多数云平台采用分布式存储，其节点间通信方式为以太网，当以太网络不稳定时缺少第三方的判定依据，容易对虚拟机误操作导致脑裂。VMware的HA方案借助其vmfs，通过虚拟机文件锁来避免脑裂，但VMware需要较高的购买费用。
在电力云平台资源池的架构中，物理服务器被划分为多个集群，一个机房通常会配备一台或多台FCSAN来存放虚拟机磁盘镜像。云平台中一般存在一个或多个控制中心用于资源池的整体调控。计算节点是分散在不同的机架甚至可能在不同机房中，这些物理服务器节点通常通过以太网络来进行通信。HA的实现首先需要依赖控制中心对每个服务器节点的状态进行实时精准的感知，而基于以太网络的通信则是用于感知节点状态的主要途径。为了安全，物理机不能通过业务网络通信，管理网络将作为唯一的通信通道。管理网故障时，虚拟机可能仍然正常运行，而控制中心却无法感知虚拟机及其宿主机的任何信号，HA的调度将变得两难。在判定不充分的情况下，很容易导致虚拟机脑裂。实际情况更复杂，可能出现网络间歇性闪断，服务器还可能自动重启、死机等情况，这些都不是单一的以太网感知方式能够有效应对的。本文将介绍通过FCSAN的信号补偿机来提升虚拟机HA的可靠性的整体方案。
1 HA方案概述
本方案包括心跳保持、HA迁移触发、FCSAN心跳机制、多机房HA结构、调度模块设计5个部分。
如图1，电力云平台采用无固定中心结构部署，基于“控制中心/代理”模式架构，控制中心采用pacemaker集群方式部署，数据库采用双节点相互实时同步，避免出现单点故障。FCSAN存储和管理网均采用双链路冗余部署。承载虚拟机网络的业务网与管理网络是隔离的，此处不能用于HA管理通信。
控制中心需要实时感知计算节点是否处于“可联系”状态，当控制中心在一定时间内无法通过任何途径感知计算节点时，控制中心将虚拟机调度到其它可用的计算节点上运行。计算节点需要不断检查本节点是否处于“失联”的状态，计算节点检测到自己“失联”时，会从本机移除虚拟机运行权，以避免脑裂。
1.1 心跳保持
在资源池中主要将“虚拟机”和“物理机”作为关注点，系统通过实时保持计算节点和控制中心的心跳信号来确认它们的正常运行状态。正常情况下，计算节点将不间断地通过管理网向控制中心发送心跳信号，控制中心被动接收心跳信号。计算节点基于TCP/IP发送正常心跳，控制中心对计算节点的TCP心跳请求进行响应，响应内容包含控制中心的实时信息，因为控制中心节点在集群中也是动态变化的（见图2）。
当正常心跳不能保持并达到超时时间，HA将进入心跳异常处理，心跳异常处理也将直到正常心跳的恢复或异常处理完毕为止。心跳双方的异常处理策略如下。
（1）控制中心异常心跳策略。
当控制中心无法接收到计算节点的正常心跳，且达到超时时间，将采取以下方式和顺序主动获取计算节点的信号，直到条件成立。如果条件不成立或超时则进行下一步骤。①搜集计算节点所有有效IP地址，并发地发起ICMP请求直到响应或超时为止。②主动多次尝试通过计算集群代理节点获取计算节点向FCSAN中写入的心跳信号，直到取得信号变化或超时为止。③通过对所有网卡旁路监听，直到获取到来自目标的信号或超时为止。
（2）计算节点心跳策略。
当计算节点无法向控制中心发送成功正常心跳信号，且达到超时时间，将采取以下方式和顺序向控制中心或本集群的FCSAN持续地发送心跳信号，直到条件成立。如果条件不成立或超时则进行下一步骤。①检查本机所有网卡，找到状态正常的网卡或超时为止。②搜集控制中心所有有效IP地址，并发地发起ICMP请求直到响应或超时为止。③向本集群的FCSAN发送心跳信号，直到信号发送成功或超时为止。
心跳策略必须要求控制中心和计算节点双方在同一时间执行才能确保策略的有效性。在正常心跳下，是由策略双方共同完成一次成功心跳，一旦正常心跳出现中断，双方将在同一时间点被心跳双方感知到。但是控制中心很可能因故障的发生（如网络中断时无法读写数据库）不能正常完成策略的处理。
为了防止心跳策略双方执行时间不对等问题，我们引入“HA故障检测时段”，它的时间的定义范围是从最后一次正常心跳的时间开始到数分钟后为止。故障的判定和相关处理只在该时间阶段进行，过时则不再处理。否则可能出现信号不对称导致错误感知，使计算节点正常运行情况下又将虚拟机启动到其它计算节点。这种情况下，存储中的同一份虚拟机磁盘镜像将被两个实例同时读写，这就形成虚拟机脑裂。脑裂发生后，虚拟机关键数据很可能损坏，造成较大损失。
1.2 HA迁移触发
当控制中心依次尝试完所有途径均无法检测到来自计算节点的信号时，会将该计算节点上的虚拟机迁移到其它可用计算节点上。虚拟机迁移分为带内存迁移和不带内存迁移两种情况。
（1）带内存迁移。
当因计算节点所有网络均发生故障，而存储可访问时，虚拟机将无法与外界通信，服务也就中断了。如果需要带内存恢复服务，可将虚拟机的内存保存先在FCSAN存储中，然后再从其它计算节点通读取存储中的内存进行恢复。具体做法（见图3）：可在存储上为虚拟机专门创建一个LV（Logical Volume）来临时保存内存，LV通过文件系统格式化后挂载到虚拟机的宿主机，然后通过宿主机将内存写入文件系统（KVM等虚拟机均支持将内存转存到文件），内存保存完成后，虚拟机运行实例将被销毁，在FCSAN上进行标记，控制中心就可以在其它计算节点上将虚拟机内存文件系统先挂载，然后直接从内存文件恢复虚拟机。
（2）不带内存迁移。
当因计算节点宕机导致的故障，虚拟机内存直接丢失掉了，这种情形将由控制中心为虚拟机在集群内寻找另一个可用的计算节点重新启动虚拟机。当计算节点的以太网络和FCSAN通道均无法通信时，计算节点将虚拟机运行实例直接销毁。
不带内存迁移可确保虚拟机更快地恢复运行，带内存迁移将需要耗费较长的时间，因此在设定虚拟机恢复级别时需要根据实际业务需要来确定。
1.3 FCSAN心跳机制
针对每个物理机计算集群，需要从FCSAN上划分一个LUN，并通过LVM的方式管理。HA将为集群中的每一个计算节点创建一个LV。下文将该LV称之为“光纤心跳块”，它将以物理机ID号作为命名依据。计算节点采用向光纤心跳块写数据的方式发送心跳。控制中心从对应光纤心跳块中读取光纤心跳信号。由于脑裂本身是因两个虚拟机实例对FCSAN中的虚拟机磁盘产生了双写造成的，因此从避免脑裂的角度来看，以FCSAN的信号作为计算节点可用性判定依据比其它条件更充分。
光纤心跳信号设计。
取0-N的正整数，每一次心跳信号将顺序地将这些数值通过二进制形式写入到光纤心跳块的起始位置，达到最大值后又从0开始递增。使得信号写入期间，控制中心能够从光纤心跳块上读取到在0-N间变化的数值。
1.4 多机房HA结构
当需要将多个机房中的设备纳入同一个资源池管理时，控制集群只会部署在其中一个机房。而不同机房往往是配备的独立的FCSAN存储，不同机房间存储链路不互通。
如图4，这种情况下，控制中心无法直接访问机房二中的光纤心跳块。针对这种情况，控制中心将选举一个代理节点来读取光纤块心跳。下文称该节点为“HA检测代理”。控制中心每一次读取光纤心跳信号时，均需要从集群2中动态选举一个可用的计算节点作为“HA检测代理”。HA检测代理实时监听来自控制中心的信号读取请求，并将读取结果返回给控制中心。
1.5 调度模块设计
为了确保HA调度过程中，每一个环节互不影响，同时也不受某一台物理机环境故障的影响，我们将HA的每个环节设计为独立的模块（见表1）。HA调度模块如下：
T指的是轮循任务，确保动作的持续性。L指的是事件监听器，L负责多线程处理T发起的事件请求，采用消息和事件监听模式实现，确保故障可以被大规模持续处理。
2 验证测试
我们针对云平台中常见的网络故障场景，分别采用某个基于openstack架构的云平台软件（因涉及商业问题不便公开，下文称为X方案）与采用本方案的云平台软件进行对比测试。X方案主要采用以太网络心跳和IPMI作为故障感知方式。
测试环境准备：先后分别采用相同的5台物理机搭建云平台，通过相同的5台虚拟机镜像克隆20台虚拟机，每台物理机运行4台虚拟机，分别按相同顺序对每个测试场景进行3组操作，操作过程中对虚拟机进行ping操作，记录每一次中断时间。测试结果见表2。
3 结语
相比仅采用以太网络心跳和IPMI作为故障感知方式的云平台HA方案，本方案在網络故障场景下能较好地避免对虚拟机进行误操作，云平台虚拟机的可用性更高。在一定条件下，采用带内存迁移来恢复故障虚拟机可更快地恢复业务。采用全异步方式进行HA调度可在同时出现大量故障的场景中更快地完成虚拟机恢复。
参考文献
[1] VMware，Inc.Patent Issued for VM Availability during Management and VM Network Failures in Host Computing Systems （USPTO 9465704）[J].Computer Weekly News，2016.
[2] 佘文魁，袁亮，田富强，等.基于KVM虚拟化平台的轻量级HA机制研究[J].电子世界，2018（12）：45-46.
[3] 陈天翼.FCSAN为智能化腾飞插上翅膀[J].中国公共安全，2019（Z1）：107-108.
[4] 白伟华.面向云计算的小粒度应用容器模型研究与应用[D].广州：华南理工大学，2017.
[5] 郭煜.可信云体系结构与关键技术研究[D].北京：北京交通大学，2017.
[6] 杜威科.基于Kubemetes的大数据流式计算Spark平台设计与实现[D].南京：南京邮电大学，2017.
