This is an old revision of the document!
BLCR
So we need a day of down time to switch file server functionality from greentail to sharptail. It would be nice if everybody did not loose any computational progress. To do that, we need to learn to checkpoint at the application level. If a node crashes or power is lost, those applications can then restart the job from the last checkpoint.
I've decided to support one checkpoint/restart utility, The Berkeley Laboratory Checkpoint/Restart tool. Hence this page.
BLCR consists of two kernel modules, some user-level libraries, and several command-line executables. No kernel patching is required. Modules are loading upon boot via /etc/rc.local. The modules are dependent on the kernel source where the compilation took place. So for our first supported BLRC modules I've chosen the mw256 queue and nodes. Here is some documentation on BLCR
First lets test on a node to grasp the concept.
# are modules loaded
[hmeij@n33 blcr]$ lsmod | grep blcr
blcr 115529 0
blcr_imports 10715 1 blcr
# set env
export PATH=/share/apps/blcr/0.8.5/mw256/bin:$PATH
export LD_LIBRARY_PATH=/share/apps/blcr/0.8.5/mw256/lib:$LD_LIBRARY_PATH
# is it all working
[hmeij@n33 blcr]$ cr_checkpoint --help
Usage: cr_checkpoint [options] ID
Options:
General options:
-v, --verbose print progress messages to stderr.
-q, --quiet suppress error/warning messages to stderr.
-?, --help print this message and exit.
--version print version information and exit.
...
# and here is our application and output (one extra character per second)
[hmeij@n33 blcr]$ ./t-20001030-01
*
**
***
****
*****
******
...
So now lets run this under BLCR and observe what happens. After we define the proper environment, we use cr_run to launch our application. Standard output and error are written into the output file context. We then observe the PID of our process and use cr_checkpoint to write a checkpoint file and immediately terminate the process.
# start application [hmeij@n33 blcr]$ cr_run ./t-20001030-01 > context 2>&1 & [1] 12789 # observe PID [hmeij@n33 blcr]$ ps PID TTY TIME CMD 12789 pts/29 00:00:00 t-20001030-01 12817 pts/29 00:00:00 ps 28257 pts/29 00:00:00 bash # wait, then checkpoint and terminate process [hmeij@n33 blcr]$ sleep 30 [hmeij@n33 blcr]$ cr_checkpoint --term 12789 [1]+ Terminated cr_run ./t-20001030-01 > context 2>&1 # save the output [hmeij@n33 blcr]$ mv context context.save <code> Ok. Next we use ''cr_restart'' to restart our application by pointing it to the checkpoint file generated. Then we'll wait a bit and terminate the restart. <code> # restart in background [hmeij@n33 blcr]$ cr_restart ./context.12789 > context 2>&1 & [1] 13579 # wait and terminate the restart [hmeij@n33 blcr]$ sleep 30 [hmeij@n33 blcr]$ kill %1 [1]+ Terminated cr_restart ./context.12789 > context 2>&1
So what we're interested in is the boundary between first termination and subsequent restart. It alooks like this:
[hmeij@n33 blcr]$ tail context.save ***************************************** ****************************************** ******************************************* ******************************************** ********************************************* ********************************************** *********************************************** ************************************************ ************************************************* ************************************************** [hmeij@n33 blcr]$ head context *************************************************** **************************************************** ***************************************************** ****************************************************** ******************************************************* ******************************************************** ********************************************************* ********************************************************** *********************************************************** ************************************************************ # pretty nifty! # but be forewarned that there are binary characters lurking at this boundary # you can strip them out with ''sed'' or ''tr'' # it looks like this ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@***************************************************
[hmeij@n33 blcr]$ ./run.serial& [1] 2082 [hmeij@n33 blcr]$ process_id=2084 sleep 140; kill 2084 [hmeij@n33 blcr]$ ./run.serial: line 24: 2084 Terminated cr_run ./t-20001030-01 > context 2>&1 Checkpoint failed: no processes checkpointed ll total 344 -r——– 1 hmeij its 180798 Oct 31 10:22 checkpoint.2084 -rw-r–r– 1 hmeij its 12560 Oct 31 10:23 context -rw-r–r– 1 hmeij its 5643 Oct 31 10:18 info.txt -rw-r–r– 1 hmeij its 2867 Oct 30 14:27 lsf_readme.txt -rwxr–r– 1 hmeij its 657 Oct 31 10:08 run.serial -rwxr-xr-x 1 hmeij its 7298 Oct 17 14:16 t-20001030-01 [1]+ Done ./run.serial [hmeij@n33 blcr]$ tail -1 context * [hmeij@n33 blcr]$ tail -1 context | wc -c 158
[hmeij@sharptail ~]$ ll /sanscratch/62322 total 16 -rwx—— 1 hmeij its 1796 Oct 31 11:06 1383231850.62322 -rw——- 1 hmeij its 0 Oct 31 11:06 1383231850.62322.err -rw——- 1 hmeij its 0 Oct 31 11:06 1383231850.62322.out -rwxr–r– 1 hmeij its 1457 Oct 31 11:07 1383231850.62322.shell -rw-r–r– 1 hmeij its 0 Oct 31 11:07 context -rwxr-xr-x 1 hmeij its 7298 Oct 17 14:16 t-20001030-01 [hmeij@sharptail ~]$ ll ~/.ls ls: cannot access /home/hmeij/.ls: No such file or directory [hmeij@sharptail ~]$ ll ~/.lsbatch/ total 0 lrwxrwxrwx 1 hmeij its 34 Oct 31 11:06 1383231850.62322 → /sanscratch/62322/1383231850.62322 lrwxrwxrwx 1 hmeij its 38 Oct 31 11:06 1383231850.62322.err → /sanscratch/62322/1383231850.62322.err lrwxrwxrwx 1 hmeij its 38 Oct 31 11:06 1383231850.62322.out → /sanscratch/62322/1383231850.62322.out lrwxrwxrwx 1 hmeij its 40 Oct 31 11:06 1383231850.62322.shell → /sanscratch/62322/1383231850.62322.shell
