Information Technology Reference
In-Depth Information
and resubmission of a scheduled job. Along with this, we tried to mini-
mize the cost of the environment in terms of disk space and CPU con-
sumption for the user interface. While a 500 MB quota account was just
enough to handle a single instance during the deployment on avian l u [21],
it was now enough to handle no less than 20 instances simultaneously. Most
of the job i les were now generated dynamically, which also allowed the
user to modify on the l y the coni guration of the resource brokers and the
job requirements and this way, the user was sure that the next submissions
would take these modii cations into account. Figure 14.5 describes the
overall architecture of the environment and the deployment process:
The user is interacting with the system through the two main scripts
(wisdom_submit and wisdom_status) deployed on the user inter-
face. These scripts will take care automatically of job i les genera-
tion, submission, status follow-up, and eventually resubmission.
The jobs are submitted directly to the grid workload management
system, and are executed on the grid computing elements. As
soon as it is running, a job transfers all the i les stored on the
storage elements via the data management system of the grid, and
the FlexX software, which asks a l oating license for the FlexLm
license server, can start to process the dockings.
During the job lifetime, the status is retrieved from the user inter-
face and some statistics are generated and collected to a remote
server that hosts a relational database and outputs these statistics
through a Web site.
User Interface
CEs & WNs
SEs
Submits the jobs
D
M
S
/
G
F
T
P
Wisdom_submit
WMS
FlexX
Checks job status
resubmits
Wisdom_status
Statistics
Structure file
FlexX
job
Flexlm
Compounds file
Statistics
server
Output file
Docking information
Healthgrid Server
WISDOM
DB
Output
DB
inputs
outputs
Web site
FIGURE 14.5
Evolution of the production environment.
 
Search WWH ::




Custom Search