CN111381933A - 一种Docker热迁移实现方法 - Google Patents

一种Docker热迁移实现方法 Download PDF

Info

Publication number
CN111381933A
CN111381933A CN202010154292.XA CN202010154292A CN111381933A CN 111381933 A CN111381933 A CN 111381933A CN 202010154292 A CN202010154292 A CN 202010154292A CN 111381933 A CN111381933 A CN 111381933A
Authority
CN
China
Prior art keywords
container
memory
page
host
mem
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010154292.XA
Other languages
English (en)
Other versions
CN111381933B (zh
Inventor
王冠
孙悦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing University of Technology
Original Assignee
Beijing University of Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing University of Technology filed Critical Beijing University of Technology
Priority to CN202010154292.XA priority Critical patent/CN111381933B/zh
Publication of CN111381933A publication Critical patent/CN111381933A/zh
Application granted granted Critical
Publication of CN111381933B publication Critical patent/CN111381933B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/4557Distribution of virtual machine instances; Migration and load balancing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45575Starting, stopping, suspending or resuming virtual machine instances
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)

Abstract

本发明公开一种Docker热迁移实现方法。虽然现有的CRIU中已经支持部分热迁移相关的功能,但是无法将这些功能直接用于Docker热迁移,且现在Docker的官方版本并不支持热迁移。本发明利用共享文件系统NFS、CRIU以及自己添加的外部脚本实现了热迁移,并且在热迁移过程中针对高脏页率内存被重复拷贝的问题,增加了一个预测模块,在该模块中利用markov预测算法根据内存页当前被更改的频率预测其将来被更改的概率,将内存页分成高脏页率内存页和低脏页率内存页,在前期拷贝过程中先拷贝低脏页率内存页,该方法能够减少重复内存页的拷贝,进而减少迁移过程中传输的数据量,降低迁移时间,提高资源利用率。

Description

