Automating service management

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

2. Content • Autonomic computing • Self-management • Concept • Architectural issues • Our prototype • Architecture • Basic functionality

3. Autonomic computing – some ideas ”Systems with selfware capabilities can automatically adapt their behavior in relation to the configuration of the drastically changing environment and their user preferences.” 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.” Dobson et.al.: A Survey of Autonomic Communications. ACM Tr. On Autonomous and Adaptive Systems 1(2):223-259, Dec 06

4. Eight Goals for an Autonomic System • System must know itself • System must be able to reconfigure itself within its operational environment • System must pre-emptively optimise itself • System must detect and respond to its own faults as they develop • System must detect and respond to intrusions and attacks • System must know its context of use • System must live in an open, heterogeneous, world • System must actively shrink the gap between user/business goals and IT solutions

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

6. SELF-MANAGEMENT SELF-ADAPTIVE SELF-CONFIGURING SELF-OPTIMIZING SELF-PROTECTING SELF-HEALING SELF-ORGANIZING Autonomic Computing: Overview Autonomic Computing Initiative by IBM, 2001

7. 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 Self-* properties (selfware)

8. Content • Autonomic computing • Self-management • Concept • Architectural issues • Our prototype • Architecture • Basic functionality

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

10. Three Layer Architecture Model for Self-Management Kramer & Gomaa: Self-Managed Systems: an Architectural Challenge. In Future of Software Engineering (FOSE’07), 2005.

11. 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.

12. Software reconfiguration: states of a component Gomaa & Hussein: Model-based Software Design and Adaptation. In SEAMS’07.

13. Content • Autonomic computing • Self-management • Concept • Architectural issues • Our prototype • Architecture • Basic functionality

14. Serving node Serving node ... Serving node ... Our prototype: Architecture • Client has one main connection point • Service nodes can be located anywhere • Services can be running on (almost) any service node Access Point (gateway) Client Management Service Repository

15. 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.

16. 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) Management Client

17. Management functions • Service deployment • Based on client request • Choose the ’most suitable’ node • The one closed to the client • The one with least load or running services • Other 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

18. Serving node Serving node ... Serving node ... 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 Management Service Repository

19. 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.

20. Details of our implementation Client Gateway Serving node Routes/NATs connections to Hosts Connects Sets and removes routing/NAT Services Connects Front-End Status of running services Informs Copies and manages the service Updates Management List of available services Stores Accesses Service Repository Start/Stop services

21. 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.