Information Technology Reference
In-Depth Information
10.4.3 Cloud-Based AutoDock Workflows
We are going to present the way to migrate an existing workflow to the cloud
based on the AutoDock Vina application.
The migration of the generator and collector nodes was required to follow
the following steps:
• Reconfigure the nodes to run on the cloud: For this the node's con-
figuration window (see Figure 10.3) had to be opened; and the node's
type
had to be set to cloudbroker; the
name
to platform; the
resource
,
region
and
instance type
to MTA SZTAKI.
• Assign robot certificates to the nodes: As accessing the cloud resources
requires CBP credentials but it is not feasible to ask every end user of
the customized gateway to have a valid CBP credential, a CBP robot
credential had to be set for the nodes. A dedicated account for the
AutoDock users in the CBP with access granted to the MTA SZTAKI
OpenNebula cloud infrastructure has been created, and this account
has been set during the nodes' configuration as seen in Figure 10.8.
The migration of the parameter sweep node was a bit more difficult, as this
node of the original workflow was set to run on a volunteer DG. In the case
of DG applications, the executable resides on the DG server and may consist
of multiple files (one “main” executable and supporting files), such as for the
Vina DG application. The DG application is only referenced by name in the
WS-PGRADE workflow's configuration.
To migrate such an application to the cloud, all executable files of the DG
application need to be collected from the DG server and the workflow must
be reconfigured to submit these files from the portal server. In the case of
a multiile application, there are two options: either the workflow node
has to be configured to run the main executable and additional input files
FIGURE 10.8
Robot certificate association.
Search WWH ::
Custom Search