软件学报
JOURN AL OF SOFTWARE
1999年　第10卷　第10期　Vol.10　No.10　1999



工作站网络系统进程迁移机制 
裴 丹 汪东升 沈美明
摘要　进程迁移是工作站网络系统实现负载平衡、提高系统可用性功能的重要手段.该文提出了一种基于接收/发送方消息记录的进程迁移技术.它在消息传递库PVM(parallel virtual machine)之上实现,具有对用户程序透明、可移植性好、开销小和实现简单等特点.此技术已实际应用于作者自行研制的“并行程序运行回卷恢复与进程迁移系统―ChaRM(checkpointing-based rollback recovery and migration system)”中.
关键词　进程迁移,工作站网络,PVM,进程状态.
中图法分类号　TP393
Process Migration for the Network of Workstations
PEI Dan WANG Dong-sheng SHEN Mei-ming
(Department of Computer Science and Technology Tsinghua University Beijing 100084)
Abstract Process migration is an important tool on NOWs (network of workstations) for load-balancing and high availability. In this paper, the authors present a log-based approach to provide process migration for parallel applications. Because this approach is implemented on top of PVM (parallel virtual machine), it is transparent to users and portable. This approach has been used in the ChaRM (checkpointing-based rollback recovery and process migration system) system. The experiments show that the overhead is low.
Key words Process migration, network of workstations (NOW), PVM (parallel virtual machine), process state.
　　在工作站网络(NOW)系统中,各结点的负载分布情况在很大程度上影响着系统的执行效率.进程迁移技术能动态地改变系统的负载分布,因而它是支持系统动态负载平衡、合理有效地利用资源、提高系统整体性能和系统可用性的关键技术.文献[1～4]指出,利用进程迁移,(1) 在计算过程中,可以把进程从负载较重的结点迁移到负载较轻的结点上,实现动态负载平衡;(2) 可以充分利用NOW中的空闲工作站,并且在主人要求独占其工作站资源时及时迁出进程;(3) 在长时间计算的过程中,可以使某结点退出计算以进行系统维护,提高系统的可用性;(4) 使I/O操作在设备所在的结点上进行,减少网络通信量.
　　PVM(parallel virtual machine)是一个应用广泛的并行编程环境,但其本身并没有支持进程迁移.我们在PVM的通信库上对其功能进行扩充,开发了一个基于检查点机制的并行程序运行回卷恢复和进程迁移系统―ChaRM(checkpointing-based rollback recovery and migration system).ChaRM系统提供了并行计算环境下的容错功能和进程迁移功能,并能与负载平衡调度工具相结合,实现对工作站网络系统的智能化资源管理.
　　进程的状态是指,为了保证进程在迁移之后能够继续正确地执行所必需的信息.进程状态应该包括进程的数据段、用户栈内容,还应包括程序计数器PC、处理机状态字PSW、栈指针SP内容、活动文件信息以及中断、信号等信息.在进程迁移时,迁移进程捕获其进程状态,并将它直接通过UNIX的socket通道传给系统为它在目标结点上创建的一个骨架进程;骨架进程则从socket通道中读出进程状态,并在自己的进程空间内重建该状态.进程状态传输完毕后,迁移进程自动终止,由骨架进程代替它继续运行.
　　在并行系统中,还必须保证迁移后其他进程以原来的任务号访问该迁移进程对应的骨架进程,并且保证那些在迁移前和迁移过程中发往该迁移进程的消息都能够以正确的顺序接收,否则将造成消息的丢失并引起程序执行错误.
1　丢失消息的处理
　　在进程迁移过程中由于迁移进程与骨架进程任务号不同而引起的几种消息丢失的情况如图1所示.进程迁移从t0时刻开始,t1时刻结束(各进程的t0和t1可能不一样).MP代表被迁移进程,SP代表MP在目标结点上对应的骨架进程,NMP代表应用程序中的非迁移进程.在迁移过程中,MP挂起,NMP继续运行.迁移结束后,MP消亡,由SP代替MP在应用程序中参与计算.

