-
摘要: 讨论现有基于模型的故障诊断与容错控制方法的局限性, 并由此提出一个基于$\nu$- 间隙度量来处理故障诊断与容错控制的新框架. 并且, 讨论了如何在此框架下对故障进行分类和分级以及提出如何进行容错控制的一般性控制结构.
-
关键词:
- 故障诊断 /
- 容错控制 /
- $\nu$- 间隙度量 /
- 鲁棒控制 /
- 系统辨识
Abstract: This paper discusses the limitations of existing model-based fault diagnosis and fault-tolerant control methods, and proposes a new framework for fault diagnosis and fault-tolerant control based on $\nu$-gap metric. The paper discusses further how to classify faults under this framework and proposes a general control structure for fault-tolerant control.-
Key words:
- Fault diagnosis /
- fault-tolerant control /
- $\nu$-gap metric /
- robust control /
- system identification
-
云服务[1]是一种当下热门的互联网模型, 它将软硬件资源进行整合, 以虚拟环境和裸机环境两种方式为用户提供对象存储、容量型、性能型等存储和计算功能. 一方面, 云平台可以隐藏复杂硬件特征, 用户无需具备专业计算机软、硬资源知识即可使用, 这种特性大大降低了个体运维成本; 另一方面, 虚拟技术为用户应用提供了独占资源环境, 可避免由资源共享带来的干扰[2-3]. 然而, 随着部署于云中的应用数量以及规模的急剧扩张, 云服务面临着一个难以忽视的高能耗问题. 在这种场景下, 在线迁移技术应时而生, 它可将应用在云中适时聚合与分离, 实现能耗可控性, 进而成为当下的研究热点之一. 深入研究有效的云端管理平台将对控制理论的发展和各种实际应用起到积极推动的作用[4-5].
与裸机在线迁移技术不同, 云进程在线迁移成本主要受两方面的影响: 虚拟执行环境和任务执行环境. 虚拟执行环境由应用执行所必须的虚拟机构成; 任务执行环境则包括任务自身执行状态, 所需输入、输出数据等. 当前云服务平台最主流的几种执行环境为KVM[6], VMware[7]和Xen[8]. 然而在迁移场景下, 由于程序运行局部性和磁盘I/O (Input/output)读写局限性原理, 导致记录磁盘的写操作会有较多的冗余, 它们高昂的管理开销、繁冗的管理层次更成为阻碍其发展的主要缺陷[9-10]. 鉴于虚拟机环境上述特征并不适于为大数据应用提供服务, 虚拟执行环境自身开销过高严重影响了在线迁移效率, 而轻量级容器利用自身低开销可以降低迁移系统自身的数据成本, 满足当前企业需求——高效、节能. 因此, 基于轻量级容器的迁移策略成为云服务相关技术中所急需的研究内容之一.
Docker[11]是目前热门的容器技术之一, 如图1所示, 根据最新RightScale[12]云计算调查报告显示Docker的采用率从2017年的35%增长到了2018年的49% (增长率为40%). 作为一款轻量级开源容器引擎, 有能力简化和快速部署应用隔离环境, 完成云平台不同企业应用之间的“隔离”需求.
在图2中, 分别对比了KVM和Docker的执行开销, 具体的实验是以内存带宽基准测试程序Stream的Copy, Scale, Add和Traid四个组件为例. 横坐标分别代表内存占用为20 ~ 800 MB, 纵坐标分别代表Stream四个组件随着脏页速率变化各自的数据处理能力. 实验结果表明, 对于内存密集型程序而言, KVM自身执行环境比Docker自身执行环境多出了20%以上的开销. 内存计算型任务的迁移成本是影响在线迁移效率的另一个重要因素, 将庞大的应用数据迁入内存, 降低与外设交互所引发的开销是实现大数据应用高效执行的重要手段. 然而, 在动态迁移的场景下, 庞大的内存数据迁移会带来高昂的迁移开销.
总的来说, 云端虚拟机迁移的成本主要源于两方面, 即虚拟机自身开销和用户应用所占据的资源开销. 单纯对某一方面进行管控, 都无法明显降低迁移成本. 根据对比Docker和KVM测试Stream发现, Docker技术已显著减少了虚拟机自身开销, 但仍然无法满足内存密集型或者大数据应用动态迁移的成本需求. 实际上, 诸如华为、阿里等主流云服务提供商对于动态迁移所产生的时刻和所迁往的目标都有明确的管理方法, 只要科学采用这些信息, 充分利用云平台的闲置资源, 提前将一部分必须且稳定的数据放在云端存储上, 那么将显著降低宿主机的数据规模, 减少宿主机在后续迁移过程中的开销. 此外, 待迁移开始之后, 利用网络并行性, 宿主机和云端存储同时将各自数据迁移至指定目的主机, 在线迁移将同时获益于宿主机数据规模缩小以及网络并行性.
本文提出一种新的基于云预存储技术的Docker在线迁移方法: PF-Docker, 该方法将预存技术与成熟的Pre-copy技术相结合, 充分利用云平台的网络和存储资源, 实现高效在线迁移. PF-Docker在应用程序平稳运行时, 将动态搜集用户数据行为, 并将稳定数据预存至闲置的网络存储资源上. 待在线迁移启动, 宿主机将对剩余数据实施基于Pre-copy的在线迁移, 而云存储中的数据将同时向目标机进行传输. PF-Docker明显受益于缩小的宿主机数据规模以及云平台中丰富的网络存储并行性. 实验结果说明, 相对于现有容器迁移方法, 本文方法在不同类型的服务负载下均能正确执行. 对于空负载的Docker容器, 本方法对比文献[13]中的迁移方法降低了25%的数据成本; 在高负载写密集环境下, 本方法降低了15%的数据成本迁移和减少了总传输时间11%; 在服务降级率方面, 本文Docker动态迁移框架比KVM动态迁移更加稳定.
本文主要贡献如下:
1)云服务和预存储结合的动态迁移策略. 在迁移命令下达之前, 在云端寻找空闲服务器作为数据管理平台, 宿主机在特定条件下将容器动态迁移的稳定数据预存储到云端存储; 在迁移命令下达之后, 云端存储与宿主机利用网络并行性同时向目的机传输数据.
2)轻量级容器Docker动态预存储迁移框架. 采用预存储、迭代传输和检查点恢复机制相结合的方式, 减少迭代次数与传输时间, 实现轻量级容器Docker动态预存储迁移.
3)引入限定预存储阈值触发策略. 设定服务器预负载的上限, 判断运行Docker容器的服务器是否满足预存储的条件, 防止预存储无效占用云端资源.
1. 相关工作研究
迁移技术一直是云计算研究的重点, 针对云端虚拟机环境动态迁移, 目前国内外已经有了许多相关的研究和方案. Collective项目比较早地支持了虚拟机在线迁移, 主要是面向无实时性和不确定性的服务, 为需要迁移计算程序的用户提供了便利[14]. Kozuch等[15]提出了一种采用Freeze-and-Copy的虚拟机在线迁移方法. Clark等[16]提出了一种采用Pre-copy内存迁移算法的虚拟机动态迁移机制, 目前基于Pre-copy算法的虚拟机动态迁移已经得到广泛使用, 当前流行的虚拟化工具如KVM、Xen和VMware都提供基于Pre-copy算法的虚拟机动态迁移机制. 清华大学周佳祥等[17]提出采用自适应双阈值进程动态迁移负载平衡系统. 北京大学张彬彬等[18]提出了一种三阶段全系统动态迁移算法TPM (Three-phase migration). 中国科学技术大学邵曦煜[19]提出了非共享存储的Ceph虚拟机动态迁移系统. 吉林大学赵佳[20]提出了一种新的高效迁移机制——HMDC和FMC. 北京航天航空大学的吕小虎等[21]也提出了一种基于虚拟机磁盘的动态迁移机制.
虽然业界对于虚拟化动态迁移技术已经有了很多的研究成果, 但针对容器动态迁移的相关研究仍处于起步阶段. Zap作为一个进程迁移的典型系统, 其设计目标是在网络计算体系结构下支持可迁移的计算环境, 但本身不支持动态迁移[22]. OpenVZ是目前容器迁移技术中相对成熟的技术之一, 通过修改内核来达到虚拟化的目的, 利用检查点恢复机制支持容器的动态迁移. 但OpenVZ本质是基于Linux内核和作业系统的操作系统虚拟化技术, 和主流容器技术有很大的区别, 动态迁移效率和传统虚拟机差别不大, 且主要问题在于OpenVZ只能使用经过特定补丁的内核. 相比之下, Docker容器技术直接从Linux内核进行虚拟化, 具有很大的优势. 针对容器迁移问题, 可以借助于进程组迁移原理来解决, 已有一些相关的开源工具和项目支持容器进程组迁移, 具体如CRIU[23], P.Haul[24]. Docker官方目前只支持离线迁移, 对于无状态容器, 迁移的过程为备份和恢复. 电子科技大学禹超[25]提出基于Linux容器的同步迁移文件系统机制FFSAS, 根据监控并记录Linux是容器对文件系统的修改, 将更改信息通过五元组的形式保存在高速缓存中, 最后同步到目的机, 减少整个迁移过程中的传输数据量, 但是这种机制很大程度上仅仅针对文件系统进程, 对于高负载写密集环境的云应用并不适用. 中国科学院大学胡丹琪[13]提出基于容器内部检查点恢复机制的Docker容器整体迁移框架, 通过runC调用CRIU来实现相应功能, 避免了P.Haul等工具迁移完成后需要重启Docker守护进程的限制, 但是忽视了容器内部系统数据, 导致传输的数据量和总传输时间依旧很高.
从降低开销的角度考虑容器动态迁移问题, 减少数据传输和优化迁移算法都是正确的选择之一[26-27], 但不同的应用场景和环境可能需要采用不同的策略和方法. 以内存程序为例: 不同源主机容器中运行程序的内存文件所占比例并不可控, 因此内存程序的传输能耗标准并不一致, 选择合适的方法并不容易. 对于本文中提出的Docker容器动态迁移策略, 实验发现减少源主机的传输数据量能直观感受到数据传输开销的降低. 采用云服务和预存储相结合的方式有利于降低整个动态迁移过程的性能影响、开销和提高数据传输效率.
2. PF-Docker基于预存储的动态迁移方法
本文提出基于云预存的PF-Docker算法, 用于解决云服务器中的高能耗、高负载和管理难等问题, 算法采用动态预存技术和成熟的Pre-copy技术, 以减少Docker容器动态迁移过程中宿主机的传输数据量, 并充分利用云服务网络和存储等资源来实现高效的Docker容器在线迁移. 具体流程如图3所示. PF-Docker主要由两部分构成: 动态云预存和动态迭代迁移. 当服务器和内部应用程序的运行状态趋于稳定时, PF-Docker自动进入到动态云预存阶段, 此阶段会定时动态搜集两种必要信息: 应用程序数据行为和服务器运行数据状况. 根据对运行在不同宿主机上的Docker容器应用程序和宿主机本身运行状态进行采样分析, 重点针对Docker容器自身挂载文件和内部应用程序输出数据等稳定的数据文件, 结合宿主机的CPU使用率、带宽传输比例和内存占比, 将符合条件的稳定数据文件(流动数据)动态预存至指定的处于空闲状态的网络存储资源上; 将不符合条件的数据(冗余数据)留在各自的宿主机上. 这两类数据呈正交, 彼此互斥, 共同组成了完整的程序运行数据空间. 当用户需要对服务器进行维护时, PF-Docker根据相关的命令进入到动态迭代迁移阶段, 它同时驱动宿主机和云端存储器向目标主机进行在线迁移. 网络目标机将对流动数据和部分冗余数据实施网络并行传输, 宿主机将对剩余冗余数据实施基于Pre-copy的动态迭代迁移, 以此保证云服务网络和存储的利用最大化, 实现高效的Docker容器的动态迁移.
图 3 基于预存储的容器动态迁移框架: PF-DockerFig. 3 Prestorage-based dynamic migration framework for containers: PF-Docker2.1 动态云预存
与传统数据预存技术[28]不同, 动态云预存技术通过阶段性对宿主机内部Docker应用程序的执行状态进行学习和分析, 选择符合某种特性的稳定数据, 将其在动态迁移之前预先传输至云端存储. 如图4所示. 根据对容器动态迁移进行实验分析, 发现在迁移过程的每次迭代时间开销主要由遍历、压缩和传输三部分构成. 其中遍历是指对应用程序所占内存页状态的遍历时间开销; 压缩是指在迭代传输期间一次迭代中压缩脏页和其他已变化信息的时间开销; 传输是指在迭代传输期间一次迭代中传输压缩数据的时间成本. 在容器动态迁移的每次迭代过程中, 对冗余数据的遍历结果重点分为已变化和无变化两种, 而传输阶段所传输数据主要为脏页和进程输出信息等已变化的运行数据, 进一步分析发现, 在这三个阶段中遍历和压缩的时间开销是影响迭代周期设置的重要因素. 而对于大数据应用而言, 遍历与压缩的成本会严重增加迭代周期, 进而影响容器的整体迁移时间. 在已有的研究成果中[29], 采取将压缩算法结合入迁移过程. 目前, 采用诸如LZ4[30]等最佳压缩算法可以将数据压缩到1%. 这个压缩比能大大减少迭代数据的传输量, 以此迅速完成数据的传输. 本文后续将使用LZ4作为标准压缩算法. 在压缩算法的配合下, 传输开销的分量将明显降低, 甚至可被忽略. 其中迭代迁移的开销计算方式如下
$$ \begin{equation} T_{{\rm{iter}}} = T_{{\rm{travs}}} + T_{{\rm{comp}}} \end{equation} $$ (1) 其中, $ {T_{{\rm{iter}}}} $表示迭代传输阶段时间间隔; $ {T_{{\rm{travs}}}} $表示在迭代期间一次遍历所有内存页的时间成本, 与进程所占内存大小密切相关; $ {T_{{\rm{comp}}}} $表示在迭代期间一次迭代中压缩脏页的时间成本, 与进程所占内存大小相关. 基于上述分析, 为了保证高效的网络传输和数据的均衡性, 本文根据对程序运行过程中的数据更改情况进行学习分析, 如式(2)所示, 在特定周期内, 数据修改频率大于这段时间的迭代次数, 那么将这种数据定义为稳定数据, 执行预存传输.
$$ \begin{equation} \eta = \sum\limits_{i = 1}^n{C_i}> \frac{{T}}{T_{{\rm{iter}}}} = \frac{{T}}{T_{{\rm{travs}}}+T_{{\rm{comp}}}} \end{equation} $$ (2) 为了描述这一问题, 本文对预存数据进行如下定义: 宿主机容器和内部进程数据单次修改频率为$ {C} $, 那么$ {n} $次数据修改频率为$ \eta = \sum\nolimits_{i = 1 }^n{C_i} $, 当迭代传输次数小于数据修改率$ \eta $时, 满足预存数据的定义, 进行有效的预存传输.
迁移总数据包含预存数据和宿主机数据, 而预存数据量与宿主机数据量成反比, 预存数据量越多, 则留在宿主机的数据量越少, 网络传输和云存储的利用率也就越高. 如图5所示, 预存数据分为Docker容器环境依赖和进程的数据文件, 其中Docker容器环境依赖包括基础镜像、子系统文件和挂载数据, 进程的数据文件包括应用的内存页、程序输出数据和进程执行信息. 分析发现Docker容器的环境依赖文件基本不会发生变化, 可以直接传给云端存储器; 而进程的数据文件会随着程序的运行发生改变, 这时需要采用动态预存算法对该部分数据文件进行分类处理, 寻找出符合条件的预存数据, 再传给云端存储器. 具体的预存传输过程分为以下两部分:
1)在宿主机和云端存储平台之间建立socket通信管道, 用于预存数据的传输;
2)利用Docker本身提供的inspect接口实现相关函数的调用, 获取与容器相关的数据信息, 将Docker容器运行所需的基础镜像、挂载数据、子系统文件和其他稳定的数据信息预存储到云端存储平台, 等待容器动态迁移命令下达.
在利用云预存储技术实现容器动态迁移的前提下, 为避免对宿主机容器进程的重复采样分析影响进程的自身执行情况, 本文采用限定阈值的方法来确定宿主机是否满足预存储的条件. 基于限定阈值的PF-Docker迁移方法需要综合考虑宿主机CPU、带宽、内存资源的利用率.
宿主机的CPU使用率为
$$ \begin{equation} P_{{\rm{cpu}}} = \frac{{\sum\limits_{i = 1}^n{D_{{\rm{cpu}}}{\left(\sum\limits_{i = 1}^nV_{d_i}\right)}}}}{S_{{\rm{cpu}}}} \end{equation} $$ (3) 其中, $ {V_{di}} $表示单个Docker容器在单个CPU中的使用率, ${D_{{\rm{cpu}}}{(\sum\nolimits_{i = 1}^n{V_{d_i})}}}$表示单个CPU在该物理节点所有Docker容器${d_i}$中使用率, $ {S_{{\rm{cpu}}}} $表示该物理服务器总的CPU使用率.
宿主机的带宽使用率为
$$ \begin{equation} P_{{\rm{bw}}} = \frac{{\sum\limits_{i = 1}^n{D_{{\rm{bw}}}{(i)}}}}{T_{{\rm{bw}}}} \end{equation} $$ (4) 其中, $ {D_{{\rm{bw}}}{(i)}} $表示Docker容器$ {d_i} $在该物理节点的带宽使用情况; $ {T_{{\rm{bw}}}} $表示该物理节点带宽流量的最大值.
宿主机的内存使用率为
$$ \begin{equation} P_{{\rm{mem}}} = \frac{{\sum\limits_{i = 1}^n{D_{{\rm{mem}}}{(i)}}}}{A_{{\rm{mem}}}} \end{equation} $$ (5) 其中, $ {D_{{\rm{mem}}}{(i)}} $表示Docker容器$ {d_i} $在该物理节点使用的内存大小; $ {A_{{\rm{mem}}}} $表示该物理节点总的内存大小. 云服务器节点的CPU、带宽、内存等资源的使用率可以用一个向量集合$ {P_{{\rm{coc}}} = {({P_{{\rm{cpu}}}},{P_{{\rm{mem}}}},{P_{{\rm{bw}}}})}} $表示.
通过预存储阈值设定算法的检测, 重点获取当前服务器中Docker容器内部任务的运行状况, 主要具有以下两点优势:
1)动态调控. 目前主流的任务类型主要分为: 计算密集型、内存密集型、多线程执行等. 用户首先可以根据 Docker 容器内部执行任务的类型来设定预存阈值的大小; 其次在保证任务正常运行的情况下, 根据主机之间的资源利用情况来调控预存阈值的大小, 保证资源的充分利用.
2)预存防积. 在Docker任务实际运行过程中, 针对计算和内存密集型等相关变化过快的类型, 为了防止频繁地触发预存, 影响Docker任务运行. 本文通过定时收集Docker任务的运行全局信息, 并在一定周期之内对全局数据比较并分析, 判断Docker任务的变化, 获取恰当的预存阈值参数, 防止预存积累, 减少资源损耗.
采集云服务器节点的CPU、带宽、内存等资源的物理数据时, 必须保证采集的数据具有准确性, 同时不能对节点运行的Docker容器产生影响. 在确定预存储的判定条件之后, 用户根据任务类型设定一个预存储的阈值$ {T_{{\rm{pre}}}} $. 在一定周期$ {T} $时间内, 如果服务器的$ {P_{{\rm{coc}}}} $值小于设定的阈值$ {T_{{\rm{pre}}}} $, 则该物理节点未达到预转储触发条件, 不用考虑预存储问题. 除此之外, 当$ {P_{{\rm{cpu}}}> {T_{{\rm{pre}}}{(P_{{\rm{cpu}}})}}} $, 即CPU使用率超过设定的CPU阈值时, CPU满足触发条件; 当$ {P_{{\rm{bw}}}< {T_{{\rm{pre}}}{(P_{{\rm{bw}}})}}} $, 即应用服务所需带宽占比低于带宽阈值时, 带宽满足触发条件; 当$ {P_{{\rm{mem}}}> {T_{{\rm{pre}}}{(P_{{\rm{mem}}})}}} $, 即内存使用率超过设定的内存阈值时, 内存满足触发条件. 以上各种情况均属于该物理节点满足预存储条件, 在针对不同类型任务的情况下, 采取不同的预设阈值. 具体触发流程的伪代码见算法1.
算法1. 预存储阈值触发判断算法
输入. $P_{\rm{coc}} $ ← $[P_{\rm{cpu}} $, $P_{\rm{bw}} $, $P_{\rm{mem}} ]$数组.
输出. 判断是否启动预存.
1: PRE_STORE ← True
2: PRE_SEND ← True
3: $T_{\rm{pre}} $ ← $\{T_{\rm{bw}} $, $T_{\rm{mem}} $, $T_{\rm{cpu}}\} $
4: handle = pre_file () // get container information
5: function PreSTore (PRE_SEND, $P_{\rm{coc}}) $
6: while PRE_STORE do
7: if $P_{\rm{coc}} $ < $T_{\rm{pre}} $ then
8: PRE_STORE ← False
9: else
10: if $P_{\rm{coc}} $.$P_{\rm{wb}}$ < $T_{\rm{pre}} $.$T_{\rm{wb}}$ then
11: handle.prestore (PRE_SEND)
12: send_data (prestore_data)
13: PRE_STORE ← False
14: else
15: if $P_{\rm{coc}} $.$P_{\rm{cpu}} $> $T_{\rm{pre}} $.$T_{\rm{cpu}} $ || $P_{\rm{coc}} $.$P_{\rm{mem}}$> $T_{\rm{pre}} $.$T_{\rm{mem}} $ then
16: handle.prestore (PRE_SEND)
17: send_data (prestore_data)
18: PRE_STORE ← False
19: end if
20: PRE_STORE ← True
21: end if
22: PRE_STORE ← True
23: end if
24: PRE_STORE ← True
25: end while
2.2 动态迭代迁移
综合考虑宿主机和目的主机之间没有共享存储硬件和软件环境, 以及${\rm{Docker}} $容器数据和系统文件的特殊性, 本文设计了一种基于预存储的Docker容器动态迁移框架, 采用Pre-copy算法结合检查点恢复操作的方法, 以此来实现云端Docker容器动态迁移.
在Docker容器动态迁移时, 主要在两个阶段进行容器内部进程运行的相关信息传输: 迭代拷贝和停机拷贝阶段. 前者主要传输内存页面信息, 首先将容器进程所有内存页面传输至目的主机, 再通过迭代循环实现脏页的更新, 当宿主机和目的主机之间的内存数据基本同步之后, 跳转至停机拷贝阶段; 后者将容器运行剩余脏页和状态信息传输至目的主机. 最后在目的主机上重启容器运行, 确保迁移的容器继续平稳运行.
具体流程如图6所示, 在宿主机、云端存储和目的主机三者之间分别建立 socket 通信管道, 用于数据的传输. 数据的传输主要分为初始传输、迭代传输和停机传输.
1)初始传输. 如图6中①所示, 在迁移命令下达之后, 宿主机给云端存储下达迁移命令, 云端存储将预存储数据传输的目的主机, 包括Docker容器重启所需的基础镜像、挂载数据和容器系统信息等相关数据.
2)迭代传输. 如图中②所示, 在宿主机向云端存储下达迁移命令的同时, 宿主机对Docker容器内部进程执行检查点预转储操作, 然后利用Linux内存跟踪机制获取修改后的内存页, 并迭代执行数据传输. 最后在满足一定的循环终止条件后, 结束迭代传输进入停机传输.
3)停机传输. 如图中③和④所示, 对宿主机上的Docker容器内部进程执行检查点转储操作, 挂起容器和容器内部运行的程序, 获取剩余的脏页和容器进程执行数据信息. 将检查点转储文件传输到目的主机上, 待目的主机完全接收到重启容器和进程所需的文件后, 执行重启容器操作. 如若重启成功, 则动态迁移正常结束, 删除宿主机上被挂起的Docker容器和进程, 并卸载相关文件目录, 删除云端存储上的所有预存数据文件. 反之容器与进程回到宿主机与云端存储, 恢复被挂起的Docker容器与进程.
基于预存储的Docker容器动态迁移, 物理机之间不需要共享存储硬件的支持, 降低了硬件环境的要求. 同时Docker容器本身开销相对于进程而言可以忽略不计, 利用Pre-copy算法进行迭代传输减少了迁移的总时间和停机时间.
3. 实验设计与分析
3.1 实验设计
本节从两个方面对PF-Docker迁移开销进行评估: 应用类型与并行度. 应用类型对在线迁移的开销有明显影响, 本节选取了两种代表性应用类型, 分别为内存计算密集型和I/O型. 其次, 本节还对并行程序的迁移开销进行了评估, 主要选取了多线程Linux内核编译.
本文分别从迁移总时间、宿主机迁移数据量和服务降级率3个方面来检测迁移效率, 为此选择了Loop测试和Stream测试两种具有代表性的测试用例来检测PF-Docker动态迁移的性能指标. 具体如表1所示.
表 1 实验负载类型表Table 1 Experimental load type table负载类型 具体配置 Loop测试 基础镜像为Ubuntu14.04.1, 在Ubuntu操作系统下执行永真循环打印程序(低负载写空闲) Stream基准测试 基础镜像为Ubuntu14.04.1, 通过设置不同的内存读写速率进行测试(高负载写密集) 多线程内核编译测试 在Ubuntu14.04.1上部署内核编译依赖环境, 生成镜像zx/Ubuntu1, 在不同线程下测试(并行程序写密集) PF-Docker框架的3台服务器操作系统均为Ubuntu14: 04.1, 内核的版本为4.2.0-36-generic, 安装相同版本CRIU和LM-Docker, 其中CRIU为2.12, LM-Docker是在官方Docker boucher目录下v1.9.0-experimental-cr.1版本基础上进行修改. 实验时Docker容器中部署ubuntu操作系统, 采用基础镜像为ubuntu14: 04.1, 大小为788 MB. 文献[13]框架的服务器与本文的框架硬件和软件配置一样, 不同之处在于文献[13]框架采用的是两台服务器.
3.2 评估方法
本文采用了文献[13]和[25]的评测方法, 分别从迁移总时间、宿主机迁移数据量、服务降级率3个方面对PF-Docker动态迁移方法进行评估.
1)迁移总时间: 是指迁移指令发起到整个迁移过程完成所耗费的总时间, 具体为
$$ \begin{equation} T_{{\rm{PF}}} = \sum\limits_{i = 1}^n{T_{{\text{pre-dump}}}{(i)}}+ {T_{{\rm{rover}}}} + {T_{{\rm{dump}}}} + {T_{{\rm{res}}}} \end{equation} $$ (6) 其中, $\sum\nolimits_{i = 1}^n{T_{{\text{pre-dump}}}{(i)}}$是迭代传输的总时间, ${T_{{\rm{rover}}}}$为流动数据和部分冗余数据传输时间, ${T_{{\rm{dump}}}}$是停机传输时间, ${T_{{\rm{res}}}}$是目的机重启容器进程的时间, 以上各部分时间构成了PF-Docker迁移总时间. 由于云服务中动态迁移应用场景多在负载均衡和在线升级维护上, 为了防止因突发情况导致动态迁移失败, 要求动态迁移总时间尽可能低.
2)总迁移数据量: 是指迁移指令发起到整个迁移过程完成所传输数据的总量, 具体为
$$ \begin{equation} D_{{\rm{PF}}} = \sum\limits_{j = 1}^n{D_{{\text{pre-dump}}}{(j)}}+ {D_{{\rm{rover}}}} + {D_{{\rm{dump}}}} + {D_{{\rm{edy}}}} \end{equation} $$ (7) 其中, ${\sum\nolimits_{j = 1}^n{D_{{\text{pre-dump}}}{(j)}}}$是迭代传输数据量, $ {D_{{\rm{rover}}}} $是流动数据量, $ {D_{{\rm{dump}}}} $是停机传输数据量, $ {D_{{\rm{edy}}}} $是部分冗余数据量, 以上各部分数据构成了PF-Docker迁移总数据量. 由于云服务中应用进程彼此之间对网络资源存在一定的竞争, 而传输数据占用的网络带宽与传输数据量的大小成正比, 为了减少服务器网络带宽的占用和降低对云服务网络I/O的影响, 动态迁移过程中传输的数据量越少越好.
3)服务降级率: 指动态迁移等其他服务操作对进程运行的影响, 具体为
$$ \begin{equation} S_{{\rm{PF}}} = \sum\limits_{a = 1}^n{D_{{\rm{checkpoint}}}{(a)}}+ {S_{{\rm{lm}}}} + {S_{{\rm{res}}}} \end{equation} $$ (8) 其中, $ {\sum\nolimits_{a = 1}^n{D_{{\rm{checkpoint}}}{(a)}}} $是检查点操作对容器进程服务影响, $ {S_{{\rm{lm}}}} $是容器停机传输过程中对容器内部运行进程的影响, $ {S_{{\rm{res}}}} $是重启容器服务对容器内部运行程序的影响. 因为动态迁移中传输数据会抢占整体云服务中的带宽资源, 频繁检查点操作还会占用服务器的CPU资源, 这都会对运行中的应用程序服务性能带来负面影响, 所以好的迁移方法在迁移过程中应尽量减少服务降级率.
3.3 实验结果分析
3.3.1 面向不同应用类型的迁移
3.3.1.1 Loop场景测试
在Loop测试场景下对比本文和文献[13]两种Docker迁移框架的性能. 如图7所示, 由于容器内部应用程序和容器自身的脏页产生率较低和网络传输的延迟性, 导致动态迭代迁移过程中的迁移算法和压缩算法带来的收益无法实现, 因此在传输时间开销上, 本文PF-Docker迁移框架对比文献[13]的Docker迁移框架不占优势. 但是由于数据预存储使得宿主机向目的主机传输的数据量降低了25%, 减少了宿主机的网络带宽使用, 降低了部分开销.
图 7 读写空闲场景下两种Docker动态迁移方法性能对比Fig. 7 Performance comparison of two Docker dynamic migration methods in read-write idle scenarios3.3.1.2 Stream场景测试
Stream测试是业界公认的内存带宽性能测试基准工具. 同Loop的读写空闲测试相比, Stream基准测试可以选择读写密集空间的测试. 为了分析在不同读写密集空间脏页率下PF-Docker容器动态迁移性能, 分别选取内存数据大小为20 MB, 50 MB, 100 MB, 200 MB, 300 MB, 400 MB, 500 MB, 600 MB, 700 MB, 800 MB, 900 MB, 1000 MB, 1500 MB和2000 MB 14组负载进行测试. PF-Docker将分别从总迁移时间和总迁移数据量两个方向和文献[13]的Docker迁移方法进行性能对比, 从应用程序服务降级率和KVM动态迁移进行性能对比.
由于Stream测试进程的脏页更新率与Stream进程的占用内存成正比. Docker动态迁移面临着随内存占用的增大, Stream测试进程的脏页更新率不断增大以及网络带宽的堵塞, 导致动态迁移长时间内无法实现数据的收敛, 增加了动态迁移针对脏页传输的迭代次数, 从而导致整个动态迁移的总时间会不断增加. 而在本文PF-Docker迁移框架中, 由于提前将数据预存储, 减少了预传输阶段对源主机网络带宽的堵塞, 使得动态迁移算法可以更快地实现数据的收敛.
图8为PF-Docker迁移框架和文献[13] 的Docker迁移框架在迁移总时间开销方面的对比, 分析发现当Stream的内存占用在500 MB之前时, 对比两种框架在总迁移时间并没有很大的变化, 然而在500 MB之后, 随着Stream内存占用的不断增大, 网络带宽堵塞的情况越来越严重, 导致容器动态迁移的数据收敛越来越困难, 而本文PF-Docker迁移框架在迁移总时间开销的效果就越来越明显, 总迁移时间相比于文献[13]的方法降低了20%.
图9为PF-Docker迁移框架数据总传输量和Docker迁移框架数据总传输量. 其中, 根据PF-Docker迁移框架的特殊性, 为更好地分析数据传输来源, 将其又细分为宿主机传输数据量和预存储传输数据量. 实验对比中, PF-Docker的数据总传输量始终低于Docker动态迁移框架, 并随着Stream内存占比的不断增加, 数据总传输量的优势越来越明显. 同时根据对PF-Docker的数据来源分析, 分为预存储和宿主机分别向目的主机传输, 而Docker迁移框架只采用宿主机向目的主机的传输方式, 对比分析发现在单一从宿主机向目的主机传输的数据量中, PF-Docker的宿主机传输量低于Docker迁移框架的宿主机传输量, 随着数据的收敛和迭代传输次数的减少, 在宿主机总迁移数据也降低了22%.
如图10所示, 实验测试内容包括Docker、PF-Docker、KVM和LM-KVM, 分别代表Docker本地执行、PF-Docker动态迁移、KVM本地执行和KVM动态迁移. 通过实验对比Docker、PF-Docker、KVM和LM-KVM在Stream执行时间随脏页速率的变化. 可以看到, PF-Docker动态迁移在脏页率较少时, 性能略差于KVM本地执行, 但随着脏页率增加, PF-Docker方法表现越好. 从图10中还可以看出, 在该实验场景下, Docker和KVM性能差异不是很大, 这是由于Stream测试中内存读写操作是连续的, 内核通过数据预取操作进行优化, KVM虚拟内存和宿主机物理内存映射次数较少. 这也是本文选择Stream测试工具作为对比分析动态迁移性能差异的原因.
图 10 Stream测试下PF-Docker与LM-KVM对比Fig. 10 The comparison of PF-Docker and LM-KVM under Stream test3.3.2 面向并行程序的迁移
以下对内核编译测试数据进行分析. 如图11所示, 对比Docker本地执行和KVM本地执行性能, 在8, 4, 2, 1四种多线程并发下本地KVM开销比Docker分别多耗了33.3%, 38.1%, 17.9%, 18.5%. PF-Docker动态迁移执行性能相比Docker本地分别下降了4.8%, 3.6%, 2.4%, 1.8%. KVM动态迁移执行性能相比KVM本地分别下降了21.4%, 17.2%, 183%, 78%. KVM动态迁移执行开销相比PF-Docker动态迁移分别多耗了54.6%, 56.3%, 225%, 107%. 由此可知, 在多线程并发高负载下PF-Docker动态迁移带来的服务降级率比KVM要低.
图 11 内核编译负载下Docker与KVM对比Fig. 11 The comparison of Docker and KVM under the kernel compilation load3.3.3 面向风险迁移过程
针对计算密集型和内存密集型的进程, 在迁移过程出现失败的几率会大大增加, 结合在第 2 节提到的3个预存条件(CPU、内存、带宽)和执行多线程编译任务的实验数据进行动态迁移的风险迁移分析.
如图12所示, 预存阶段频繁使用3个单一的阈值触发判定条件会一定程度影响计算密集型和内存密集型任务的运行状态, 本文通过预存阈值的动态调控机制, 同等环境下对比任务自身运行状态升高了7%, 但对比单一阈值判定条件对任务运行状态的影响降低了5%, 采用预存阈值动态调控机制, 能一定程度降低对任务本身运行状态的影响.
图 12 多线程内核编译在不同预存条件下对比Fig. 12 The comparison of multithreaded kernel compilation under different pre-stored conditions总的来说, 本文提出的基于Docker容器动态迁移预存储算法是在整个迁移过程中分别加入第三方数据管理平台、引入预存储阈值机制. 实验对比表明, 从总传输数据量、总迁移时间、服务降级率三个方面来看, 在Loop测试和Stream测试上, 本文框架比文献[13]中的框架从以下几个方面都有所降低, 其中包括数据量、传输时间等, 在Stream测试和内核编译测试上, 本文Docker迁移框架比KVM动态迁移服务性能更加优秀和稳定. 从而进一步提高了云中资源的利用率, 降低了部分服务器的高负载问题.
4. 结束语
随着云计算技术的高速发展, 如何降低能耗是保证高效利用云资源的前提. Docker作为目前业界使用率最高的容器引擎, 实现其动态迁移技术能有效降低能耗, 提高容器本身的容错率. 实验结果表明, 本文提出的基于Docker容器动态迁移预存储算法通过在容器迁移过程加入预存储机制和引入预存储阈值的操作, 使得容器迁移过程中减少了不必要的迁移, 从而提高了迁移的效率和降低了能耗, 可以帮助现有的云资源进行有效的利用和管理. 随着容器迁移技术的持续发展, 在后续研究中, 将会进一步考虑降低内存页的传输量和数据的存储开销, 研究并设计切实可行的相关算法, 最后从大规模任务、跨域云迁移等多种环境来证实算法的可行性, 使得容器迁移更加有效、节能.
-
图 7 闭环系统$T_1$, $T_2$和$T_3$阶跃响应
Fig. 7 Step responses of the closed-loop systems $T_1$, $T_2$ and $T_3$
图 9 故障按照对系统性能影响程度分级示意图
Fig. 9 Illustrative diagram for fault classification according to its impact on system performance
图 10 按$\nu$- 间隙度量分成故障等级示意图
Fig. 10 Illustrative diagram for fault classification according to $\nu$-gap metric
-
[1] Chen J, Patton R. Robust Model-Based Fault Diagnosis for Dynamic Systems. Springer, 1999. [2] Ding S X. Model-Based Fault Diagnosis Techniques -Design Schemes, Algorithms and Tools. 2nd Edition, Springer-Verlag, London, 2013. [3] Ding S X. Data-Driven Design of Fault Diagnosis and Fault-Tolerant Control Systems. Springer-Verlag, London, 2014. [4] Zhou K. Essentials of Robust Contro. Prentice-Hall, Englewood Cliffs, NJ, 1998. [5] Liu N, Zhou K. Optimal robust fault detection for linear discrete time systems. Journal of Control Science and Engineering, 2008, 2008(7): 1-16 http://ieeexplore.ieee.org/document/4434125/citations [6] Li X, Zhou K. A time domain approach to robust fault detection of linear time-varying systems. Automatica, 2009, 45(1): 94-102 doi: 10.1016/j.automatica.2008.07.017 [7] Vinnicombe G. Uncertainty and Feedback: Hinf Loop-Shaping and the V-Gap Metric. World Scientific, 2000. [8] Zhou K, Ren Z. A new controller architecture for high performance, robust, adaptive, and fault tolerant control. IEEE Transactions on Automatic Control, 2001, 46(10): 1613-1618 doi: 10.1109/9.956059 [9] Zhou K. A new approach to robust and fault tolerant control. Acta Automatica Sinca, 2005, 31(1): 43-55 [10] 周克敏. 鲁棒控制: 回顾与展望(黄琳院士主编《中国学科发展战略: 控制科学》第十二章). 科学出版社, 2015.Zhou K M. Robust control: Retrospect and prospect, (Huang Lin as Editor-in-Chief of the Chinese Discipline Development Strategy: Control Science, Chapter 12), Science Press, 2015. [11] Ding S X, Yang, Y, Zhang Y, Li L. Data-driven realization of kernel and image representations and their application to fault detection and control system design. Automatica, 2014, 50: 2615-2623 doi: 10.1016/j.automatica.2014.08.022 [12] Ding S X. Application of factorization and gap metric techniques to fault detection and isolation, Part Ⅰ and Part 2. IFAC Conference Paper Archive, 2015, 48(21): 113-124 http://www.sciencedirect.com/science/article/pii/S2405896315016420 [13] Georgiou T T. On the computation of the gap metric. Systems and Control Letters, 1988, 11: 253-257 doi: 10.1016/0167-6911(88)90067-9 [14] Georgiou T T, Smith M C. Optimal robustness in the gap metric. IEEE Transactions on Automatic Control, 1990, 35: 673-686 doi: 10.1109/9.53546 [15] Koenings T, Krueger M, Luo H, Ding S X. A data-driven computation method for the gap metric and the optimal stability margin. IEEE Transactions on Automatic Control, 2018, 63(3): 805-810 doi: 10.1109/TAC.2017.2735023 -
下载:
下载:
计量
- 文章访问数: 1373
- HTML全文浏览量: 1039
- PDF下载量: 686
- 被引次数: 0
