CHAPTER 6 RESULTS AND DISCUSSION

Transcription

1 76 CHAPTER 6 RESULTS AND DISCUSSION This chapter discusses the details of agent based model for monitoring and describes about the mobile agent s role in the monitoring. This chapter discusses experimental results with GROMACS application and the performance factors such as minimization of job completion time and transfer time. This chapter also discusses the various performance factors based on simulation such as minimization of waiting time, response time, the percentage of jobs completed with meeting the user deadline and the success rate of the jobs submitted. This chapter also discusses about the comparison of the proposed network performance measurement and prediction with existing methodology. In addition, the prediction error of the proposed model is compared with NWS. The evaluation of the mobile agent based automated deployment of Network aware Resource Monitoring service is also discussed in this chapter. 6.1 AGENT BASED MONITORING MODEL The experimental setup is constructed by simulating a Grid cluster which has a head node and two compute nodes. Then the number of compute nodes is incremented and further analysis is done. The bandwidth usage for mobile agent is measured through increasing the number agents on head node and compute nodes up to 128. From the Table 6.1, it is evident that the bandwidth usage is not increased greatly although the numbers of mobile agents are scaled from 1 to 128. This scalability ensures that the mobile

2 77 agents reduce the network traffic even high in numbers roaming in the network. Table 6.1 Bandwidth used by mobile agents No. of Agents Bandwidth Usage (kbps) A comparative study of bandwidth utilization by agents and NWS with File Transfer Protocol (FTP) has been made and the experimental results are shown in Figure 6.1. It is evident that agents consume lesser bandwidth when compared to NWS even though the number of agents is increased on network so the network traffic is reduced. This is in accordance with the known fact that time to move data can significantly affect overall wall-clock runtime and network traffic. One of the most significant challenges faced in Grid is data management. By using mobile agent technology both the code and data is moved to the remote location where the task is to be accomplished. In essence the logic is moved towards the place where the data resides rather than moving the data to the place where the logic resides.

3 78 Bandwidth Usage - NWS Vs Agents Bandwidth Usage in kbps No.Of Nodes Agents Nws Figure 6.1 Bandwidth Usage of Agents based model with NWS 6.2 EXPERIMENTAL RESULTS The proposed monitoring system is tested with CARE Resource Broker (CRB) in Grid Computing Laboratory, Anna University, India. An experiment was conducted to evaluate the performance of the proposed Grid monitoring system. The experimental setup has three Grid resources namely smscluster.care.mit.in, xencluster.care.mit.in and CAREcluster.care.mit.in and all Grid resources have been configured as Beowulf cluster and each cluster has 1, 6 and 5 nodes respectively. The smscluster consists of one head node and 9 computing nodes. The xencluster consists of one head node and 5 computing nodes. The CAREcluster consists of one head node and 4 computing nodes. The CRB is installed in server hardware with 4 CPUs, 16 GB RAM with RHEL-5., and Globus Toolkit The three clusters are pushing of their information to CRB and become grid resources to CRB. The GROningen MAchine for Chemical Simulations (GROMACS) application is taken for testing the proposed monitoring system. The experimental results are evident that the minimization of transfer time is achieved with the network aware resource selection strategy and which leads to minimization of the job completion time of the GROMACS application GROMACS GROMACS is a flexible package to perform molecular dynamics and it is primarily designed for biochemical molecules like proteins, lipids

