1 / 23

AI-Driven Component Deployment in Dynamic Wide-Area Networks

This paper explores a framework for deploying components in wide-area networks using AI planning techniques. It discusses the challenges of maintaining flexible and reusable distributed applications while adapting to dynamic environments. Key concepts include the Component Placement Problem (CPP), the modeling of network nodes and components, and the use of AI planning to find feasible deployment plans. The study highlights the importance of resource constraints and component behavior in achieving an efficient deployment strategy in real-time changing conditions.

fritzi
Download Presentation

AI-Driven Component Deployment in Dynamic Wide-Area Networks

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. Constrained Component Deployment in Wide-Area Networks Using AI Planning Techniques T. Kichkaylo, A. Ivan, V. Karamcheti New York University

  2. Motivation • Component-based frameworks (CORBA, J2EE, .NET) • Distributed applications with reusable components • Static application structure • … but environments change • Dynamic frameworks (Ninja, CANS, Smock) • Different application configurations for adaptiveness • Change of configuration at run time

  3. Example: Mail Application Main components Additional components Network client server encrypt decrypt cache high bw, sec low bw, sec high bw, insec low bw, insec fast secure

  4. Modules of Dynamic Frameworks • Parts of a dynamic component-based framework • Monitor • Trigger • Planner • Deployer • Planner • Purpose: given a description of the environment and available components and goal, find a deployment plan • Set of components • Linkages between them • Placement of the components • Assumption: provided information is correct • Guarantee: if found, the deployment plan is feasible

  5. Component Placement Problem (CPP) • Basic structure of the CPP • Environment = nodes and links • Framework = components and interfaces • Constraints (quantitative and qualitative) • Goal is to place a client component on a given node • Previous work: add restrictions • Chains of components (Conductor, CANS) • Fixed locations (Ninja) • Fixed set of properties (Ninja) • Reality: need to solve the general case • Model • Algorithm

  6. Modeling of the CPP Network • Nodes • Links Framework

  7. > Modeling of the CPP Network • Nodes • Links Framework • Components • Black boxes required interfaces implemented interfaces

  8. > > Modeling of the CPP Network • Nodes • Links Framework • Components • Black boxes • Interfaces (typed data streams) implements (produces) requires (consumes)

  9. > > Modeling of the CPP Network • Nodes • Links Framework • Components • Black boxes • Placed on nodes • Interfaces (typed data streams) • Sent over links • Available on nodes

  10. > > Modeling of the CPP BW Security CPU Trust Network • Nodes • Properties • Links • Properties Framework • Components • Black boxes • Placed on nodes • Interfaces (typed data streams) • Sent over links • Available on nodes • Properties Security BW

  11. Modeling Behavior • Descriptions are application-independent • Components are reusable • Need to reason about behavior of a component in an application • Components: Placement • Required and implemented interfaces • Determines application structure (DAGs) • Conditions • Effects • Properties of implemented interfaces • Change in node properties • Interfaces: Link crossing behavior • Interface at the destination • Change in link properties

  12. <Component> <Name>ViewMailServer <Requires> <Interface>MSI-req <Implements> <Interface>MSI-impl <Conditions> Node.CPU > MSI-req.BW / 100 MSI-req.BW > 10 MSI-req.Secure = True <Effects> Node.CPU -= MSI-req.BW / 100 MSI-impl.BW := MSI-req.BW * 3 MSI-impl.Secure:=True Example of Component Description CPU BW Secure BW Secure MSI-req MSI-imp

  13. Solving the General CPP • The CPP is hard • Need both select a subset of components and place them • Need some sort of search • Too big for exhaustive search • Hundreds of nodes, dozens of component types • AI planning • Another search problem • Find a feasible sequence of operators that brings the system from the initial state to the goal state • State = set of variables • Operator = atomic action changing the state

  14. Solving the General CPP • General CPP can be reduced to AI planning problem • Resource and interface availability are variables • Component placement and link crossing are operators • Existing AI planners cannot be used directly • General AI planning is not very scalable • AI planning has limited support for resources • CPP has more complex resource expressions • Sekitei uses AI techniques to limit search • CPP has simple logical structure

  15. Sekitei • Assumptions • Size of the deployment plan is small compared to the size of the network • All resource functions are monotonic • Properties of implemented interfaces (interfaces at destination) do not appear in formulae • Limit the search • Find all operators relevant for achieving the goal • Among those find possible operators • Propagate resource constraints from the initial state • Use function monotonicity for pruning • Only then perform search in small set of operators structure constraints

  16.  0  0  0  on 0  on 0  on 0 >50 =60 0 1 2 $ 0 $ 0 10 10 10 100 40  on 0  on 0  on 1  on 1  on 1 $ 0 10 10 $ 1 $ 1 01 21 21 21  on 0  on 1  on 1  on 2  on 2  on 2  $ 0 10 $ 1 01 21 21 $ 2 $ 2 12  $  $  on 0  on 1  on 2  on 2  $ Sekitei: Example  Mail Client $ Cache  Mail Interface  Link crossing

  17. Evaluation • Reality: Want a deployment plan within seconds • Planning time can be affected by • Size of the network • Network topology • Structure of the application (bushiness of DAGs) • Number of components in the framework • Size of the plan • Number of logically necessary operators • Number of components added due to resource restrictions

  18. Experiment Setting • Java implementation • Mail application • GA Tech ITM graphs • extended with properties

  19. Scalability of Sekitei • It scales nicely with respect to • Size of the network • Number of components in the framework • Size of the plan (necessary operators)

  20. Scalability of Sekitei (Cont.) • Performance affected by number of components 2 comp, high bw, secure 3 comp, low bw, secure 4 comp, high bw, insecure 5 comp, low bw, insecure

  21. Related Work • Static planners (GARA) • Fixed application structure • Resource constraints • Dynamic component-based frameworks (Ninja, Smock) • Find a feasible deployment plan given constraints • Optimal solution (CANS) • Only for chains of components • Sekitei • The model is expressive enough to support any of the above • Algorithm produces a feasible solution • Minimum number of operators in the plan

  22. Summary • General model for the CPP • Can be used in static and dynamic component-based frameworks • Planning algorithm for the general CPP • Based on AI planning techniques • Scalable • Supports complex resource expressions • Integration • Smock • http://www.cs.nyu.edu/pdsg/ Follow the “Software” tab

  23. THE END

More Related