Nomadic Migration: A New Tool for Dynamic Grid Computing.
ABSTRACT We describe the design and implementation of a technology which provides an application with the ability to seek out and exploit remote computing resources by migrating tasks from site to site, dynamically adapting the application to a changing Grid environment. The motivation for this migration framework, dubbed "The Worm", originated from the experience of having an abundance of computing time for simulations, which is distributed over multiple sites and split in time chunks by queuing systems. We describe the architecture of the Worm, describing how new or more suitable resources are located, and how the payload simulation is migrated to these resources following a trigger event. The migration technology presented here is designed to be used for any application, including large-scale HPC simulations
- SourceAvailable from: psu.edu[Show abstract] [Hide abstract]
ABSTRACT: Thesis (M.S.)--Michigan Technological University, 2006. Includes bibliographical references.01/2006;
- [Show abstract] [Hide abstract]
ABSTRACT: Impact cratering is an important geological process of special interest in Astrobiology. Its numerical simulation comprises the execution of a high number of tasks, since the search space of input parameter values includes the projectile diameter, the water depth and the impactor velocity. Furthermore, the execution time of each task is not uniform because of the different numerical properties of each experimental configuration. Grid technology is a promising platform to execute this kind of applications, since it provides the end user with a performance much higher than that achievable on any single organization. However, the scheduling of each task on a Grid involves challenging issues due to the unpredictable and heterogeneous behavior of both the Grid and the numerical code. This paper evaluates the performance of a Grid infrastructure based on the Globus toolkit and the GridWay framework, which provides the adaptive and fault tolerance functionality required to harness Grid resources, in the simulation of the impact cratering process. The experiments have been performed on a testbed composed of resources shared by five sites interconnected by RedIRIS, the Spanish Research and Education Network.Scientific Programming 01/2005; 13:19-30. · 1.04 Impact Factor
- [Show abstract] [Hide abstract]
ABSTRACT: In recent years, there has been a dramatic increase in available compute capacities. However, these ``Grid resources'' are rarely accessible in a continuous stream, but rather appear scattered across various machine types, platforms and operating systems, which are coupled by networks of fluctuating bandwidth. It becomes increasingly difficult for scientists to exploit available resources for their applications. We believe that intelligent, self-governing applications should be able to select resources in a dynamic and heterogeneous environment: Migrating applications determine a resource when old capacities are used up. Spawning simulations launch algorithms on external machines to speed up the main execution. Applications are restarted as soon as a failure is detected. All these actions can be taken without human interaction. A distributed compute environment possesses an intrinsic unreliability. Any application that interacts with such an environment must be able to cope with its failing components: deteriorating networks, crashing machines, failing software. We construct a reliable service infrastructure by endowing a service environment with a peer-to-peer topology. This ``Grid Peer Services'' infrastructure accommodates high-level services like migration and spawning, as well as fundamental services for application launching, file transfer and resource selection. It utilizes existing Grid technology wherever possible to accomplish its tasks. An Application Information Server acts as a generic information registry to all participants in a service environment. The service environment that we developed, allows applications e.g. to send a relocation requests to a migration server. The server selects a new computer based on the transmitted resource requirements. It transfers the application's checkpoint and binary to the new host and resumes the simulation. Although the Grid's underlying resource substrate is not continuous, we achieve persistent computations on Grids by relocating the application. We show with our real-world examples that a traditional genome analysis program can be easily modified to perform self-determined migrations in this service environment. In den vergangenen Jahren ist es zu einer dramatischen Vervielfachung der verfügbaren Rechenzeit gekommen. Diese 'Grid Ressourcen' stehen jedoch nicht als kontinuierlicher Strom zur Verfügung, sondern sind über verschiedene Maschinentypen, Plattformen und Betriebssysteme verteilt, die jeweils durch Netzwerke mit fluktuierender Bandbreite verbunden sind. Es wird für Wissenschaftler zunehmend schwieriger, die verfügbaren Ressourcen für ihre Anwendungen zu nutzen. Wir glauben, dass intelligente, selbstbestimmende Applikationen in der Lage sein sollten, ihre Ressourcen in einer dynamischen und heterogenen Umgebung selbst zu wählen: Migrierende Applikationen suchen eine neue Ressource, wenn die alte aufgebraucht ist. 'Spawning'-Anwendungen lassen Algorithmen auf externen Maschinen laufen, um die Hauptanwendung zu beschleunigen. Applikationen werden neu gestartet, sobald ein Absturz endeckt wird. Alle diese Verfahren können ohne menschliche Interaktion erfolgen. Eine verteilte Rechenumgebung besitzt eine natürliche Unverlässlichkeit. Jede Applikation, die mit einer solchen Umgebung interagiert, muss auf die gestörten Komponenten reagieren können: schlechte Netzwerkverbindung, abstürzende Maschinen, fehlerhafte Software. Wir konstruieren eine verlässliche Serviceinfrastruktur, indem wir der Serviceumgebung eine 'Peer-to-Peer'-Topology aufprägen. Diese ``Grid Peer Service'' Infrastruktur beinhaltet Services wie Migration und Spawning, als auch Services zum Starten von Applikationen, zur Dateiübertragung und Auswahl von Rechenressourcen. Sie benutzt existierende Gridtechnologie wo immer möglich, um ihre Aufgabe durchzuführen. Ein Applikations-Information- Server arbeitet als generische Registratur für alle Teilnehmer in der Serviceumgebung. Die Serviceumgebung, die wir entwickelt haben, erlaubt es Applikationen z.B. eine Relokationsanfrage an einen Migrationsserver zu stellen. Der Server sucht einen neuen Computer, basierend auf den übermittelten Ressourcen-Anforderungen. Er transferiert den Statusfile des Applikation zu der neuen Maschine und startet die Applikation neu. Obwohl das umgebende Ressourcensubstrat nicht kontinuierlich ist, können wir kontinuierliche Berechnungen auf Grids ausführen, indem wir die Applikation migrieren. Wir zeigen mit realistischen Beispielen, wie sich z.B. ein traditionelles Genom-Analyse-Programm leicht modifizieren lässt, um selbstbestimmte Migrationen in dieser Serviceumgebung durchzuführen.06/2003;
Nomadic Migration: A New Tool for Dynamic Grid
Gerd Lanfermann, Gabrielle Allen, Thomas Radke, Edward Seidel
Abstract- We describe the design and implementation of
a technology which provides an application with the abil-
ity to seek out and exploit remote computing resources by
migrating tasks from site to site, dynamically adapting the
application to a changing Grid environment. The motiva-
tion for this migration framework, dubbed “The Worm”,
originated from the experience of having an abundance of
computing time for simulations, which is distributed over
multiple sites and split in time chunks by queuing systems.
We describe the architecture of the Worm, describing how
new or more suitable resources are located, and how the
payload simulation is migrated to these resources following
a trigger event. The migration technology presented here is
designed to be used for any application, including large-scale
RID computing involves utilizing computational re-
G sources, connected by networks, as needed to solve
problems. %cent advances in Grid computing are such
that applications are now in a position to begin to exploit
a wide range of available computer resources, simultane-
ously, sequentially, or both, enabling many different new
and innovative Grid usage scenarios.
Adding up the theoretically available computing time
across a pool of standard computers, such as idle work-
stations, or summing the total computing time granted to
a research group by several independent super computing
sites will typically yield an impressive capacity of process-
ing power. But these resources are neither available on a
homogenous architecture base nor are they all continuously
accessible over a long period of time.
Here we have focussed on a new type of Grid computing
appropriate for its dynamic character: self-determined mi-
gration of a simulation from one site or collection of sites 
to any other. We present a migration technology, dubbed
“the Worm”, designed for parallel applications with high
IO and memory requirements, driven by the need for per-
forming large scale simulations on HPC machines . The
technology is also applicable for the efficient use of idle
cycles from small machine pools.
A prototype implementation of the Worm was already
demonstrated at Supercomputing 2000, running across the
machines of the EGrid Testbed . The Worm was im-
plemented in the Cactus programming framework [l], .
The Worm’s payload, which describes the simulation code
G.Lanfermann, G.Allen, T.Radke and ESeidel are with the Max-
Planck-Institut fur Gravitationsphysik, Albert-Einstein-Institut,
Golm (AEI), E.Seide1 is also with the National Center for Super-
computing Applications, Champaign, IL, (NCSA)
0-7695-1296-8/01 $10.00 0 2001 IEEE
:: : :
. . ..
, , ..
: Data Acccrr
.. .. ..... .
Off-Sile Dnln Slornpe , ,
replicating Worm. The user payload is encapsulated by the Worm
Kernel, acting as a contact point to the resource detector and various
application information semrs (AIS). The transfer units stage exe-
cutables to machines and provides storage for checkpoint files during
We show the main components of a resource aware, self-
provided by scientists, was a simulation of a wave equa-
tion, although any real application written in the Cactus
framework can trivially be incorporated as a payload.
The participating EGrid sites  published characteristic
system profiles and load information to a central Resource
Manager. While the prototype Worm simulation was run-
ning on machines in the Grid, it was able to query this
central resource service, seeking available machines of a
certain configuration. Using this information it could then
migrate to another site according to some predefined crite-
111. WORM TECHNOLOGY
IN A DYNAMIC
Based on the early prototype experiences  a more sc-
phisticated Worm framework was desgined to provide the
user with range of migration policies and to overcome nu-
merous technical challenges when dealing with heteroge-
nous grid environments. With the new worm technology,
application migration can be inititated by a variety of cases,
which range from the user’s manual triggering of a migra-
tion event to fully automatic application relocation: by
monitoring the simulation performance and profiling the
current hardware with small benchmarking programms a
detailed profile of the current execution environment is gen-
Periodic lookups are performed to see if “better” re-
sources for this individual profile have become available
- in which case a migration to the more suited resource
may be initiated. Note that in this context ‘Lbetter” does
not necessarily mean “faster” but also “cheaper”, “more
storage”, “less queue waiting” or “better network”.
Since the Worm migrates between machines in a non-
predictable fashion, reacting to the dynamic nature of a
Grid, it requires a mechanism for tracking the current and
past locations of the Worm. This is handled with different
degrees of finesse, for example, by publishing the informa-
tion to a centralized Application Information Service (AIS)
or an email/SMS notification server.
Before migrating, the Worm must have located the next
resource by querying a remote Resource Broker (RB),
which tracks available computing resources, obtaining load
and other information from registered sites. Different RB
formats developed by e.g. GrADS 181 and groups within
the EGrid are understood. If a suitable resource cannot be
found, the simulation hibernates by writing a checkpoint
which is stored until appropriate machines become avail-
able to host the restarted simulation.
The Worm must provide the capability to access the dif-
ferent sites without user interaction to copy checkpoint and
parameter files, start processes and handle output data. It
is essential to provide a secure but easy way to interface
these resources. Our Worm supports methods as Globus
GSI technology [S] or more simply secure shell and secure
The Worm application (including the user provided pay-
load simulation) must be available on the different hetero-
geneous machines of the user’s virtual grid. We support
repositories of pre-built binaries and automated compiling
“on-the-fly” before execution. To restore the simulation
state in a heterogeneous machine environment, the check-
point files are coded in an architecture independent format.
We use HDF5 [ll] and the CactusCode framework [l] to
meet these requirements.
executed in Queue
Fig. 2. The timeline of migration events between three sites is shown.
The first two relocations involve hibernation of the application. In
the third case an advanced reservation scheduler is used to request
overlapping resources, which allows to directly stream checkpoints.
Automating and optimizing the usage of multiple re-
sources is an essential challenge to Grid-enabling applica-
tion software. We have described a technology that en-
ables an application on its own to seek out and exploit
computational resources on the Grid. This “Worm” ap-
proach not only provides applications with the ability to
make decisions about resource usage and to self-migrate to
new machines if necessary, it also takes into account the
heterogeneous nature of resources as well as their dynamic
availability in time.
Note that although we have spoken in terms of migrating
an entire application from site to site, future Grid appli-
cations will be able to take advantage of work flow par-
allelism: e.g. analysis tasks may be spawned off to other
grid resources. The Worm technology paves the ground for
these advanced and intelligent Grid applications. There are
many possible uses that will be discussed elsewhere [lo].
The development of the EGrid Worm is a highly collab-
orative effort,, and we are indebted to a great many experts
at different institutions, especially on the EGrid for their
advice and support. It is a pleasure for us to thank, above
all Tom Goodale and John Shalf, as well as Ian Foster,
Sridhar Gullapalli, Steve Fitzgerald and the Globus team
at ANL for their Globus and Data Grid work; Mike Folk
and his HDF5 development group at NCSA; Computing
resources and technical support have been provided by the
EGrid, AEI, NCSA, ANL, and ZIB. We have also benefit-
ted from close association with and partial support of the
ASC project, NSF PHY-9979985.
[l] Cactus Code: http://vw.cactuscode.org
 Allen, G., Goodale, T., Lanfermann, G., Seidel, E., Benger, W.,