4 79 and nucleic acids that have a lot of complicated bonded interactions but since GROMACS is extremely fast at calculating the nonbonded interactions many groups are also using it for research on non-biological systems. It can be run in parallel, using standard MPI communication. There is an ongoing development to extend Gromacs with interfaces both to Quantum Chemistry and Bioinformatics/databases. GROMACS is Free Software, available under the GNU General Public License. GROMACS runs on linux, unix, and on Windows. The Protein Data Bank (PDB) is a repository for the 3-D structural data of large biological molecules, such as proteins and nucleic acids. GROMACS contains a script to convert molecular coordinates from a Protein Data Bank file into the formats it uses internally. Once a configuration file for the simulation of several molecules has been created, the actual simulation run produces a trajectory file, describing the movements of the atoms over time. This trajectory file can then be analyzed or visualized. GROMACS uses special *.mdp files to setup the parameters for every type of calculation that performs Performance Evaluation with Care Resource Broker The proposed Network Aware Resource Monitoring system is tested with GROMACS application. The GROMACS application has four input files and one output file. The GROMACS application is submitted to CARE Resource Broker with resource requirements to execute the job. The CRB accepts the job in the form standard JSDL specification. A sample JSDL specification for submitting GROMACS to CRB is shown in the Figure 6.2. This specification describes the executable file, software environment, input/output files and other requirements. <JobDefinition> <JobIdentification> <JobName>Parallel</JobName> <Description>This is a Gromacs Application Testing</Description> </JobIdentification> <Executable>/home/globus/SCRB/PhysicalJobs/gromacs-sp.sh</Executable> Figure 6.2 (Continued)

5 8 <Argument>/home/globus/SCRB/PhysicalJobs/1OMB.pdb</Argument> <Argument>/home/globus/SCRB/PhysicalJobs/em.mdp</Argument> <Argument>/home/globus/SCRB/PhysicalJobs/pr.mdp</Argument> <Argument>/home/globus/SCRB/PhysicalJobs/md.mdp</Argument> <OutputFile>/home/globus/stdout</OutputFile> <InputFile>/home/globus/SCRB/PhysicalJobs/gromacs-sp.sh</InputFile> <InputFile>/home/globus/SCRB/PhysicalJobs/1OMB.pdb</InputFile> <InputFile>/home/globus/SCRB/PhysicalJobs/em.mdp</InputFile> <InputFile>/home/globus/SCRB/PhysicalJobs/pr.mdp</InputFile> <InputFile>/home/globus/SCRB/PhysicalJobs/md.mdp</InputFile> <JobType>Parallel</JobType> <Environment>mpi</Environment> <ExecutionTime>36</ExecutionTime> <DeadLine> </DeadLine> <LRMS>PBS</LRMS> <ResourceRequirements> <OperatingSystem> <OperatingSystemName>Red Hat Enterprise Linux Server release 5 </OperatingSystemName> <OperatingSystemVersion> </OperatingSystemVersion> </OperatingSystem> <CPUArchitecture> <CPUArchitectureName>i686</CPUArchitectureName> </CPUArchitecture> <IndividualCPUSpeed> <LowerBoundedRange>3</LowerBoundedRange> </IndividualCPUSpeed> <IndividualPhysicalMemory> Figure 6.2 (Continued)

6 81 <LowerBoundedRange>248</LowerBoundedRange> </IndividualPhysicalMemory> <DiskSpace> <LowerBoundedRange>2</LowerBoundedRange> </DiskSpace> <NodeCount>5</NodeCount> </ResourceRequirements> </JobDefinition> Figure 6.2 Sample JSDL specification for GROMACS Application In the first strategy, the resource selection is based on resource monitoring through ranking of the resources using available Free Memory in it and the scheduler schedules the job to the selected resource for executing the job. In the second strategy, the resource selection is based on resource and network monitoring. The ranking is based on the RCV and NCV and the resource which has highest CCV is selected for job submission. These two approaches are tested with a Resource Broker. The total execution time or job completion time includes the execution time, transfer time and queue waiting time. The Figure 6.3 shows that the total time taken for job execution is minimized for the resource selection based on resource and network monitoring when compared to resource monitoring. In this scenario, the transfer time needed for transferring the input files and also output files is minimized when the resource selection is based on the proposed approach. The network performance monitoring helps the scheduler to select the resource for the data-intensive jobs which needs of high data transfer on Grid Sites. The third strategy works with CRB. The host identifier in CRB performs keyword based matchmaking of available Grid Resources with respect to user s requirements for identifying suitable physical resources for executing the job. The scheduler ranks the resources based on the Free RAM

