Automating service management Tiina Niklander Faculty of Science Department of Computer Science In AMICT 2008 Petrozavodsk, May 2008.

Automating service management

Tiina Niklander

Faculty of Science

Department of Computer Science

In AMICT 2008

Petrozavodsk, May 2008

Content

Autonomic computing Self-management

Concept Architectural issues

Our prototype Architecture Basic functionality

Autonomic computing – some ideas

Dobson et.al.: A Survey of Autonomic Communications. ACM Tr. On Autonomous and Adaptive Systems 1(2):223-259, Dec 06

Patouni & Alonistioti.: A Framework for the Deployment of Self-Managing and Self-configuring Components in Autonomic Environments. In WoWMoM’06.

”In principle, an adaptive system may be

significantly less variable to a user’s eyes than a

traditional nonadaptive system.”

”Systems with selfware capabilities can

automatically adapt their behavior in relation to

the configuration of the drastically changing

environment and their user preferences.”

Eight Goals for an Autonomic System

1. System must know itself

2. System must be able to reconfigure itself within its

operational environment

3. System must pre-emptively optimise itself

4. System must detect and respond to its own faults as

they develop

5. System must detect and respond to intrusions and

attacks

6. System must know its context of use

7. System must live in an open, heterogeneous, world

8. System must actively shrink the gap between

user/business goals and IT solutions

Autonomic control loop

Dobson et.al.: A Survey of Autonomic Communications. ACM Tr. On Autonomous and Adaptive Systems 1(2):223-259, Dec 06

Autonomic Computing: Overview

SELF-MANAGEMENT

SELF-CONFIGURING

SELF-OPTIMIZING SELF-PROTECTING

SELF-ADAPTIVE

SELF-HEALING SELF-ORGANIZING

Autonomic Computing Initiative by IBM, 2001

Self-* properties (selfware)

Self-configuring

Self-healing

Self-optimising

Self-protecting

Self-aware

Self-monitor

Self-adjust

Self-adaptive

Self-governing

Self-managed

Self-controlling

Self-repairing

Self-organising

Self-evolving

Self-reconfiguration

Self-maintenance

Content




Self-management

Salehie & Tahvildari: Autonomic Computing: Emerging Trends and Open Problems. ACM workshop DEAS, 2005

Three Layer Architecture Model for Self-Management

Kramer & Gomaa: Self-Managed Systems: an Architectural Challenge. In Future of Software Engineering (FOSE’07), 2005.

Autonomic Manager Framework

Generic framework for:

Automatic deployment

of a service

Dynamic, automatic

binding

Dynamic replacement

of a component

Patouni & Alonistioti.: A Framework for the Deployment of Self-Managing and Self-configuring Components in Autonomic Environments. In WoWMoM’06.

Software reconfiguration: states of a component

Gomaa & Hussein: Model-based Software Design and Adaptation. In SEAMS’07.

Content




Our prototype: Architecture

Access Point

(gateway)

Access Point

(gateway)

ManagementManagement

Service Repository

Client

Serving node

Serving node

Serving node

Serving node

Serving node

Serving node

...

...

Client has one main

connection point

Service nodes can be

located anywhere

Services can be

running on (almost)

any service node

Think about the client

Hide difficulties of accessing

a service from clients by

moving access point to a

convenient location.

Hide complexity of

underlying networks with an

overlay network. Services

are given an illusion of being

directly connected to same

subnet as the associated

access point.

Access point

The only visible address to the client Front-end for the initial client connections

List of available services Activation of the service after the selection

Gateway for the service usage Forwads the client messages to the actual service

node and vise versa Can show client status information about service

Access Point

(gateway)

Access Point

(gateway)ManagementManagementClient

Management functions

Service deployment Based on client request Choose the ’most suitable’ node

The one closed to the clientThe one with least load or running servicesOther cost issues

Normal monitoring features for maintenance and possible

self-healing or reconfiguration. Monitor the node status Monitor the service status Alarm maintenance staff when needed, or

run self-diagnosing and do some healing if possible

Services

Prefixed set of services (at the moment) Idea: Any program that client might want Each service in its own virtual machine Moved from repository to the serving node at the latest

during the client request Can be precopied to certain nodes


Service Repository

Serving node

Serving node

Serving node

Serving node

Serving node

Serving node

...

...

Virtualization

Each service in its own virtual machine Services are separated from each other

Virtual machines are easy to deploy, but need to have the

same virtual machine monitor on the nodes.

Services can be migrated even on-line, if the environment

support migration of virtual machines.

Virtual machine with service is larger than just the service,

more copying needed.

Serving node

Serving node


Front-EndFront-End

Service Repository

Status of running services

List of available services

Services

Client

Conn

ects

Accesses

Connects

Routes/NATsconnections to

UpdatesCopies and managesthe service

Sets and removesrouting/NAT

Hosts

Stores

Start/Stop services

Details of our implementation

GatewayGateway

Info

rms

Conclusion

Self-management will come. There is need and a lot of

research in that area. Context-awareness, adaptability, reconfigurability Name can be different!

Lessons from our prototype: Virtualisation makes the service management easier

(hides the heterogenous hardware). Gateway makes it possible to hide internal service

addresses from the client. Automating management will need a decision

mechanism on the management node.

Automating service management Tiina Niklander Faculty of Science Department of Computer Science In AMICT 2008 Petrozavodsk, May 2008.

Documents