uality of !

ife in the Grids: VMs meet Bioinformatics Applications

6aniel 9alron
C1D C?D

C1D

Tim Areeman

C!D

Eate Eeahey 8tephanie 9atoC?D ;atalia Maltse%C4D &le* #odrigue"C>D Mi e 1ildeCFD

C!D

C3D

The .hio 8tate )ni%ersity. galronGcis.ohio$state.edu ,ndiana )ni%ersity. sgatoGcs.indiana.edu

C4D

&rgonne ;ational :aboratory. tfreemanGmcs.anl.go%

C>D

C3D

&rgonne ;ational :aboratory. eaheyGmcs.anl.go%

&rgonne ;ational :aboratory. maltse%Gmcs.anl.go%

CFD

&rgonne ;ational :aboratory. arodriFGmcs.anl.go%

&rgonne ;ational :aboratory. wildeGmcs.anl.go%

&urrent limitations to using Grids:

Complex applications require customized software configurations such en!ironments may not "e widely a!aila"le on #rid nodes Installing scientific applications "y hand can "e arduous$ lengthy and error%prone the a"ility to amortize this process o!er many installations would help Pro!iding good isolation of #rid computations is a &ey security requirement the currently used mechanism of 'nix accounts is not sufficient Pro!iding a !ehicle for fine%grained resource usage enforcement is critical for more efficient use of #rid resources$ yet such technology is not widely a!aila"le (he a"ility to migrate or restart applications would "e of enormous !alue in a #rid en!ironment yet the current #rid framewor&s do not support it

The promise of VMs

'sing VMs has many "enefits for scientists running complex applications* Broader resource base: a !irtual machine can "e pre% configured with a required +,$ li"rary signature and application installation and then deployed on many different nodes independently of that node-s configuration Simplified deployment/distribution: VMs can "e used as distri"ution pac&ages to duplicate an installation$ .ust copy a VM image Easy Migration capability* an executing VM image can "e /frozen$0 transferred to 1another2 resource and restarted within milliseconds Fine grained resource management* one can confine resource usage within most VM implementations Enhanced security* VMs pro!ide outstanding isolation protecting the resource from the user and isolating users from each other

A Glossary of Terms: VMM (Virtual Machine Monitor) B a 3rd$party tool pro%iding the interface between a Virtual Machine and the host machine. 8ome e*amples of VMMs are VM1are and 0en. VMManager B 9rid ser%ice interface to allow a remote client to interact with the VMM VM"epository B 9rid ser%ice which catalogues VM images of a V. and which stores them for retrie%al and deployment Authori#ation $er%ice B 9rid ser%ice which the VMManager and VM#epository ser%ices call to chec if a user is authori"ed to perform the requested operation

Virtual Machines meet the Grids

In a nutshell
1e implemented the architecture using Glo'us Tool(it )*+, an open$ source grid middleware tool it which pro%ides a framewor for resource, data, and security management.

Performance Implications

,nstead of running 9rid software within VMs, we integrated VM deployment into the 9rid infrastructure: mapping a client credential to a )ni* account was replaced by deploying a VM and starting the client<s en%ironment within it.

3 3 !

The performance of applications running on a VM depends on the third$party VMMs and the applications themsel%es. & purely '()$ bound program will ha%e almost no performance degradation as all instructions will be e*ecuted directly on hardware. Typically, %irtual machines intercept pri%ileged instructions +such as ,-./ resulting in a performance hit for those instructions although new methods, such as those implemented by 0en, impro%e this factor. ,n our implementation, we e*perimented with VM1are 1or station and 0en and in our e*perience slowdown was

ne%er more than 323 and is often less than 43. +The 0en slowdown was much less than 323/

Descri"ing VM Properties
1

Migration
1

& VM constitutes a %irtual wor space configured to meet the requirements of 9rid computations. 1e use an 0M: 8chema to describes %arious aspects of such wor space including %irtual hardware +#&M si"e, dis si"e, Virtual '6$#.M dri%es, serial ports, parallel ports/, installed software including the operating system +e.g. ernel %ersion, distribution type/ as well as library signature, as well as other properties such as image name and VM owner. 5ased on those descriptions VMs can be selected, duplicated, or further configured.

3egend
$ VMManager $ VM#epository

1. !. 3. ,n

