Toward R E D U B I N Broad-Spectrum Autonomic Management - - PowerPoint PPT Presentation

toward
SMART_READER_LITE
LIVE PREVIEW

Toward R E D U B I N Broad-Spectrum Autonomic Management - - PowerPoint PPT Presentation

I V N E U R S E I T H Y T O H F G Toward R E D U B I N Broad-Spectrum Autonomic Management Edmund Smith <edmund.smith@stir.ac.uk> Paul Anderson <dcspaul@inf.ed.ac.uk> ICN 2007, April 2007 Overview


slide-1
SLIDE 1

Toward Broad-Spectrum Autonomic Management

Edmund Smith <edmund.smith@stir.ac.uk> Paul Anderson <dcspaul@inf.ed.ac.uk>

ICN 2007, April 2007

T H E U N I V E R S I T Y O F E D I N B U R G H

slide-2
SLIDE 2

Overview

  • Background
  • “system configuration” & “autonomics”
  • a comparison & a practical illustration
  • The problem
  • most practical “fabrics” require elements of both
  • this means that there is usually no clear declarative

specification for the fabric configuration

  • A proposed approach
  • a integrated multi-resolution framework
  • further research
slide-3
SLIDE 3

System Configuration

Configuration

Hardware “Fabric” performing according to specification Software Specifications& Policies Convergence

slide-4
SLIDE 4

System Configuration

  • Starting with:
  • several hundred new machines with empty disks
  • a repository of all the necessary software packages
  • a specification of the required service
  • Load the software and configure the machines to

provide the service

  • This involves many internal services:
  • DNS, LDAP, DHCP, NFS, NIS, SMTP,

Web …

  • the relationships are most important
  • Maintain the specification when things change
  • either the requirements, or the system (failures)
slide-5
SLIDE 5

Autonomics

  • Autonomic computer systems are ones which:

“Maintain and adjust their operation in the face of changing workloads, demands, and external conditions, and in the face of hardware or software failures of innocent, or malicious origin.” J Kephart

slide-6
SLIDE 6

Autonomics

  • Autonomic operations can occur at any level in

the configuration “stack” -

  • recreate a corrupt configuration file on one host
  • restart a failed daemon on one host
  • redeploy a service to another host when a host fails
  • configure extra hosts into a cluster when the overall

load increases

  • Autonomics can be thought of as the automation
  • f the entire system configuration process
slide-7
SLIDE 7

A comparison

  • The fields of Autonomics and System Configuration

have evolved in separate communities with a different emphasis -

  • System configuration provides ways of specifying

and managing the configuration of an infrastructure, and “low-level” autonomics

  • Autonomics provide solutions to “high-level”

automation, such as service migration

  • Current practical installations use elements of

both

slide-8
SLIDE 8

An example

  • A high-level autonomic process may determine

which nodes are to be used to provide the elements of a web-service - web front-end, database etc.

  • this will handle service migration and

reconfiguration in response to load or failures

  • Lower-level system configuration tools support

(re-)configuration of the underlying infrastructure

  • DNS, Kerberos, firewall holes, backups, etc.
slide-9
SLIDE 9

The problem

  • Modern system configuration tools allow the

fabric configuration to be maintained from an explicit declarative specification.

  • This is important -
  • we can reason about the configuration - eg. for

security verification

  • we can compose multiple aspects
  • If the configuration is manipulated by a separate

autonomic layer, then the overall declarative specification is usually lost

slide-10
SLIDE 10

An example - LCFG

compiler 1 2 3 client 4 3 client 4 3 client 4

slide-11
SLIDE 11

What do we need?

  • A model which supports a uniform configuration

process at all levels

  • Manual and autonomic elements of the

specification must be integrated so that it is possible to reason across the whole system

  • for example, about authorisation
  • Autonomic components must generate

configurations which are governed by declarative constraints

  • “loose” specifications
slide-12
SLIDE 12

A multi-resolution framework

Nodes Aspects Services Service classes Installation Autonomics Team 1 Team 2 Bindings: Specifications: c b d f a e

slide-13
SLIDE 13

Further research

  • Specification languages -
  • constraints (mcfg)
  • aspect composition (mcfg)
  • authorisation (cfgas)
  • multi-resolution specifications
  • Deployment
  • distributed evaluation
  • deployment sequencing
slide-14
SLIDE 14

Some Links

  • Slides:

http://homepages.inf.ed.ac.uk/dcspaul/publications/icn2007-slides.pdf

  • Paper:

http://homepages.inf.ed.ac.uk/dcspaul/publications/icn2007.pdf

  • Paul Anderson

http://homepages.inf.ed.ac.uk/dcspaul <dcspaul@inf.ed.ac.uk>

  • LISA, Large installation System Administration Conference

November 11th-16th 2007, Dallas http://www.usenix.org/events/lisa07/

T H E U N I V E R S I T Y O F E D I N B U R G H