一种Docker热迁移实现方法
技术领域
本发明属于虚拟化技术热迁移领域,具体涉及一种Docker热迁移实现方法。
背景技术
Docker作为一种新兴的虚拟化方式,可以将应用程序及其依赖打包到一个可移植的镜像中,然后发布到任何流行的Linux或Windows机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。与传统的虚拟化方式相比,其具有诸多优势,例如:实现更快的交付和部署;高效的扩容;更高的资源利用率以及更简单的管理。
虚拟机热迁移是指在保证虚拟机中服务正常运行的同时,将其从一个物理主机拷贝到另一个物理主机,整个迁移过程对用户是透明的,即用户感觉不到虚拟机位置的变化。与传统虚拟机的热迁移研究相比,目前针对容器热迁移技术的研究还相对较少。其中对热迁移过程中的研究主要集中在如何降低内存页的传输量,因为虚拟机的内存在所有迁移状态中传输数据最多,耗时最长。
Zap是一种部分OS虚拟化技术,它通过修改linux内核来支持OS虚拟化功能,但是Zap不支持虚拟机的动态迁移。OpenVZ是目前操作系统级虚拟化技术中较成熟的技术之一,它是通过修改linux内核并创建容器来达到虚拟化的目的,虽然OpenVZ较好地支持了虚拟机的动态迁移,但是OpenVZ的本质是基于linux内核和作业系统的操作系统虚拟化技术,和主流的容器技术有很大的差别。LXC是另一个比较有竞争优势的操作系统级虚拟化技术,且LXC得到了linux内核主线的支持,实现LXC容器的热迁移可以借助进程迁移的机制来实现。Docker是现在流行的容器技术,但现在Docker的官方版本并不支持热迁移,虽然可以使用CRIU中的checkpoint/restore以及pre-dump等功能,但是Docker的官方版本并不能直接实现热迁移,必须借助一些外部脚本将一些支持热迁移的功能添加到Docker中。
本发明的目的是提供一种Docker热迁移实现方法,该方案的整体架构如图1所示,包括:
资源准备步骤:收集源主机和目的主机的网络带宽、目的主机的内存大小,完成目的主机的初始化和资源预留工作,为后续热迁移做准备。
热迁移步骤:调用热迁移模块,完成对源主机的检查点预转储操作,调用监控模块和预测模块对内存页再次被更改的概率进行预测,并向目的主机迭代传输内存页信息,使源主机和目的主机之间的内存数据基本同步。
停机拷贝步骤:将容器迭代拷贝过程中最后一轮产生的脏页、源主机的CPU状态和IO设备状态传输至目的主机。
目的主机恢复步骤:利用源主机传输过来的内存页文件、CPU状态和IO设备状态,在目的主机上恢复容器中进程的执行,使迁移之后的容器恢复运行,代替源主机继续向外提供服务。
在上述的Docker热迁移实现方法中,所述资源准备步骤具体包括:
步骤a1:收集有关源主机和目的主机的网络带宽、目的主机的内存大小,以及源主机上容器及其内部运行的应用所占的内存空间大小。
步骤a2:根据步骤a1收集到的信息判断目的主机上的内存大小是否大于源主机上容器及其内部运行的应用所占的内存空间大小。
步骤a3:根据步骤a2中的判断条件,如果目的主机上的内存大小小于源主机上容器及其内部运行的应用所占的内存空间大小,则目的主机中的内存不满足需求,就会停止容器热迁移的进行。
步骤a4:根据步骤a2中的判断条件,如果目的主机上的内存大小大于源主机上容器及其内部运行的应用所占的内存空间大小,则目的主机中的内存满足需求。在目的主机中预留出容器及其内部运行的应用所需要的内存空间。
步骤a5:在源主机和目的主机上分别安装NFS文件共享系统。
步骤a6:在源主机上安装容器的根文件系统rootfs,rootfs中通常包含了一个操作系统运行所需的文件系统,其中包括Docker镜像的文件内容以及运行docker容器的配置文件。
步骤a7:在源主机上设置容器的配置文件,设置在容器的/tmp处挂载一个tmpfs,并将容器的根文件系统rootfs设置为只读。
步骤a8:利用共享文件系统NFS同步容器的文件系统rootfs。
步骤a9:分别在源主机和目的主机上准备好迁移脚本。因为现有的Docker官方版本并不支持热迁移功能,因此,需要加入自己写好的脚本,实现热迁移。
其中,源主机端的脚本就是为了对客户端执行检查点操作和传输检查点文件。在源主机端的脚本中,定义了用于对内存进行预转储操作的函数pre-dump(),在该函数中,设置了对容器进程以pre-dump方式执行检查点checkpoint操作的命令,并将容器的内存信息存储到检查点文件,同时利用python库中的time()函数记录pre-dump操作的开始时间和结束时间。预转储完成之后,又定义了用于对内存进行转储操作的函数dump(),在该函数中将checkpoint命令设置为“--leave-running”模式,表示执行完checkpoint操作之后,容器继续运行。同时利用python库中的time()函数记录dump操作的开始时间和结束时间。预转储pre-dump和转储dump操作完成之后,再设置用于传输上述两个操作执行之后产生的检查点文件的函数,同时利用python库中的time()函数记录传输的开始时间和结束时间。
目的主机端的脚本用来侦听来自源主机端的迁移脚本的命令。在该脚本中,首先创建socket套接字,并将套接字绑定到本地主机和端口,建立socket连接,连接建立之后,目的主机开始在socket上监听源主机端的信号。当目的主机接收到源主机端传输检查点文件的信号时,会启动一个页服务器page-server,页服务器将会从源主机接收检查点文件,并将它放入挂载的tmpfs。源主机迭代传输完成,发出restore命令后,目的主机开始执行恢复命令restore,该命令执行完之后,如果返回0,则代表恢复成功,否则恢复失败。在这个过程中会利用python库中的time()函数记录开始时间和结束时间。以上操作完成之后,关闭源主机和目的主机的socket连接。
在上述的Docker热迁移实现方法中,所述热迁移步骤具体包括:
热迁移模块接收到资源收集模块发出的迁移命令之后,在源主机的客户端上运行迁移脚本中的迁移命令。具体流程如下所示:
步骤b1:宿主机对Docker容器内存进程执行检查点操作。
步骤b2:将步骤b1中产生的检查点文件,其中包括容器进程的所有内存页,传输到目的主机。
步骤b3:步骤b2中检查点文件传输的同时,记录当前轮pre-copy期间被改写过的页面。
步骤b4:监控模块将步骤b3中收集到的被改写过的页面传送给预测模块。
步骤b5:在预测模块中,利用markov预测算法根据内存页当前被更改的频率预测其将来被更改的概率。事先设置一个参数β,将其作为判断脏页率的阈值。β是属于(p0/2,2p0)的n的线性函数,在实验中取β=p0/2+np0/N。其中,p0表示内存页被修改时脏页率的增加值,n代表迭代次数,N=2n/3。如果markov的预测值小于β,则该内存页就属于低脏页率内存页;如果markov的预测值大于β,则该内存页就属于高脏页率内存页。
步骤b6:根据步骤b5,Markov预测算法的具体步骤包括:
步骤b6.1:为了便于表示,引入以下参数:Dirty Set、mem_send、mem_skip、mem_remain、β。Dirty Set:表示当前被修改的内存页集合即脏页集;mem_send:表示本轮最终要发送的脏页集合,不包括在预测过程中变成脏页的那部分内存;mem_skip:表示下轮需要传输的脏页;mem_remain:表示最后一轮传输的脏页。β是判断脏页率的阈值,这里取β=p0/2+np0/N。
步骤b6.2:在第n次迭代拷贝中,通过markov算法得到当前脏页集中每个内存页再次被修改的概率Pi。
步骤b6.3:根据步骤b6.2,若pi<β,则该内存页就属于低脏页率内存页,把该内存页放入本轮最终发送的脏页集合mem_send。
步骤b6.4:根据步骤b6.2,若pi>β,则该内存页就属于高脏页率内存页,把该内存页放入mem_skip。
步骤b6.5:每轮迭代,只拷贝mem_send集合中的脏页。
步骤b6.6:在下一轮迭代拷贝中,仍然通过预测模型得到pi,并通过pi与β的大小比较来决定将当前脏页放到mem_send还是mem_skip。
步骤b6.7:对于脏页集中的每个内存页Mi∈Dirty Set,如果Mi∈mem_send且pi>β,即Mi是上一轮保存下来的脏页并且在本轮迭代中其预测的再次被修改的概率大于阈值β,则将Mi放到mem_skip中,本轮不拷贝。
步骤b6.8:如果Mi∈mem_send且pi<β,即Mi是上一轮保存下来的脏页并且在本轮迭代中其预测的再次被修改的概率小于阈值β,则Mi仍存放到mem_send中。
步骤b6.9:如果
Figure BDA0002403536390000041
且pi<β,即Mi不是上一轮保存下来的脏页并且在本轮迭代中其预测值小于阈值,则把Mi放到mem_send中。
步骤b6.10:如果
Figure BDA0002403536390000051
Figure BDA0002403536390000052
且pi>β,即Mi不是上一轮保存下来的脏页并且在本轮迭代中也没有存放在mem_skip中,但是其预测值大于阈值,则把Mi放到mem_skip中,本轮不拷贝。
步骤b6.11:如果Mi∈mem_send且pi>页面传输速率,将会立即结束本轮迭代,之后再次重复以下过程:根据迭代次数n更新β,根据mem_skip更新mem_send,并清空mem_skip,首轮mem_send为所有内存页。
步骤b6.12:根据步骤b6.7-b6.11更新mem_skip和mem_send,如果本轮中传送的内存页数小于wws(进程页面的可写工作集),迭代终止,进入步骤b6.13。
步骤b6.13:由mem_skip更新mem_remain,结束脏页率计算,进入停机拷贝阶段。
步骤b7:第二轮pre-copy开始,每一轮只传送上一轮pre-copy期间产生的低脏页率内存页,即mem_send中存储的脏页集合,同时记录当前轮pre-copy期间产生的脏页,且每一轮迭代结束之后都要判断是否满足进入停机拷贝阶段的条件,即是否满足本轮中传送的内存页数小于wws(进程页面的可写工作集)。
步骤b8:根据步骤b7中的判断结果,如果满足进入停机拷贝的条件,就给冻结模块发送stop-and-copy命令,挂起虚拟机,并向目的主机同步迭代拷贝过程中最后一轮产生的脏页以及源主机的CPU状态和IO设备状态。
步骤b9:根据步骤b7中的判断结果,如果不满足进入停机拷贝的条件,就继续下一轮迭代传输。
在上述的Docker热迁移实现方法中,所述停机拷贝步骤具体包括:
步骤c1:获取容器迭代拷贝过程中最后一轮产生的脏页以及源主机的CPU状态和IO设备状态。
步骤c2:将步骤c1中收集到的迭代过程最后一轮产生的脏页、源主机的CPU状态和IO设备状态传输至目的主机。
在上述的Docker热迁移实现方法中,所述目的主机恢复步骤具体包括:
步骤d1:目的主机上的冻结模块收到源主机热迁移模块发送的唤醒信号之后,开始执行restore命令。
步骤d2:restore命令从checkpoint目录读取检查点,利用源主机传输过来的检查点文件、CPU状态和IO设备状态,恢复目的主机容器中进程的运行,将所有内容还原到在检查点期间的状态。
步骤d3:容器恢复成功,开始运行之后,代替源主机上的容器继续向外提供服务。
步骤d4:结束源主机上容器中所有的进程,删除源主机上的容器,并且卸载它的文件系统。
步骤d5:若步骤d2中容器重启失败,则恢复源主机上被挂起的Docker容器与进程。
本发明具有如下优点:通过在源宿主机和目的宿主机上引入共享文件系统NFS,简化了文件传输过程,加快了热迁移速度。通过在热迁移过程中引入markov预测算法,减少了高频脏页被重复传输的概率,进而减少了数据传输总量,缩短了迁移时间,该方案能够实现Docker热迁移并且对热迁移过程进行了优化。
附图说明
图1是本发明的热迁移总体框架图。
图2是本发明的源宿主机端迁移流程图。
图3是本发明的目的主机端迁移流程图。
具体实施方式
本发明的目的是提供一种Docker热迁移实现方法,该方案的整体框架如图1所示,主要包括:资源准备模块,热迁移模块,停机拷贝模块以及目的主机恢复模块。接下来将会对以上四个模块进行详细介绍:
一、资源准备模块
该模块主要是收集源主机和目的主机的网络带宽、目的主机的内存大小,完成目的主机的初始化和资源预留工作,为后续热迁移做准备。主要实施步骤如下:
步骤a1:收集有关源主机和目的主机的网络带宽、目的主机的内存大小,以及源主机上容器及其内部运行的应用所占的内存空间大小。
步骤a2:根据步骤a1收集到的信息判断目的主机上的内存大小是否大于源主机上容器及其内部运行的应用所占的内存空间大小。
步骤a3:根据步骤a2中的判断条件,如果目的主机上的内存大小小于源主机上容器及其内部运行的应用所占的内存空间大小,则目的主机中的内存不满足需求,就会停止容器热迁移的进行。
步骤a4:根据步骤a2中的判断条件,如果目的主机上的内存大小大于源主机上容器及其内部运行的应用所占的内存空间大小,则目的主机中的内存满足需求。在目的主机中预留出容器及其内部运行的应用所需要的内存空间。
步骤a5:在源主机和目的主机上分别安装NFS文件共享系统。
步骤a6:在源主机上安装容器的根文件系统rootfs,rootfs中通常包含了一个操作系统运行所需的文件系统,其中包括Docker镜像的文件内容以及运行docker容器的配置文件。
步骤a7:在源主机上设置容器的配置文件,设置在容器的/tmp处挂载一个tmpfs,并将容器的根文件系统rootfs设置为只读。
步骤a8:利用共享文件系统NFS同步容器的文件系统rootfs。
步骤a9:分别在源主机和目的主机上准备好迁移脚本。因为现有的Docker官方版本并不支持热迁移功能,因此,需要加入自己写好的脚本,实现热迁移。
其中,源主机端的脚本就是为了对客户端执行检查点操作和传输检查点文件。在源主机端的脚本中,定义了用于对内存进行预转储操作的函数pre-dump(),在该函数中,设置了对容器进程以pre-dump方式执行检查点checkpoint操作的命令,并将容器的内存信息存储到检查点文件,同时利用python库中的time()函数记录pre-dump操作的开始时间和结束时间。预转储完成之后,又定义了用于对内存进行转储操作的函数dump(),在该函数中将checkpoint命令设置为“--leave-running”模式,表示执行完checkpoint操作之后,容器继续运行。同时利用python库中的time()函数记录dump操作的开始时间和结束时间。预转储pre-dump和转储dump操作完成之后,再设置用于传输上述两个操作执行之后产生的检查点文件的函数,同时利用python库中的time()函数记录传输的开始时间和结束时间。
目的主机端的脚本用来侦听来自源主机端的迁移脚本的命令。在该脚本中,首先创建socket套接字,并将套接字绑定到本地主机和端口,建立socket连接,连接建立之后,目的主机开始在socket上监听源主机端的信号。当目的主机接收到源主机端传输检查点文件的信号时,会启动一个页服务器page-server,页服务器将会从源主机接收检查点文件,并将它放入挂载的tmpfs。源主机迭代传输完成,发出restore命令后,目的主机开始执行恢复命令restore,该命令执行完之后,如果返回0,则代表恢复成功,否则恢复失败。在这个过程中会利用python库中的time()函数记录开始时间和结束时间。以上操作完成之后,关闭源主机和目的主机的socket连接。
二、热迁移模块
该模块主要是调用热迁移模块,完成对源主机的检查点预转储操作,调用监控模块和预测模块对内存页再次被更改的概率进行预测,并向目的主机迭代传输内存页信息,使源主机和目的主机之间的内存数据基本同步。主要实施步骤如下:
热迁移模块接收到资源收集模块发出的迁移命令之后,在源主机的客户端上运行迁移脚本中的迁移命令。主要实施步骤如下:
步骤b1:宿主机对Docker容器内存进程执行检查点操作。
步骤b2:将步骤b1中产生的检查点文件,其中包括容器进程的所有内存页,传输到目的主机。
步骤b3:步骤b2中检查点文件传输的同时,记录当前轮pre-copy期间被改写过的页面。
步骤b4:监控模块将步骤b3中收集到的被改写过的页面传送给预测模块。
步骤b5:在预测模块中,利用markov预测算法根据内存页当前被更改的频率预测其将来被更改的概率。事先设置一个参数β,将其作为判断脏页率的阈值。β是属于(p0/2,2p0)的n的线性函数,在实验中取β=p0/2+np0/N。其中,p0表示内存页被修改时脏页率的增加值,n代表迭代次数,N=2n/3。如果markov的预测值小于β,则该内存页就属于低脏页率内存页;如果markov的预测值大于β,则该内存页就属于高脏页率内存页。
步骤b6:根据步骤b5,Markov预测算法的具体步骤包括:
步骤b6.1:为了便于表示,引入以下参数:Dirty Set、mem_send、mem_skip、mem_remain、β。Dirty Set:表示当前被修改的内存页集合即脏页集;mem_send:表示本轮最终要发送的脏页集合,不包括在预测过程中变成脏页的那部分内存;mem_skip:表示下轮需要传输的脏页;mem_remain:表示最后一轮传输的脏页。β是判断脏页率的阈值,这里取β=p0/2+np0/N。
步骤b6.2:在第n次迭代拷贝中,通过markov算法得到当前脏页集中每个内存页再次被修改的概率Pi。
步骤b6.3:根据步骤b6.2,若pi<β,则该内存页就属于低脏页率内存页,把该内存页放入本轮最终发送的脏页集合mem_send。
步骤b6.4:根据步骤b6.2,若pi>β,则该内存页就属于高脏页率内存页,把该内存页放入mem_skip。
步骤b6.5:每轮迭代,只拷贝mem_send集合中的脏页。
步骤b6.6:在下一轮迭代拷贝中,仍然通过预测模型得到pi,并通过pi与β的大小比较来决定将当前脏页放到mem_send还是mem_skip。
步骤b6.7:对于脏页集中的每个内存页Mi∈Dirty Set,如果Mi∈mem_send且pi>β,即Mi是上一轮保存下来的脏页并且在本轮迭代中其预测的再次被修改的概率大于阈值β,则将Mi放到mem_skip中,本轮不拷贝。
步骤b6.8:如果Mi∈mem_send且pi<β,即Mi是上一轮保存下来的脏页并且在本轮迭代中其预测的再次被修改的概率小于阈值β,则Mi仍存放到mem_send中。
步骤b6.9:如果
Figure BDA0002403536390000091
且pi<β,即Mi不是上一轮保存下来的脏页并且在本轮迭代中其预测值小于阈值,则把Mi放到mem_send中。
步骤b6.10:如果
Figure BDA0002403536390000092
Figure BDA0002403536390000093
且pi>β,即Mi不是上一轮保存下来的脏页并且在本轮迭代中也没有存放在mem_skip中,但是其预测值大于阈值,则把Mi放到mem_skip中,本轮不拷贝。
步骤b6.11:如果Mi∈mem_send且pi>页面传输速率,将会立即结束本轮迭代,之后再次重复以下过程:根据迭代次数n更新β,根据mem_skip更新mem_send,并清空mem_skip,首轮mem_send为所有内存页。
步骤b6.12:根据步骤b6.7-b6.11更新mem_skip和mem_send,如果本轮中传送的内存页数小于wws(进程页面的可写工作集),迭代终止,进入步骤b6.13。
步骤b6.13:由mem_skip更新mem_remain,结束脏页率计算,进入停机拷贝阶段。
步骤b7:第二轮pre-copy开始,每一轮只传送上一轮pre-copy期间产生的低脏页率内存页,即mem_send中存储的脏页集合,同时记录当前轮pre-copy期间产生的脏页,且每一轮迭代结束之后都要判断是否满足进入停机拷贝阶段的条件,即是否满足本轮中传送的内存页数小于wws(进程页面的可写工作集)。
步骤b8:根据步骤b7中的判断结果,如果满足进入停机拷贝的条件,就给冻结模块发送stop-and-copy命令,挂起虚拟机,并向目的主机同步迭代拷贝过程中最后一轮产生的脏页以及源主机的CPU状态和IO设备状态。
步骤b9:根据步骤b7中的判断结果,如果不满足进入停机拷贝的条件,就继续下一轮迭代传输。
三、停机拷贝模块
该模块主要是将容器迭代拷贝过程中最后一轮产生的脏页、源主机的CPU状态和IO设备状态传输至目的主机。主要实施步骤如下:
步骤c1:获取容器迭代拷贝过程中最后一轮产生的脏页以及源主机的CPU状态和IO设备状态。
步骤c2:将步骤c1中收集到的迭代过程最后一轮产生的脏页、源主机的CPU状态和IO设备状态传输至目的主机。
四、目的主机恢复模块
该模块主要是利用源主机传输过来的内存页文件、CPU状态和IO设备状态,在目的主机上恢复容器中进程的执行,使迁移之后的容器恢复运行,代替源主机继续向外提供服务。主要实施步骤如下:
步骤d1:目的主机上的冻结模块收到源主机热迁移模块发送的唤醒信号之后,开始执行restore命令。
步骤d2:restore命令从checkpoint目录读取检查点,利用源主机传输过来的检查点文件、CPU状态和IO设备状态,恢复目的主机容器中进程的运行,将所有内容还原到在检查点期间的状态。
步骤d3:容器恢复成功,开始运行之后,代替源主机上的容器继续向外提供服务。
步骤d4:结束源主机上容器中所有的进程,删除源主机上的容器,并且卸载它的文件系统。
步骤d5:若步骤d2中容器重启失败,则恢复源主机上被挂起的Docker容器与进程。

