1 / 23

Presenter: David Fleeman { fleeman@ohio } D. Fleeman, M. Gillen, A. Lenharth, M. Delaney,

Quality-based Adaptive Resource Management Architecture (QARMA): A CORBA Resource Management Service. Presenter: David Fleeman { fleeman@ohio.edu } D. Fleeman, M. Gillen, A. Lenharth, M. Delaney, L. Welch, D. Juedes and C. Liu Center for Intelligent, Distributed & Dependable Systems

kin
Download Presentation

Presenter: David Fleeman { fleeman@ohio } D. Fleeman, M. Gillen, A. Lenharth, M. Delaney,

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quality-based Adaptive Resource Management Architecture (QARMA):A CORBA Resource Management Service Presenter: David Fleeman { fleeman@ohio.edu } D. Fleeman, M. Gillen, A. Lenharth, M. Delaney, L. Welch, D. Juedes and C. Liu Center for Intelligent, Distributed & Dependable Systems Ohio University Athens, OH WPDRTS 2004 April 26, 2004

  2. Presentation Overview • QARMA • Overview of Architecture • GME/VEST-based Modeling Tool • System Repository Service • Resource Management Service • Enactor Service • Experimental Results • Integration Efforts • RT CORBA Dynamic Scheduling Service (URI) • Utah CPU Broker (Utah) • Technology Transition • DARPA PCES BBN OEP (UAV) • DARPA ARMS MLRM component • Place services into TAO • Conclusions and Future Work

  3. Generic Resource Management Architecture Configuration Files Detectors Decision-Maker Monitors Information Repository Enactors Environment Resource Instrumentation Software Instrumentation Resource and Software Management Commands Computing Environment & User Applications

  4. CORBA Resource Management Architecture Resource Management Architecture QARMA Components Specification Tool Configuration Files System Repository Service Resource Management Service Enactor Service Replaceable Components Host and Network Monitor / Detector Software Performance Monitor / Detector Enactor (Quality Connector) Hosts/Networks Host and Network Monitor / Detector Software Performance Monitor / Detector Enactor (Quality Connector) Host and Network Monitor / Detector Software Performance Monitor / Detector Enactor (Quality Connector) Resource Management Service Goal • Each chain of applications achieves a “benefit” based on it’s service attribute settings (e.g., frame rate) and extrinsic attribute settings (e.g., importance). • The Resource Management Service changes service attributes in order to optimize total benefit, subject to the constraint that all tasks meet their real-time requirements. UAV Video ATR Tracking Application Layer (independent of QoS mechanism)

  5. QARMA System Repository Service • Purpose • Central repository for communicating all specification and state data to management components • Benefits • Reduced complexity of other components • Other components become stateless • Need for replication and fault tolerance of other components is decreased • Flexibility in replacing storage mechanism behind System Repository (e.g., memory, XML files, database) • Integration with components developed by other organizations hinges only on agreement of the data stored in the System Repository • Drawbacks • Becomes a single point of failure • Not scalable for arbitrarily large systems • These drawbacks can be handled with standard fault-tolerance and replication mechanisms.

  6. QARMA Resource Management Service • Purpose • Translate specification into algorithmic model. • Make intelligent allocation decisions. • Benefits • Ability to perform global feasibility analysis for tasks that require multiple resources. • Ability to perform global optimization for service quality settings. • Drawbacks • Not scalable for arbitrarily large systems. • Hierarchical decision-makers, such as the one presented this morning may be used in place of this component.

  7. IDL Interface module QARMA { … interface RM_Service { typedef sequence<string> Hint; typedef sequence<Hint> Hint_seq; void reactive_rm(in Hint_seq hints); }; … }; Invocation by Host Detector // Create a hint for the RM Service QARMA::RM_Service::Hint_seq hints; hints.length(1); hints[0].length(2); hints[0][0] = CORBA::string_dup(“Overload”); hints[0][1] = CORBA::string_dup(“host1”); // Invoke the RM Service rm_service->reactive_rm(hints); QARMA Resource Management ServiceCode Snippets

  8. QARMA Resource Management ServiceThe Key Problems • Information Acquisition • Information Modeling • Resource Allocation Algorithms • Feasibility Testing • Optimization Objective • Control Mechanisms • Pluggable

  9. Information Acquisition • Obtained from System Repository Service • Resource Specification: • Describes hosts, network devices, and network connectivity. • Software Specification: • Describes the extrinsic attributes that affect performance of applications and the service attributes that can be used to control application resource usage and quality. • Describes the application connectivity and dependencies, performance requirements, and performance characteristics. • Monitoring Data: • Host and network resource usage state and statistics • Software performance state and statistics

  10. Information Modeling • Specification data is transformed into mathematical models. • Based on the models presented in chapters 3 and 9 of Jane Liu’s “Real-Time Systems” book. • Service and extrinsic attributes have been added to extend the model presented in the book. • Four models are created: • Resource Model • Task Model • Profile Model • Benefit Model

  11. Host ou4.cidds { Memory 256 MB; … Network { Interface eth0 { Name “10.0.0.11”; … } } } Host ou3.cidds { … Network { Interface eth0 { … } } } Switch lan1 { Network { Interface eth0; Interface eth1; } } Network Topology { Link { Interface lan1 eth0; Interface ou4.cidds eth0; Speed 100 MB/sec; Latency 0.0 sec; } … } … struct NetworkInterface { string name; … } struct Host { string name; long memory; sequence<NetworkInterface> interfaces; } typedef Host NetworkSwitch; struct NetworkLink { sequence<StringPair> source_interfaces; sequence<StringPair> sink_interfaces; double link_speed; doulbe link_latency; } Example: Specification => Data Structure => Model I I L L H H S L L ou4.cidds with loopback interface ou3.cidds with loopback interface full- duplex link switch lan1 full- duplex link

  12. QARMA Control Mechanisms • Long term goal is to have all the following: • Service Level Adaptation • Process Allocation (Startup capabilities) • Process Migration (Ability to stop and restart processes) • Process Replication • Dynamic Network Routing • Network Reservation and Prioritization (IntServ / DiffServ) • CPU Reservation and Prioritization (Utah CPU Broker) • Currently implemented in QARMA: • Service Level Adaptation • Process Allocation (simplest) • Process Migration (simplest)

  13. Example Resource Allocation Algorithm:Greedy Service Level Optimization • INPUT: • Resource Model, Task Model, Profile Model, Benefit Model • OUTPUT: • Setting of Service Levels such that the resource utilization on any resource is less than 69% and utility is maximized. • ALGORITHM • Choose lowest quality settings for all tasks • Rank/order systems by importance • For each system in order of importance: • Set service level to the highest • While not feasible, decrease service level • Return service level settings

  14. QARMA Enactor Service • Purpose • Enact changes to the allocation of resources as directed by the Resource Management Service. • Benefits • Delegates change directives to lower-level enactors. • Specification for enactors allows enactment mechanisms to be swapped out. • Drawbacks • ???

  15. Integration with the BBN OEP Resource Management Architecture Specification Tool Configuration Files System Repository Service Resource Management Service Enactor Service Replaceable Components Host and Network Monitor / Detector Quality Connector Instance (Quo Enactor) Hosts/Networks Host and Network Monitor / Detector Host and Network Monitor / Detector Software Performance Monitor / Detector Application Layer QuO Middleware set QuO Contracts sys cond QuO Contracts sys cond read sys cond Event Channel sys cond ** System Condition objects were added. ** Contracts were modified to allow RM Service to force a chosen region. QuO Kernel Application Layer BBN OEP UAV System Video Source Process Video Distributor Video Display Proxy Video Stream Video Display QuO QuO QuO Video File VIDEO DISTRIBUTION HOST MOBILE VIDEO SOURCE HOST VIDEO DISPLAY HOST

  16. Receiver1 CORBA Services Distrib1 UAV1 Viewer1 Receiver2 Distrib2 UAV2 CORBA RM Services Viewer2 Host Mon Host Mon Host Mon OU1 OU3 OU2 LOAD Global Resource Mgmt. Demo Configuration OU4 • There are two Sender-Distributor-Receiver streams. • Receiver1 is set to the highest priority (because it is viewing a target). • Use Hourglass to apply CPU load on the Receiver node. • Load increases every 90 seconds as follows: • 40% at time 40 • 60% at time 130 • 90% at time 220 • 98% at time 310 • 100% at time 400

  17. Global RM vs. Local RM - CPU Load Experiment Frame Rate Local RM Global RM

  18. Global RM vs. Local RM - CPU Load Experiment Frame Rate Results

  19. Global RM vs. Local RM - CPU Load Experiment Latency Local RM Global RM

  20. Global RM vs. Local RM - CPU Load Experiment Latency Results Average Latency Standard Deviation Baseline QARMA Baseline V1 Baseline V2 QARMA V1 QARMA V2

  21. Global RM vs. Local RM - CPU Load Experiment Conclusions • Applications controlled by the global RM • demonstrate greater stability • exhibit greater determinism • have lower average latency • delivered • higher frame rate for more important streams • higher average frame rate

  22. Future Work • Integrate other resource management mechanisms • Investigate and develop more advanced allocation algorithms • Provide fault tolerance and stabilization of the Resource Management Service as well as reflexive management. • Continue integration, transition and validation efforts • Validation with RMBench • Validation with PCES OEP (Boeing and BBN) • Integration with PCES technology • Scheduling Service, Kokyu, CPU Broker • Transition into DARPA ARMS MLRM infrastructure • Transition into TAO as CORBA Services

  23. Envisioned PCES Component Integration Resource Management Architecture Specification Tool (OU/URI) Configuration Files System Repository Service (OU) Resource Management Service (OU) Enactor Service (OU) Other PCES Components Host and Network Monitor / Detector Resource Enactors (KU) CPU Broker (Utah) Host and Network Monitor / Detector Resource Enactors (KU) CPU Broker (Utah) Scheduling Service (URI) Resource Monitoring (KU) Resource Enactor (KU) CPU Broker (Utah) Enactor (Quality Connector) Hosts/Networks Enactor (Quality Connector) Quality Enactor (OU) RT CORBA Pluggable Scheduler Kokyu (WUSTL) RT CORBA scheduling point . . . . . . Adaptation Parameter Adjustments (i.e., frame rate) UAV Video ATR Tracking Application Layer

More Related