OpenNebula Service Manager
name:
OpenNebula Service Manager
url:
http://dev.opennebula.org/projects/oneservice/wiki
brief description:
OpenNebula component that enables users to control the life-cycle of clustered services easily
type:
tool
license:
Apache
opennebula version:
1.4.x, 2.0.x
author:
Waheed Iqbal, Constantino Vázquez
organization:
organization: dsa-logo.jpg}}
keyword:
service,
control,
VM cluster
last update:
2010-11-16
Description

Clustered services are multi-tier services composed of several interconnected virtual machines. Currently, OpenNebula does not offer a service management component allowing users to deploy and manage their clustered applications. The exact contribution of this tool is to allow users to control the life-cycle of clustered services easily.

This component has been developed in the context of the Google Summer of Code 2010 program.

Benefits

The OpenNebula Service Manager adds the following features to the OpenNebula experience:

  • Management of multi-tier services with atomic operations (submit, shutdown, cancel)
  • Description of service components (VM) interdependencies through a Service Description Language (SDL)
  • Non-intrusive install (no OpenNebula modification required)
  • Graphical representation of services
  • Multiple options for traversing the dependencies graph
  • New command line interface ('oneservice')
Release Notes 0.9

The OpenNebula Service Manager allows users to control the life-cycle of clustered services easily.

This version of 'oneservice' introduces the following features:

  • Client-side DB to store service metadata
  • Introduction of 'oneservice' command line interface
  • Service deployment description through Service Deployment Language
  • Graphic representation of SDL
  • New operations over services: submit, shutdown, cancel, stop, suspend, resume, delete, list, show
Installation and Configuration

In order to install the OpenNebula Service Manager, a working and configured OpenNebula installation must be into place.

Once the above requirement is met, follow the next steps to get the OpenNebula Service Manager installed and configured:

  • Download the source from the git repo

$ git clone git://opennebula.org/one-service.git

  • Run the install.sh command from the 'one-service.git' newly created directory

$ cd one-service.git
$ ./install.sh
OpenNebula Service Manager successfully installed

  • Configure the path to the OpenNebula Service Manager DB in '$HOME/.one/oneservice.conf'
Usage Guide

Introduction

Clustered service are multi-tier services composed of several components/tiers. They can be hosted as a group of interconnected virtual machines in a cloud with specific deployment requirements. The OpenNebula Service Manager is a component that enables end users to deploy and manage the life cycle of their clustered applications. It provides several atomic operations to all components in the application to support the full life cycle management of the application. OpenNebula Service Manager provides the following operations/actions:

  • submit: deploy a clustered application defined in the Service Description Language (SDL) template
  • shutdown: shutdown all the components of the given service
  • cancel: cancel all the components of the given service
  • stop: stop all the components of the given service
  • suspend: suspend all the components of the given service
  • resume: resume all the components of the given service
  • delete: permanently delete a given service and all its components from the system
  • list: provide details about all services
  • show: provide detail about the given service

Service Description Language (SDL)

Service Description Language (SDL) is used to define the service template that allows users to define application components, deployment requirements/dependencies and strategies for the life cycle of clustered application.

Following is a sample example of SDL with comments: 

##########################################################################
#General description about the service.
#Syntax: TITLE <TITLE_FOR_THE_SERVICE>
#  Example: TITLE “sge cluster”
##########################################################################
TITLE “An example of a clustered application”

##########################################################################
#Describe definition of each distinct component/virtual machine in the service. 
#Syntax: COMPONENT <UNIQUE_COMPONENT_NAME> <COMPONENT_TEMPLATE> <CARDINALITY>
#  Example: COMPONENT master master.template 2
#########################################################################
COMPONENT sge_master1 /opt/cloud/one/share/examples/sge_master1.one 1
COMPONENT sge_node1 /opt/cloud/one/share/examples/sge_node1.one 1
COMPONENT sge_node2 /opt/cloud/one/share/examples/sge_node1.one 1


#############################################################################
#Define dependencies if a harder synchronization is needed, i.e. do not submit 
#children until parent reaches RUNNING
#Syntax: PARENT <LIST OF COMPONENTS> CHILD <LIST OF COMPONENTS>
#  Example: PARENT master1, master2 CHILD node1, node2
#############################################################################
PARENT sge_master1 CHILD sge_node1, sge_node2


