结合CRIU实现cloud foundry app进程的快速dump/restore

背景：

在cloud foundry中需要实现app的suspend/restore来动态的回收分配资源（mainly memory），传统的kill/start方式在start这一步骤会相当慢，直接现象是一个应用一段时间没访问突然有访问了会需要几十秒的时间才能启动，因此这里考虑使用process dump/restore方式实现

CRIU简介：

Checkpoint/Restore In Userspace, or CRIU , is a software tool for Linux operating system. Using this tool, you can freeze a running application (or part of it) and checkpoint it to a hard drive as a collection of files. You can then use the files to restore and run the application from the point it was frozen at. The distinctive feature of the CRIU project is that it is mainly implemented in user space.

安装要求：

内核版本大于 3.11，目前使用的发行版为ubuntu 14.04，但是这个版本有个内核参数没有默认开启，需要手动更改：

perl -p -i -e 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"/g' /etc/default/grub

/usr/sbin/update-grub

then reboot system

 

在ubuntu 14.04上部署warden：

warden默认判断只支持到ubuntu precise版本， 需要修改 warden/root/linux/skeleton/lib/common.sh，增加对trusty版本的判断

 

使用场景和方法：

1. 在同一个container内部进行dump/restore

dump：

crtools dump -t 35   -D /root/  -d --tcp-established --file-locks --shell-job

所耗时间：4s~5s

restore：

crtools restore --tcp-established -D /root/  -d

所耗时间：4s~5s

 

2. 在不同的container之间进行dump/restore

使用方法和场景1类似，只是在另外一个container restore之前，需要把dump出来的文件拷贝到目的container中，除此之外

还会缺失一些原container的文件，比如：

/home/vcap/base/geronimo/var/catalina/logs/*

/home/vcap/base/geronimo/var/cache/*

需要把这些文件手动拷贝到目的container中。

dump出来的文件大小主要取决于原进程占用的内存大小，一般应用在1G左右。

目前只能做到在目的container中把geronimo的进程恢复回来，恢复完成以后恢复的服务端口和以前保持一致，因此需要在

目的container中增加一个端口映射

 net_in --handle 17opdlcpflf --host_port * --container_port *

但是进程中加载的文件有些异常，导致应用页面访问不正常，还需要进一步研究。

 

在执行dump和restore过程中产生异常对criu代码做的更改：

1. 在有tcp连接的时候dump失败

dump过程中需要通过iptables结束一些连接，但是在ubuntu 14.04中iptables的参数用法发生变化，和criu不一致目前在netfilter.c中注释了这一部分 

2. restore geronimo进程

restore长时间block不结束：

修改cr-restore.c， 函数restore_pgid(void)，return after pgid = getpgrp()

3. 再次dump不成功：

 修改sk-inet.c，函数getsockopt，在ret返回0时不直接报错退出，tcpi_state != TCP_CLOSE时不直接报错退出