7 82 available in it and schedules the job to that resource for execution. In the fourth strategy, the proposed network aware resource monitoring is integrated with CRB. The resource selector queries the updated Global archive to select the suitable resource which has highest CCV of CRB listed resources which was discussed in the previous section and sending that information to scheduler to schedule the job to that selected resource. The Figure 6.3 shows that the total time taken for job execution is minimized for the CRB integration of the proposed approach when compared to CRB and other strategies. The time minimization is achieved with the proposed resource selection algorithm which utilizes the network metrics and resource metrics. Job Completion time (Secs) M inimization of Job Completion Time No.of Nodes RM CRB RM with NM CRB with NM Figure 6.3 Minimization of Job Completion Time of different Resource Selection Strategies The Figure 6.4 is evident that the transfer time is minimized for the proposed approach, because within time minimization, the network metrics influence the job to be dispatched to the Grid resource which assures the less execution time of the submitted job.

8 Transfer Time M inimization RM CRB Resource with NM Resource Selection Strategies CRB with NM Figure 6.4 Minimization of Transfer Time 6.3 SIMULATION RESULTS A simulated data-intensive program was created to evaluate the proposed approach using GridFTP. The simulation results show that the proposed monitoring system with resource metrics and network metrics increases the resource utilization and also increases the percentage of jobs completed within deadline. In this simulation 1, 2, 3, 4, and 5 jobs were considered and submitted in CRB. It is very difficult to estimate the real effect of resource selection and scheduling of the jobs, if the jobs are run at different times. The results of the different resource selection strategies are taken at different times. To perform the comparison of the resource selection strategies, the short term jobs are executed in a similar environment. The actual execution time of the job is stable for the long and short term jobs but the data transfer time will vary due to network performance. The network cost value influences the minimization of data transfer time but there is no link with the job execution time. For the long term jobs, the waiting time will influence the overall job completion time.

9 84 Job Completion Time = T wt + T tt + T et (6.1) where T wt = Waiting time in the meta-scheduler queue T tt = Data transfer time T et = Job execution time The varying numbers of jobs are submitted in the Resource Broker and their waiting time and execution time are observed. The execution time is the time taken for a job when it is executing on the resource, it does not include the waiting time. The waiting time includes the time in the metascheduler queue and the time spent on the local resource manager s queue. The Figure 6.5 shows that the minimization of the waiting time for the jobs with the proposed approach compared to Resource Monitoring (RM), CRB, and Resource monitoring with Network Monitoring (RM with NM). The higher number of jobs executed at a site increase the waiting time and influence the overall job completion time, because the new jobs are competing for the resources to get the slot for execution. Waiting Time for Jobs W aiting Time (Secs) RM CRB RM with NM CRB with NM No. of Jobs Figure 6.5 Minimization of Waiting Time

10 85 The Figure 6.6 demonstrate that the minimization of the response time for the jobs with the proposed approach compared to Resource Monitoring (RM), CRB, and Resource monitoring with Network Monitoring (RM with NM). 35 Response Time for Jobs Response time (Secs) No. of Jobs RM CRB RM with NM CRB with NM Figure 6.6 Minimization of Response Time The large varying number of jobs submitted on the Resource Broker and the comparative study is made. The number of jobs completed versus time for the four resource selection strategies is tested in a simulated data-intensive environment. The completed number of jobs was more in network aware resource monitoring, because the waiting time in the queue is minimized, and the transfer time of the jobs from data sources is also minimized. This can be seen in the Figure 6.7, where the maximum number of jobs completion is achieved using network aware resource monitoring.