Claims (5)

1.一种Docker热迁移实现方法,其特征在于,该方法包括如下步骤:
资源准备步骤:收集源主机和目的主机的网络带宽、目的主机的内存大小,完成目的主机的初始化和资源预留工作,为后续热迁移做准备;
热迁移步骤:调用热迁移模块,完成对源主机的检查点预转储操作,调用监控模块和预测模块对内存页再次被更改的概率进行预测,并向目的主机迭代传输内存页信息,使源主机和目的主机之间的内存数据同步;
停机拷贝步骤:将容器迭代拷贝过程中最后一轮产生的脏页、源主机的CPU状态和IO设备状态传输至目的主机;
目的主机恢复步骤:利用源主机传输过来的内存页文件、CPU状态和IO设备状态,在目的主机上恢复容器中进程的执行,使迁移之后的容器恢复运行,代替源主机继续向外提供服务。
2.根据权利要求1所述的Docker热迁移实现方法,其特征在于,所述资源准备步骤具体包括:
步骤a1:收集有关源主机和目的主机的网络带宽、目的主机的内存大小,以及源主机上容器及其内部运行的应用所占的内存空间大小;
步骤a2:根据步骤a1收集到的信息判断目的主机上的内存大小是否大于源主机上容器及其内部运行的应用所占的内存空间大小;
步骤a3:根据步骤a2中的判断条件,如果目的主机上的内存大小小于源主机上容器及其内部运行的应用所占的内存空间大小,则目的主机中的内存不满足需求,就会停止容器热迁移的进行;
步骤a4:根据步骤a2中的判断条件,如果目的主机上的内存大小大于源主机上容器及其内部运行的应用所占的内存空间大小,则目的主机中的内存满足需求;在目的主机中预留出容器及其内部运行的应用所需要的内存空间;
步骤a5:在源主机和目的主机上分别安装NFS文件共享系统;
步骤a6:在源主机上安装容器的根文件系统rootfs,rootfs中通常包含了一个操作系统运行所需的文件系统,其中包括Docker镜像的文件内容以及运行docker容器的配置文件;
步骤a7:在源主机上设置容器的配置文件,设置在容器的/tmp处挂载一个tmpfs,并将容器的根文件系统rootfs设置为只读;
步骤a8:利用共享文件系统NFS同步容器的文件系统rootfs;
步骤a9:分别在源主机和目的主机上准备好迁移脚本;因为现有的Docker官方版本并不支持热迁移功能,因此,需要加入自己写好的脚本,实现热迁移;
其中,源主机端的脚本就是为了对客户端执行检查点操作和传输检查点文件;在源主机端的脚本中,定义了用于对内存进行预转储操作的函数pre-dump(),在该函数中,设置了对容器进程以pre-dump方式执行检查点checkpoint操作的命令,并将容器的内存信息存储到检查点文件,同时利用python库中的time()函数记录pre-dump操作的开始时间和结束时间;预转储完成之后,又定义了用于对内存进行转储操作的函数dump(),在该函数中将checkpoint命令设置为“--leave-running”模式,表示执行完checkpoint操作之后,容器继续运行;同时利用python库中的time()函数记录dump操作的开始时间和结束时间;预转储pre-dump和转储dump操作完成之后,再设置用于传输上述两个操作执行之后产生的检查点文件的函数,同时利用python库中的time()函数记录传输的开始时间和结束时间;
目的主机端的脚本用来侦听来自源主机端的迁移脚本的命令;在该脚本中,首先创建socket套接字,并将套接字绑定到本地主机和端口,建立socket连接,连接建立之后,目的主机开始在socket上监听源主机端的信号;当目的主机接收到源主机端传输检查点文件的信号时,会启动一个页服务器page-server,页服务器将会从源主机接收检查点文件,并将它放入挂载的tmpfs;源主机迭代传输完成,发出restore命令后,目的主机开始执行恢复命令restore,该命令执行完之后,如果返回0,则代表恢复成功,否则恢复失败;在这个过程中会利用python库中的time()函数记录开始时间和结束时间;以上操作完成之后,关闭源主机和目的主机的socket连接。
3.根据权利要求1所述的Docker热迁移实现方法,其特征在于,所述热迁移步骤具体包括:
热迁移模块接收到资源收集模块发出的迁移命令之后,在源主机的客户端上运行迁移脚本中的迁移命令;具体流程如下所示:
步骤b1:宿主机对Docker容器内存进程执行检查点操作;
步骤b2:将步骤b1中产生的检查点文件,其中包括容器进程的所有内存页,传输到目的主机;
步骤b3:步骤b2中检查点文件传输的同时,记录当前轮pre-copy期间被改写过的页面;
步骤b4:监控模块将步骤b3中收集到的被改写过的页面传送给预测模块;
步骤b5:在预测模块中,利用markov预测算法根据内存页当前被更改的频率预测其将来被更改的概率;事先设置一个参数β,将其作为判断脏页率的阈值;β是属于(p0/2,2p0)的n的线性函数,在实验中取β=p0/2+np0/N;其中,p0表示内存页被修改时脏页率的增加值,n代表迭代次数,N=2n/3;如果markov的预测值小于β,则该内存页就属于低脏页率内存页;如果markov的预测值大于β,则该内存页就属于高脏页率内存页;
步骤b6:根据步骤b5,Markov预测算法的具体步骤包括:
步骤b6.1:为了便于表示,引入以下参数:Dirty Set、mem_send、mem_skip、mem_remain、β;Dirty Set:表示当前被修改的内存页集合即脏页集;mem_send:表示本轮最终要发送的脏页集合,不包括在预测过程中变成脏页的那部分内存;mem_skip:表示下轮需要传输的脏页;mem_remain:表示最后一轮传输的脏页;β是判断脏页率的阈值,这里取β=p0/2+np0/N;
步骤b6.2:在第n次迭代拷贝中,通过markov算法得到当前脏页集中每个内存页再次被修改的概率Pi;
步骤b6.3:根据步骤b6.2,若pi<β,则该内存页就属于低脏页率内存页,把该内存页放入本轮最终发送的脏页集合mem_send;
步骤b6.4:根据步骤b6.2,若pi>β,则该内存页就属于高脏页率内存页,把该内存页放入mem_skip;
步骤b6.5:每轮迭代,只拷贝mem_send集合中的脏页;
步骤b6.6:在下一轮迭代拷贝中,仍然通过预测模型得到pi,并通过pi与β的大小比较来决定将当前脏页放到mem_send还是mem_skip;
步骤b6.7:对于脏页集中的每个内存页Mi∈Dirty Set,如果Mi∈mem_send且pi>β,即Mi是上一轮保存下来的脏页并且在本轮迭代中其预测的再次被修改的概率大于阈值β,则将Mi放到mem_skip中,本轮不拷贝;
步骤b6.8:如果Mi∈mem_send且pi<β,即Mi是上一轮保存下来的脏页并且在本轮迭代中其预测的再次被修改的概率小于阈值β,则Mi仍存放到mem_send中;
步骤b6.9:如果
Figure FDA0002403536380000031
且pi<β,即Mi不是上一轮保存下来的脏页并且在本轮迭代中其预测值小于阈值,则把Mi放到mem_send中;
步骤b6.10:如果
Figure FDA0002403536380000041
Figure FDA0002403536380000042
且pi>β,即Mi不是上一轮保存下来的脏页并且在本轮迭代中也没有存放在mem_skip中,但是其预测值大于阈值,则把Mi放到mem_skip中,本轮不拷贝;
步骤b6.11:如果Mi∈mem_send且pi>页面传输速率,将会立即结束本轮迭代,之后再次重复以下过程:根据迭代次数n更新β,根据mem_skip更新mem_send,并清空mem_skip,首轮mem_send为所有内存页;
步骤b6.12:根据步骤b6.7-b6.11更新mem_skip和mem_send,如果本轮中传送的内存页数小于wws(进程页面的可写工作集),迭代终止,进入步骤b6.13;
步骤b6.13:由mem_skip更新mem_remain,结束脏页率计算,进入停机拷贝阶段;
步骤b7:第二轮pre-copy开始,每一轮只传送上一轮pre-copy期间产生的低脏页率内存页,即mem_send中存储的脏页集合,同时记录当前轮pre-copy期间产生的脏页,且每一轮迭代结束之后都要判断是否满足进入停机拷贝阶段的条件,即是否满足本轮中传送的内存页数小于进程页面的可写工作集wws;
步骤b8:根据步骤b7中的判断结果,如果满足进入停机拷贝的条件,就给冻结模块发送stop-and-copy命令,挂起虚拟机,并向目的主机同步迭代拷贝过程中最后一轮产生的脏页以及源主机的CPU状态和IO设备状态;
步骤b9:根据步骤b7中的判断结果,如果不满足进入停机拷贝的条件,就继续下一轮迭代传输。
4.根据权利要求1所述的Docker热迁移实现方法,其特征在于,所述停机拷贝步骤具体包括:
步骤c1:获取容器迭代拷贝过程中最后一轮产生的脏页以及源主机的CPU状态和IO设备状态;
步骤c2:将步骤c1中收集到的迭代过程最后一轮产生的脏页、源主机的CPU状态和IO设备状态传输至目的主机。
5.根据权利要求1所述的Docker热迁移实现方法,其特征在于,所述目的主机恢复步骤具体包括:
步骤d1:目的主机上的冻结模块收到源主机热迁移模块发送的唤醒信号之后,开始执行restore命令;
步骤d2:restore命令从checkpoint目录读取检查点,利用源主机传输过来的检查点文件、CPU状态和IO设备状态,恢复目的主机容器中进程的运行,将所有内容还原到在检查点期间的状态;
步骤d3:容器恢复成功,开始运行之后,代替源主机上的容器继续向外提供服务;
步骤d4:结束源主机上容器中所有的进程,删除源主机上的容器,并且卸载它的文件系统;
步骤d5:若步骤d2中容器重启失败,则恢复源主机上被挂起的Docker容器与进程。
CN202010154292.XA 2020-03-07 2020-03-07 一种Docker热迁移实现方法 Active CN111381933B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010154292.XA CN111381933B (zh) 2020-03-07 2020-03-07 一种Docker热迁移实现方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010154292.XA CN111381933B (zh) 2020-03-07 2020-03-07 一种Docker热迁移实现方法

