Dependability Issues in an Autonomic Computing Environment

1
Dependability Issues in an Autonomic Computing
Environment

• Jie Xu
• Department of Computer Science
• University of Durham

2
Issues to Consider

• What is Autonomic Computing?
• What are research challenges?
• Why fault tolerance dependability?
• Community Registry
• Event-Driven Solutions
• Consensus among Neighbours
• Ontological Meta-Data

3
Autonomic Computing

• (IBMs definition) An approach to self-managed
  computing
• systems with a minimum of human interference.
• (The term derives from the body's autonomic
  nervous system, which controls key functions
  without conscious awareness or involvement.)
• Fully distributed over networks
• Large-scale cooperation/collaboration over
  computing elements
• No centralised management mechanism(s)
• Boundary-less
• Rapid and concurrent evolution

4
Research Challenges

• System identity - how to define system boundaries
  in a dynamic environment
• Interface design - consistent interfaces for a
  heterogeneous environment
• Human interfaces translating business policy into
  IT policy?
• System architecture - unite autonomic components
  into a federated system
• Adaptive mechanisms/algorithms to deal with
  changing environments and/or faults and/or attacks

5
Fault Tolerance Dependability
Dependability reliability attributes
flexibility attributes
(e.g. high availability (e.g. environmental
fault tolerance
and security etc.) and adaptability
etc.)

• Large scales lead to poor system reliability and
  security
• Large amount of resources facilitate the
  provision of fault tolerance
• Full distribution increases the difficulty in
  managing and controlling redundancy for fault
  tolerance
• Dependability must cover the adaptability (or
  flexibility) attribute to cope with ever-changing
  system environments

6
Community Registry

• Community registry can become a single point of
  failure - a service provider needs to register
  itself to several different registries
• Community registry itself must be somehow
  fault-tolerant (e.g. replication plus voting)
• What about a faulty service provider?
• How to detect the fault? Who informs whom? Mobile
  agents?
• Alternative service provider(s)? How to decide
  the similar functionalities? Ontology plus
  meta-data?

7
Event-Driven Solutions

• How could a faulty service provider notify
  correctly its abnormality to registry and/or
  other services?
• Time-out?
• Fault-tolerant communication facility plus a
  robust exception handling core within each
  service provider?
• Cant trust the information from a faulty
  provider? Then fault tolerance must be used
• A majority of the neighbours of the faulty
  provider may be able to develop a consensus as to
  the status of the faulty provider

8
Group Communications

• Distributed system-level fault diagnosis
• Coordinated atomic actions
• Replication of group members with voting
• Design diversity for coping with software faults
• Need a fully distributed solution for monitoring
  and management
• Then communication costs
• Mobile agents again?

9
Ontological Meta-Data

• Redundancy of service provision?
• Redundant components or service providers
• Similar funcitionalities
• How to judge?
• Definition of a commonly accepted ontology
• Attach additional ontological meta-data to a
  standard interface specification (or interface
  document)
• Need a new mechanism for inspecting meta-data to
  decide whether a service is equivalent to another