Quality-based Adaptive Resource Management Architecture (QARMA): A CORBA Resource Management Service Presenter: David Fleeman { [email protected]} 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
23
Embed
Quality-based Adaptive Resource Management Architecture (QARMA): A CORBA Resource Management Service Presenter: David Fleeman { [email protected] }[email protected].
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
TrackingATRUAV VideoResource 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.
QARMA Components
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.
• 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
Service
EnactorService
System Repository
Service
ConfigurationFiles
SpecificationTool
syscondQuO
Contracts
QuO Kernel
read
Resource Management Architecture
syscond
syscond
syscond
Application LayerQuO Middleware
QuOContracts
VIDEO DISTRIBUTIONHOST
VideoDistributor
Video Display
VIDEO DISPLAY HOST
VideoDisplayProxy
QuO
Video Stream
QuO
VideoSourceProcess
MOBILE VIDEOSOURCE HOST
Video File
QuO
Application LayerBBN OEP UAV System
Replaceable Components
set
Host and NetworkMonitor / Detector
Software Performance
Monitor / Detector
EventChannel
Hosts/Networks
** System Condition objects were added.** Contracts were modified to allow RM Service to force a chosen region.
Host and NetworkMonitor / Detector
Host and NetworkMonitor / Detector
Quality Connector Instance
(Quo Enactor)
16
Global Resource Mgmt. Demo Configuration
OU1
CORBAServices
CORBA RMServices
UAV1
Host Mon
OU3
Host Mon
OU2Host Mon
UAV2
Distrib1
Distrib2
Receiver1
Viewer1
Receiver2
Viewer2
LOAD 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
• 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