Reliable Architecture Ved Henrik Bærbak Christensen Autonomic Computing And Self Managed Architectures Emne: self star overview 11 december 2009.

Præsentationer af emnet: "Reliable Architecture Ved Henrik Bærbak Christensen Autonomic Computing And Self Managed Architectures Emne: self star overview 11 december 2009."— Præsentationens transcript:

1 Reliable Architecture Ved Henrik Bærbak Christensen Autonomic Computing And Self Managed Architectures Emne: self star overview 11 december 2009

2 Opgave Beskrivelse

3 Name aspects of self-management and describe how they are generally handled today and how an autonomic computing system would handle them. Aspekter (s. 43 Kephart/chess): high level policies, business objectives Selv konfiguration: selv integration, selv registrering, hvad ikke hvordan Selv optimering: monitorere, eksperimentere og justere, lære at vælge rigtige parametre ud fra kontekst (cost, performance) self healing: detektere, diagnosticere, reparere lokale problemer self protection: beskyttelse mod indtrængen, være opmærksom på ikke at blive en del af masse-fejl i andre delsystemer, forudse fejl vha. monitoring/analyse

4 In Kephart and Chess (2003) an overview of an architecture for autonomic computing is sketched in fig 2. Explain the dynamics of such a system: which behavioral units are activated and how in situations like a)crashes of a software unit b)security breaches c)defects detected in software units? Monitoring, analyse, plan (forsøge at finde alternativ service, der opfylder kravene)

5 In Kephart and Chess (2003) fig 2, an informal notation is used. How would this proposal look using the component-connector view and deployment view proposed by Christensen et al.? Autonomic manager Managed element (flere) Autonomic element Manager

6 How does the architectural drawing correlate to the architectural description given by White et al. (2004)? Kephart Autonomic manager: Analyzer Plan Monitor Knowledge Execute Managed / autonomic element White Policies (behaivor and constraints) Monitoring and test interface Lifecycle interface Policy interface Nogotiation and binding interface Infrastruktur: registry, sentinel, aggregator, broker negotiator

7 Outline the architectural requirements to autonomic elements as defined by White et al. (2004)? Selv managed (konfigurering, healing, optimering, beskyttelse) I stand til at etablere og vedligeholde relationer til andre autonome elementer Kontrollere opførsel og opfylde sine forpligtelser

8 What software engineering challenges do Kephart and Chess (2003) state as important for autonomic computing? Lifecycle Design, test, verifikation Installation/konfiguration Overvågning og problemløsning Opgradering Styring (Schedule / prioritering) Relationships Specifikation Lokalisering af services og blive lokaliseret Protokoller (negotiation) Provision(udbyde eller tilbyde service, ressource) Operation afslutning Systemwide sikkerhed, beskyttelse af data være underlagt sikkerhedspolitikker robuste mod angreb indefra Mål Specifikation sprog sikre at spec er korrekt, konsistent, realiserbar osv.

9 Concerning the engineering challenges, discuss how these can be supported or aided by - Agent technology (review the Sundsted article, or perhaps reference 4 (Jennings) in Kephart-Chess) - Web services - Virtualization techniques - Technologies like SOA (service-oriented architecture), Jini, CORBA, Java RMI,.NET or others you may know Lifecycle Overvågning: Agent (autonomic, mål orienteret, simple applikation ikke komplet applikation): Relationships Jini: : -block the notion of allocation and deallocation of resources -location-independence of services - Service Registry - Broker - Agenter kan varetage registry services, dermed haves ikke et centralt registry men flere distribuerede registrys

10 Relate the self-healing design patterns, especially self-regenerating cluster, in White et al. to the tactics of fault tolerance Introduced earlier in the course. Self-generation klusters Design pattern for self-healing: Formål: Undgå single point of failure, Koncept: kluster 2 eller flere instanser af en specifik type af autonomic element, således at de deler input services og svarer på forepørgsler på output services vha. ‘spraying teknikker’. Desuden kan elementer i et kluster overvåge hinanden, således, at hvis et element fejler, så kan et af resterende elementer genererer eller finde et nyt element af samme type og binde det i kluster og dermed samle kluster igen Fault tolerance relation: taktikker: Lyu og recovery blocks og N-programming Koncept: vha. en adjudicator vurdere resultatet af komponenternes resultater: Kluster: N-version komponenter eller recovery blocks