#############################################################################
#Define deployment order, if you need a soft synchronization point, e.g. to #instantiate IPs correctly.
#Syntax: DEPLOY <STRATEGY> <LIST OF COMPONENTS> where STRATEGY could be STRAIGHT, #REVERSE, or DONOTCARE.
#  Example: DEPLOY REVERSE master, node
#############################################################################
DEPLOY STRAIGHT sge_master1, sge_node1

#############################################################################
#Optionally, we can override the default strategies of actions (SHUTDOWN, CANCEL, RESUME, SUSPEND, #STOP, and DELETE) 
#Example: 
#SHUTDOWN DONOTCARE
#SUSPEND REVERSE		
#CANCEL REVERSE 
#RESUME REVERSE 
#STOP DONOTCARE
#DELETE STRAIGHT
#############################################################################

The following figure shows the PARENT-CHILD relations of components defined in the SDL:

Strategies for actions

SDL allows us to define STRAIGHT, REVERSE, and DONOTCARE strategies for deploy, shutdown, stop, resume, cancel, and delete. The following provides explanation about the strategies :

  • STRAIGHT: Do not perform the action being modified by this strategy until all the parents reach to the given state. For instance, a simple example of STRAIGHT strategy is used for the DEPLOY action in the SDL given above. OpenNebula Service Manager will not deploy sge_node1 and sge_node2 until sge_master1 reaches to the RUNNING state.
  • REVERSE: Do not perform the action being modified by this strategy until all children reach to the required state. For instance if we use “DEPLOY REVERSE sge_master1” in the above mentioned SDL, OpenNebula Service Manager will not start deploying sge_master1 until sge_node1 and sge_node2 do not reach the RUNNING state.
  • DONOTCARE: Do not pay attention to the PARENT-CHILD relationship. For instance, if we use “DEPLOY DONOTCARE sge_node1, sge_node2” in the above mentioned SDL, OpenNebula Service Manager will deploy sge_node1 and sge_node2 without deploying first their children or parents.)

Default Strategies for action

In SDL you must have to define DEPLOY action while other actions are optional to define. If the user does not define other actions, OpenNebula Service Manager will use the following default strategies to perform them:

  • SHUTDOWN REVERSE (It is a reverse of the DEPLOY)
  • SUSPEND REVERSE (It is a reverse of the DEPLOY)
  • CANCEL REVERSE (It is a reverse of the DEPLOY)
  • RESUME STRAIGHT (It is same as the DEPLOY)
  • STOP REVERSE (It is a reverse of the DEPLOY)
  • DELETE REVERSE (It is a reverse of the DEPLOY)

:!: “reverse of the DEPLOY” means the action will uses the reverse order of components to perform. For instance, if a service is deploying component c1, c2, and c3 in a sequence then reverse of it will be c3, c2, and c1. If DEPLOY uses DONOTCARE strategy than all other actions will also use DONOTCARE strategy as a default.

State Transitions

OpenNebula Service Manager has six possible states (running, stop, suspend, shutdown, cancel, and delete) for the managed services. The following figure shows the possible state transitions:

Usage

Assuming that the SDL template mentioned above is already saved in a file named example.sdl:

Submit (deploy) a service

$ oneservice submit example.sdl 
Service ID: 2   Action to perform: DEPLOY       Strategy: STRAIGHT 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: pend 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: pend 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: pend 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: runn 
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: pend 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: pend
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: pend 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: pend
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: pend 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: pend
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: runn 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: runn

List down all services

$ oneservice list 
ID	    TITLE                                      STATE   
2       “An example of a clustered application”      RUNNING

Obtain details about a service

$ oneservice show 2 
SERVICE INFORMATION  
-------------------                                        
ID             : 2                                       
TITLE          : “An example of a clustered application” 
STATE          : RUNNING                                 
SERVICE COMPONENTS INFORMATION
------------------------------                                                  
VM_ID      VM_Name        VM_STATE            
1339       sge_m1               	runn                
1340       sge_n1               	runn                              
1341       sge_n2               	runn   
SERVICE DESCRIPTION TEMPLATE   
----------------------------                                     
##########################################################################
#General description about the service.
#Syntax: TITLE <TITLE_FOR_THE_SERVICE>
#  Example: TITLE “sge cluster”
##########################################################################
TITLE “An example of a clustered application”