11 86 Total No.of Jobs Completed No. of Jobs Completed RM CRB RM with NM CRB with NM Time (hrs) Figure 6.7 No. of Jobs Completed with Resource Selection Strategies The job success rate is also estimated for 24 hours with the submission of 5 jobs using simulated data-intensive program using GridFTP. The high job success rate is achieved with the proposed approach which is shown in the Figure 6.8. The more number of jobs completed with the network aware resource selection strategy ensures high success rate for the submitted jobs when compared with other resource selection strategies. 1 Job Success Rate Success Rate (%) SR(RM ) SR(CRB) SR(RM NM ) SR(CRB with NM ) Time(hrs) Figure 6.8 The Success Rate of submitted Jobs with Resource Selection strategies

12 87 The experimental results exhibit that the job execution time is minimized with the proposed resource selection strategy due to the minimization of data transfer time. The simulation results demonstrate that minimization of waiting time for submitted jobs is achieved with the proposed approach which influences the minimization of response time and the maximization of jobs completion to ensure the high success rate of the submitted jobs. 6.4 NETWORK PERFORMANCE MEASUREMENTS AND PREDICTION Another experiment was carried out for evaluating results of the prediction model corresponding to bandwidth, RTT, packet loss, and jitter using Holt-Winters (HW) model. The obtained results show that the prediction of all network metrics closely matches the measured one with the proposed prediction model. Also the observed and predicted performance values of Grid network for 24 hours show that the predicted values are approaching the actual measured values. The cost function, called closeness defined by Ferrari and Giacomini (24) is compared with our proposed cost function to measure the network performance which is shown in Figure 6.9. Network Performance Performance Comparison closeness cost function Time (hrs) Figure 6.9 Visualization of the Network performance

13 88 Additional metrics considered in the proposed cost function are jitter and latency which have the high impact in the network link if the link is between the different clusters or grids. The NCF measures the network performance at most accurate but the high deviation in measurement denotes the dynamic variant of network metrics in the network. Since the mobile agents use less bandwidth and they are used for collecting the network metrics which lead to less response time. The evaluation results of the prediction model corresponding to jitter, packet loss, RTT and bandwidth using the proposed monitoring strategy and Holt-Winters (HW) prediction model are shown respectively in Figure 6.1(a-d). The vertical axis in each of the figures represents the appropriate unit of measurement for the metric under consideration and the horizontal one is the time in hours. From the Figure 6.1(a-d), it is evident that the proposed system predicts network performance at most accurately. 2 Jitter Jitter (ms) Time (hrs) M easured Jitter(ms) Predicted Jitter(ms) (a) Measured Vs Predicted Jitter Figure 6.1 (Continued)

14 89 2 Packet Loss Packet Loss (%) Time (hrs) M easured Packet Loss (%) Predicted Packet Loss (%) (b) Measured Vs Predicted Packet Loss.2 RTT.18 RTT (ms) Time (hrs) M easured RTT (ms) Predicted RTT (ms) (c) Measured Vs Predicted RTT 1 TCP Bandw idth TCP bandwidth (mbps) Time (hrs) M easured TCP BandWidth (mbps) Predicted TCP BandWidth (mbps) (d) Measured Vs Predicted Bandwidth Figure 6.1 Measured Vs Predicted Values of Network Characteristics

15 9 The observed and predicted performance values of the Grid network for 24 hours are shown in Figure 6.11 which promises that the predicted values are approaching the actual measured values. NCF Network Performance Time (hrs) M easured NCF Predicted NCF Figure 6.11 Measured Vs Predicted Network Performance The evaluation criteria to assess the performance of the proposed prediction are Mean Absolute Deviation (MAD) and Mean Magnitude of Error Relative to estimate (MMER). Mean Absolute Deviation (MAD) is the arithmetic mean of the absolute deviations of each forecast from its actual value. It is a better measure of dispersion than the standard variation when there are outliers in the data. An outlier is a data point which is far removed in value from the others in the data set. It is an unusually large or an unusually small value compared to the others. MAD castigates all errors in direct proportion to their absolute size. MAD = (6.2) MMER = (6.3) If MAD.25 then the prediction model is acceptable as an efficient one. MMER measures the error relative to the estimate so it is