Publications (2)

Publication Number Publication Date
CN111381933A true CN111381933A (zh) 2020-07-07
CN111381933B CN111381933B (zh) 2023-09-22

Family

ID=71217230

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010154292.XA Active CN111381933B (zh) 2020-03-07 2020-03-07 一种Docker热迁移实现方法

Country Status (1)

Country Link
CN (1) CN111381933B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112241305A (zh) * 2020-10-21 2021-01-19 海光信息技术股份有限公司 虚拟机脏页处理方法、处理芯片、计算机设备及存储介质
CN117290075A (zh) * 2023-11-23 2023-12-26 苏州元脑智能科技有限公司 进程迁移方法、系统、装置、通信设备及存储介质
WO2024119924A1 (zh) * 2022-12-05 2024-06-13 华为技术有限公司 进程的迁移方法、装置及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014082459A1 (zh) * 2012-11-30 2014-06-05 华为技术有限公司 实现虚拟机热迁移的方法、装置及系统
CN105335223A (zh) * 2014-06-20 2016-02-17 富士通株式会社 源主机和目的主机上的虚拟机内存迁移装置、方法及系统
CN107526626A (zh) * 2017-08-24 2017-12-29 武汉大学 一种基于CRIU的Docker容器热迁移方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014082459A1 (zh) * 2012-11-30 2014-06-05 华为技术有限公司 实现虚拟机热迁移的方法、装置及系统
CN105335223A (zh) * 2014-06-20 2016-02-17 富士通株式会社 源主机和目的主机上的虚拟机内存迁移装置、方法及系统
CN107526626A (zh) * 2017-08-24 2017-12-29 武汉大学 一种基于CRIU的Docker容器热迁移方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
李阳阳;: "基于开源KVM的服务器虚拟机迁移方案研究" *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112241305A (zh) * 2020-10-21 2021-01-19 海光信息技术股份有限公司 虚拟机脏页处理方法、处理芯片、计算机设备及存储介质
CN112241305B (zh) * 2020-10-21 2023-01-31 海光信息技术股份有限公司 虚拟机脏页处理方法、处理芯片、计算机设备及存储介质
WO2024119924A1 (zh) * 2022-12-05 2024-06-13 华为技术有限公司 进程的迁移方法、装置及系统
CN117290075A (zh) * 2023-11-23 2023-12-26 苏州元脑智能科技有限公司 进程迁移方法、系统、装置、通信设备及存储介质
CN117290075B (zh) * 2023-11-23 2024-02-27 苏州元脑智能科技有限公司 进程迁移方法、系统、装置、通信设备及存储介质

