Checkpoint:CRIU的使用
Checkpoint/Restore是分布式系统容错领域的重要技术,本篇介绍了一个实现CR的工具的使用。CRIU:Checkpoint/Restore in Userspace是Linux平台在用户空间实现checkpoint/restore功能的工具软件。通过该工具,可以冻结正在运行的应用程序或者其中的一部分,并将应用程序的执行状态以文件形式保存在磁盘上,然后通过这些快照文件,...
Checkpoint/Restore是分布式系统容错领域的重要技术,本篇介绍了一个实现CR的工具的使用。
CRIU:Checkpoint/Restore in Userspace
是Linux平台在用户空间实现checkpoint/restore功能的工具软件。通过该工具,可以冻结正在运行的应用程序或者其中的一部分,并将应用程序的执行状态以文件形式保存在磁盘上,然后通过这些快照文件,可以将应用程序从冻结的时间点恢复回来继续运行。
另外还有个内核级的CR工具–BLCR,这里先挖个坑,以后填。
实验环境
- centos 7
安装
yum -y install criu
criu check
>>> Looks good.
实验准备
vim test_criu.c
编写一个用于测试的C程序:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char const *argv[]) {
int i = 0;
while(true) {
sleep(1);
printf("%d\n", i);
i++;
}
return 0;
}
编译生成可执行文件:
gcc test_criu.c -o test_criu
实验1:简单的dump和restore命令
1)执行测试程序
./test_criu
0
1
2
3
killed
2)另一个终端查看测试程序pid:
ps -ef | grep test_criu
>>> root 1597 1691 0 21:45 pts/2 00:00:00 ./test_criu
3)dump:设置检查点并中断程序
mkdir checkpoint_file
criu dump -D checkpoint_file -j -t 1597
>>> Warn (compel/arch/x86/src/lib/infect.c:249): Will restore 1597 with interrupted system call
4)恢复程序:
criu restore -D checkpoint_file -j
4
5
6
...
5)检查进程是否使用原来的进程号继续运行:
ps -ef | grep test_criu
命令说明:
dump命令:由实验中可以看到,当设置进程1597的checkpoint后,再查找该进程,发现进程不存在,即进程已经退出。查看快照文件目录,生成很多img文件,这些文件主要用于恢复应用。
-D(等价于–images-dir):选项指定应用的快照文件保存目录
-j(等价于–shell-job):表示该应用是一个通过shell启动的作业
-t:指定需要checkpoint的应用pid
当对应用设置checkpoint后,应用会自动退出,如果希望应用继续执行,需指定-R或–leave-running选项(见实验2)。restore命令:由实验中可以看到,恢复后的程序从设置checkpoint的时间点继续运行,程序在输出3时被kill掉,恢复后继续输出4,恢复后查找进程1597,发现进程使用原来的进程号继续运行。
实验2:追踪内存更改
实验步骤概述:
1 为程序创建一个pre-dump存储于chkp01
2 在上次快照的基础上再创建一个pre-dume存储于chkp02
3 在上次快照的基础上再创建一个dump存储于chkp03,并保持程序执行
4 在上次快照的基础上再创建一个dump存储于chkp04,终止程序
5 在第3步的基础上恢复程序运行
6 在第4步的基础上恢复程序运行
准备工作:
1)启动测试程序:
./test_criu
2)另一个终端:创建保存快照的文件夹,查看进程pid
mkdir chkp01
mkdir chkp02
mkdir chkp03
mkdir chkp04
mkdir chkp05
ps -ef | grep test_criu
开始实验:
1)创建一个内存快照存储于chkp01,打开内存更改追踪,并保持程序执行
criu pre-dump -j -D chkp01 -t 1597
2)在步骤1快照的基础上再创建一个pre-dume存储于chkp02(在目标1的基础上创建目标2的快照,可以减少系统开销,减少程序执行时间,减少存储占用空间)
criu pre-dump -j -D chkp02 -t 1597 --prev-images-dir chkp01
3)在步骤2快照的基础上再创建一个dump存储于chkp03,并保持程序执行
criu dump --track-mem --j -D chkp03 -t 1597 --prev-images-dir chkp02 --leave-running
–track-mem:追踪内存更改
–leave-running:不终止程序
4)在步骤3快照的基础上再创建一个dump存储于chkp04,终止程序
criu dump -j -D chkp04 -t 1597 --prev-images-dir chkp03
5)在步骤3的基础上恢复程序运行
criu restore -j -D chkp03
6)在步骤4的基础上恢复程序运行
kill -9 1597
criu restore -j -D chkp04
命令及参数说明:
dump:没有别的参数的情况下,转储所有进程信息并杀死进程
pre-dump:仅仅转储内存文件,打开内存更改跟踪,并保留程序运行
–track-mem:打开内存更改跟踪
–prev-images-dir:指明上次检查点的文件路径
–leave-running:让进程继续存活
小结:
1.追踪内存更改的作用何在?
在做检查点的时候,可能测试程序很大,检查点很多,这样就会产生一种结果,需要大量的存储空间,以及大量的时间,为了节约资源,可以仅仅存储某些改变了的内存页(增量存储),这样就能节约大量的时间和空间。–stack-mem就能完成这个功能,它可以使后面执行的语句在使用–prev-images-dir的时候有机会发现没有改变的内存页,从而跳过这些页的存储。
【更专业的说明:https://criu.org/Memory_changes_tracking】
2.为什么我们仅仅恢复了第三步和第四步的快照呢?
这是因为pre-dump 是不完整的快照,无法恢复,仅仅dump才可以恢复。它仅仅为了生成 –prev-images-dir 参数所需要的文件
更多推荐
所有评论(0)