,ntegrating Virtual Machines with 9rid technology allows easy migration of applications from one node to another. The steps are as follows: )sing 9rid software, the client free"es e*ecution of the VM The client then sends the HmigrateI command to the VMManager, specifying the new host node as a parameter &fter chec ing for the proper authori"ation, the VM is registered with the new host and a 9ridAT( call transfers the image terms of performance this is on a par with deployment B it is mainly bound by the length of transfer. ,n our tests, we migrated a !95 VM image from two identical nodes through a Aast 7thernet connection.

VM Deployment
The VM deployment process has 3 major steps: 1. The client queries the VM repository, sending a list of criteria describing a wor space. The repository returns a list of VM descriptors that match them. !. The client contacts the VMManager, sending it the descriptor of the VM they want to deploy, along with an identifier, and a lifetime for the VM. The VMManager authori"es the request using an access control list. 3. The VM instance is registered with the VMManager and the VM is copied from the VM#epository. The VMManager then interfaces with the VMM on the resource to power on the VM.
400

The graph to the right shows the proportion of time ta en by the constituents of the deployment process, measured in seconds. ;ote that the graph does not include time for authori"ation, but those times are comparable to registration time. &lso, the actual migration time depends on the networ latency and bandwidth. The pause and resume times are dependent on 3rd party VMM.

400

350

300

250 Pausing Registration 200 Copying Unpausing 150

100

50

The graph to the right shows the proportion of time ta en by the constituents of the deployment process, measured in seconds. The authori"ation time is not included, but it is comparable to registration time. The dominant factor in o%erall deployment time depends on networ latency and bandwidth.

350

300

250 Q ue ry 200 R e gis tra tio n C o py

150

100

50

&fter a scientist has deployed a VM onto the resource, he may run an application in it. Aor this purpose, each of our VMs was configured with the 9lobus Tool it. This picture represents a scientist running the T.(. program, creating an image of a transmembrane protein.

The low le%el features of our architecture are detailed in the diagram to the right. The diagram describes for nodes, each running a +potentially different/ host .8. 7ach node is running a VMM and a VMManager 9rid 8er%ice. .n top of that layer, run the actual VMs, which are installed with 9rid software, allowing them to be run as 9rid nodes. The VMs could also be used as independent e*ecution en%ironments, without 9rid middleware installed on them. +,nstead they would run applications directly/.

How does using VMs help the Bioinformatics community?

Do VMs fulfill their promise?
5roader base of resources: .ur tests show that this first promise is met. 'onsider the following situation: a scientist can use a testbed on 6.7 8cience 9rid across se%eral clusters. & scientist has access to !2 8olaris nodes in :5;:, !2 nodes in &;:<s =a"" 'luster +:inu* nodes/, and !2 :inu* nodes on ;7#8'<s pdsf cluster. ,f only the =a"" nodes ha%e the necessary configuration to run 7M5.88, it would ta e a lot more wor to get 7M5.88 to run on the :5;: and pdsf clusters. ,f we install 7M5.88 on a VM, and then run an instance of the VM on each node we can use all >2 nodes instead of just !2. 7asier deployment-distribution: )sing VMs ma es deployment easier and faster. ,n our tests we e*perimented with a ! 95 minimal VM image with the following results: 7M5.88 installation: ?4 minutes VM deployment on our testbed: > minutes !3 seconds (eace of mind +not ha%ing to debug installation/: priceless@ Aine 9rained resource management: 6epending on the implementation of, a VM can pro%ide fine$grained resource usage enforcement critical in many scenarios in the 9rid 7nhanced security: VMs offer enhanced isolation and are therefore a more secure solution for representing user en%ironments.

Issues or Pro"lems )ncountered

1hen de%eloping the architecture we encountered se%eral important but interesting issues and problems we had to resol%e. 'loc s: 1hile a VM image is fro"en or powered$off, the VM<s cloc does not update. 1e need a way to update a VM<s cloc as soon as it is powered$on or unpaused. ,( &ddresses: 1e need a way to assign unique ,( addresses to each new VM instance +i.e. each time a VM is deployed/ so that multiple copies of the same VM can be deployed on the same subnet. 8tarting a 9rid container: 1e also need a way to automatically start up a 9rid container on startup of a VM if we want it to be a full$fledged 9rid node, or at least launch a )ser Josting 7n%ironment. 1e sol%ed these issues by installing a daemon on the VM: upon deployment, it sets the ,( address of the VM, launches a )J7 and, if needed, updates the cloc .