图1　　进程迁移可能造成的消息丢失
　　在图1(a)中,由NMP在t1时刻之后向MP发送的消息m1找不到接收方MP,而SP也无法收到,消息m1丢失.如果NMP在t1时刻之后等待来自MP的消息,由SP发来的消息m2由于发方不是MP,NMP无法接收,m2也丢失了.为了避免这两种完全由于迁移造成的进程任务号的改变而导致丢失消息,一般支持进程迁移的系统都采用了一种MP,SP的任务号之间的匹配机制.这种机制在系统中维护MP与SP之间的任务号的匹配表,当其他进程要与MP通信时,先通过匹配表查到对应的SP的任务号,然后再与SP进行实际的通信,这样就解决了m1和m2的丢失.但是,单纯的任务号匹配机制并不能处理像图1(b)中的m3和图1(c)中的m4那样的丢失消息.当NMP在t0到t1时刻之间向MP发送m3时,本次迁移导致的任务号变化还无法反映在NMP当时的匹配表中,因此m3被发往MP而不是发往SP;而此时MP已经停止计算,在t1时刻之后将消亡,它无法收到m3,消息m3丢失.图1(c)中的m4和m5是在t0时刻之前已经发送出去,但是接收进程尚未收到的消息.与m3的情况类似,NMP发送m4时并不知道任务号的变化,因此m4被发往MP而丢失.消息m5是由于采用了任务号匹配机制而产生的丢失消息,在t1时刻之后,NMP通过查询匹配表等待接收发自SP的消息,所以无法收到发自MP的消息m5,消息m5丢失.在有多个进程同时进行迁移时,迁移进程之间的丢失消息与图1中所示类似,但由于它们彼此在t0到t1时刻之间不发送应用消息,所以不存在m3一类的消息.
　　在支持进程迁移的系统中,有如下几种维护任务号匹配表的方法.(1) 直接在每个用户进程中维护.这种方法不依赖于特定的并行环境,但是每个用户进程的虚存空间都因此而增长,而且要同时更新匹配表,以维护匹配表内容的唯一性.(2) 由并行编程环境系统在每个结点上的daemon(如pvmd)进程维护.这种方法比前一种方法更能节省空间,匹配表更新容易,但需要修改并行编程环境系统源码,可移植性差.(3) 在每个结点上增加一个管理进程,专门负责维护匹配表,并接管进程的通信.这种方法也不依赖于特定的并行环境,但是在进程间通信频繁的情况下有可能成为系统的瓶颈.
　　处理m3,m4,m5这样的丢失消息的方法一般有两种.(1) 同步方式.在迁移的整个过程中,挂起NMP(暂停计算),因此m3这样的消息根本就不会出现;在传输进程状态前,MP和NMP分别阻塞接收m4和m5,避免这两类消息的丢失.这种方式实现简单,但是由于迁移会导致整个应用程序暂停计算,开销大,效率低.(2) 异步方式.这种方式允许NMP在迁移过程中继续运算.为了避免丢失m3,m4或m5一类的消息,MPVM[2]等系统引入了复杂的消息转发和排序机制.这种方式执行效率高,但实现复杂,且需要修改并行编程环境系统源代码.
2　ChaRM系统进程迁移
　　我们为ChaRM系统设计了一种新的进程迁移机制,它允许NMP在迁移过程中继续计算,只是在迁移开始和结束时进行简单的协调工作.为了支持在不同并行环境之间的可移植性,ChaRM系统由一个专门的管理进程C-Manager进程负责系统总体控制.为了处理图1中的几种消息丢失,ChaRM系统采取了PVM函数封装、任务号隐式匹配、消息驱赶和消息的延迟发送等技术.
　　(1) PVM函数的封装. 在执行真正的PVM函数前后,进行一些额外的工作以完成ChaRM系统的功能,但是提供给用户的接口与原PVM函数的接口完全一致.这种封装技术避免了对PVM源码的直接修改,而且使ChaRM所做的工作对用户透明.
　　(2) 任务号隐式匹配. ChaRM在每个用户进程空间中维护一个任务号匹配表,并使进程在每次通信时都先查询匹配表再进行真正的通信.在迁移结束前,更新各个进程的匹配表.在整个计算过程中,应用程序只需知道各进程创建时的任务号,而完全不必知道该进程是否发生过迁移.这种机制有效地避免了图1中的m1和m2一类消息的丢失.
　　(3) 消息驱赶机制. ChaRM利用PVM通信机制本身的FIFO语义将一个进程向另一个进程的消息通道清空.假设在迁移过程中,A进程向B进程发送一个特殊的就绪消息后就不再向B发送其他消息;而B进程等待接收该就绪消息,将接收到的应用消息妥善保存到预先指定的接收缓冲中.根据FIFO语义,当B进程收到来自A进程的就绪消息时,可以推断从A进程到B进程的单向通信通道中的所有消息已被驱赶至B进程.这种基于收方的消息记录避免了图1中的m4,m5的丢失,同时也保证了正确的消息接收顺序.
　　(4) 消息的延迟发送机制. 为了避免产生图1中的消息m3,ChaRM对PVM的消息发送函数进行了封装,使得当NMP要在t0到t1时刻之间向MP发送应用消息时,并不进行真正的发送,而是将该消息记录到一个延迟发送消息表中.等到迁移完毕再根据更新过的匹配表将延迟发送消息表中的应用消息发送出去.这实际上是一种基于发方的消息记录.
　　算法1. ChaRM系统的迁移算法.
1. C-Manager: IF　接收到迁移发起信号MIGRATE_SIG THEN 
　　　　　　　　　向所有MP发出迁移启动信号MIG_CHECK_SIG;
　　　　　　　　　向所有NMP发出迁移协调信号MIG_SYNC_SIG;
2. MP:　　　　IF　收到MIG_CHECK_SIG THEN 
　　　　　　　　　暂停计算,建立起一个用于与SP通信的socket管道;
　　　　　　　　　向C-Manager发送PRT_MSG,通知它的socket的地址、端口号等信息;
　　　　　　　　　向其他所有进程发送就绪消息RDY_MSG;
　　　　　　　　　持续接收向它发送的消息,直至收到来自其他所有进程的RDY_MSG.
　　　　　　　　　IF 收到除RDY_MSG 以外的其他消息(被驱赶而来的中途应用消息) THEN
　　　　　　　　　把这个消息保存到预先指定的接收缓冲中;
　NMP: 　　　 IF　收到MIG_SYNC_SIG THEN 
　　　　　　　　　向所有MP发送就绪消息RDY_MSG;
　　　　　　　　　继续进行计算;
　　　　　　　　　IF 在迁移完毕之前,要向MP发送应用消息 THEN 
　　　　　　　　　将消息记录到延迟发送消息表中,不进行真正的发送;
　C-Manager:　IF　收到从MP发来的PRT_MSG消息 THEN
　　　　　　　　　在目标结点上派生出MP对应的骨架进程SP;
　　　　　　　　　将MP的socket地址、端口信息通过PRT_MSG传送给骨架进程;
3. MP:　　　　IF　已经收到其他所有进程发来的RDY_MSG THEN
　　　　　　　　　等待与相应的SP建立socket连接;
　　　　　　　　　捕获进程状态,并将进程状态通过socket传给骨架进程;
　　　　　　　　　状态传输完毕后消亡;
　　SP: 　　　IF　收到C-Manager发来的PRT_MSG THEN 
　　　　　　　　　与相应的MP建立socket连接;
　　　　　　　　　从socket中读出进程状态,并在自己的进程空间内重建该状态;
　　　　　　　　　将任务号变化通过RJN_MSG通知C-Manager;
4.C-Manager:　IF　收到所有SP发来的RJN_MSG THEN 
　　　　　　　　　向所有NMP再次发送MIG_SYNC_SIG;
　　　　　　　　　并向所有进程发送LST_MSG用于各进程更新其任务号匹配表;
　　NMP:　　　IF　收到MIG_SYNC_SIG信号 THEN
　　　　　　　　　持续接收向它发送的消息,直至收到所有发自MP的RDY_MSG;
　　　　　　　　　IF　收到除RDY_MSG 以外的其他消息(被驱赶而来的中途应用消息) THEN
　　　　　　　　　把这个消息保存到预先指定的接收缓冲中;
　　　　　　　　　接收C-Manager发来的LST_MSG,更新各自的任务号匹配表;
　　　　　　　　　根据新的匹配表将延迟发送消息表中延迟发送的消息发送出去;
　　　　　　　　　继续执行;
　　SP: 　　　IF　接收到由C-Manager发来的LST_MSG THEN 
　　　　　　　　　更新任务号匹配表;
　　　　　　　　　继续执行;
　　在算法的第2步中,MP向所有其他进程发送就绪消息,NMP向所有MP发送;然后,MP将所有其他所有进程向它发送的应用消息驱赶到缓冲区中;NMP则继续进行计算,而并不在此时就进行消息驱赶,这是因为在第2步中进程间彼此发送的消息较多,将这一工作推迟到第4步再做可以使NMP因消息驱赶所花费的开销最小.在第4步中,在NMP消息驱赶完毕后,它将延迟发送的消息发送出去并继续执行.这种延迟发送机制带来的附加开销很小,这有两方面原因:一方面,NMP执行完消息发送命令后不必理会接收进程是否收到而可以继续计算,即发送应用消息并不在NMP执行的关键路径上,所以这种机制对NMP的计算过程无直接影响;另一方面,由于延迟发送的消息是在迁移完毕后立即被发送出去,而MP直到迁移完毕后才继续计算和接收应用消息,所以它不会因为长时间等待接收发自NMP的应用消息而明显增加执行时间.
　　在同步方式的进程迁移中,NMP的开销与MP的开销大致相当;而在算法1中,NMP除了在迁移发起时和迁移结束时做一些协调工作以外,一直处于计算过程中,其开销远小于同步方式.在异步方式的进程迁移中,虽然NMP没有明显的协调工作,但这种方式引入的复杂的消息转发和排序机制也会给应用程序的正常运行带来一定的开销;而算法1中以NMP在迁移过程中参与协调为代价,使得算法易于实现,并且正常运行开销小于异步方式.综上所述,算法1中基于发送/接收方的消息记录的算法有效地结合了同步方式的易于实现和异步方式的效率高的优点.
3　性能测试
　　测试环境为由4台SUN Ultra2(每个结点两个CPU,主频200MHz)经100M快速以太网连接而成的工作站网络系统,操作系统为Solaris2.5.测试用例为计算密集型的矩阵幂程序,该程序由一个根任务在4个结点上各派生出两个子任务,总共8个子任务.测试结果如表1所示,其中状态空间是指通过socket传送的进程状态信息的总和;挂起时间是指从MP在源结点上暂停计算到在目标结点上继续计算所花费的时间,它等于状态传输时间加上协调时间;MP协调时间是指除了在网络上进行进程状态传输以外,它所进行的所有其他工作所花费的时间,其中包括发送及接收就绪消息、与C-Manager通信、骨架进程的派生、维护任务号匹配表等工作;NMP最大协调时间是指各NMP为进程迁移所花费的时间中的最大值,包括发送及接收就绪消息、与C-Manager通信、延迟发送消息、维护任务号匹配表等工作.
表1 矩阵幂程序进程迁移开销

