540 likes | 726 Views
Adaptive Parallel Applications in Distributed Computing Environment. Sheikh K. Ghafoor Department of Computer Science Tennessee Technological University May 05, 2010. Outline. Overview RMS for adaptive parallel application A model for adaptive parallel system Conclusions Future research.
E N D
Adaptive Parallel Applications in Distributed Computing Environment Sheikh K. Ghafoor Department of Computer Science Tennessee Technological University May 05, 2010
Outline • Overview • RMS for adaptive parallel application • A model for adaptive parallel system • Conclusions • Future research
Autonomic Computing ”What is autonomic computing? It is the ability of systems to be more self-managing. The term autonomic comes from the autonomic nervous system, which controls many organs and muscles in the human body. Usually, we are unaware of its workings because it functions in an involuntary, reflexive manner -- for example, we don't notice when our heart beats faster or our blood vessels change size in response to temperature, posture, food intake, stressful experiences and other changes to which we're exposed. And, by the way, our autonomic nervous system is always working” Alan Ganek, VP Autonomic Computing, IBM
Research Area • Autonomic computing -systems that adapt themselves without human intervention in response to unpredictable events and data • Adaptive hardware • Adaptive OS • Adaptive system software • Adaptive applications
Demand for Computational Speed • Applications in science and engineering are computationally intensive • Continual demand of greater computational speed from computer systems than is currently feasible • Areas requiring great computational speed include numerical modeling and simulation of scientific and engineering problems
Examples • Weather forecasting • Manufacturing and design • Modeling large DNA structures • Modeling motion of astronomical bodies • Problems in particle physics
Classification of Parallel Application [Feitelson and Rudolp 1996] Rigid Fixed no. of processors defined by users Moldable Fixed no. processors defined by Resource Management Systems (RMS) Evolving Processors vary during execution, initiated by application Malleable Processors change during execution, initiated by RMS
Adaptive Applications • Evolving and malleable applications • Change resources during execution • Characteristics of Adaptive Applications • Capable of expanding or shrinking • Capable of communicating with RMS • Capable of negotiating resources with RMS • May have resource utilization constraints • Consist of phases where adaptation can occur
Adaptive RMS • Characteristics • Handle additional scheduling event • Release or request of resources from running evolving applications • Scheduling may involve rescheduling running applications • Request for change in resource allocation • Additional degree of freedom with malleable applications • Negotiate resource reallocation with running applications
Motivation • Adaptive applications promise • New classes of applications driven by unpredictable data and events • Autonomic computing • Improved system utilization • Better application performance • Current job schedulers and resource management systems are unable to handle adaptive applications efficiently • Lack of infrastructure supports • Absence of large number of adaptive applications
Research Objective • To investigate the characteristics of adaptive workload and the RMS, and their impact on system and application performance.
Research Methodology • Investigate through prototype system • Investigate by modeling and simulation
Research Issues • Resource management system (RMS) • Programming model for adaptive applications • Scheduling
RMS Requirement for Malleable Applications • Negotiate with running malleable applications • Allocate/Claim resources to/from running malleable applications • Scheduler • Consider running applications in addition to pending applications • Choose candidates to allocate idle resources • Choose resource preemption candidates
Resource Negotiation Protocol • Different communication scenarios are possible • Supports all possible negotiation scenarios • Supports multi-round and multiple resources negotiations • The resource negotiation model consists of two parties • Any party may initiate the negotiation • Negotiation is done by exchanging Negotiation Template(NT)
Architecture of RMS user Job Submission Event Handler Update System State Update Read State events Poll Events invoke Coordinator Server Scheduler New Job List Neg. List New JobList Neg. Status Update Negotiation Manager Dispatcher job info Mal. Job Registration JobCompletion Node Controllers invoke negotiate Running Applications Execution of agreement
Test Rigid Application • OpenSees (Simulation of structural behavior in response to earthquake) • Implemented using PVM • Master-Slave (coordinator, computing) • Input – host list, structure list • Embarrassingly parallel • Execution time proportional to number of structure Host list & list. of structures Coordinator Computing Computing H1 H2
Negotiation Expand 2 Accept 1 Host 3 Computing H3 Malleable Application • Coordinator capable of negotiation • Parameters: Min. and max. processors • Accept offer as long as total processors between min. and max. • Create and destroy computing process during execution RMS Coordinator Computing Computing H1 H2
Experimental Setup • Scheduling Policy • First Come First Serve (FCFS) • Pending jobs have priority over running malleable jobs • No job preemption • Expansion and shrinkage candidates are selected in chronological order of start time • Workload • Two workloads • 40 jobs • 120 jobs • Hardware • 4 processor Pentium Linux cluster connected by 100mb Ethernet • 16 processor Pentium Linux cluster connected by 100mb Ethernet
Experimental Results (120 Job Workload) • Max.improvement • Utilization – (87 – 100)% • Schedule Span – (5058-4390) • Avg. TAT – (1969-1657) • With 10% Malleable • Utilization – (87-91)% • Schedule Span – (5058-4861) • Avg. TAT – (1969-1849)
Conclusions From Prototype • Presence of malleable jobs in workload improved performance • High percentage of malleable jobs is not necessary to make significant improvement in performance • On average for malleable jobs, execution time increased, while turn around time decreased • Overhead of managing malleable jobs is low
Modeling Adaptive System with Malleable Jobs • Developed a model for Adaptive System • Workload • RMS • Applications • Numerically simulated the model with synthetic data
Model of Workload(relative composition of evolving/malleable/rigid, characteristic of evolving applications, etc) Model of Negotiationsand Agreement (performance ofcommunication protocol, Convergence etc.) Conceptual Model(Model Components) System Status User(workload) Model of Management(resources, QoS, eventprocessing, etc) Model of Scheduling (policies, objectives, decisions, performance etc) Server Scheduler Negotiator Dispatcher Model of Resource Reallocation(performance, constraints, etc) Node Controllers Running Jobs Model of Adaptive Applications (ability to negotiate, ability to shrink and expand, cost of adaptation, time to respond, etc)
Collaboration Diagram of Conceptual Model 2 3 1 Negotiator User Server Scheduler 7 8 9 Dispatcher One or Multiple Invocation 11 14 5 Node Controllers 4 6 12 Running Jobs 10 13 • Interactions between objects • Submit Job (Job info) • Schedule (System State) • Negotiate (proposal) • Offer/Counter offer • Counter offer • Accept/Reject Notification • Negotiation outcome (Agreements) • Execute (schedule) 9. Execute schedule 10 . Execute (Agreement) 11. Start New Job (Job execution info) 12. Launch Job 13. Request for negotiation 14. Complete job (Job completion info)
Application Model • Assumptions • Applications are parallel • Computation is linearly distributed over time. • Applications perform negotiation in a non blocking manner • Applications can adapt at any point during execution • Only processors are considered as resources • Application consists of • One coordinating process • Negotiation • Adaptation • Multiple computing processes • Application consists of phases • During a phase • Processors remain unchanged • Negotiation occurs • Adaptation results in phase change
Workload Model • Assumption • Workload consists of rigid and malleable applications only • We need realistic workload data • Validating against real rigid data • Develop realistic malleable workload • Models available for rigid workload • Downy (1997), Feitelson(1998), Lubin (2003) etc. • No model available for malleable workload • Selected Downy’s model for modification to generate malleable workload • Validated against real data • Used by researcher • Open source code is available
Workload Model • Downy model • Input: No. of jobs, minimum – maximum runtime, minimum – maximum processors • Output: Set of jobs – arrival time, runtime, processor requirement • Extended Downy model • Additional input: No. of malleable job, distribution of malleable job, flexibility range • Output: Set of jobs – job type, arrival time, runtime, processor requirement, flexibility range
Negotiation Model • Negotiation cost depends on • Communication time between RMS and application • RMS response time to an offer • Application response time to an offer • Number of rounds of negotiation • Assumptions • Communication time and RMS response time is constant • Negotiations is performed sequentially • Negotiation cost varies • From application to application • From negotiation to negotiation
Negotiation Model • Negotiation cost is approximated by a single parameter Cn • Cost is stochastically selected from a random ramp distribution. • Probability decreases linearly as cost increases
Adaptation Model • Adaptation cost depends on • Application’s business logic • Data structure used by the application • Number of processors change during adaptation • Adaptation cost varies • From application to application • From adaptation to adaptation • Assumptions • Adaptation cost is linearly proportional to the change in the number of processors • Adaptation cost doesn’t vary from shrinkage to expansion
Experimental Design for Investigation of Impact of Parameters on Performance • Each of the parameters were varied while the others kept constant • To isolate the impact of one parameter on performance • Simulation Data • No of jobs: 1000 • Runtime: 100 – 3600 seconds • Flexibility: 2-128 processors
Parameters • % of Malleable jobs • 10% -100% in steps of 10 • Flexibility of Malleable Jobs • 2-16, 2-32, 2-64, 2-80, 2-96, 2-112, and 2-128 • 4-130, 8-134, 12-138, and 16-142 • Cost of Negotiation • 0.0015, 0.003, 0.006, 0.006, 0.0012, 0.012, 0.024, 0.048, 0.96, 0.2, 0.4, 0.8, 2, 4, and 8 seconds. • Cost of Adaptation • 0.002, 0.004, 0.008, 0.01, 0.02, 0.04, 0.08, 0.2, 0.4, 0.8, 1 second, 2, 4, and 8 seconds
Performance With % of Malleable Jobs Negotiation Cost: 0.0015 Secs. Adaptation Cost: 0.002 Secs
Avg. TAT With % of Malleable Jobs Negotiation Cost: 0.0015 Secs. Adaptation Cost: 0.002 Secs
Wait, Avg. TAT and Execution Time as function of % of Malleable Jobs Negotiation Cost: 0.0015 Secs. Adaptation Cost: 0.002 Secs Cluster Size: 256 Processors
Summary of Performance with the Variation of Number of Malleable Jobs • Utilization improves as number of malleable jobs increases • Improvement saturates • It is possible achieve maximum utilization with malleable workload • The maximum possible utilization can be achieved with relatively few malleable jobs • Average turn around time decreases as the number of malleable jobs increases • As the number of malleable jobs increases, the job execution time increases on average, but the average turn around time decreases. This is because with higher number of malleable jobs, a job has to wait less in the pending queue.
Summary of Performance with the Variation of Flexibility • Performance decreases as the lower bound of flexibility increases • The impact of lower bound decreases as the number of malleable job increases • For a given flexibility utilization increases with the number of malleable jobs and saturates • At saturation point, utilization increases as flexibility increases and saturates at certain flexibility
Variation of Number of Negotiation with Variation of Number of Malleable Jobs
Summary of Performance with the Variation of Negotiation Cost • Negotiation cost up to 0.8 second has no significant impact on performance • Negotiation cost doesn’t impact 10% and 100% job mixes • For the same negotiation cost as the number of malleable job increases the utilization decreases, and then the utilization increases as the number of malleable increases further
Summary of Performance with the Variation of Adaptation Cost • Performance decreases as adaptations cost increases • Adaptation cost doesn’t impact 10% and 100% job mixes significantly • The impact of adaptation cost on performance more pronounced compared to the impact of negotiation cost
Conclusions From Simulation • Performance improves as number of malleable jobs increases and it is possible to achieve maximum utilization with relatively few malleable jobs • Performance decreases as the lower bound of flexibility increases • The impact of lower bound decreases as the number of malleable job increases • For a given flexibility, utilization increases with the number of malleable jobs and saturates • Negotiation cost does not have significant impact on performance • Adaptation cost impact performance significantly • Number of negotiation varies with the number of malleable applications in the workload
Future Work • Scheduling algorithm • Policy regarding selection of negotiation candidates • Failed Negotiation • Further investigation of impact of flexibility • Late release of resources • Model involving evolving applications • Programming model for adaptive applications • Extending the present work in Grid environment