A Predictive Approach for Selecting Suitable Computing Nodes in Grid Environment by Using Data Mining Technique - Advances in Computational Science and Engineering - page 196

Con3: there have not been existed another attribute for selection.

Step3: if any conditions of step 2 for desired node are not true, then this node should
be developed. Thus:
− Step3.1 : find all attributes in a path from root node to desired node, and then re-

move it from attribute set. So remaining attribute will be more luck for selection.

− Step3.2 : for every remaining attribute (A i ), we should select an attribute according

to Entropy measure [10] to develop the tree (A max ).

− Step3.3 : split X set into subsets X 1 , X 2 ,…, X mAmax so that, all elements in X i , there

is a coefficient of fuzzy term v i for A max .

− Step3.4 : for every of these subsets, we will define nodes t 1 , t 2 ,…, t mAmax and then

the edges are labeled by v i values (i=1,2,…, m Amax ). Then, the degree membership
for each example to new node will be computed as following.

(7)

µ ( x ∈ X ) = µ ( x ∈ X ). µ ( x ∈ X )

c v c Vi

k i k

− Step3.5 : exchange each X i with X and then repeat step 2 and 3.

4 System Architecture

This section describes the design of our approach as a part of Resource Broker, which is
enhanced by adding the functionality to enable adaptability. We have shown a general
architecture for this approach in figure 2 (Fig 2). The Resource Broker performs a num-
ber of basic functions. The first step is the discovery and selection of resources that best
fit the needs of the Grid application. The broker will then submit jobs in the application
to the chosen nodes. GRB use machine learning technique for Node selection. The bro-
ker thus handles submission of jobs but not how the job is actually executed on the
resource. These actions are referred to as scheduling in the Resource Broker, but in this
paper we will not discourse in this topic. Once jobs are being executed (or waiting to be
executed), the broker monitors the resources and the progression of the jobs. Our appli-
cation can change its behavior depending on available resources, optimizing itself to its
dynamic environment for each new arrival job.
Our supplied application is performed on top of GT3. But it can be applied for
GT4. For the nonce, we have provided an isolated application that can be worked
based on GT3, for this purpose. The Result of every node is sent in an XML docu-
ment and is stored in a Temporary XML Database (TXD).

4.1 Miner Application

To do this, we want to install a Miner Application (MA) for every node in a purposed
grid. MA contains an internal small database (in log file role). One of the primary tasks
of MA is writing log file. When desired node is connected to grid, MA must update its
log file (insert a new record to database) or when a new job is submitted to this node,
MA will update the related record (connection record) and also insert a new record for
submitted job in desired table (contain job properties and status). This is more important
because we want to know the number of submitted jobs that are successfully executed
or failed on this node. At the moment, if the job is finished successfully or if the job is