1 / 21

Automating service management

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.

talmai
Download Presentation

Automating service management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related