状态空间
(MBytes)挂起
时间(s)状态传输
时间(s)协调
时间(s)NMP最大协调时间(ms)
1.680.4180.2190.1892.0
2.000.4380.2530.1851.7
3.010.5840.3680.1962.6
4.000.6610.4720.1892.5
5.000.7590.5650.1943.5
6.010.9380.6840.2545.8
7.011.0390.8190.2207.5
8.021.1200.9160.2042.6



　　从表1可以看出,进程状态传输时间是挂起时间的主体部分,它随着进程状态空间的增加,大致呈线性增加,其上下波动是由网络传输的波动所致,这部分开销的大小主要取决于网络硬件;协调时间随着进程状态空间的增加虽然呈增加趋势,但变化并不显著,在0.2s左右,这是由于协调工作与进程状态空间的关系很小所致.从图2中可以更直观地看出MP各部分开销与状态空间的关系.表1中的NMP的协调时间很小,与MP挂起时间相差两个量级,这验证了我们对算法1的分析:NMP开销远小于同步方式,而用毫秒级的协调开销来避免实现复杂的异步方式进程迁移也是完全可以接受的.这一开销逐渐变大的趋势是由于传输较大的进程状态空间导致网络通信变慢所致. 

图2　　矩阵幂程序MP迁移开销折线图
　　另外,我们还对其他一些程序进行了测试,结果见表2.其中偏微分方程、哈达码变换为计算密集型,ASE、分数维、FFT为通信密集型.可以看出,计算密集型与通信密集型在MP的协调时间上区别很小,证明消息驱赶和延迟发送机制的效率较高;而在通信密集型的应用程序中,由于NMP要保存和重发的消息比计算密集型的多,所以其协调时间有一定的增加,同时这一增加也受状态空间大小的影响.
表2 应用程序进程迁移开销

