automating service management tiina niklander faculty of science department of computer science in...
TRANSCRIPT
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
Autonomic computing Self-management
Concept Architectural issues
Our prototype Architecture Basic functionality
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
Autonomic computing Self-management
Concept Architectural issues
Our prototype Architecture Basic functionality
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
ManagementManagement
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
ManagementManagement
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.