边缘计算体验之四:ZStack Mini3.0 FT如何提升企业可用性
科技猎 · 2020-09-02 09:54:34 · 热度:加载中...

随着新基建提速换挡,必将带动基础设施即服务的新一轮增长。当我们关注高光项目的同时,不应忽略传统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开源软件构建网站的“三驾马车”,可以说是自建网站的最经典的选择。

在E企研究院使用的ZStack Mini中,集成了LNMP、MariaDB和Tomcat三个最常使用的应用

如果利用虚机安装这三个应用,可能需要花费数小时,而且还极有可能出错。现在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 3.0中的FT功能。

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

本文来源:科技猎