Group d
Download
1 / 17

Group D - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

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. Aim.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Group D' - anais


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Group d

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


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



System attributes
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


Hierarchical control separation of concerns
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


Control cases
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


E g reliability
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


Group d1

Group D

Decentralized MAPE


Topology patterns
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


Decentralized mape mape c
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


Master slave me c m c ape c 1
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


Regional planner mae n c p
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


Information sharing m c ape
Information sharing- (MCAPE)*

A

P

M

E

A

P

M

E

A

P

M

E

Host

  • +

  • - no coordinated actions

MAPE component

Legend

Coordination


Design space for coordination
Design space for coordination

  • Explicit communication vs. implicit/indirect inference

  • Deterministic vs. Probabilistic

  • ...


Properties
Properties

  • Time to solution/stabilization (messages, rounds, evantually...)

  • Coordination overhead (CPU, overall bandwidth/number of messages)

  • Trust, privacy, ownership, information hiding, ...


Hypotheses
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


Hypotheses1
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


ad