##########################################################################
#Describe definition of each distinct component/virtual machine in the service. 
#Syntax: COMPONENT <UNIQUE_COMPONENT_NAME> <COMPONENT_TEMPLATE> <CARDINALITY=1>
#  Example: COMPONENT master master.template 2
#########################################################################
COMPONENT sge_master1 /opt/cloud/one/share/examples/sge_master1.one 1
COMPONENT sge_node1 /opt/cloud/one/share/examples/sge_node1.one 1
COMPONENT sge_node2 /opt/cloud/one/share/examples/sge_node1.one 1


#############################################################################
#Define dependencies if a harder synchronization is needed, i.e. do not submit 
#children until parent reaches RUNNING
#Syntax: PARENT <LIST OF COMPONENTS> CHILD <LIST OF COMPONENTS>
#  Example: PARENT master1, master2 CHILD node1, node2
#############################################################################
PARENT sge_master1 CHILD sge_node1, sge_node2


#############################################################################
#Define deployment order, if you need a soft synchronization point, e.g. to #instantiate IPs correctly.
#Syntax: DEPLOY <STRATEGY> <LIST OF COMPONENTS> where STRATEGY could be STRAIGHT, #REVERSE, or DONOTCARE.
#  Example: DEPLOY REVERSE master, node
#############################################################################
DEPLOY STRAIGHT sge_master1, sge_node1

#############################################################################
#Optionally, we can override the default strategies of actions (SHUTDOWN, CANCEL, RESUME, SUSPEND, #STOP, and DELETE) 
#Example: 
#SHUTDOWN DONOTCARE
#SUSPEND REVERSE		
#CANCEL REVERSE 
#RESUME REVERSE 
#STOP DONOTCARE
#DELETE STRAIGHT
#############################################################################

Stop a service

$ oneservice stop 2 
Service ID: 2	Action to perform: STOP	Strategy: REVERSE 
VM_Name: sge_n2  VM_Id: 1340 ...................... VM_Status: epil 
VM_Name: sge_n1  VM_Id: 1341 ...................... VM_Status: epil
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: stop 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: stop 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: save 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: epil 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: stop

Resume a service

$ oneservice resume 2
Service ID: 2	Action to perform: RESUME	Strategy: STRAIGHT 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: pend 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: pend 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: pend 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: runn 
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: pend 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: pend 
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: pend 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: pend 
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: runn 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: runn

Suspend a service

$ oneservice stop 2 
Service ID: 2	Action to perform: SUSPEND	Strategy: REVERSE 
VM_Name: sge_n2  VM_Id: 1340 ...................... VM_Status: save 
VM_Name: sge_n1  VM_Id: 1341 ...................... VM_Status: save
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: susp 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: susp 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: runn
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: save 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: stop

Shutdown a service

Before issuing the following command make sure that the service is in running state. 

$ oneservice stop 2 
Service ID: 2	Action to perform: SHUTDOWN	Strategy: REVERSE 
VM_Name: sge_n2  VM_Id: 1340 ...................... VM_Status: shut 
VM_Name: sge_n1  VM_Id: 1341 ...................... VM_Status: shut
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: epil 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: epil
VM_Name: sge_n1  VM_Id: 1340 ...................... VM_Status: done 
VM_Name: sge_n2  VM_Id: 1341 ...................... VM_Status: done 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: shut
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: epil 
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: done

Delete a service

$ oneservice delete 2 
Service ID: 2	Action to perform: DELETE	Strategy: REVERSE 
VM_Name: sge_n2  VM_Id: 1340 ...................... VM_Status: done 
VM_Name: sge_n1  VM_Id: 1341 ...................... VM_Status: done
VM_Name: sge_m1  VM_Id: 1339 ...................... VM_Status: done

Additional Documentation

All the contents are licensed under Creative Commons Attribution-NonCommercial-ShareAlike License
Copyright 2002-2012 © OpenNebula Project Leads (OpenNebula.org). All Rights Reserved.
Please send comments to webmaster. Legal Notice. This site is hosted by C12G Labs.