1 / 51

Provisioning Dynamic QoS Adaptation for Enterprise Distributed Real-time Embedded (DRE) Systems

Institute for Software Integrated Systems. Vanderbilt University Nashville, Tennessee. Provisioning Dynamic QoS Adaptation for Enterprise Distributed Real-time Embedded (DRE) Systems. Proposal Defense, March 3 rd , 2006 Gan Deng dengg@dre.vanderbilt.edu www.dre.vanderbilt.edu/~dengg.

joshwa
Download Presentation

Provisioning Dynamic QoS Adaptation for Enterprise Distributed Real-time Embedded (DRE) Systems

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. Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee Provisioning Dynamic QoS Adaptation for Enterprise Distributed Real-time Embedded (DRE) Systems Proposal Defense, March 3rd, 2006 Gan Deng dengg@dre.vanderbilt.edu www.dre.vanderbilt.edu/~dengg

  2. Presentation Road Map • Research Motivation • Taxonomy of Related Research • Research Challenges & Proposed Solutions • Evaluation of Success • Dissertation Timeline

  3. R&D Motivation: Enterprise DRE Systems Key Characteristics • Large-scale, network-centric, dynamic, “systems of systems” • Highly diverse & complex problem domains • Simultaneous QoS demands with resource constraints • e.g., loss of resources Examples • Mission-critical systems for critical infrastructure • e.g., power grid control, real-time warehouse management & inventory tracking • Total Ship Computing Environment (TSCE) • http://peoships.crane.navy.mil/ddx/

  4. Utility “Curve” “Broken” “Works” Utility Resources “Harder” Requirements Demands of Traditional DRE Systems • Key Characteristics • Stringent timing requirements, e.g., deadline, latency & jitter • System resources & workloads are known in advance • System resources & workloads change infrequently Traditional closed DRE Systems

  5. Utility “Curve” Desired Utility Curve “Broken” “Works” Utility “Working Range” Utility Resources Resources “Harder” Requirements “Softer” Requirements Demands of Enterprise DRE Systems • Key Challenges • Highly heterogeneous platform, languages & tool environments • Changing system running environments • Enormous inherent & accidental complexities Enterprise DRE Systems My R&D goal is to ensure end-to-end real-time QoS for enterprise DRE systems

  6. … … … Container Container Middleware Bus Replication Security Persistence Transaction Promising Solution: Component Middleware • Components encapsulate application “business” logic • Components interact via ports • Provided interfaces, e.g.,facets • Required connection points, e.g., receptacles • Event sinks & sources • Attributes • Containers provide execution environment for components with common operating requirements • Components/containers can also • Communicate via a middleware bus & • Reuse common middleware services • All components must be deployed & configured (D&C) into the target environment …

  7. Enterprise DRE System D&C Requirements • Large scale, i.e., thousands of components • Systems ideally use standards-based middleware & D&C model • Configure underlying middleware to provision desired real-time QoS settings Scenarios based on DARPA ARMS program

  8. Enterprise DRE System D&C Requirements • Large scale, i.e., thousands of components • Systems ideally use standards-based middleware & D&C model • Configure underlying middleware to provision desired real-time QoS settings • Reconfigure the system on demand to accommodate dynamically changing system operating conditions Enterprise DRE systems require bounded & scalable (re)deployment & (re)configuration capabilities to ensure end-to-end QoS

  9. SW Creator1 SW Creator2 InfrastructureInterfaces A2 A1 Implementations Deployment requirements Shipping DeploymentInterfaces Deployment Infrastructure Deployment Tools (generic) SW Deployer Component Deployment & Configuration (D&C) Goals of D&C Phase • Promote component reuse • Build complex applications by assembling existing components • Automate common services configuration • Declaratively inject QoS policies into applications • Dynamically deploy components to target heterogeneous domains • Optimize systems based on component configuration & deployment settings OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)

  10. OMG D & C Spec (PIM & PSMs) SW Creator1 SW Creator2 XMLSchemaGeneration D & C Profile InfrastructureInterfaces IDLGeneration A2 A1 Implementations InterchangeFormats Deployment requirements Shipping DeploymentInterfaces Deployment Infrastructure Deployment Tools (generic) SW Deployer Component Deployment & Configuration (D&C) My research enhances the D&C spec to support dynamic QoS provisioning OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)

  11. Presentation Road Map • Research Motivation • Taxonomy of Related Research • Research Challenges & Proposed Solutions • Evaluation of Success • Dissertation Timeline

  12. Taxonomy of Research Continuum for Real-time QoS Provisioning

  13. Code tangling Code Scattering Component A Component B Development-time QoS Provisioning • Key Ideas: • Raise the level of abstraction by viewing QoS policies as first-class entities • Use specialized languages features (e.g., AspectJ or AspectC++), middleware programming interfaces (e.g., Real-time CORBA), or QoS composing techniques (e.g., configuration metadata) to provision QoS statically

  14. Related Research: Development-time QoS Provisioning Development-time QoS provisioning is mainly suited for closed DRE systems

  15. Development-time QoS Provisioning: What is Missing? • Unresolved Challenges • What if system resources & workloads fluctuate frequently? • Development-time QoS provisioning can not address the problem because all real-time QoS settings are fixed Solution: Deployment-time QoS Provisioning

  16. Taxonomy of Research Continuum for Real-time QoS Provisioning

  17. Deployment-time QoS Provisioning • Key Ideas: • Use declarative approach to describe service contracts that capture adaptation rules & policies to specify when & how • Use special compiler or aspect weaving tools to synthesize or weave code to provision specified adaptive behavior • Generated application can be “reflective” to allow runtime adaptation Runtime Phase Deployment-time Phase Specialized Compiler or Aspect weaver Specify QoS Service Contracts Woven adaptation behavior code

  18. Related Research: Deployment-time QoS Provisioning Suitable for DRE systems where QoS adaptation rules are known a priori

  19. Deployment-time QoS Provisioning: What is Missing? • Unresolved Challenges • Adaptation rules or utility control models still must be known a priori • It’s hard to handle dynamically changing operating conditions since new application behavior & adaptations are needed after systems are deployed Emergency response required! Solution: Runtime QoS Provisioning

  20. Taxonomy of Research Continuum for Real-time QoS Provisioning

  21. Control Algorithm Control Algorithm Running Systems Runtime QoS Provisioning • Key Ideas • Decouple system adaptation policy from system application code & allow them to be changed independently from each other • Decouple system deployment framework & middleware from core system infrastructure to allow enterprise DRE systems dynamically reconfigurable My Research Focus Area

  22. Related Research: Runtime QoS Provisioning Runtime QoS provisioning is essential for enterprise DRE systems

  23. Runtime QoS Provisioning: What is Missing? • Unresolved Challenges • How to dynamically reconfigure enterprise DRE systems & real-time policies from the perspective of different end-users? • How to make reconfiguration process more predictable & time-bounded? • How to simplify the planning of reconfiguration process workflow?

  24. Presentation Road Map • Research Motivation • Taxonomy of Related Research • Research Challenges & Proposed Solutions • Evaluation of Success • Dissertation Timeline

  25. Operational string App App App App App Research Goals • Computational model – Develop dynamic reconfiguration techniques for enterprise DRE systems • Execution platform – Map the dynamic reconfiguration techniques to a more predictable & time-bounded execution platform • Programming model – Develop a domain-specific modeling language to simplify dynamic reconfiguration workflow Constraint is to support standards-based component & D&C model

  26. Limitations with OMG D&C Model Hypothesis Existing CCM components & applications could be enhanced with dynamic capabilities w/out breaking standard component programming model & D&C model D & C Profile • The existing D&C model cannot change the configuration once an application is deployed • Must shutdown the entire application & redeploy, which is not feasible for enterprise DRE systems D&C Tools SW Deployer Target Environment No QoS Assurance Applications always static • The existing D&C model cannot ensure real-time QoS when performing initial D&C & reconfiguration • Enterprise DRE systems have stringent QoS requirements for dynamic redeployment & reconfiguration G. Deng et al, “DAnCE: A QoS-enabled Component Deployment & Configuration Engine”, ACM/IFIP Component Deployment’ 05, Grenoble, France, November 28-29, 2005. Baseline: DAnCE Deployment And Configuration Engine (D&C Spec)

  27. Challenge 1: Reconfigure Enterprise DRE Systems from End-User Perspective • Context • Enterprise DRE systems may have thousands of components distributed across hundreds of nodes • Components are often grouped together by system architect in the form of operational strings • Problem • How to make enterprise DRE systems manageable from end-users (e.g., software architect, software engineer) perspective? Time-critical end-to-end path through operational string

  28. App App MLRM MLRM Infrastructure Infrastructure Resource Pool Resource Pool Resources Resources Solution  ReDaC Computational Model • Develop a ReDaC computational model: • Introduce operational strings as first-class entities • Provide a rich set of services to manage enterprise DRE systems & system resources at different levels of granularity • Components Real-time policy set • Add_Instance <Plan ID> <Node ID> <Component Type> <Policy Set> • Remove_Instance <Plan ID> <Component ID> • Bind <Plan ID> <Source Component ID : Port Name> <Dest Component ID : Port Name> • Remove_Binding <Plan ID> <Source Component ID : Port Name> <Dest Component ID : Port Name>

  29. Operational string App App App App App App MLRM MLRM Infrastructure Infrastructure Resource Pool Resource Pool Resources Resources Solution  ReDaC Computational Model • Develop a ReDaC computational model: • Introduce operational strings as first-class entities • Provide a rich set of services to manage enterprise DRE systems & system resources at different levels of granularity • Components • Operational strings • Add_OpString  <Plan ID> <OpString Descriptor> • Remove_OpString  <Plan ID> <OpString ID> • Update_OpString  <Plan ID> <OpString Descriptor> • Bind_OpString_OpString <Source OpString ID : Port ID> <Dest OpString ID : Port ID> Mission

  30. Operational string App App App App App App MLRM MLRM Infrastructure Infrastructure Resource Pool Resource Pool Resources Resources Solution  ReDaC Computational Model • Develop a ReDaC computational model : • Introduce operational strings as first-class entities • Provide a rich set of services to manage enterprise DRE systems & system resources at different levels of granularity • Components • Operational strings • Entire system deployment plan • Deploy_Plan < Deployment Plan Descriptor> • Teardown_Plan < Deployment Plan ID> • Update_Plan < Plan  ID> <Deployment Plan Descriptor> Mission

  31. Operational string App App App App App App MLRM MLRM Infrastructure Infrastructure Resource Pool Resource Pool Resources Resources Solution  ReDaC Computational Model • Develop a ReDaC computational model : • Introduce operational strings as first-class entities • Provide a rich set of services to manage enterprise DRE systems & system resources at different levels of granularity • Components • Operational strings • Entire system assemblies • Interactions among these entities through well-defined interfaces • Components shared by independently designed assemblies Bind_OpString_Component <Plan ID> <OpString ID : Port ID> <Dest Component ID : Port ID> Mission

  32. Current Status of ReDaC Designed & implemented the baseline & integrated it with DAnCE Enhanced DAnCE to support configuring CCM components with RT policies Designed & implemented the initial ReDaC computational model • Adding a component is on a per-instance basis • Specify component configuration & binding information • Specify what QoS policy the component should be configured • Container placement is transparent to clients for optimization • Removing a component is on a per-instance basis • Reconfigurations are transparent to peer components • Components could be shared across assemblies Instance information Instance & binding configuration & QoS G. Deng et al, “Modularizing Variability & Scalability Concerns in DRE Systems with Modeling Tools & Component Middleware: A Case Study”, IEEE ISORC '06, Korea

  33. Criteria for Evaluation Performance Criteria For Reconfiguration (Hypothesis) • Baseline – Existing DARPA ARMS GT4 Testbed, 3 operational strings, with mission effectiveness values (MEV) of 3, 2, 2 • Metric M1 – Average mission effective value loss of all operational strings • Divide the total down time of each operational string by the total experiment operational time. • Multiply it by the MEV of that operational string to produce the average MEV loss for that string. • Sum up all average MEV loss. Goal: Reduce M1 value by 20-30%

  34. Research Contributions & Related Publications • Identified key D&C complexities for enterprise DRE systems • Propose to enhance standards-based component middleware to provision dynamic capability for enterprise DRE systems to ensure QoS • Propose a ReDaC computational model to simplify the enterprise DRE system reconfiguration 1. “Modularizing Variability & Scalability Concerns in Distributed Real-time & Embedded Systems with Modeling Tools & Component Middleware: A Case Study”, IEEE ISORC '06, April 24-26, 2006, Gyeongju, Korea. 2. “DAnCE: A QoS-enabled Component Deployment & Configuration Engine”, ACM/IFIP CD’ 05, Grenoble, France, November 28-29, 2005. 3. “Addressing Domain Evolution Challenges for Software Product-line Architectures (PLAs)”, ACM/IEEE MoDELS 2005 workshop October 2, 2005, Jamaica. 4. “Concern-based Composition & Reuse of Distributed Systems”, ACM/IEEE ICSR8, Madrid, Spain, July 2004. 1st Author 3rd Author

  35. Challenge 2: Ensure Reconfiguration QoS • Context • Multiple reconfiguration service requests might arrive simultaneously • Problems • How to differentiate services from different requests based on their priorities? • Non-Critical • Critical

  36. Deployer Deployer Deployer Deployer Proposed Solution  ReDaC Execution Platform • ReDaC Execution Platform for Service Execution • A novel approach to integrate Real-time CORBA (RT CORBA) features to build a predictable platform model • All standards-based deployment agents (e.g., ExecutionManager, NodeApplicationManager, & NodeManager) are configured with appropriate RT CORBA policies & run atop RT CORBA middleware • Deploy_OpString • <OpString Descriptor> • [Service Priority] • When external clients request setting up & modifying services, the priority level could also be specified as part of the request

  37. LynxOS Priority 128 Solaris Priority 136 Proposed Solution  ReDaC Execution Platform • RT-CORBA Features Leveraged by ReDaC Execution Platform • Priority Model • Use “ClientPropagated” policy to propagate client request priorities • ThreadPool Model • Use “ThreadPoolWithLanes” policy serve client requests concurrently • The “lane” feature offers priority partitioning to avoid priority inversion • Connection Model • Use PriorityBanded policy to differentiate service request based on priority

  38. Current Status of ReDaC Execution Platform • Deploy_OpString • <OpString Descriptor> • [Service Priority] • Initial Design Phase

  39. Criteria for Evaluation Performance Criteria For Reconfiguration (Hypothesis) • Baseline – Current DARPA ARMS GT4 Testbed (6 operational strings, with priority values of 3, 2, 2, 2, 1, 1, & system workloads are high) • Metric M2 – Highest priority operational stringsmission effective loss Goal: Reduce M2 value by 20-30% • Determine when the first operational string with the highest MEV goes down and obtain that timestamp. • Subtract that from the timestamp when all operational strings with the highest MEV were first up. • Repeat if another operational string with the highest MEV goes down. • Sum up all highest MEV operational down time. • Divide it by the total experimental measurement time

  40. Research Contributions & Related Publications • Identified key complexities in provisioning predictable dynamic reconfiguration service for enterprise DRE systems • Proposed a novel solution to address the above challenges by leveraging real-time CORBA features 1. “Supporting Configuration & Deployment of Component-based DRE Systems Using Frameworks & Aspects”, Poster paper of OOPSLA 2005, San Diego, CA, October 2005. 2. “Resolving Component Deployment & Configuration Challenges for DRE Systems via Frameworks & Generative Techniques”, Doctoral Symposium ACM ICSE 2006, Shanghai , China, May 20-28, 2006 1st Author 2nd Author

  41. Operational string App App App App App App Challenge 3: Ad Hoc Techniques for Planning the System Reconfiguration Process • Context: • Enterprise DRE system reconfiguration process is usually composed of a number of subtasks

  42. Operational string App App App App App App Ad Hoc Techniques for Planning the Reconfiguration Process • Problem: • How to allow the reconfiguration process to managed from end-users' perspective? • How to specify the causal relationship among various subtasks? 3 5’ 1 4 2 5

  43. Solution  Reconfiguration Modeling Language (ReML) • Develop a ReDaC Programming Model called ReML: • Allow end-users to declaratively specify the workflow of the reconfiguration process through ReML, a visual DSML • Combine the ReML with ReDaC to provision full-fledged enterprise DRE system reconfiguration capability RemoveInstance (W) AddOpString (XYZ) BindOpString (X to Y) UpdatePlan (P1, P.cdp)

  44. Current Status of ReML • Initial Design Phase of ReML • Significant experiences gained before in developing DSMLs: • Developed an Event QoS Aspect Modeling Language (EQAL), used in DARPA PCES program EQAL • “Model-driven Configuration & Deployment of Component Middleware Publisher/Subscriber Services”, ACM GPCE ‘04, Vancouver, Canada, Oct 2004. • “Model Driven Middleware: A New Paradigm for Deploying & Provisioning Distributed Real-time & Embedded Applications”, Elsevier Journal of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006 (to appear). • “Model-Driven Integration of Federated Event Services in Real-Time Component Middleware”, ACMSE ‘04, Huntsville, AL, Apr, 2004.

  45. Operational string App App App App App App Criteria for Evaluation • The Integration of ReDaC Programming Model & Computational Model could reduce enterprise DRE systems reconfiguration effort (Hypothesis) • Metrics  Lines of Code (LOCs) reduced • M3 = LOC Saved Per Instance (Estimated ~200 LOC) • M4 = LOC Saved Per Connection (Estimated ~200 LOC) • M5 = LOC Saved Per Operational String (Estimated ~5,000 LOC for a size of 10 components & 15 connections) Goal: Maximize the LOC Savings

  46. Research Contributions & Related Publications • Identified key complexities in provisioning reconfiguration workflow for enterprise DRE systems • Proposed a model-based solution to address the above challenge by leveraging model driven development (MDD) & domain-specific modeling language (DSML) technologies 1. “Model-driven Configuration & Deployment of Component Middleware Publisher/Subscriber Services”, GPCE ‘04, Vancouver, Canada, October 2004 2. “Model-Driven Integration of Federated Event Services in Real-Time Component Middleware”, ACMSE ‘04, Huntsville, AL, April 2-3, 2004 1st Author 2nd Author

  47. Summary of Research Contributions

  48. Presentation Road Map • Research Motivation • Taxonomy of Related Research • Research Challenges & Proposed Solutions • Evaluation of Success • Dissertation Timeline

  49. Dissertation Timeline Methodology Validation & Architectural Design, DAnCE Baseline Initial ReDaC Framework Implementation ReDaC & ReML Implementation & Experiments ReDaC RT Enhancements ReML Design DAnCE Architectural Design & Initial Implementation ReDaC Framework Design & Implementation March 3, 2006 May 2003 I’m here Dec 2004 Dec 2006 Dec 2005 March 2007 CD 2005 OOPSLA 2005 Poster MoDELS 2005 Workshop Journal of Sci of Comp Programming 2006 ICSR 2004 OOPSLA 2003 Workshop OOPSLA 2004 Poster GPCE 2004 ACMSE 2004 ISORC 2006 ICSE 2006 Doctoral Sym

  50. Summary of Publications • Supporting Configuration & Deployment of Component-based DRE Systems Using Frameworks, Models, & Aspects, Poster paper of ACM OOPSLA 2005, San Diego, CA, Oct 2005. • Model-driven Configuration & Deployment of Component Middleware Publisher/Subscriber Services, ACM GPCE ‘04, Vancouver, Canada, Oct 2004. • Model Driven Middleware: A New Paradigm for Deploying & Provisioning Distributed Real-time & Embedded Applications, Elsevier Journal of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006 (to appear). • Model-Driven Integration of Federated Event Services in Real-Time Component Middleware, ACMSE ‘04, Huntsville, AL, Apr, 2004. • Resolving Component Deployment & Configuration Challenges for DRE Systems via Frameworks & Generative Techniques, Doctoral Symposium ACM ICSE 2006, Shanghai , China, May 2006 • Modularizing Variability & Scalability Concerns in Distributed Real-time & Embedded Systems with Modeling Tools & Component Middleware: A Case Study”, IEEE ISORC '06, Apr, 2006, Gyeongju, Korea. • DAnCE: A QoS-enabled Component Deployment & Conguration Engine, ACM/IFIP CD’ 05, Grenoble, France, Nov, 2005. • Addressing Domain Evolution Challenges for Software Product-line Architectures, ACM/IEEE MoDELS 2005 workshop Oct, Jamaica. • Evaluating Techniques for Dynamic Component Updating, OTM DOA '05, Agia Napa, Cyprus, Nov, 2005. • “Concern-based Composition & Reuse of Distributed Systems”, ACM/IEEE ICSR8, Madrid, Spain, Jul 2004. • “Model Driven Development of Inventory Tracking System”, ACM OOPSLA 2003 Workshop on DSML, Anaheim, CA, Oct 2003. First Author 2nd Author Others

More Related