随着新基建提速换挡，必将带动基础设施即服务的新一轮增长。当我们关注高光项目的同时，不应忽略传统IT需求，传统IT领域很多应用上云面临种种困难，如何让他们在新基建浪潮提速？
比如在工业制造业、交通、能源电力等传统行业的业务场景中，可用性永远是高频词汇，如何让应用主机在不同物理节点之间实现秒级切换？如何获得可靠、高效的FT/HA技术让用户服务“永不宕机”？
在之前的文章《边缘计算体验之二：简单高可用 ZStack Mini的巧妙设计》中，介绍了ZStack如何在2U机箱设计的ZStack Mini中实现了高可用（HA）。
当监测到物理节点故障无法为应用服务器提供服务的时候，高可用就将应用服务器迁移到正常运行的物理节点上，保证业务的连续性，但是业务系统也会受到轻微影响，基于HA的高可用依旧有数分钟的业务中断。
这在有些场景下是不可接受的，比如一些场景需要秒级的切换，以保证业务的连续性。在本篇文章中，将介绍ZStack Mini 3.0中的核心功能——FT。
**ZStack Mini 3.0——让易用性更上一层楼
**
ZStack Mini 3.0是ZStack Mini产品家族的一次重大升级，主要是软件部分的升级。可以在保持ZStack Mini边缘计算一体机硬件不变的情况下，将软件版本从原来的2.0升级到最新的3.0，获得更多对中小企业实际使用非常有帮助的功能。
ZStack Mini一体机升级到3.0后的管理中心界面，从左侧边栏可以看到，与2.0相比，多了“应用中心”、“我的应用”、“外接磁盘备份”等菜单，同时在上图看不到的是在“存储”中多了“FC-SAN存储”的功能。
FC-SAN存储功能，让ZStack Mini可以外接FC-SAN存储阵列，帮助企业更好地利用数据中心内已有的FC-SAN存储，可以利旧，并有助于数据流通与整合。
在ZStack Mini边缘计算一体机中安装额外的FC-HBA卡，即可与数据中心内的FC-SAN存储进行连接。上图红框中即为FC-HBA卡，正与外接FC-SAN存储进行数据整合
外接磁盘备份，顾名思义，就是通过将USB接口的移动硬盘（或U盘）接入ZStack Mini平台，将ZStack Mini平台中现有的数据备份到磁盘之中。
应用中心，在E企研究院测试的ZStack Mini中集成了三个应用模板，分别为MariaDB、LNMP和Tomcat，这是许多中小企业利用Apache开源软件构建网站的“三驾马车”，可以说是自建网站的最经典的选择。
如果利用虚机安装这三个应用，可能需要花费数小时，而且还极有可能出错。现在ZStack Mini将这三个应用软件集成到“应用中心”内，通过鼠标点击即可一键部署，并在数分钟内完成可用。可以说极大地节省了用户在安装、部署和维护方面的难度。
通过这些功能加入，ZStack Mini边缘计算一体机平台不但具备已有的简单易用功能，同时也让企业用户在业务部署、后期维护上更简单。这也与ZStack Mini边缘计算一体机的易用性特点是一脉相承的，产品的使用并不会因为升级而变得复杂。
接下来，将介绍ZStack Mini 3.0中最重磅的功能——FT功能。
FT——让可用性进一步提高
在前一篇文章中，采用HA（High Availability，高可用）对ZStack Mini中的虚机进行保护的话，业务依旧会有1分钟左右的中断，那么ZStack Mini 3.0中新加入的FT（Fault-Tolerance，容错）功能则能够做到真正意义的秒级切换，且不会对业务造成影响。
在ZStack Mini边缘计算一体机平台中，E企研究院事先创建了一个目前最火热的应用之一——视频直播。其由两个虚机构成：
视频推流服务器：其作用类似于我们智能手机的直播App，将手机摄像头“看到”的图像上传到云端的服务器。稍微与直播不同的是，在演示中，E企研究院用一段视频替代直播图像，在视频推流服务器中将一段视频实时推流到在线编码服务器。
在线编码服务器：手机中的直播App将图像上传到云端的编码服务器，编码服务器进行编解码，然后再推送到观众的手机或电脑端（接收端）。在演示中，则用演示用的笔记本电脑作为接收端。
首先，我们在视频推流服务器中将一段视频流推送到在线编码器，然后用笔记本电脑接收经过在线编码服务器处理的音视频信号。视频推流服务器——在线编码服务器——接收端，构成了一个最简化的视频直播应用环境。其中，在线编码服务器是企业为最终用户提供视频直播服务的核心，一旦其出现故障，无法正常运行，整个直播服务将会中断。
在线编码服务器位于IP地址为“172.24.100.3”的物理主机之上，并开启了FT保护模式。同时在ZStack Mini管理平台中可以看到，在线编码服务器会有一台备用的云主机，在“FT辅助云主机信息”面板可以看到，其备用云主机正常运行在IP地址为172.24.100.4的物理主机之上。
在线编码服务器详情，本身位于172.24.100.3物理主机之上，使用FT保护模式，其备用云主机位于172.24.100.4物理主机之上
在视频直播正常运行过程中，E企研究院将在线编码服务器所在的物理主机（即172.24.100.3）进入维护模式，以模拟这台物理主机出现故障，需要停机维护，暂时无法提供服务。
ZStack Mini边缘计算一体机中，IP地址为172.24.100.3的物理主机进入维护模式
在物理主机进入维护模式时，切换到笔记本电脑接收端，音视频信号一切正常，并没有出现停顿。再看在线编码服务器的状态，虚机已经切换到172.24.100.4物理主机之上，因为其原来所在的物理主机进入维护模式（172.24.100.3）。
ZStack Mini边缘计算一体机最小二节点部署，因为其中一台物理主机进入维护模式，原本位于172.24.100.3的在线编码服务器在第一时间就切换到了172.24.100.4物理主机之上，视频直播业务正常运行。但是通过上图可见，在线编码服务器已经不再处于保护状态，因为其已经没有了备用的云主机，正处于“单工模式”，一旦其所在的物理主机也需要停机，将影响正在运行的直播业务。因此还是要尽快将故障的物理主机修复或替换，重新上线作为备份节点。
在这个测试验证场景中，E企研究院进入到“一体机”界面中，将处于“维护模式”的172.24.100.3这台物理主机启用，表示故障修复，重新上线。
在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 On 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平台与应用连通，提供更加简化的使用体验。