Also Published As

Publication number Publication date
CN111381933B (zh) 2023-09-22

Similar Documents

Publication Publication Date Title
AU623708B2 (en) Method for loading an operating system through a network
CN111381933A (zh) 一种Docker热迁移实现方法
US7412578B2 (en) Snapshot creating method and apparatus
EP2306320B1 (en) Server image migration
US8745614B2 (en) Method and system for firmware upgrade of a storage subsystem hosted in a storage virtualization environment
CN101398770B (zh) 迁移一个或多个虚拟机的系统和方法
EP2467782B1 (en) Proxy backup of virtual disk image files on nas devices
CN102959518B (zh) 把文件系统恢复到目标存储器的计算机执行的方法和系统
US9547562B1 (en) Boot restore system for rapidly restoring virtual machine backups
EP2945065A2 (en) Real time cloud bursting
CN106062742B (zh) 用于改进快照性能的系统和方法
CN102713856B (zh) 用于恢复在计算机系统内的文件系统的方法和系统
US20110208929A1 (en) In-place virtualization during operating system installation
CN105446826A (zh) 虚拟机备份、恢复的方法及设备
Van Hensbergen et al. Dynamic policy disk caching for storage networking
WO2012033554A1 (en) On demand virtual machine image streaming
CN106469117B (zh) 一种用于虚拟机存储迁移的存储资源管理方法及装置
CN110990133B (zh) 边缘计算服务迁移方法、装置、电子设备及介质
US11921593B2 (en) Multi-phase file recovery from cloud environments
CN112286640B (zh) 一种基于CRIU的Podman自动迁移系统及方法
CN1276349C (zh) 一种机群跨平台并行系统镜像备份的方法
CN110928624A (zh) 用于用户终端的云桌面调用方法、装置及终端
CN114490176B (zh) 一种Linux跨磁盘卷组的灾备系统以及灾备方法
CN113515410B (zh) 一种虚拟机保护系统及实现方法
WO2006045217A1 (en) Incremental provisioning of software

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant