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): , 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): , Dec 06

Autonomic Computing: Overview SELF-MANAGEMENT SELF-CONFIGURING SELF-OPTIMIZINGSELF-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) Management Service Repository Client 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) Management Client

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

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 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 Management Front- End Service Repository Status of running services List of available services Service s Client Connects Accesses Connects Routes/NATs connections to Updates Copies and manages the service Sets and removes routing/NAT Hosts Stores Start/Stop services Details of our implementation Gateway Informs

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.