Hege, H.-C., Merzky, A., Mass4 J., Radke, T. and Shalf, J.,
Solving Einstein’s Equation on Supemmputers, IEEE Computer,
p.52-59, December, 1999. http://vw.computer.org/computer/
 Seidel, E. and Suen, W.M., J. Comp. Appl. Math., 109,
 G. Allen, T. Dramlitsch, G. Lanfermann, E. Seidel, EBcient
Techniques for Distributed Computing submitted to HPDClO.
 G. Allen, W. Benger, T. Goodale, H. Hege, G. Lanfermann, A.
Merzky, T. Radke, E. Seidel, J. Shalf, “Cactus Tools for Grid
Applications”, to appear in Cluster Computing, (2001).
 Globus Metacomputing Toolkit: http://rvv.globus.org/
[7 The European Grid-Forum: http://uw.egrid.org
 Grid Application Development
http ://W. isi .edu/grads
 G. Allen, T. Dramlitsch, T. Goodale, G. Lanfermann, T. Radke,
E. Seidel, T. Kielmann, K. Verstoep, 2. Balaton, P. Kacsuk,
F. Szalai, J. Gehring, A. Keller, A. Streit, L. Matyska, M. Ruda,
A. Krenek, H. Frese, H. Knipp, A. Merzky, A. Reinefeld, F. Schin-
.tke, B. Ludwiczak, J. Nabrzyski, J. Pukacki, H.-P. Kersken, and
M. Russell, Early ezperiences with the Egrid testbed, in IEEE
International Symposium on Cluster Computing and the Grid,
[lo] G. AllenJ. Foster, T. Goodale, G. Lanfermann,T .
Radke,M. Russel1,E. Seidel, J. Shalf Grid Computing: An Ap-
plications Perspective (in preparation)
[Ill Hierarchical Data Format Version 5
http: //hdf .ncsa. uiuc. edu/HDF5