1 / 16

CaDAnCE: A Criticality-aware Deployment And Configuration Engine

Institute for Software Integrated Systems. Vanderbilt University Nashville, Tennessee. CaDAnCE: A Criticality-aware Deployment And Configuration Engine. Gan Deng, Douglas Schmidt & Aniruddha Gokhale www.dre.vanderbilt.edu. Presented at ISORC 2008 Orlando, FL, USA, May 5-7, 2008.

oki
Download Presentation

CaDAnCE: A Criticality-aware Deployment And Configuration Engine

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 CaDAnCE: A Criticality-aware Deployment And Configuration Engine Gan Deng, Douglas Schmidt & Aniruddha Gokhale www.dre.vanderbilt.edu Presented at ISORC 2008 Orlando, FL, USA, May 5-7, 2008

  2. New Demands on Open Distributed Real-time & Embedded (DRE) Systems … … … … Container Container Middleware Bus Replication Security Persistence Transaction Open Distributed real-time & embedded (DRE) systems • Network-centric & larger-scale “systems of systems” • Dynamic context • Stringent simultaneous QoS demands • e.g., scalability, dependability, throughput

  3. NASA MMS Mission System Case Study C Three Operational String Example B A • Operational String A A mission-critical task that collects important field data when a satellite moves to particular locations • High criticality • Operational String B Domain-centric data analysis based on predefined analysis models • Medium criticality • Operational String C  Collect auxiliary field data occasionally, such as Sun zenith, satellite view zenith (only when requested by B) • Low criticality

  4. Operational String Deployment: OMG D&C Facet Facet Event Sink Event Sink App App App App startLaunch startLaunch install spawn spawn startLaunch • Operational string deployment via Synchronous Method Invocation (SMI) • ExecutionManager (EM) iteratively makes synchronous invocation on each NodeManager (NM) to install components • Each NM propagates component port references back to the EM • DAM dispatches component port object references to NMs for connection establishment, i.e., fulfill dependency requirement between components

  5. Challenge 1: Avoid Deployment Order Inversion • Context • A deployment order is the order in which operational strings are deployed, which is determined by the dependencies between operational strings • Problem • Deployment order inversion happens when a higher criticality operational string has a dependency to a lower criticality operational string • A deployment order inversion can propagate across multiple operational strings due to such dependencies

  6. Challenge 2: Preserve Predictability of Other Operational Strings • Context • The dynamic nature of open DRE systems requires on-demand deployment of a number of operational strings in one request • Each operational strings has certain utility value to the entire DRE system • Problem • While the D&C framework improves the predictability of high-criticality operational strings by minimizing their D&C latencies, it should also preserve the D&C predictability of other operational strings

  7. Our Solution  The CaDAnCE Approach Develop an D&C framework called Criticality-Aware Deployment And Configuration Engine (CaDAnCE) Based on our prior work on DAnCE Step 1  Convert a set of operational strings (based on XML-based deployment descriptors) into a set of directed graphs Step 2  Recompose the graphs based on operational strings criticalities & their dependency relationships by promoting components from one to another Step 3  Convert recomposed graphs back into a new set of in-memory operational strings Benefit: Minimize D&C latency of mission-critical operational strings

  8. Overview of the Recomposition Algorithm in CaDAnCE • Sort & iterate through all the operational strings, from the highest criticality to the lowest • Process all the external dependencies of each operational string sequentially • For each operational string, identify the components causing deployment order inversion by tracing criticality-inverted dependency trace • Remove all external dependencies causing deployment order inversion by promoting components from lower criticality ones to higher criticality ones Component Promoting Component Promoting Removing all criticality-inverted dependencies avoids deployment order inversion

  9. Predictability  Parallel Deployment via AMI/AMH startLaunch App App App App startLaunch install install spawn spawn startLaunch ? • Asynchronous deployment & serializability • Apply Asynchronous Method Invocation (AMI) to take advantage of parallel processing among many nodes • AMI, however, does not provide a mechanism to coordinate different nodes, which is required by D&C for connection establishment • To ensure serializability of D&C process, we combine AMI with Asynchronous Method Handling (AMH)

  10. Empirical Evaluation of CaDAnCE – HW/SW Testbed • Run experiments on a prototype implementation of NASA MMS Mission System • 15 components in a sample operational strings • Experimented with up to 64 operational strings & 960 components in total • Experiments performed in the ISIS Lab • Dual 2.8 GHz Xeon CPUs, 1GB of ram, 40GB HDD, & gigabit ethernet cards • Real-time Fedora Core 4 Linux kernel version 2.6.20-rt8-UNI • Used up to 6 nodes

  11. Effects on Operational String Recomposition Low Medium High • Hypothesis • CaDAnCE should not change the functional correctness while producing correct dependencies between operational strings • Experimental design • The experiments consist of 3 operational strings with criticality level of high, medium, and low, respectively • Before the experiment, 2 arbitrary criticality-inverted external dependencies are populated • Measure the total # of components & # of dependencies (both internal & external) of each operational string before & after applying the CaDAnCE algorithm

  12. Results & Analysis for the Experiment • CaDAnCE reduced the D&C latency of high criticality operational strings significantly (Both w/ AMI/AMH & w/o AMI/AMH) • Without AMI/AMH, the total end-to-end latency of all operational strings increased due to component distribution effect • With AMI/AMH, the total end-to-end latency of all operational strings is almost the same as without CaDAnCE Without AMI/AMH With AMI/AMH CaDAnCE minimizes D&C latency of mission-critical operational strings

  13. D&C Latency vs. Criticality • Hypothesis • CaDAnCE can avoid deployment order inversion when higher criticality operational strings have dependencies on lower criticality operational strings • Experimental design • Two experiments with different operational string configurations • The first experiment has 3 operational strings with low operational string growth effect • Each string has 15 components evenly distributed across 5 nodes • The second experiment has 2 strings with high operational string growth effect (worst case scenario) • Same configuration as above High Growth Effect Low Growth Effect

  14. Results & Analysis for the Second Experiment • The latency of deploying the high criticality operational string is nearly the same as deploying it without applying the CaDAnCE algorithm • However, the D&C latency of low criticality operational string increases & becomes the same as that of high criticality string • Due to the operational string merge effect • In worse case scenario, CaDAnCE performs the same as baseline, i.e., without using CaDAnCE CaDAnCE preserves predictability of lower criticality strings in case of merge

  15. Concluding Remarks • Component middleware has already received widespread acceptance in enterprise business domains • e.g.,J2EE, Web Services • Developers of DRE systems have encountered limitations with the available component middleware platforms • This research applies methodologies & techniques to improve both the human productivity & computing performance of D&C of component-based DRE systems • Our techniques are most relevant with below two component models: • OMG CORBA Component Model • OSOA Service Component Architecture (SCA) Open-source software can be downloaded from www.dre.vanderbilt.edu/CIAO & www.dre.vanderbilt.edu/CoSMIC

  16. Thank You

More Related