| Prev | Part IV. Deployment And Virtualization Chapter 15. XML Deployment Descriptors |
 |
Next |
| Prev | Part IV. Deployment And Virtualization Chapter 15. XML Deployment Descriptors |
|
Next |
The main goal of using deployment descriptors is to remove all the deployment-related parameters from the source.
Thus, a same source code can be used to deployed an application on different infrastructures.
Parameters tied to the deployment of an application should be
totally described in a xml deployment descriptor. Hence within the source
code, there are no longer any references to:
Machine names
Creation Protocols
Registry/Lookup and Communications Protocols
rmi
http
rmissh
ibis
soap
Files Transfers
scp, rcp
arc (nordugrid)
other protocols like globus soon
A ProActive application can be deployed on different hosts, with different protocols without changing the source code
Within a ProActive program, active objects are created on Nodes as usual.
PAActiveObject.newActive(className, constructorParameters, node);
Nodes can be obtained from VirtualNodes (VN) declared and defined in a ProActiveDescriptor
Nodes are actual entities:
running into a JVM, on a host
they are the results of mapping VN --> JVMs
But it is the VirtualNodes which are actually used in program source.
After activation, the names of Nodes mapped to a VirtualNode are defined as the VirtualNode name concatenated to a random number.
VNs have the following characteristics:
a VN is uniquely identified with a String ID
a VN is defined in a ProActiveDescriptor
a VN has an object representation in a program after activation
A ProActiveDescriptor file specifies:
the mapping betweens VNs and JVMs
the way to create, acquire JVMs using processes defined in the lower infrastructure part
local, remote processes or combination of both to create remote jvms.
For instance defining an sshProcess that itself references a local jvmProcess. At execution, the ssh process will launch a jvm on the remote machine specified in hostname attribute of sshProcess definition.
files transfers
fault tolerance, security
Example:
<?xml version="1.0" encoding="UTF-8"?> <ProActiveDescriptor xmlns="urn:proactive:deployment:3.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd"> <!-- Variable Definitions --> <variables> <descriptorVariable name="PROACTIVE_HOME" value="/user/ffonteno/home/proactive-git/programming" /> <descriptorVariable name="JAVA_HOME" value="/user/ffonteno/home/src/java/jdk" /> </variables> <!-- Virtual Node Definitions --> <componentDefinition> <virtualNodesDefinition> <virtualNode name="VN1"/> </virtualNodesDefinition> </componentDefinition> <deployment> <!-- Mappings between Virtual Nodes and JVMs --> <mapping> <map virtualNode="VN1"> <jvmSet> <vmName value="jvm" /> </jvmSet> </map> </mapping> <!-- Mappings between JVMs and process references. --> <!-- Process references are used hereafter (within the infrastructure element) to describe the process used to create the JVMs. --> <jvms> <jvm name="jvm"> <creation> <processReference refid="jvmProcess" /> </creation> </jvm> </jvms> </deployment> <infrastructure> <processes> <!-- Process Definitions --> <processDefinition id="jvmProcess"> <jvmProcess class="org.objectweb.proactive.core.process.JVMNodeProcess"> </jvmProcess> </processDefinition> </processes> </infrastructure> </ProActiveDescriptor>
This example shows a VirtualNode called VN1, which is mapped to a JVM called jvm.
This jvm will be created using the process called jvmProcess which is defined in the infrastructure part. This part will be discussed later on. But you can already notice that there are two parts in a descriptor file: an abstract one containing VirtualNode definitions and deployment informations and a more concrete one containing concrete infrastructure informations where all processes are defined.
Typical example of a program code:
String descriptorFile = Main.class.getResource(
"/org/objectweb/proactive/examples/documentation/XMLDeployment/SSHDescriptor.xml").getPath();
// Creates the ProActiveDescriptor corresponding to the descriptor file
ProActiveDescriptor proActiveDescriptor = PADeployment.getProactiveDescriptor(descriptorFile);
// Gets the virtual node named VN1 described in the descriptor file.
VirtualNode virtualNode = proActiveDescriptor.getVirtualNode("VN1");
// Activates the virtual node.
// For activating several virtual node at once, you can use
// proActiveDescriptorAgent.activateMappings()
virtualNode.activate();
String className = A.class.getName();
Object[] constructorParameters = new Object[] {};
// Gets a node on which the active object will be created
Node node = virtualNode.getNode();
// Creates the active object
A a = (A) PAActiveObject.newActive(className, constructorParameters, node);
org.objectweb.proactive.core.descriptor.data.ProActiveDescriptor and
org.objectweb.proactive.core.descriptor.data.VirtualNode provides you with a set of methods
to manipulate VirtualNodes. Please refer to the javadoc to learn more.
Mapping one to one: 1 VN --> 1 JVM
<virtualNodesDefinition>
<virtualNode name='Dispatcher'/>
</virtualNodesDefinition>
<deployment>
<mapping>
<map virtualNode='Dispatcher'>
<jvmSet>
<vmName value='Jvm0'/>
</jvmSet>
</map>
</mapping>
</deployment>
Another possibility for the one to one mapping is to map 1 VN to the jvm running the program. In that case the lookup protocol can be specified but is optionnal (default value is the property proactive.communication.protocol) as it is shown in the following:
<virtualNodesDefinition>
<virtualNode name='Dispatcher'/>
</virtualNodesDefinition>
<deployment>
<mapping>
<map virtualNode='Dispatcher'>
<jvmSet>
<currentJVM protocol='rmi'/>
<!-- or <currentJVM/> -->
</jvmSet>
</map>
</mapping>
</deployment>
Since it is the current JVM, it does not have to be redifined later on in the descriptor. This will be shown in a complete example.
Mapping one to n: 1 VN --> N JVMs
<virtualNodesDefinition>
<virtualNode name='Renderer' property='multiple'/>
</virtualNodesDefinition>
<deployment>
<mapping>
<map virtualNode='Renderer'>
<jvmSet>
<currentJVM/>
<vmName value='Jvm1'/>
<vmName value='Jvm2'/>
<vmName value='Jvm3'/>
<vmName value='Jvm4'/>
</jvmSet>
</map>
</mapping>
</deployment>
Note that the property attribute is set to multiple since you want to map 1 VN to
multiple JVMs. Then a set of JVMs is defined for the
VirtualNode Renderer.
Four values are possible for this property
attribute:
unique - one to one mapping
unique_singleAO - one to one mapping and only one active object deployed on the corresponding node
multiple - one to N mapping
multiple_cyclic - one to N mapping in a cyclic manner.
This property is not mandatory but an
exception can be thrown in case of incompatibility. For instance, an
exception can be thrown if this
property is set to unique and more than one jvm is defined in the
jvmSet tag. In case of property set to unique_singleAO, the getUniqueAO() method of the
org.objectweb.proactive.core.descriptor.data.VirtualNode class
returns the unique AO created.
Three other attributes timeout, waitForTimeout, minNodeNumber can be set when defining a virtualNode
<virtualNodesDefinition>
<virtualNode name='Dispatcher' timeout='200' waitForTimeout='true'/>
<virtualNode name='Renderer' timeout='200' minNodeNumber='3'/>
</virtualNodesDefinition>
Depending on the value of waitForTimeout, the timeout attribute
has two different meanings.
If the waitForTimeout attribute, which is a boolean, is
set to true, then you will have to
wait exaclty timeout milliseconds before accessing Nodes.
If waitForTimeout is set to
false, then timeout represents the
maximum amount of time to wait, i.e. no more nodes will be created
once this timeout over.
Defaut value for waitForTimeout
attribute is false.
The minNodeNumber attribute defines the minimum
number of nodes to be created. If not
defined, access to the nodes will occur once the timeout expires,
or the number of nodes expected are effectively created. Setting
this attribute allows to redefine the number of nodes expected, we
define it as the number of nodes needed for the VirtualNode to be
suitable for the application. In the exammple above, once
3 nodes are created and mapped to
the VirtualNode Renderer, this
VirtualNode starts to give access to its nodes. Those options are
very usefull when there is no idea about how many nodes will be
mapped on the VirtualNode (which is often unususal). All those
attributes are optional.
Mapping n to one: N VN --> 1 JVMs
<virtualNodesDefinition>
<virtualNode name='Dispatcher' property='unique_singleAO'/>
<virtualNode name='Renderer' property='multiple'/>
</virtualNodesDefinition>
<deployment>
<mapping>
<map virtualNode='Dispatcher'>
<jvmSet>
<vmName value='Jvm1'/>
</jvmSet>
</map>
<map virtualNode='Renderer'>
<jvmSet>
<vmName value='Jvm1'/>
<vmName value='Jvm2'/>
<vmName value='Jvm3'/>
<vmName value='Jvm4'/>
</jvmSet>
</map>
</mapping>
</deployment>
In this example both VirtualNodes Dispatcher and Renderer have a mapping with Jvm1, it means that at deployment time, both VirtualNodes will get nodes created in the same JVM. Here is the notion of co-allocation in a JVM.
VirtualNode registration
Descriptors provide the ability to register a VirtualNode in a registry such as RMIRegistry, HTTP registry, IBIS/RMI Registry Service. Hence this VirtualNode will be accessible from another application as it is described in Section 15.3.2, “VirtualNodes Acquisition”. The protocol (registry) to use can be specified in the descriptor. If not specified, the VirtualNode will register using the protocol specified in the proactive.communication.protocol property which is rmi by default.
<virtualNodesDefinition>
<virtualNode name='Dispatcher' property='unique_singleAO'/>
<virtualNodesDefinition/>
<deployment>
<register virtualNode='Dispatcher' protocol='rmi'/>
<!-- or <register virtualNode='Dispatcher'/> -->
<!-- Using this syntax, registers the VirtualNode with the protocol
specified in proactive.communication.protocol property -->
<mapping>
<map virtualNode='Dispatcher'>
<jvmSet>
<vmName value='Jvm0'/>
</jvmSet>
</map>
</mapping>
</deployment>
The register tag allows to
register the VirtualNode Dispatcher when activated, on the local
machine in a RMIRegistry. As said before this VirtualNode will
be accessible by another application using the lookup tag (see
below) or using the lookupVirtualNode method of
the PADeployment class.
Descriptors provide the ability to acquire a VirtualNode already deployed by another application. Such VirtualNodes are defined in VirtualNodes Acquisition tag as it is done for VirtualNodesDefinition except that no property and no mapping with jvms are defined since such VNs are already deployed. In the deployment part, the lookup tag gives information on where and how to acquire the VirtualNode. Lookup will be performed when activating the VirtualNode.
<virtualNodesAcquisition>
<virtualNode name='Dispatcher'/>
</virtualNodesAcquisition>
..........
<deployment>
..........
<lookup virtualNode='Dispatcher' host='machine_name' protocol='rmi' port='2020'/>
</deployment>
As mentioned in the previous section, in order to acquire VirtualNode Dispatcher, it must have previously been registered on the specified host by another application. Sometimes, the host where to perform the lookup will only be known at runtime. In that case, it is specified in the descriptor with '*' for the host attribute.
<lookup virtualNode='Dispatcher' host='*' protocol='rmi'/>
Then when the host name is available, ProActive provides the method
setRuntimeInformations in the
org.objectweb.proactive.core.descriptor.data.VirtualNode class to update the
value and to perform the lookup. Typical example of code:
// Returns a ProActiveDescriptor object from the xml file
ProActiveDescriptor pad = PADeployment.getProactiveDescriptor(String xmlFileLocation);
// Activates all VirtualNodes (definition and acquisition)
pad.activateMappings();
// Gets the Dispatcher virtual node
VirtualNode vnDispatcher = pad.getVirtualNode('Dispatcher');
// Sets the host to lookup by setting the LOOKUP_HOST property
vnDispatcher.setRuntimeInformations('LOOKUP_HOST','machine_name);
To summarize, all VirtualNodes are activated when calling the activate method except if '*' is set for a VirtualNode to be acquired. In that case, the lookup will be performed when giving host informations.
Registration and lookup can be performed automatically when using
tags in the descriptor as well as programmatically using static methods
provided by the org.objectweb.Proactive class:
PADeployment.registerVirtualNode(VirtualNode virtualNode, String registrationProtocol, boolean replacePreviousBinding);
PADeployment.lookupVirtualNode(String url, String protocol);
PADeployment.unregisterVirtualNode(VirtualNode virtualNode);
1 JVM --> 1 Node
........................... <jvm name='jvm1'> <creation> <processReference refid='jvmProcess'/> </creation> </jvm> ...........................
In this example, jvm1 will be created using the process
called jvmProcess (as discussed
later on, this process represents a java process and can be seen as
the java ProActiveClassname command)
1 JVM --> N Nodes on a single JVM
........................... <jvm name='jvm1' askedNodes='3'> <creation> <processReference refid='jvmProcess'/> </creation> </jvm> ...........................
1 JVM --> N Nodes on N JVMs
This is the case when the referenced process is a cluster process (LSF, PBS, GLOBUS, ...) or a process list (see Process list)
Descriptors give the ability to acquire JVMs instead of creating them. To do so, it must be specified in the acquisition tag which service to use in oder to acquire the JVMs. Services will be described below, in the infrastructure part. At this point one service is provided: the RMIRegistryLookup service.
<jvm name='jvm1'> <acquisition> <serviceReference refid='lookup'/> </acquisition> </jvm> ...........................
In this example, Jvm1 will be acquired using the service called lookup (as discussed later on, this service represents a way to acquire a JVM). Note that the name lookup is totally arbitrary on condition that a service with the id lookup is defined in the infrastructure part.
To avoid mistake when building XML descriptors, ProActive provides an XML Schema called DescriptorSchema.xsd. To validate your file against this schema, the following line must be put at the top of the xml document as it is done for all ProActive examples:
<ProActiveDescriptor xmlns="urn:proactive:deployment:3.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
Note that this schema is available in the ProActive distribution
package in the PROACTIVE_HOME/src/Core/org/objectweb/proactive/core/descriptor/xml/schemas/deployment/3.3/deployment.xsd file.
Using descriptors related
methods (Proactive.getProactiveDescriptor(file)) triggers automatic and
transparent validation of the file using Xerces2_4_0 if
the ProActive property schema.validation
is set to enable (see Chapter 11, ProActive Basic Configuration for more details). If a problem occurs during
the validation, an error message is displayed. Otherwise, if the
validation is successful, no message appears. An XML validation tool such
as xmllint command on Unix or XMLSPY5.0 on Windows can also be used to validate XML descriptors.
The following XML files was used for the C3D application before being replaced by GCM Deployment descriptors. The first file is read when launching the C3DDispatcher. The second one is read every time a C3DUser is added. Both files contain many features described earlier in this document.
<ProActiveDescriptor
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation='DescriptorSchema.xsd'>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name='Dispatcher' property='unique_singleAO'/>
<virtualNode name='Renderer' property='multiple'/>
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<register virtualNode='Dispatcher'/>
<mapping>
<map virtualNode='Dispatcher'>
<jvmSet>
<currentJvm/>
</jvmSet>
</map>
<map virtualNode='Renderer'>
<jvmSet>
<vmName value='Jvm1'/>
<vmName value='Jvm2'/>
<vmName value='Jvm3'/>
<vmName value='Jvm4'/>
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name='Jvm1'>
<creation>
<processReference refid='jvmProcess'/>
</creation>
</jvm>
<jvm name='Jvm2'>
<creation>
<processReference refid='jvmProcess'/>
</creation>
</jvm>
<jvm name='Jvm3'>
<creation>
<processReference refid='jvmProcess'/>
</creation>
</jvm>
<jvm name='Jvm4'>
<creation>
<processReference refid='jvmProcess'/>
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id='jvmProcess'>
<jvmProcess
class='org.objectweb.proactive.core.process.JVMNodeProcess'/>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
Example 15.1. C3D_Dispatcher_Render.xml
The abstract part containing VirtualNodes definition and
deployment informations has already been explained. To summarize, two
VirtualNodes are defined Dispatcher and
Renderer. Dispatcher is mapped to the jvm running the main() method,
and will be exported using the protocol specified in the proactive.communication.protocol property. This
VirtualNode will be registered in a Registry (still using the protocol
specified in proactive.communication.protocol property) when
activated. As for Renderer, it is mapped to a set of
JVMs called Jvm1, ..., Jvm4.
<ProActiveDescriptor
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation='DescriptorSchema.xsd'>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name='User'/>
</virtualNodesDefinition>
<virtualNodesAcquisition>
<virtualNode name='Dispatcher'/>
</virtualNodesAcquisition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode='User'>
<jvmSet>
<currentJvm/>
</jvmSet>
</map>
</mapping>
<lookup virtualNode='Dispatcher' host='*' protocol='rmi'/>
</deployment>
<infrastructure>
<processes>
<processDefinition id='jvmProcess'>
<jvmProcess
class='org.objectweb.proactive.core.process.JVMNodeProcess'/>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
Example 15.2. C3D_User.xml
This file is read when addind a C3DUser. Two VirtualNodes are
defined: User which is mapped to the jvm
running the main() method, whose acquisition method is performed by looking up
the RMIRegistry, and Dispatcher in the
virtualNodesAcquisition part which will
be the result of a lookup in the RMIRegistry of a host to be specified at
runtime.
In the previous example, all defined JVMs are created using jvmProcess process. This process is totally defined in the infrastructure part. Of course the process name in the creation part must point to an existing defined process in the infrastructure part. For instance, if the name in the creation tag is localJVM, there must be a process defined in the infrastructure with the id localJVM
In the previous example, the
defined process jvmProcess will create
local JVMs. The class attribute defines the class to instantiate in
order to create the process. ProActive library provides a class to
instantiate in order to create processes that will launch local JVMs:
org.objectweb.proactive.core.process.JVMNodeProcess
<infrastructure>
<processes>
<processDefinition id='jvmProcess'>
<jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcesss'>
<classpath>
<absolutePath value='/home/ProActive/classes'/>
<absolutePath value='/home/ProActive/lib/bcel.jar'/>
<absolutePath value='/home/ProActive/lib/asm.jar'/>
<absolutePath value='/home/ProActive/lib/reggie.jar'/>
</classpath>
<javaPath>
<absolutePath value='/usr/local/jdk1.4.0/bin/java'/>
</javaPath>
<policyFile>
<absolutePath value='/home/ProActive/dist/proactive.java.policy'/>
</policyFile>
<log4jpropertiesFile>
<relativePath origin='user.home' value='ProActive/dist/proactive-log4j'/>
</log4jpropertiesFile>
<ProActiveUserPropertiesFile>
<absolutePath value='/home/config.xml'/>
</ProActiveUserPropertiesFile>
<jvmParameters>
<parameter
value='-Djava.library.path=/home1/fabrice/workProActive/ProActive/lib'/>
<parameter
value='-Dsun.boot.library.path=/home1/fabrice/workProActive/ProActive/lib'/>
<parameter value='-Xms512 -Xmx512'/>
</jvmParameters>
</jvmProcess>
</processDefinition>
</processes>
</infrastructure>
As shown in the example above, ProActive provides the ability to define or change the classpath environment variable, the java path, the policy file path, the log4j properties file path, the ProActive properties file path (see Chapter 11, ProActive Basic Configuration for more details) and also to pass parameters to the JVM to be created.
![[Note]](images/png/note.png) |
Note |
|---|---|
|
Note that parameters to be passed here are related to the jvm in opposition to properties given in the configuration file (see Chapter 11, ProActive Basic Configuration), which is more focused on ProActive or application behaviour. In fact parameters given here will be part of the java command to create other jvms, whereas properties given in the config file will be loaded once the jvm is created. |
If not specified, there is a default value (except for the jvmParameters element) for each of these variables. In the first example of this section, only the Id of the process, and the class to instantiate are defined. If for example the home directory of the remote machine where you want to create a JVM is not the same as the one of your local machine, then you might want to define or redefine variable such as the classpath or java path or policyfile path. As shown in the example, paths to files can be either absolute or relative. If relative, an origin must be provided, it can be user.home or user.dir or user.classpath and it is resolved locally, i.e on the JVM reading the descriptor and not on the remote JVM that is going to be created.
As mentionned in the configuration file (see Chapter 11, ProActive Basic Configuration), if the <ProActiveUserPropertiesFile> is not defined for remote JVMs, they will load a default one once created.
Even if not shown in this example, a specific tag is provided for
XbootClasspathi option under the form.
<bootclasspath>
<relativePath origin='user.home' value='/IOFAb/Ibis/'/>
<relativePath origin='user.home' value='/IOFAb/classlibs/jdk'/>
</bootclasspath>
With XML Deployment Descriptor, ProActive provides the ability to create remote Nodes (remote JVMs). You can specify in the descriptor if you want to access the remote host with rsh, ssh, rlogin, lsf, pbs, oar, prun, globus, arc (nordugrid). How to use these protocols is explained in the following examples. Just remind that you can also combine these protocols.The principle of combination is fairly simple, you can imagine for instance that you will log on a remote cluster frontend with ssh, then use pbs to book nodes and to create JVMs on each. You will also notice that there is at least one combination for each remote protocol. Indeed each remote protocol must have a pointer either on another remote protocol or on a jvmProcess to create a jvm (discussed previoulsy).
You can find in the $PROACTIVE_HOME/descriptors/examples_legacy_descriptors/ directory
several examples of supported protocols and useful combinations.
|
Note |
|---|---|
|
For using the ProActive XML Deployment, ProActive has to be installed on the local host as well as on every machine you want to create Nodes on. |
RSH
........................... <jvm name='jvm1'> <creation> <processReference refid='rshProcess'/> </creation> </jvm> ........................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='rshProcess'> <rshProcess class='org.objectweb.proactive.core.process.rsh.RSHProcess' hostname='sea.inria.fr'> <processReference refid='jvmProcess'/> </rshProcess> </processDefinition> </processes>
For jvm1 the creation process
is rshProcess
which is defined in the infrastructure section. To define this
process you have to give the class to instantiate to create the
rsh process. ProActive provides
org.objectweb.proactive.core.process.rsh.RSHProcess
to create rsh process. You must
give the remote host name to log on with rsh. You can define as well
username='toto' if you plan to use rsh with
-l option. As said before this
rsh process must reference a local process, and in the
example, it references the process defined with the id jvmProcess. It means that once logged on
sea.inria.fr with rsh, a local JVM will be launched, ie a ProActive
node will be created on sea.inria.fr thanks to the process defined
by jvmProcess.
Here is a complete RSH deployment example:
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME" value="/home/user/ProActive"/> <!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME" value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="matrixNode" property="multiple" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="matrixNode">
<jvmSet>
<vmName value="Jvm1" />
<vmName value="Jvm2" />
<vmName value="Jvm3" />
<vmName value="Jvm4" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="localJVM" />
</creation>
</jvm>
<jvm name="Jvm2">
<creation>
<processReference refid="rsh_crusoe" />
</creation>
</jvm>
<jvm name="Jvm3">
<creation>
<processReference refid="rsh_waha" />
</creation>
</jvm>
<jvm name="Jvm4">
<creation>
<processReference refid="rsh_amstel" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="localJVM">
<jvmProcess class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath value="${JAVA_HOME}/bin/java"/>
</javaPath>
<policyFile>
<absolutePath value="${PROACTIVE_HOME}/dist/proactive.java.policy"/>
</policyFile>
<log4jpropertiesFile>
<absolutePath value="${PROACTIVE_HOME}/dist/proactive-log4j"/>
</log4jpropertiesFile>
<!--<jvmParameters>
<parameter value="-Dproactive.communication.protocol=rmissh"/>
</jvmParameters>-->
</jvmProcess>
</processDefinition>
<processDefinition id="rsh_crusoe">
<rshProcess
class="org.objectweb.proactive.core.process.rsh.RSHProcess"
hostname="crusoe.inria.fr">
<processReference refid="localJVM"></processReference>
</rshProcess>
</processDefinition>
<processDefinition id="rsh_waha">
<rshProcess
class="org.objectweb.proactive.core.process.rsh.RSHProcess"
hostname="waha.inria.fr">
<processReference refid="localJVM"></processReference>
</rshProcess>
</processDefinition>
<processDefinition id="rsh_amstel">
<rshProcess
class="org.objectweb.proactive.core.process.rsh.RSHProcess"
hostname="amstel.inria.fr">
<processReference refid="localJVM"></processReference>
</rshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
RLOGIN
........................... <jvm name='jvm1'> <creation> <processReference refid='rloginProcess'/> </creation> </jvm> ........................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='rloginProcess'> <rloginProcess class='org.objectweb.proactive.core.process.rlogin.RLoginProcess' hostname='sea.inria.fr'> <processReference refid='jvmProcess'/> </rloginProcess> </processDefinition> </processes>
You can use rlogin in the same way that you would use rsh
SSH
........................... <jvm name='jvm1'> <creation> <processReference refid='sshProcess'/> </creation> </jvm> ........................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='sshProcess'> <sshProcess class='org.objectweb.proactive.core.process.ssh.SSHProcess' hostname='sea.inria.fr'> <processReference refid='jvmProcess'/> </sshProcess> </processDefinition> </processes>
ProActive provides
org.objectweb.proactive.core.process.ssh.SSHProcess
to create ssh process.
In order to use ssh to log on a remote host, you must perform some actions. First you need to copy your public key (located in identity.pub under ~/.ssh on your local machine) in the authorized_keys file (located under ~/.ssh) of the remote host. Then to avoid interactivity, you will have to launch on the local host the ssh-agent command: ssh-agent $SHELL. This command can be put in your .xsession file, in order to run it automatically when logging on your station. Then launching ssh-add command to add your identity, you will be asked to enter your passphrase, the one you provided when you have generated your ssh key pair.
Note that if the generated key pair is not encrypted (no passphrase), you do not need to run neither the ssh-agent, nor the ssh-add command. Indeed it is sufficient when using non encrypted private key, to only copy the public key on the remote host (as mentionned above) in order to get logged automatically on the remote host.
These steps must be performed before running any ProActive application using ssh protocol. If you are not familiar with ssh, see openSSH
The following is a complete SSH deployment example.
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="matrixNode" property="multiple" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="matrixNode">
<jvmSet>
<vmName value="Jvm1" />
<vmName value="Jvm2" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="ssh_crusoe" />
</creation>
</jvm>
<jvm name="Jvm2">
<creation>
<processReference refid="ssh_waha" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="localJVM">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess" />
</processDefinition>
<processDefinition id="ssh_crusoe">
<sshProcess
class="org.objectweb.proactive.core.process.ssh.SSHProcess"
hostname="crusoe.inria.fr">
<processReference refid="localJVM"></processReference>
</sshProcess>
</processDefinition>
<processDefinition id="ssh_waha">
<sshProcess
class="org.objectweb.proactive.core.process.ssh.SSHProcess"
hostname="waha.inria.fr">
<processReference refid="localJVM"></processReference>
</sshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
Process List
ProActive provides a way to define a list of processes for RSH, SSH, RLOGIN protocols. Using processList or processListbyHost elements avoids having a long deployment file when many machines with similar names are going to be connected with protocols mentionned before. The first example below shows how to use processList tag and the second one how to use processListbyHost.
........................... <jvm name='jvm1'> <creation> <processReference refid='processlist'/> </creation> </jvm> ........................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='processlist'> <processList class='org.objectweb.proactive.core.process.ssh.SSHProcessList' fixedName='node-' list='[0-100;2]^[10,20]' padding='3' domain='sophia.grid5000.fr'> <processReference refid='jvmProcess'/> </processList> </processDefinition> </processes>
When using processList tag, the class attribute can take 3 values:
org.objectweb.proactive.core.process.ssh.SSHProcessList
public class SSHProcessList extends AbstractListProcessDecorator {
/**
*
*/
public SSHProcessList() {
super();
}
/**
* @see org.objectweb.proactive.core.process.AbstractListProcessDecorator#createProcess()
*/
@Override
protected ExternalProcessDecorator createProcess() {
return new SSHProcess();
}
}
org.objectweb.proactive.core.process.rsh.RSHProcessList
public class RSHProcessList extends AbstractListProcessDecorator {
/**
*
*/
public RSHProcessList() {
super();
}
/**
* @see org.objectweb.proactive.core.process.AbstractListProcessDecorator#createProcess()
*/
@Override
protected ExternalProcessDecorator createProcess() {
return new RSHProcess();
}
}
org.objectweb.proactive.core.process.rlogin.RLoginProcessList
public class RLoginProcessList extends AbstractListProcessDecorator {
/**
*
*/
public RLoginProcessList() {
super();
}
/**
* @see org.objectweb.proactive.core.process.AbstractListProcessDecorator#createProcess()
*/
@Override
protected ExternalProcessDecorator createProcess() {
return new RLoginProcess();
}
}
The fixedName attribute
is mandatory and represents the fixed part shared by all machine
names.
The list attribute is also
mandatory and can take several forms:
[m-n] means from m to n with a step 1,
[m-n;k] means from m to n with a step k (m, m+k, m+2k, ....),
[m-n]^[x,y] means from m to n exluding x and y,
[m-n]^[x,y-z] means from m to n exluding x and values from y to z,
[m-n;k]^[x,y] same as before except that the step is k.
The padding attribute is
optional (default is 1) and represents the number of digits to use for the node number.
For instance, the node 1 with a padding equal to 3 will be written 001.
Finally, the domain attribute is mandatory
and represents the last part shared by all machine names. Thus, in
the previous example, a jvm is going to be created using ssh on
machines: node000.sophia.grid5000.fr,
node002.sophia.grid5000.fr,..., node098.sophia.grid5000.fr,
node100.sophia.grid5000.fr (note that step is 2) excluding machines:
node010.sophia.grid5000.fr and node020.sophia.grid5000.fr.
........................... <jvm name='jvm1'> <creation> <processReference refid='processlist'/> </creation> </jvm> ........................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='processlist'> <processListbyHost class='org.objectweb.proactive.core.process.ssh.SSHProcessList' hostlist='crusoe waha nahuel' domain='inria.fr'> <processReference refid='jvmProcess'/> </processListbyHost> </processDefinition> </processes>
Using processListbyHost element allows to give a hostlist separated with a whitespace. The class attribute is defined as described in the processList tag. The domain attribute is optional since the complete hostname can also be provided in the hostlist attribute. In the example, a jvm is going to be created using ssh on crusoe.inria.fr, waha.inria.fr, nahuel.inria.fr.
Here are complete examples of SSH deployment using processList and processListbyHost.
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME" value="/home/user/ProActive"/> <!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME" value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="plugtest"/>
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="plugtest">
<jvmSet>
<vmName value="Jvm1"/>
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="ssh_list"/>
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="localJVM">
<jvmProcess class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath value="${JAVA_HOME}/bin/java"/>
</javaPath>
<policyFile>
<absolutePath value="${PROACTIVE_HOME}/dist/proactive.java.policy"/>
</policyFile>
<log4jpropertiesFile>
<absolutePath value="${PROACTIVE_HOME}/dist/proactive-log4j"/>
</log4jpropertiesFile>
<!--<jvmParameters>
<parameter value="-Dproactive.communication.protocol=rmissh"/>
</jvmParameters>-->
</jvmProcess>
</processDefinition>
<processDefinition id="ssh_list">
<processList class="org.objectweb.proactive.core.process.ssh.SSHProcessList" fixedName="125.110.118." list="[96-200]^[96,102,103,104,105,110,11,112]" domain="" username="rquilici"> <!--CHANGE ME!!!! -->
<processReference refid="localJVM"></processReference>
</processList>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
and
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="matrixNode" property="multiple" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="matrixNode">
<jvmSet>
<vmName value="Jvm1" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="ssh_list" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="localJVM">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess" />
</processDefinition>
<processDefinition id="ssh_list">
<processListbyHost
class="org.objectweb.proactive.core.process.ssh.SSHProcessList"
hostlist="crusoe waha amstel"> <!--CHANGE ME!!!! -->
<processReference refid="localJVM"></processReference>
</processListbyHost>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
LSF
This protocol is used to create Nodes (JVMs) on a cluster.
ProActive provides
org.objectweb.proactive.core.process.lsf.LSFBSubProcess
to create bsub process.
In this part, we assume that you want to submit a job from a machine which is not the cluster frontend. As described before, you can combine protocols. In this case , you will have to define a process to log on the front-end of the cluster (rlogin if your machine is on the same LAN than the cluster front-end, else ssh (Remember that to use ssh you will have to run some commands as explained above).
<jvm name='Jvm2'> <creation> <processReference refid='sshProcess'/> </creation> </jvm> ................................................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='bsubInriaCluster'> <bsubProcess class='org.objectweb.proactive.core.process.lsf.LSFBSubProcess'> <processReference refid='jvmProcess'/> <bsubOption> <hostlist>cluster_machine1 cluster_machine2<hostlist/> <processor>6</processor> <scriptPath> <absolutePath value='/home/ProActive/dist/scripts/unix/cluster/startRuntime.sh'/> </scriptPath> </bsubOption> </bsubProcess> </processDefinition> <processDefinition id='sshProcess'> <sshProcess class='org.objectweb.proactive.core.process.ssh.SSHProcess' hostname='sea.inria.fr'> <processReference refid='bsubInriaCluster'/> </sshProcess> </processDefinition> </processes>
In this example, the JVM called Jvm2 will be created using ssh to log on the cluster front end. Then a
bsub command will be generated
thanks to the process defined by bsubInriaCluster.
This bsub command will create Nodes on several
cluster machines, since bsubInriaCluster references the jvmProcess defined process. All tags defined
under <bsubOption> are not
mandatory, but they can be very usefull. The <hostlist> tag
defines possible candidates in the job attribution, if not set the
job will be allocated among all cluster's machines. The
<processor> tag defines the number of processor requested, if
not set, one processor is requested. The <resourceRequirement>
tag defines the expected number of processors per machine. For
instance <resourceRequirement value='span[ptile=2]'/> ensures
that 2 processors per machines will be used, whereas
<resourceRequirement value='span[ptile=1]'/> forces LSF to allocate only one
processor per machine. It represents the -R option of LSF. At last, <scriptPath>
defines the path on the cluster front end of the
startRuntime.sh script which is necessary to run ProActive on a cluster.
This script is located under the Proactive/dist/scripts/unix/cluster directory. If not
set the default location is set as
~/Proactive/dist/scripts/unix/cluster.
If you want to submit the job directly from the cluster entry point, define only the bsubProcess like in the previous example and skip the ssh definition.
<jvm name='Jvm2'> <creation> <processReference refid='bsubInriaCluster'/> </creation> </jvm> ................................................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='bsubInriaCluster'> <bsubProcess class='org.objectweb.proactive.core.process.lsf.LSFBSubProcess' interactive='true' queue='short'> <processReference refid='jvmProcess'/> <bsubOption> <hostlist>cluster_machine1 cluster_machine2<hostlist/> <processor>6</processor> <scriptPath> <absolutePath value='/home/ProActive/dist/scripts/unix/cluster/startRuntime.sh'/> </scriptPath> </bsubOption> </bsubProcess> </processDefinition> </processes>
Note that in the example above two new attributes has appeared: interactive and queue. They are optional, and have a default value: respectively false and normal. They represent option in the bsub command: interactive mode, and the name of the queue.
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME"
value="/home/user/ProActive" /><!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME"
value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="plugtest" timeout="160000" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="plugtest">
<jvmSet>
<vmName value="Jvm1" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="sshInriaCluster" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="localJVM1">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath
value="${JAVA_HOME}/bin/java" />
</javaPath>
<policyFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive.java.policy" />
</policyFile>
<log4jpropertiesFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive-log4j" />
</log4jpropertiesFile>
<jvmParameters>
<parameter
value="-Dproactive.communication.protocol=rmissh" />
</jvmParameters>
</jvmProcess>
</processDefinition>
<processDefinition id="bsubInriaCluster">
<bsubProcess
class="org.objectweb.proactive.core.process.lsf.LSFBSubProcess">
<processReference refid="localJVM1" />
<bsubOption>
<processor>60</processor>
<resourceRequirement value="span[ptile=2]" />
<scriptPath>
<absolutePath
value="${PROACTIVE_HOME}/scripts/unix/cluster/startRuntime.sh" />
</scriptPath>
</bsubOption>
</bsubProcess>
</processDefinition>
<processDefinition id="sshInriaCluster">
<sshProcess
class="org.objectweb.proactive.core.process.ssh.SSHProcess"
hostname="frontend" username="plugtest">
<processReference refid="bsubInriaCluster" />
</sshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
PBS
This protocol is used to create jobs on cluster managed by
PBS, PBSPro or Torque. ProActive provides
org.objectweb.proactive.core.process.pbs.PBSBSubProcess
to create pbs processes. As
explained for LSF, you can combine protocols in order to
log on the cluster's frontal with ssh and then to create nodes using
PBS, or you can also use only PBS without ssh if you are already
logged on the frontend. Example below shows how to combine an ssh
process to log on the cluster and a PBS process that references a
jvmProcess in order to create nodes
on processors requested by PBS.
<jvm name='Jvm2'> <creation> <processReference refid='sshProcess'/> </creation> </jvm> ................................................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='pbsCluster'> <pbsProcess class='org.objectweb.proactive.core.process.pbs.PBSSubProcess'> <processReference refid='jvmProcess'/> <pbsOption> <hostsNumber>4</hostsNumber> <processorPerNode>1</processorPerNode> <bookingDuration>00:15:00</bookingDuration> <outputFile>/home1/rquilici/out.log</outputFile> <scriptPath> <absolutePath value='/home/ProActive/dist/scripts/unix/cluster/pbsStartRuntime.sh'/> </scriptPath> </pbsOption> </pbsProcess> </processDefinition> <processDefinition id='sshProcess'> <sshProcess class='org.objectweb.proactive.core.process.ssh.SSHProcess' hostname='frontend'> <processReference refid='pbsCluster'/> </sshProcess> </processDefinition> </processes>
Note that not all options are listed here, and some options mentionned in the example are optionnal:
hostsNumber represents the number of host requested using pbs (default is 1)
processorPerNode represents the number of processor per hosts requested (1 or 2, default is 1)
bookingDuration represents the duration of the job (default is 1 minute)
outputFile represents the file where to put the ouput of the job(default is specified by pbs)
scriptPath represents the location on the
frontend_host of the script pbsStartRuntime.sh (default is
/user.home/ProActive/dist/scripts/unix/cluster/pbsStartRuntime.sh)
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME"
value="/home/user/ProActive" /><!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME"
value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="plugtest" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="plugtest">
<jvmSet>
<vmName value="Jvm1" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="sshInriaCluster" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="localJVM1">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath
value="${JAVA_HOME}/bin/java" />
</javaPath>
<policyFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive.java.policy" />
</policyFile>
<log4jpropertiesFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive-log4j" />
</log4jpropertiesFile>
<jvmParameters>
<parameter
value="-Dproactive.communication.protocol=rmissh" />
</jvmParameters>
</jvmProcess>
</processDefinition>
<processDefinition id="pbsInriaCluster">
<pbsProcess
class="org.objectweb.proactive.core.process.pbs.PBSSubProcess">
<processReference refid="localJVM1" />
<commandPath value="/opt/torque/bin/qsub" />
<pbsOption>
<hostsNumber>32</hostsNumber>
<processorPerNode>2</processorPerNode>
<bookingDuration>02:00:00</bookingDuration>
<scriptPath>
<!--absolutePath value="/home/plugtest/ProActive/scripts/unix/cluster/pbsStartRuntime.sh"/-->
<absolutePath
value="${PROACTIVE_HOME}/scripts/unix/cluster/pbsStartRuntime.sh" />
</scriptPath>
</pbsOption>
</pbsProcess>
</processDefinition>
<processDefinition id="sshInriaCluster">
<sshProcess
class="org.objectweb.proactive.core.process.ssh.SSHProcess"
hostname="frontend" username="plugtest">
<processReference refid="pbsInriaCluster" />
</sshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
Sun Grid Engine
This protocol is used to create jobs on cluster managed by Sun
Grid Engine. ProActive provides
org.objectweb.proactive.core.process.gridengine.GridEngineSubProcess
to create grid engine processes. As
explained above, you can combine protocols in order to
log on the cluster's frontal with ssh and then to create nodes using
SGE, or you can also use only SGE without ssh if you are already
logged on the frontend. The example below shows how to combine an ssh
process to log on the cluster and a SGE process that references a
jvmProcess in order to create nodes
on processors requested by SGE.
<jvm name='Jvm2'> <creation> <processReference refid='sshProcess'/> </creation> </jvm> ................................................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='sgeCluster'> <gridengineProcess class='org.objectweb.proactive.core.process.gridengine.GridEngineSubProcess'> <processReference refid='jvmProcess'/> <gridEngineOption> <hostsNumber>4</hostsNumber> <bookingDuration>00:15:00</bookingDuration> <scriptPath> <absolutePath value='/home/ProActive/dist/scripts/unix/cluster/gridEngineStartRuntime.sh'/> </scriptPath> <parallelEnvironment>mpi</parallelEnvironment> </gridEngineOption> </gridengineProcess> </processDefinition> <processDefinition id='sshProcess'> <sshProcess class='org.objectweb.proactive.core.process.ssh.SSHProcess' hostname='frontend'> <processReference refid='sgeCluster'/> </sshProcess> </processDefinition> </processes>
As mentionned previously, many options exist, and correspond
to the main options specified in an SGE system. For example, ScriptPath represents the location on the
frontend_host of the script gridEngineStartRuntime.sh (default is /user.home/ProActive/dist/scripts/unix/cluster/gridEngineStartRuntime.sh).
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME"
value="/home/user/ProActive" /><!--CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="plugtest" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="plugtest">
<jvmSet>
<vmName value="Jvm1" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="sshCluster" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="internalJVM">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath
value="/home/plugtest/j2sdk1.4.2_05/bin/java" /> <!--CHANGE ME!!!! -->
</javaPath>
<policyFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive.java.policy" />
</policyFile>
<log4jpropertiesFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive-log4j" />
</log4jpropertiesFile>
<jvmParameters>
<parameter
value="-Dproactive.communication.protocol=rmissh" />
</jvmParameters>
</jvmProcess>
</processDefinition>
<processDefinition id="sgeprocess">
<gridEngineProcess
class="org.objectweb.proactive.core.process.gridengine.GridEngineSubProcess"
queue="normal">
<processReference refid="internalJVM" />
<commandPath
value="/opt/gridengine/bin/lx26-x86/qsub" />
<gridEngineOption>
<hostsNumber>10</hostsNumber>
<bookingDuration>3600</bookingDuration>
<scriptPath>
<absolutePath
value="${PROACTIVE_HOME}/scripts/unix/cluster/gridEngineStartRuntime.sh" />
</scriptPath>
<parallelEnvironment>mpi</parallelEnvironment>
</gridEngineOption>
</gridEngineProcess>
</processDefinition>
<processDefinition id="sshCluster">
<sshProcess
class="org.objectweb.proactive.core.process.ssh.SSHProcess"
hostname="frontend" username="plugtest"> <!--CHANGE ME!!!! -->
<processReference refid="sgeprocess" />
</sshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
OAR
OAR is a cluster protocol developed at INRIA Alpes and used on
Grid5000. ProActive
provides
org.objectweb.proactive.core.process.oar.OARSubProcess
to use such a protocol. As explained above, you can combine protocols in
order to log on the cluster's frontend with ssh and then to
create nodes using OAR, or you can also use only OAR without ssh if
you are already logged on the frontend. The example below shows how to
combine an ssh process to log on the cluster, then an OAR process
that references a jvmProcess in
order to create nodes on processors requested by OAR.
<jvm name='Jvm2'> <creation> <processReference refid='sshProcess'/> </creation> </jvm> ................................................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='oarCluster'> <oarProcess class='org.objectweb.proactive.core.process.oar.OARSubProcess'> <processReference refid='jvmProcess'/> <oarOption> <resources>node=2,weight=2</resources> <scriptPath> <absolutePath value='/home/ProActive/dist/scripts/unix/cluster/oarStartRuntime.sh'/> </scriptPath> </oarOption> </oarProcess> </processDefinition> <processDefinition id='sshProcess'> <sshProcess class='org.objectweb.proactive.core.process.ssh.SSHProcess' hostname='frontend'> <processReference refid='oarCluster'/> </sshProcess> </processDefinition> </processes>
As mentionned previously, many options exist, and correspond
to the main options specified in an OAR system. For example, ScriptPath represents the location on the
frontend host of the script oarStartRuntime.sh (default is
/user.home/ProActive/dist/scripts/unix/cluster/oarStartRuntime.sh).
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME"
value="/home/user/ProActive" /><!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME"
value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="Test" property="multiple" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="Test">
<jvmSet>
<vmName value="JvmSSH" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="JvmOARGrid">
<creation>
<processReference refid="oarGridProcess" />
</creation>
</jvm>
<jvm name="JvmSSH">
<creation>
<processReference refid="sshProcess" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="jvmProcess">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath
value="${JAVA_HOME}/bin/java" />
</javaPath>
<policyFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive.java.policy" />
</policyFile>
<log4jpropertiesFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive-log4j" />
</log4jpropertiesFile>
</jvmProcess>
</processDefinition>
<processDefinition id="oarGridProcess">
<oarGridProcess
class="org.objectweb.proactive.core.process.oar.OARGRIDSubProcess"
bookedNodesAccess="ssh" queue="default">
<processReference refid="jvmProcess" />
<commandPath value="/usr/local/bin/oargridsub" />
<oarGridOption>
<!--Available clusters are:
| idpot | caddo.imag.fr |
| gdx | devgdx002.orsay.grid5000.fr |
| toulouse | oar.toulouse.grid5000.fr |
| sophia | oar.sophia.grid5000.fr |
| lyon | oar.lyon.grid5000.fr |
| parasol | oar.rennes.grid5000.fr |
| tartopom | dev-powerpc.rennes.grid5000.fr |
| paraci | dev-xeon.rennes.grid5000.fr |
| icluster2 | ita101.imag.fr |
-->
<resources>
sophia:nodes=2,lyon:nodes=1
</resources>
<walltime>00:03:00</walltime><!-- hour:min:sec-->
<scriptPath>
<!--relativePath origin="user.home" value="Proactive/scripts/unix/cluster/oarGridStartRuntime.sh"/-->
<absolutePath
value="${PROACTIVE_HOME}/scripts/unix/cluster/oarGridStartRuntime.sh" />
</scriptPath>
</oarGridOption>
</oarGridProcess>
</processDefinition>
<processDefinition id="sshProcess">
<sshProcess
class="org.objectweb.proactive.core.process.ssh.SSHProcess"
hostname="oar.grenoble.grid5000.fr">
<processReference refid="oarGridProcess" />
</sshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
PRUN
PRUN is a cluster protocol developed at Amsterdam to manage
their cluster.
ProActive provides org.objectweb.proactive.core.process.prun.PrunSubProcess
to use such a protocol.
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME" value="/home/user/ProActive"/> <!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME"
value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="plugtest" timeout="120000"/>
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="plugtest">
<jvmSet>
<vmName value="Jvm1"/>
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="sshProcess"/>
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="linuxJVM1">
<jvmProcess class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath value="${JAVA_HOME}/bin/java"/>
</javaPath>
<policyFile>
<absolutePath value="${PROACTIVE_HOME}/dist/proactive.java.policy"/>
</policyFile>
<log4jpropertiesFile>
<absolutePath value="${PROACTIVE_HOME}/dist/proactive-log4j"/>
</log4jpropertiesFile>
</jvmProcess>
</processDefinition>
<processDefinition id="prunCluster">
<prunProcess class="org.objectweb.proactive.core.process.prun.PrunSubProcess" queue="plugtest">
<processReference refid="linuxJVM1"/>
<commandPath value="/usr/local/VU/reserve.sge/bin/prun"/>
<prunOption>
<hostsNumber>20</hostsNumber>
<processorPerNode>2</processorPerNode>
<bookingDuration>02:00:00</bookingDuration>
</prunOption>
</prunProcess>
</processDefinition>
<processDefinition id="sshProcess">
<sshProcess class="org.objectweb.proactive.core.process.ssh.SSHProcess" hostname="frontend" username="rquilici"> <!--CHANGE ME!!!! -->
<processReference refid="prunCluster"/>
</sshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
GLOBUS
Like ssh, using Globus requires some steps to be performed. In particular the java COG Kit (no need for the whole GT) must be installed on the machine that will originates the RSL request. See COG Kit Installation to know how to install the client kit. Then you have to initialize your proxy by running COG_INSTALLATION/bin /grid-proxy-init. You will be asked for a passphrase, which is the one you provided when requesting a user certificate at globus.org. Once these steps are performed, you can run ProActive application using GRAM protocol.
ProActive provides
org.objectweb.proactive.core.process.globus.GlobusProcess
to create globus process.
<jvm name='Jvm2'> <creation> <processReference refid='globusProcess'/> </creation> </jvm> ................................................... <processes> <processDefinition id='jvmProcess'> <jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcess'/> </processDefinition> <processDefinition id='globusProcess'> <globusProcess class='org.objectweb.proactive.core.process.globus.GlobusProcess' hostname='globus1.inria.fr'> <processReference refid='jvmProcess'/> <environment> <variable name='DISPLAY' value='machine_name0.0'/> </environment> <globusOption> <count>10</count> </globusOption> </globusProcess> </processDefinition> </processes>
In this example, Jvm2 will be created using GRAM. An RSL request will be generated with informations provided in the descriptor. For instance, the <environment> tag is not mandatory, but for the globus host to export the DISPLAY on your machine, you can define the value in the descriptor as well as other environment variable, except the classpath (or java path,...) which must be defined in the jvmProcess referenced by globusProcess as explained before. <globusOption> is not mandatory either. Default value for <count> element is 1. It represents the number of requested processor.
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME"
value="/home/user/ProActive" /><!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME"
value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
<descriptorVariable name="GLOBUS_USER_HOME"
value="/globus/home/user"
/> <!--CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="plugtest" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="plugtest">
<jvmSet>
<vmName value="Jvm1" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="globusProcess" />
</creation>
</jvm>
</jvms>
</deployment>
<infrastructure>
<processes>
<processDefinition id="localJVM1">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath
value="${JAVA_HOME}/bin/java" />
</javaPath>
<policyFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive.java.policy" />
</policyFile>
<log4jpropertiesFile>
<absolutePath
value="${PROACTIVE_HOME}/dist/proactive-log4j" />
</log4jpropertiesFile>
<jvmParameters>
<parameter
value="-Dproactive.communication.protocol=http" />
<parameter value="-Dproactive.http.port=22500" />
</jvmParameters>
</jvmProcess>
</processDefinition>
<processDefinition id="globusProcess">
<globusProcess
class="org.objectweb.proactive.core.process.globus.GlobusProcess"
hostname="globus_frontend">
<processReference refid="localJVM1" />
<globusOption>
<count>8</count>
<maxTime>120</maxTime>
<errorFile>
${GLOBUS_USER_HOME}/error.txt
</errorFile>
</globusOption>
</globusProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
ARC (NorduGrid):
ProActive provides
org.objectweb.proactive.core.process.nordugrid.NGProcess
to use such a protocol.
To use ARC you will need to download the ARC Client.
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME" value="/home/user/ProActive"/> <!--CHANGE ME!!!! -->
<descriptorVariable name="JAVA_HOME"
value="/path/to/jdk1.5.0" /><!-- Path of the remote JVM , CHANGE ME!!!! -->
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="plugtest" timeout="1200000"/>
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="plugtest">
<jvmSet>
<vmName value="Jvm1"/>
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="ngProcess"/>
</creation>
</jvm>
</jvms>
</deployment>
<fileTransferDefinitions>
<fileTransfer id="ng_transfer">
<file src="http://grid.uio.no/runtime/j2re1.4.2_08.tar.gz" dest="j2re1.4.2_08.tar.gz" />
<file src="lib/ProActive.jar" dest="ProActive.jar" />
<file src="lib/javassist.jar" dest="javassist.jar" />
<file src="lib/components/fractal.jar" dest="fractal.jar" />
<file src="lib/bouncycastle.jar" dest="bouncycastle.jar" />
<file src="lib/log4j.jar" dest="log4j.jar" />
<file src="lib/xercesImpl.jar" dest="xercesImpl.jar" />
<file src="dist/proactive-log4j" dest="proactive-log4j" />
<file src="dist/proactive.java.policy" dest="proactive.java.policy" />
</fileTransfer>
</fileTransferDefinitions>
<infrastructure>
<processes>
<processDefinition id="localJVM1">
<jvmProcess class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath value="${JAVA_HOME}/bin/java"/>
</javaPath>
<policyFile>
<absolutePath value="proactive.java.policy"/>
</policyFile>
<log4jpropertiesFile>
<absolutePath value="proactive-log4j"/>
</log4jpropertiesFile>
</jvmProcess>
</processDefinition>
<processDefinition id="ngProcess">
<ngProcess class="org.objectweb.proactive.core.process.nordugrid.NGProcess" hostname="ng_frontend">
<processReference refid="localJVM1"/>
<fileTransferDeploy refid="ng_transfer">
<copyProtocol>processDefault</copyProtocol>
<sourceInfo prefix="file://${PROACTIVE_HOME}" />
</fileTransferDeploy>
<ngOption>
<executable>
<absolutePath value="${PROACTIVE_HOME}/scripts/unix/cluster/ngStartRuntime.sh"/>
</executable>
<count>28</count>
<outputFile>hello.txt</outputFile>
<errorFile>hello1.txt</errorFile>
</ngOption>
</ngProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
MPI
ProActive provides
org.objectweb.proactive.core.process.mpi.MPIDependentProcess
to use such a protocol. You have to couple this process with the
DependentListProcessDecorator explained below.
Here is the complete example that you can find within the ProActive distribution.
<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor
xmlns="urn:proactive:deployment:3.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:proactive:deployment:3.3 http://www-sop.inria.fr/oasis/ProActive/schemas/deployment/3.3/deployment.xsd">
<variables>
<descriptorVariable name="PROACTIVE_HOME" value="ProActive" />
<descriptorVariable name="REMOTE_HOME" value="/home/smariani" />
<descriptorVariable name="MPIRUN_PATH"
value="/usr/src/redhat/BUILD/mpich-1.2.6/bin/mpirun" />
<descriptorVariable name="QSUB_PATH"
value="/opt/torque/bin/qsub" />
<descriptorVariable name="USER_HOME"
value="/user/smariani/home" />
</variables>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name="CPI" />
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode="CPI">
<jvmSet>
<vmName value="Jvm1" />
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name="Jvm1">
<creation>
<processReference refid="sshProcess" />
</creation>
</jvm>
</jvms>
</deployment>
<fileTransferDefinitions>
<fileTransfer id="transfer">
<!-- Transfer mpi program on remote host -->
<file src="cpi" dest="cpi" />
</fileTransfer>
</fileTransferDefinitions>
<infrastructure>
<processes>
<processDefinition id="localJVM1">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess">
<classpath>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/ProActive.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/bouncycastle.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/fractal.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/trilead-ssh2.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/javassist.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/log4j.jar"/>
<absolutePath value="${PROACTIVE_HOME}/dist/lib/xercesImpl.jar"/>
</classpath>
<javaPath>
<absolutePath
value="${REMOTE_HOME}/jdk1.5.0_05/bin/java" />
</javaPath>
<policyFile>
<absolutePath
value="${REMOTE_HOME}/proactive.java.policy" />
</policyFile>
<log4jpropertiesFile>
<absolutePath
value="${REMOTE_HOME}/${PROACTIVE_HOME}/dist/proactive-log4j" />
</log4jpropertiesFile>
<jvmParameters>
<parameter
value="-Dproactive.useIPaddress=true" />
<parameter value="-Dproactive.rmi.port=6099" />
</jvmParameters>
</jvmProcess>
</processDefinition>
<!-- remote jvm Process -->
<processDefinition id="jvmProcess">
<jvmProcess
class="org.objectweb.proactive.core.process.JVMNodeProcess">
<jvmParameters>
<parameter
value="-Dproactive.useIPaddress=true" />
<parameter value="-Dproactive.rmi.port=6099" />
</jvmParameters>
</jvmProcess>
</processDefinition>
<!-- pbs Process -->
<processDefinition id="pbsProcess">
<pbsProcess
class="org.objectweb.proactive.core.process.pbs.PBSSubProcess">
<processReference refid="localJVM1" />
<commandPath value="${QSUB_PATH}" />
<pbsOption>
<hostsNumber>3</hostsNumber>
<processorPerNode>1</processorPerNode>
<bookingDuration>00:02:00</bookingDuration>
<scriptPath>
<absolutePath
value="${REMOTE_HOME}/${PROACTIVE_HOME}/scripts/unix/cluster/pbsStartRuntime.sh" />
</scriptPath>
</pbsOption>
</pbsProcess>
</processDefinition>
<!-- mpi Process -->
<processDefinition id="mpiCPI">
<mpiProcess
class="org.objectweb.proactive.core.process.mpi.MPIDependentProcess"
mpiFileName="cpi">
<commandPath value="${MPIRUN_PATH}" />
<mpiOptions>
<processNumber>3</processNumber>
<localRelativePath>
<relativePath origin="user.home"
value="${PROACTIVE_HOME}/scripts/unix" />
</localRelativePath>
<remoteAbsolutePath>
<absolutePath value="${REMOTE_HOME}/MyApp" />
</remoteAbsolutePath>
</mpiOptions>
</mpiProcess>
</processDefinition>
<!-- dependent process -->
<processDefinition id="dpsCPI">
<dependentProcessSequence
class="org.objectweb.proactive.core.process.DependentListProcess">
<processReference refid="pbsProcess" />
<processReference refid="mpiCPI" />
</dependentProcessSequence>
</processDefinition>
<!-- ssh process -->
<processDefinition id="sshProcess">
<sshProcess
class="org.objectweb.proactive.core.process.ssh.SSHProcess"
hostname="nef.inria.fr" username="smariani">
<processReference refid="dpsCPI" />
</sshProcess>
</processDefinition>
</processes>
</infrastructure>
</ProActiveDescriptor>
This process is used when a process is dependent on an another
process. The first process of the list can be any process but the second
one must be a DependentProcess. Thus the second one has to implement the
org.objectweb.proactive.core.process.DependentProcess interface.
<!-- mpi Process --> <processDefinition id="mpiCPI"> <mpiProcess class="org.objectweb.proactive.core.process.mpi.MPIDependentProcess" mpiFileName="cpi"> <commandPath value="${MPIRUN_PATH}" /> <mpiOptions> <processNumber>3</processNumber> <localRelativePath> <relativePath origin="user.home" value="${PROACTIVE_HOME}/scripts/unix" /> </localRelativePath> <remoteAbsolutePath> <absolutePath value="${REMOTE_HOME}/MyApp" /> </remoteAbsolutePath> </mpiOptions> </mpiProcess> </processDefinition> <!-- dependent process --> <processDefinition id="dpsCPI"> <dependentProcessSequence class="org.objectweb.proactive.core.process.DependentListProcess"> <processReference refid="pbsProcess" /> <processReference refid="mpiCPI" /> </dependentProcessSequence> </processDefinition> <!-- ssh process --> <processDefinition id="sshProcess"> <sshProcess class="org.objectweb.proactive.core.process.ssh.SSHProcess" hostname="nef.inria.fr" username="smariani"> <processReference refid="dpsCPI" /> </sshProcess> </processDefinition>
We can notice in this example that the second process of the DependentListProcess (mpiCPI)
instantiate the org.objectweb.proactive.core.process.mpi.MPIDependentProcess class
which, as required above, implements the org.objectweb.proactive.core.process.DependentProcess interface.
As mentionned previously, instead of creating jvms, ProActive gives the possibility to acquire existing jvms. To do so, as shown in the example below, a service must be referenced in the acquisition tag. At this point one service is implemented: RMIRegistryLookup. The RMIRegistryLookup service performs a lookup in an RMIRegistry at the url specified in the service definition to find a ProActiveRuntime (a JVM) with the given name.
<?xml version='1.0' encoding='UTF-8'?>
<ProActiveDescriptor
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation='DescriptorSchema.xsd'>
<componentDefinition>
<virtualNodesDefinition>
<virtualNode name='VnTest' property='multiple'/>
</virtualNodesDefinition>
</componentDefinition>
<deployment>
<mapping>
<map virtualNode='VnTest'>
<jvmSet>
<vmName value='Jvm1'/>
</jvmSet>
</map>
</mapping>
<jvms>
<jvm name='Jvm1'>
<acquisition>
<serviceReference refid='lookupRMI'/>
</acquisition>
</jvm>
</jvms>
</deployment>
<infrastructure>
<services>
<serviceDefinition id='lookupRMI'>
<RMIRegistryLookup url='//localhost:2020/PA_JVM1'/>
</serviceDefinition>
</services>
</infrastructure>
</ProActiveDescriptor>
The RMIRegistryLookup service needs only an URL to perform the lookup.
The example above shows a VirtualNode VnTest, that is mapped to one JVM, Jvm1. Jvm1 represents a JVM that will be acquired using an RMI Lookup.
Fault Tolerance can also be defined at the service level. See Chapter 32. Fault-Tolerance for more information.
ProActive provides also the ability to use all processes defined above without using XML Deployment Descriptor. You can programmatically create such processes.
In order to get familiar on how to create processes programmatically, see the javadoc of the org.objectweb.proactive.core.process package.
For instance, you can create an SSH process as follows:
SSHProcess ssh = new SSHProcess(new SimpleExternalProcess("ls -lsa"));
ssh.setHostname("kisscool.inria.fr");
ssh.startProcess();
This piece of code will create an SSHProcess in charge of executing the ls -lsa command on kisscool.inria.fr.
As it is explained in Chapter 16, ProActive File Transfer, ProActive provides a File Transfer mechanism which enables to transfer a file from a node to another one. File transfers are normally done through the ProActive API. however, File Transfers can also be specified using ProActive Descriptors. The main advantage of this scheme is that it allows deployment and retrieval of input and output (files). In this section we will concentrate on mainly three topics:
XML Descriptor File Transfer Tags
Deployment File Transfer
Retrieval File Transfer
The File Transfer related tags, are placed inside the descriptor at three different parts (or levels).
The first one corresponds to the fileTransferDefinitions tag, which contains a list of FileTransfer definitions. A FileTransfer definition is a high level representation of the File Transfer, containing mainly the file names. It is created in such a way, that no low level information such as: hosts, protocols, prefix is present (this is the role of the low level representation). The following example shows a FileTranfer definition named example which has to placed between the deployment and the infrastructure tag:
<fileTransferDefinitions>
<fileTransfer id="mytransfer">
<file src="src-test.txt" dest="dest-test-deployment.txt" />
</fileTransfer>
<!--
<fileTransfer id="another_transfer">
...
</fileTransfer>
-->
</fileTransferDefinitions>
The FileTransfer definitions can be referenced through their names, from the VirtualNode tags using two attributes:fileTransferDeploy and fileTransferRetrieve. The first one, corresponds to the file transfer that will take place at deployment time, and the second one corresponds to the file transfer that the user will trigger once the user application is done.
<virtualNode name="VN" fileTransferDeploy="mytransfer" fileTransferRetrieve="mytransfer"/>
All the low level information such as: hosts, username, protocols, prefix, etc... is declared inside each process. Both fileTransferDeploy and fileTransferRetrieve are specified separetly using a refid attribute. The refid can be a direct reference to a FileTransfer definition, or the keyword implicit. If implicit is used, then the reference will be inherited from the corresponding VirtualNode. In the following example both mechanisms (Deploy and Retrieve) reference indirectly and directly the example definition:
<processDefinition id="ssh_jily"> <sshProcess class="org.objectweb.proactive.core.process.ssh.SSHProcess" hostname="jily.inria.fr"> <processReference refid="localJVM" /> <!-- Inside the process, the FileTransfer tag becomes an element instead of an attribute. This happens because FileTransfer information is process specific. Note that the destination hostname and username can be omitted, and implicitly inferred from the process information. --> <fileTransferDeploy refid="implicit"> <copyProtocol>processDefault, rcp, scp, pft</copyProtocol> <sourceInfo prefix="/tmp"/> <destinationInfo prefix="/tmp"/> </fileTransferDeploy> <fileTransferRetrieve refid="implicit"> <sourceInfo prefix="/tmp"/> <destinationInfo prefix="/tmp"/> </fileTransferRetrieve> </sshProcess> </processDefinition>
In the example above, fileTransferDeploy has an implicit refid. This means that the File Transfer definitions used will be inherited from the VirtualNode. The first element shown inside this tag corresponds to copyProtocol. The copyProtocol tag specified the sequence of protocols that will be executed to achieve the FileTransfer at deployment time. Notice the processDefault keyword, which specifies the usage of the default copy protocol associated with this process. In the case of the example, this corresponds to an sshProcess and therefore the Secure Copy Protocol (scp) will be tried first. To complement the higher level File Transfer definition, other information can be specified as attributes in the sourceInfo and destinationInfo elements. In this example, we provide a prefix attribute that indicates from and to which directory the file should be transfered. Other attributes such as hostname and username can also be given.
For fileTransferRetrieve, no copyProtocol needs to be specified. ProActive will use its internal mechanism to transfer the files. This implies that no hostname or username are required.
The supported protocols for file transfer are the following one:
pftp (ProActive File Transfer Protocol)
scp (ssh processDefault)
rcp (rsh processDefault)
nordugrid (Nordugrid processDefault)
The start of the File Transfer will take place when the deployment of the descriptor file is executed. In the case of external protocols (scp, rcp), this will take place before the process deployment. In the case of internal protocols (nordugrid), this will take place with the process deployment. In any case, it should be noted that interesting things can be achieved, such as transfering the ProActive libraries into the deploying machine using an on-the-fly style. This means that it is possible to deploy on remote machines without having ProActive pre-installed. Even further, when the network allows, it is also possible to transfer other required libraries like the JRE (Java Runtime Envirorment).
There is one protocol that behaves differently from the others: the ProActive FileTransfer Protocol (pftp). pftp uses the ProActive FileTranfer API (described in Chapter 16, ProActive File Transfer), to transfer files between nodes. The main advantage of using the pftp is that no external copy protocols are required to transfer files at deployment time. Therefore, if the grid infrastructure does not provide a way to transfer files, a FileTransfer Deploy can still take place using the pftp. On the other hand, the main drawback of using pftp is that ProActive must already be install on the remote machines, and thus on-the-fly deployment is not possible.
Since distributed application's termination is difficult to detect. The responsability of triggering the deployment corresponds to the user. To achieve this, we have provided a specific mehod that will trigger the retrieval of all files associated with a VirtualNode.
List<RemoteFile> rfList = virtualNode.getVirtualNodeInternal().fileTransferRetrieve();
This will trigger the retrieval of all the files specified in the descriptor, from all the nodes that were deployed using this virtual node using the pftp.
As a result of calling this method, a list of RemoteFile will
be created, representing all the retrieved files.
This section provides internal details and information on how the File Transfer is implemented. Reading this section to use the File Transfer mechanisms provided by ProActive is not necessary.
These definitions can be referenced from a VirtualNode. They contain the most basic information of a FileTransfer:
id attibute - A unique identification name.
file element - source and optionally destination file name.
dir element - source and optionally destination directory name.
References from the VirtualNode are made using the unique definition name.
These definitions contain more architecture specific information, and are therefore contained within the Process:
refid attribute: A reference to an abstract definition, or the "implicit" key word indicating that the reference will be inherited from the VirtualNode.
copyProtocols element: A sequence of Copy Protocols that will be used.
sourceInfo and destinationInfo element: Source and Destination information (prefix, username, hostname, file separator, etc.)
If some of this information (like username or hostname) can be inferred from the process, it is not necessary to declare it in the definition. Optionally, information contained in the protocol can be overridden if specified.
When a FileTransfer starts, both abstract and concrete information are merged using the FileTransfer Workshop. The result of this process corresponds to a sequence of CopyProtocols, as specified in the Concrete Definition.
Each CopyProtocol will be tried before the deployment takes place, until one succeeds. Once one succeeded or all failed, the process deployment will take place.
© 1997-2010 INRIA/University of Nice-Sophia Antipolis/ActiveEon All Rights Reserved
