边缘计算体验之四：ZStack Mini3.0 FT如何提升企业可用性

在172.24.100.3这台物理主机恢复上线之后，在线编码服务器的FT功能自动检测到新主机加入，将再次恢复FT保护级别；但是，在172.24.100.3这台物理主机进入维护模式这段时间，视频直播应用一直在正常运行，不断产生新的数据，同时内存状态也在实时变化。

这意味着要恢复在线编码服务器的“FT保护级别”需要进行数据同步，不仅是存储的数据同步，还包括内存状态的同步；同步数据与内存状态，在以往的高可用方案中都是一个非常困难的问题，因为一旦出错，就会造成数据不一致，甚至可能影响到正常运行的业务。

但是在ZStack Mini边缘计算一体机中，在经过数分钟的同步之后，在线编码服务器重新达成FT保护，视频直播业务并没有受到影响。

如上图所示，在线编码服务器重新达成FT保护级别，其所在物理主机的IP地址为172.24.100.4，而原来的172.24.100.3的物理主机则承载备用云主机，与测试之前的状态相比，主、备进行了切换，但业务依旧正常运行。

从ZStack Mini 2.0中HA切换需要数分钟业务停顿——这也是目前大多数虚机迁移或故障切换所需要的时间，到3.0中FT保护缩短到秒级，切换时间极大地被缩短，但并没有引入新的硬件，也没有提升使用难度，那么FT究竟是怎样的技术？

FT技术背后的原理

传统的基于SAN存储的数据保护通常要么对业务造成短暂影响，要么需要额外解决方案介入，不在本文讨论范围内。在基于虚拟化技术的云环境中，虚机迁移或虚机故障切换通常都需要一定的时间，就如同ZStack Mini 2.0中的HA技术一样，本质上，这都采用的相同技术。

要保证部署虚机上的业务在迁移或切换时尽量不受影响，其最重要的一环就是数据同步——包括存储数据同步和内存状态同步。因为应用程序不间断运行，不停产生数据并改变内存状态，这就给数据同步并保持数据一致性带来极大的挑战。目前虚机间主流的数据同步方式采用锁步（Lock-stepping）或连续检查点（Continuous Checkpoint）。

但这两种数据同步方式各有各的不足，比如锁步会导致复制开销过多，因为虚拟机中的内存访问是不确定的；而连续检查点同样会导致过多的复制，同时还会带来额外的网络延迟。

ZStack通过与英特尔的合作，延伸出一种新的数据同步方式——粗粒级锁步（COarse-grain LOck-stepping，简称COLO），来实现FT功能所需的快速切换。其通过比较主虚机（Primary VM，PVM）与备用虚机（Secondary VM，SVM）的传输数据包来进行数据同步。

粗粒级锁步（COLO）架构示意图，其分别通过快复制进程与COLO代理，以及COLO Frame进程来实现数据与内存状态在PVM与SVM之间的同步

因为涉及到存储数据和内存状态的同步，所以其由不同软件模块（并行）实现。比如存储数据同步如下所示：

COLO中的读、写流程示意图

在存储数据读写方面：

当应用发起读请求，不仅PVM直接从自身存储进行数据读取，SVM也会进行相应的读取操作，只是正常状态下并不传输给应用。

当应用发起写请求，PVM将写请求发送给SVM，同时将数据写入自身存储；而SVM接收到写请求后，会将原始数据加载到SVM Cache并进行写入（Copy O n Write）。

在内存状态同步方面，COLO采用了一种巧妙的同步方式，如下图所示：

COLO技术中的内存状态同步示意图

如上图所示，主节点会对PVM的脏页（Dirty Pages）进行跟踪，并将其发送到备用节点。备用节点再收到PVM的脏页之后，将其保存在PVM内存缓存（Memory Cache）中，然后在检查点，将PVM内存缓存中的状态更新到SVM内存之中。

在之前的COLO技术中，COLO Proxy通常采用内核方案（Kernel Scheme），功能更强但不够灵活，但最新COLO技术中，基于目前更为流行的用户空间方案（Userspace scheme）的Proxy进程则具有更佳的灵活性。

通过对FT功能背后的技术解析，我们可以看到ZStack不仅关注用户的使用体验，尽最大努力将ZStack Mini的使用做到最简化，还深入用户实际业务需求，将ZStack Mini平台与应用连通，提供更加简化的使用体验。

同时，ZStack也没放弃对创新技术的追求，通过了解用户痛点与难题，进行针对性的开发与合作，用整个生态的力量去改变产品体验，并将最新的技术融入产品中，传递给用户，帮助用户在最快时间享受到创新技术带来的便利。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!