Migration Technology

In this section, we discuss the migration technology including the process migration, migration strategy, job migration in the Grid system, and the load sharing policy.

2.4.1 Process Migration

The term “Process” appeared in the 1960s, presented by the Multic system designer [7].

Process migration is an action which transferring a state of process from one machine to another for processing or executing on the target machine. The earliest migration technologies were used on the operating system, via the inter-connection framework to allocate the CPU resource to the process. The other migration applications are used in image process, memory page, and so on. We summarize the three points of migration technology advantage, including (1) to help dynamic load balancing, and reduce the network traffic. Many operating systems developed process migration mechanism, such as the Accent Sprite and V. (2) to help the resource sharing, the resource such as specific node with a special hardware device, large amounts of free memory, or some other unique resource, help users access more processing power. (3) to improve system administration by transferring the process that prevent many unexpected problems, such as machine shut down in suddenly. [45, 39, 35]

Migration technology can be divided into three actions:

Step 1. Suspend the process in the source node.

Step 2. Transfer the data, file and information state to the remote node.

Step 3. Reconstruct the process on the remote node, and restart the process.

These steps are the basic action of the migration strategy. According with above steps, many migration strategies are reformed, and assist in reduce the system cost and raise the system performance. The common migration strategies, like the Eager, Lazy and Precopy.

Eager is the simplest and most common migration strategy. Because of this strategy transfer all information (data, file and state) in a one transfer time. When system starts the Eager migration strategy, the first step is suspending the process on the source node and beginning transfer information to the remote node. After the information was transferred complete, the process will reconstruct the process on the remote node. The time and cost of Eager is higher than other strategies [39], but it is most easily to implement.

2.4.2 Job Migration in Grid environment

The development of migration technology from process migration (inter-connection) to deal with large scale and geographically distributed system, such migration applications through the Wide Area Network (WAN) to connect various computing machines are called internet-connection. The resource in the Grid computing environment is dynamically, and we could achieve load balancing by job migration between the computing nodes.

The Grid is a cross-geographical and heterogeneity system, the job must be adapted in different computing capacity and to re-scheduling constantly. Most of the impact factors of the Grid consider the usage of site resource. In the past load balancing or scheduling studies [32], only consider the CPU and memory state. But it should be considered more impact factors in the real Grid environment.

The job migration in distributed system need to reflect three issues to facilitate the load balancing implementation, there are when to active the migration strategy, how to implement migration strategy and the consideration of migration cost. Active the migration strategy based on the job scheduling strategy. General speaking, job scheduling strategy must match

user’s requirement and the condition of the job or according with the node status (such as CPU or memory state), then to determine whether to start migration strategy. As to how the implement migration strategy, we could establish the migration strategy on the computing node or site. The load sharing policy defines the transfer rules between the nodes. We could adapt load sharing policy to establish the migration strategy. In the next section, we will describe and discusses the loading sharing policies

2.4.3 Load Sharing Polices

Decentralized system collects a lot of nodes for computing resources sharing. The load sharing in a decentralized system could helps improve the usage of computing resources, system performance and obtains the minimal job execution time via sharing the workload to idle or light load computing resources. In the study [27], shown that when information is transferred from the source to the destination, will has the significantly affected by the network state, including the network latency, communication delay, and so on.

Generally speaking, load sharing policy can be divided into dynamic, static and adaptive.

The dynamic load sharing policy uses the system state information (the load of site), and make the decision by the system state at any time. The static load sharing policy adopts the prior knowledge, such as the average task-initiation rate and execution rate of each node.

Dynamic load sharing policy also could improve the quality of decision more than the static load sharing policy. Adaptive policy is the special one, which is started to change system state when variables or the policy is changed [44]. Dynamic load sharing policy could classify into Sender-initiated, Receiver-initiated, and Symmetric-initiated. By using load sharing policy, we can increase the usage of computing resources, and decrease the job response time through adequate resources allocation [10, 8]. The following are three general dynamic load sharing

„ Sender-initiated policy

Sender-initiated policy shares the system load from the overload system to light load system for abating its own loading [10]. We could get better performance by using this policy in light or medium system load [35]. But, if using this policy in high load system will cause a lot of useless request messages (which will be rejected by other nodes, until request times meets the default upper bound), leading to the communication channel congestion problem. Too many request times may also bring the delay and waste of bandwidth.

„ Receiver-initiated policy

When any light load node has the capacity to sustain more load, it will send request message to the node in heavy load to share its load actively. But when light load node cannot find any suitable load node, it will execute its own job, thus good performance is assured. Using this policy in light or medium load system, the performance is worse than that of sender-initiated policy. Just like using sender-initiated in heavy load system, using receiver-initiated policy in light load system will bring lots of useless messages. This result in the information collection delay, even some system performance improvement gained is useless. Nevertheless, unlike using sender-initiated policy in heavy load system, using receiver-initiated in light load system will obtain the better efficiency, because the few job in system which means less departure of jobs, thus rarely influenced by delay of data collection [10, 11].

„ Symmetric-initiated policy

Symmetric-initiated policy combines the above two policies, thus with both two’s pros and coins. That is using sender-initiated policy in heavy load system and using receiver-initiated policy in light or medium load system both result in many useless messages. Using symmetric-initiated policy in light or heavy load system both will

generate many useless messages, and consumption of communication capacity.

Compared with the above two policies in cost, symmetric-initiated policy is a more expensive algorithm [10, 8].