16 91 preferable to MAD. Table 6.2 shows the network performance estimations by changing the smoothening and trend components which assure the less percentage on the prediction errors for =.8 and =.1 with MMER and MAD. Table 6.2 Mean absolute deviation for the performance estimation Parameter MMER MAD =.8, = =.9, = =.7, = =.2, = =.2, = The Table 6.3 shows the comparison of measure network performance and predicted network performance of the proposed NCF and cost function defined by Ferrari and Giacomini (24). The MAD for the proposed approach is less than.25 when compared to the cost function of Ferrari and Giacomini (24) and it is evident that the proposed NCF is an efficient one for the network perfromance measurement, because the prediction also almost matches with the measure one. From this, it is well kown that the proposed Network Cost Function model ensures the correctness of network perfromance estimation and as well as prediction. Constants used Cost Function Proposed Model Ferrari and Giacomini(24) Table 6.3 Prediction Evaluation =.8 =.1 =.9 =.1 =.7 =.8 =.2 =.2 =.2 =.6 MMER MAD MMER MAD The variation of the prediction error with the measured value for all clusters of MITGrid is shown in Figure 6.12 and the prediction accuracy is

17 92 also obvious and acceptable one. The prediction error for the proposed NCF is less than 25% and it is acceptable one in the dynamic change of network characteristics when compared with the cost function of Ferrari and Giacomini (24). 35.% Prediction Error (%) 3.% 25.% 2.% 15.% 1.% 5.%.% Proposed M odel Ferrari and Giacomini(24) Different Clusters of M ITGrid Figure 6.12 Prediction Error of Proposed Prediction Model with Ferrari and Giacomini (24) The network performance value between the different clusters of the MITGrid infrastructure is measured and the prediction is carried out. From the Figure 6.13, it is evident that the proposed prediction model provides better prediction results when compared to NWS. Also the observation of prediction error percentage is high for NWS, because of the high variation in the network performance metrics. The prediction error for the proposed NCF is less than 25% and it is also acceptable one in the dynamic change of network characteristics when compared with NWS. From the observation, the NWS prediction error is more than 4% for the three cases and the proposed prediction accuracy is also obvious and acceptable one from the Figure 6.13.

18 93 Prediction Error (%) 7.% 6.% 5.% 4.% 3.% 2.% 1.%.% Proposed M odel NWS Different Clusters of M ITGrid Figure 6.13 Prediction Error of Proposed Prediction Model with NWS 6.5 EVALUATION OF THE AUTOMATED DEPLOYMENT OF PROPOSED MONITORING SERVICE Mobile agents are utilized in the automated deployment process to facilitate error free deployment since mobile agents are not affected by network failures and the time taken for deployment is also less when compared to manual deployment. The time taken for the mobile agents to deploy the service in a new resource is calculated as follows: Let t(dt) is the time taken for automated deployment. t(dt) = t( ) + t( ) (6.4) where, t( ) is the time taken for the deployment agent to migrate to a node. t( ) is the time taken for deployment.

19 94 From the Figure 6.14, it is evident that mobile agent based automated deployment consumes less time than the script based approach in Automated Deployment of Monitoring Service (ADMS) (Yiduo et al 27) and manual deployment. If the dependency packages for Ganglia are downloaded, the time taken to install Ganglia is equal to running four commands which completes the installation. ADMS has to install Component Auto-deploy Proxy (CAP) and cluster and thereby it takes more time than the mobile based approach Service Deployment Time Deployment Time( Secs) No. of Resources M anual Deployment ADM S Agent based Deployment Figure 6.14 Manual vs. Automated Deployment Time A simulation based test is adopted to verify the efficiency of the proposed method. It is seen that the time taken for manual deployment increases as the number of resources increases. Since the response time of mobile agent is less, the time taken for automated deployment using mobile agent does not increase proportionately with the increase in the number of resources.