Group D

1. Group D From Centralized to Decentralized Control in Self-Adaptation Danny Weyns, Schahram Dustdar, Holger Giese, Karl Göschka, Vincenzo Grassi, Jeff Kramer, Sam Malek, Raffeala Mirandola, Christian Prehofer, Rick Schlichting, Bradley Schmerl, Jochen Wuttke

2. Aim • Push on different design spaces for multiple control loop designs • Hierarchical vs. peer-to-peer vs. combinations • Still have system-wide goals that need to be met

3. Motivating Example

4. System attributes • Assumptions of existing system: • Data center are hierarchically arranged • Could be intermediate hierarchical entities like company, country • Higher up the level of system hierarchy, the larger the communication latency

5. Hierarchical Control: Separation of Concerns • Separate how to deal with certain SA concerns (goals, phenomena) • Resources • Managing a rack • Concerns • Performance and power consumption • Hard to make orthogonal • Benefits: • Can choose architecture for each concern independently • Simpler optimization problems • Drawbacks: • Reconciliation of control at upper levels • Less optimal solution

6. Control Cases (a) (b) cl • Information filtered up • Actions issued and refined at lower level • Control loop closed at the top • Filtering aids scalability • Affects quality/speed of decision • Refinement may be hard • Control loops at all levels • Lower levels can react while passing information on • Passing decisions and information up • Goals (not actions) set on lower control groups • Issues • Each control level needs to different time scales, and different levels resources • Ensure benefits of changes are met • Stability, if they work against each other Refine Filter cl cl

7. E.g., Reliability • Failures need to be handled quickly • (a) this might be a problem, depending on controller speed • (b) deal with failure in lower control loops • Fast local fix, optimized over time in higher control Actuator Safety switch Safety switch Actuator

8. Group D Decentralized MAPE

9. Topology patterns • Each MAPE components can be local only, decentralized, or be a central singleton • MAPE components can be interconnected to same component type or successive component type • (Partial) trees can be constructed as well

10. Decentralized MAPE - (MAPE)C* A P M E A P M E A P M E Host • + support for multiple ownership • probably overkill for single owner MAPE component Legend Coordination

11. Master/Slave - (ME)*C (MCAPEC )1 A P M E M E M E Host • + fast and simple • - multiple ownership, scalability MAPE component Legend Coordination

12. Regional Planner - (MAE)*nC(P) P P A A A A M E M E M E M E • + scalable • - MAPE component Host Legend Interaction Coordination

13. Information sharing- (MCAPE)* A P M E A P M E A P M E Host • + • - no coordinated actions MAPE component Legend Coordination

14. Design space for coordination • Explicit communication vs. implicit/indirect inference • Deterministic vs. Probabilistic • ...

15. Properties • Time to solution/stabilization (messages, rounds, evantually...) • Coordination overhead (CPU, overall bandwidth/number of messages) • Trust, privacy, ownership, information hiding, ...

16. Hypotheses • Architecture of managed system constrains architecture of management system • E.g., hierarchical management requires a hierarchical system • Changes in scale require changes in hierarchical control scheme • More aggressive filtering may be required, which will affect control quality

17. Hypotheses • If there are good opportunities for filtering, adaptation decision and decision refinement, then centralized solutions can scale • Collection scales, and refinement scales • Hierarchies slow down the reaction time • at the higher levels