应用程序状态空间
(MBytes)挂起
时间(s)状态传输
时间(s)协调
时间(s)NMP最大协调
时间(ms)
哈达码变换1.60.4380.2120.2152.0
偏微分方程2.20.4710.2730.1963.1
分数维1.70.4370.2250.2043.3
ASE8.01.0880.8640.2231.9
FFT3.70.4450.6790.2344.4
FFT22.12.2322.4450.2116.2
FFT66.17.3487.6870.2497.6

　 
4　相关工作及结论
　　进程迁移在许多并行系统中得到了支持和应用.早期的系统Charlotte,V system,Mosix,Sprite和Mach,大都是通过修改操作系统内核,在系统级实现了对进程迁移的支持[1].这种方法效率高,透明性好,但可移植性差.用户级实现的进程迁移只使用标准的UNIX系统调用,因而可移植性好.其中MPVM[2]修改了PVM源码,并引入了复杂的消息转发和排序机制以支持异步进程迁移;Condor[3,4]支持的进程迁移是先将进程的检查点文件存入磁盘并中止该进程,等到系统找到空闲机后在该机上恢复;CoCheck[5]利用了Condor提供的单进程检查点设置和卷回恢复工具,在PVM通信库之上实现,但只支持同步方式的进程迁移.DPVM[6]利用进程迁移进一步支持了动态调度的功能.
　　与国际上的同类工作相比,ChaRM系统具有下面的一些功能和设计特点.(1) 对用户程序透明,以运行时库的方式提供给用户.用户只需将ChaRM提供的库与原有PVM应用程序链接,即可用命令方式或API函数调用进程迁移功能.(2) 在并行编程环境通信库上实现,并且由专门的管理进程C-Manager而不是选择PVM的资源管理器RM负责总体控制,从而不受限于特定的并行编程环境,可移植性好.(3) 通过引入消息驱赶和消息延迟发送机制,支持一种新的、基于收/发方消息记录的迁移技术以提高迁移效率,而未采用复杂的消息转发和排序机制.(4) 支持手工、半自动、全自动3种方式的进程迁移发起方式.即用户可以指定把哪个进程迁往哪个结点,也可以提出对某些进程的迁移请求,由系统决定迁往哪个结点,还可以由系统自行决定迁移发起的时机、迁移的进程以及目的结点.(5) 对进程状态进行了精简,排除了数据段中不必保存的区域,从而减少了由于迁移引起的状态捕获、传输和重建的时空开销.
　　本文提出的进程迁移技术可以在PVM,MPI等多种消息传递库上实现,采用了任务号隐式映射、消息驱赶和消息延迟发送技术,是一种基于接收/发送方消息记录的迁移技术,具有实现简单、对应用程序透明、可移植性好和开销小等特点.
　　在下一步的工作中,我们将在ChaRM系统中设计并实现动态负载平衡调度算法,对工作站网络系统进行智能化资源管理.
注释：本文研究得到国家863高科技项目基金资助。
作者简介：裴丹：1973年生,硕士生,主要研究领域为并行/分布系统,容错与负载平衡
　　　　　汪东升:1966年生,博士,副教授,主要研究领域为并行处理,容错计算
　　　　　沈美明:女,1938年生,教授,博士生导师,主要研究领域为并行/分布计算机系统
作者单位:清华大学计算机科学与技术系 北京 100084
E-mail: peidan@mail.cic.tsinghua.edu.cn
参考文献
1　Eskicioglu M R. Design issues of process migration facilities in distributed 
　　systems. IEEE Technical Committee on Operating Systems Newsletter, 1989,4(2):3～
　　13
2　Casas J, Clark D L et al. MPVM: a migration transparent version of PVM. Computing
　　Systems, 1995,8(2):171～216
3　Litzkow J et al. Condor a hunter of idle workstations. In: Proceedings of the 8th
　　IEEE International Conference on Distributed Computing Systems. Los Alamitos, 
　　CA: IEEE Computer Society Press, 1988. 104～111
4　Tannenbaum T, Litzkow M. The condor distributed processing system. Dr. Dobb’s 
　　Journal, 1995,(2):40～48
5　Stellner G, Pruyne J. Resource management and checkpointing for PVM. In: 
　　Proceedings of the 2nd European PVM Users’ Group Meeting. Lyon, France: Edition
　　Hermes , 1995. 131～136
6　鞠九滨,魏晓辉,徐高潮等.DPVM:支持任务迁移和排队的PVM.计算机学报,1997,20(10):872～
　　877
　　(Ju Jiu-bin, Wei Xiao-hui, Xu Gao-chao et al. DPVM: an enhanced PVM supporting 
　　task migration and queuing. Chinese Journal of Computers, 1997,20(10):872～877)
收稿日期:1998-07-20修稿日期:1998-10-09
