Chapter 7 Implementation of DECGrid and MODO Services
7.2 Facility and tools
Information obtained during literature review and industry survey helped in identifying the tools that make up the DECGrid facility. Grid projects such as Geodise, DAME, Gridbus and FIPER use similar tools. Another source of information is the Cranfield HPC (high performance computing) Grid which manages the Linux based computational facility that most science and engineering researchers use to submit FEA (finite element analysis), CFD (computational fluid dynamics) and optimisation computations for processing. The researcher is also on the mailing list of the Cranfield HPC facility. DECGrid is run in CentOS 4.0 Linux operating system (OS). The choice of Linux OS is necessitated by the fact that majority of the grid community uses Linux for grid implementation. The researcher initially tried using Windows OS to deploy Globus but on encountering problems tried to get solutions from the users’ forum but many users were not familiar with problems under Windows environment. This made the researcher to take a decision on which OS to use for deployment. This means that in grid research deployment, collaboration with other researchers may help to avoid problems by identifying popularly used platforms by the community (Ong and Jiang, 2004). This further buttressed the findings during industry survey where 63% of grid users said they used Linux OS for grid deployment. Globus Toolkit 4.0.4 (GT4) is used as the grid middleware for deploying MODO services in the grid cluster. GT4 building blocks are built on the layered architecture which runs on OGSA standard and protocols. The transfer of huge MODO data is efficient using GridFTP which also has capability for stripped storage devices (Asiki et al., 2009). Gobus is the most popular middleware among researchers
To use the design, framework and architecture of DECGrid to implement MODO services for this research.
o To describe the tools used and reasons for using them in the
implementation of DECGrid services
o To describe the process and stages of the implementation
o To implement MODO services and interfaces that are used for validation
in universities as discussed in literature and industry survey. The scheduling system used to ensure computational throughput for optimisation processes is Condor 5.0 and PostgreSQL 7.0.0 is used as the database server for the management and reuse of MODO design parameters and variables. Condor is used with Globus known as Condor-G and has enhanced workflow management capability in the Directed Acyclic Graph Manager (DAGMan) feature which can intelligently differentiate between different computational jobs and data placement tasks in heterogeneous grid resource sharing systems (Kosar and Balman, 2009). This is in addition to the cycle stealing concept that ensures optimum utilisation of idle processors. PostgreSQL has capabilities for allowing efficient queries through secured protocols of Globus. The programming languages used for implementing different functionalities of the system are C, C++, Java, Javascript, HTML and PHP. C is used to implement the quantitative mathematical models for the 3 case studies; C++ is used to implement the qualitative model of the third case study (design of a manufacturing plant layout) in Qt Designer (Qt Designer is an open source object oriented graphical user interface design application software); Java, Javascript, HTML and PHP are used to provide web- enabled user interfaces for optimisation users.
7.3 Setting-up the grid infrastructure
A room was dedicated for setting-up the grid facility that served as DECGrid within the Decision Engineering Centre (DEC) at Cranfield University. Because it is the first of its kind within the centre, it was named after the centre as DECGrid. There are 8 computers each having 200GB hard disk, 3.00GB RAM and 3.20 GHz processing speed. The systems are dual boot from Microsoft Windows XP Professional or CentOS 4.0 Linux OS. One of the systems is made the server and the remaining 7 served as the clients. The grid deployment is done in the Linux OS only. This is for the same reasons explained in section 7.2. The operating systems run on different disk partitions in the ratio of 120 GB to 80 GB for Windows and Linux respectively for the server and 140 GB to 60 GB for the clients. The bigger Linux partition for the server is to accommodate service orchestration to the client machines (Foster et al., 2002b).
After the Linux deployment, Globus Toolkit is installed on the server first. The certificate authority (CA) used is the SimpleCA. The grid security configurations were made to allow my-proxy authentication for other clients with authorised CA key
and passphrase (the name for long password in grid systems). This has the advantage of allowing remote grid resource management (Sacerdoti et al., 2004). Globus has capability for cross-functional CA; that is multiple CAs can be used by different MODO users and can still communicate and share resources. File transfer protocol (FTP) in GT4 known as the GridFTP is configured and used to remotely transfer configuration files to the clients. The same GridFTP plays a key role in ensuring that optimisation data is securely transferred and shared among distributed experts using DECGrid. Metadata generated from optimisation processes are more efficiently and securely transferred to distributed grid nodes by GridFTP for reuse and share among optimisation engineers working from remote locations (Eres et al., 2005). A component called RFT (reliable file transfer) in GT complements the capability of GridFTP by managing the transfer of data and files to different nodes. With GridFTP and RFT in place, the GRAM (grid resource allocation manager) is configured to manage the computational grid resources. The GRAM uses the JobManager to submit and mange jobs and GateKeeper to ensure that only authorised users’ jobs are submitted and allowed to run on nodes. This capability ensures more reliability, consistency and integrity of optimisation data used by experts who are sharing design model, parameters and variables. The rest of the client nodes were also configured as the server. The certificates created by the SimpleCA in the server are copied to other clients and GridFTP, RFT and GRAM were configured as discussed above. The last activity on GT deployment is the configuration of web services which enable users to start the container that refreshes and updates optimisation resources that are published as services.
Condor scheduler is deployed to make computational resources available to remote users when owners of the resources are not using them. The resources used in DECGrid are the computational processing powers, disks storage of the 8 systems. This allows optimisation jobs to be received by one condor pool and executed by another idle pool. Globus GRAM is used in this research as an interface with Condor to run optimisation services which use Condor ClassAd to match requests for resources as they are made available. This process ensures computational throughput of grid resources and avoids wastage of computational cycle time. The server was made the condor master and can monitor the utilisation percentage of the pool and 7 other systems were made the client so that jobs can be flocked to them for processing.
There are 2 pools each with 3 computers. PostgreSQL 7.0.0 database server is also deployed on the 8 systems. To access data from any of the systems, an authentication process is required on each of the machines.
MODO on grid will also enable the exploitation of individual MODO services on per- use basis. The optimisation techniques discussed in chapter 2 are all geared towards obtaining optimum designs that can increase the quality products manufactured at lower cost and ultimately increase the profit of the company. Though these techniques are there, what is lacking is the problem solving environments that allow efficient collaboration for MODO experts to work together (Lee et al., 2009). This is why a framework must align with the needs of a company. The needs of MODO applications consist of collaboration, computational power and data storage. The distributed resources are managed uniquely and globally through the GIS (Grid Information Service), GRIS (Grid Resource Information Service) and GRIIS (Grid Resource Information Index Service).
7.4 Case study considerations
The implementation process takes into consideration the case studies that are used to validate the DECGrid. The case studies are optimisation of gas turbine blade cooling system, the welded beam problem and the design of a manufacturing plant layout. The first consideration is the service interfaces that allow generic MODO tasks to be performed by distributed experts. Although the interface in this case allows the selection of a problem domain for optimisation, this is just to limit the search to the optimisation resources needed in each domain. However, the system has capability to add more application domains to cater for generality. The grid is an infrastructure that allows seamless access through the grid portal to virtualised resources (Kacsuk et al., 2004). DECGrid uses this quality of grid using Globus services that allow different domain users to access the same resources from distributed locations. The case studies involve multi-disciplinary collaboration in which parameters and variables are obtained as workflows from different collaborating experts and this makes the feature of grid portal very important to carry out multi-objective optimisation for different domains using shared resources. This provides a generalised platform upon which MODO applications can be run to solve diverse problems. Figure 7.1 is the problem domain definition interface where the 3 case studies can be selected on any of the
nodes to run optimisation on the entire grid. Different domains can be selected at the same time on different machines and still be processed concurrently using shared computational resources which are scheduled by Condor.
Main Domain Turbine blade cooling system Welded beam problem Manufacturing plant layout
User 1 User 2 User n
Figure 7.1: Main domain selection interface for distributed users