Monitoring and Reconfiguration for OCCI Resources

Mohamed Mohamed, Djamel Belaıd and Samir TataInstitut Mines-Telecom, Telecom SudParis, UMR CNRS Samovar

9 rue Charles Fourier 91011 EVRY Cedex, FranceEmail: {firstName.lastName}@mines-telecom.fr

Abstract—The OCCI Monitoring and Reconfiguration exten-sion for the resource monitoring and reconfiguration infrastruc-ture describes the needed elements to monitor and reconfigurecloud resources on demand. The definition entails the introductionof new Resources, Links and Mix-ins. On the one hand, we definedthe needed resources that generate metrics to be monitored froman SLA. On the other hand, we added new resources to monitorthe generated metrics and to reconfigure resources when needed.The newly added entities are defined as generic Kinds, that arespecialized using OCCI Mix-ins. Using these elements, the user isprovided with a monitoring and reconfiguration infrastructure ondemand. We define herein, the HTTP rendering used to establishand link the described infrastructure.

I. INTRODUCTION

Cloud Computing is a challenging area involving differentaspects of IT (Information Technologies) services. Its adoptionis increasing due its economic model based on pay-as-you-gomodel. A survey conducted by Mckinsey Quarterly in 2010shows that 68% of the companies in this survey are currentlyadopting the Cloud and 83% are planning to do in the next 18months. Many aspects related to Cloud Computing are wellexplored. Meanwhile, monitoring and reconfiguration did notget the needed attention in research works. In fact, Cloudresources are exposed to dynamic evolution during their life-cycle. This evolution is due to the environment dynamic. Tocope with this evolution, a monitoring and reconfigurationinfrastructure must be offered by the cloud provider. Thisinfrastructure has to enable dynamic reconfiguration of cloudresources with a minimal cost and a minimal performancedegradation.

Almost all of the existing cloud computing projects sup-pose that monitoring is used just to gather Key PerformanceIndicator (KPI) for billing or to notify the interested clientof eventual problems. They also consider that reconfigurationconsists of a new deployment of resources. Therefore, recon-figuration is as expensive as new deployment. Furthermore,the type of the applied reconfiguration leads to service inter-ruptions and degradation of all the system. The few othersworks concerning monitoring and reconfiguration cope justwith specific use cases. Thus, they can not respond to thedynamic of the cloud in different situation. In this paper, wepropose an on-demand monitoring and reconfiguration infras-tructure based on Open Cloud Computing Interface (OCCI)standard. This infrastructure is based on new OCCI Entities(i.e. Resources and Links) and Mix-ins. Our aim is to addmonitoring and reconfiguration facilities to OCCI resourcesindependently of the level (XaaS). In order to add monitoringand reconfiguration facilities to a resource, we propose toadd a Mix-in that has a twofold functionality. The first is toextract monitoring data from the concerned resource while the

second is to enable reconfigurations on it. We defined alsoanother Mix-in responsible of handling subscriptions and ofsending monitoring notifications to subscribers. The rest ofthe infrastructure consumes monitoring data using these latterMix-ins in order to analyze it and generate reconfigurationactions. To automatize the infrastructure establishment, wedefine a generic Autonomic Manager Resource that inspectsa Service Level Agreement (SLA) to enable monitoring onspecific metrics. Accordingly, this resource instantiate all theneeded Resources and Links. Eventually, the established in-frastructure needs some Mix-ins for specific processing.

The purpose of this paper is to provide a generic infras-tructure that allows monitoring and reconfiguration of cloudresources with a minimal cost and minimal resources outage.Therefore, the remainder of this paper is organized as follows.In Section II we define monitoring, reconfiguration and give anoverview on OCCI. Section III is the core of our proposition,and it introduces the different OCCI Entities and Mix-ins thatwe use. Then, we chain up with a HTTP API that allows themanipulation of the here proposed monitoring and reconfig-uration infrastructure. To give more details, we propose anexample that gives more understanding for our approach inSection III-D. We discuss the related works on monitoring andreconfiguration in Section IV. Finally, we conclude the paperand give some perspectives in Section V.

II. BACKGROUND

In this section, we will introduce the different terms relatedto our work. In the first hand, we will describe the differentaspects of monitoring and reconfiguration. On the other hand,we will briefly introduce Open Cloud Computing Interface(OCCI).

A. Monitoring

Monitoring consists of informing interested parts of thestatus of a property or a service. In our work, we consider twomodels of monitoring: monitoring by polling or by subscrip-tion. Polling is the simpler way of monitoring, as it allows theobserver to request the current state of a property wheneverthere is a need. The interested part can generally interactwith a specific interface that provides a getter of the neededproperty. Monitoring by subscription model is based on apublish/subscribe system which is defined as a set of nodesdivided into publishers and subscribers. Subscribers expresstheir interests by subscribing for specific notifications indepen-dently of the publishers. Publishers produce notifications thatare asynchronously sent to subscribers whose subscriptionsmatch these notifications [Baldoni et al., 2004]. Subscription

allows an observing resource to be notified about changes ofmonitored properties using one of the following modes:

• The subscription on interval: it implies that the pub-lisher (producer) broadcasts the state of its propertiesperiodically to the subscribers (consumers).

• The subscription on change: it implies that the pub-lisher has to notify the subscribers whenever its prop-erties changed.

The monitoring by subscription on change mode containsvarious types of monitoring: (i) Property Changed Monitoring(PCM): the monitored resource has to send notifications toall subscribers whenever a monitored property is changed,(ii) Method Call Monitoring (MCM): the monitored resourcesends notifications whenever one of the service’s methodsis invoked, and (iii) Execution Time Monitoring (ETM): themonitored resource notifies the subscribers about the executiontime whenever a service invocation is occurred.

B. Reconfiguration

Reconfiguration is a runtime modification of thestructure or the implementation of an Infrastructure[Hnetynka and Plasil, 2006]. In the literature, we canclassify the reconfiguration in four classes: (1) Structural:the reconfiguration leads to a change in the structure ofthe system (removing resources, adding resources, creatingor removing binding between resources). (2) Geometric:the reconfiguration leads to a new mapping of the existingresource to new locations (migration of components). (3)Implementation: the reconfiguration leads to changing theimplementation of one or more resources, but the structureof the system remains unchanged. and (4)Behavioral: thereconfiguration leads to changing the behavior of one or moreresources by changing some attributes.

These reconfiguration classes could be performed in twokinds:

• Intrusive kind: the reconfiguration is added to sourcecode of the application before deploying it.

• Independent kind: the reconfiguration code is inde-pendent from the code of the application, and it isrunning in the same time with the application to applyreconfiguration actions.

In the literature we identified that there are simple recon-figuration actions and complex ones. These latter could berepresented as a combination of a set of simple actions. Thereconfiguration actions that we identified are: Adding a newcomponent; (1) Removing a component; (2) Modification ofan attribute; (3) Adding a new connection; (4) Removinga connection; (5) Adding a component interface; and (6)Removing a component interface.

C. OCCI Specification overall

The Open Grid Forum defines the Open Cloud ComputingInterface (OCCI) [Nyren et al., 2011] as ”an abstraction ofreal world resources, including the means to identify, clas-sify, associate and extend those resources.” OCCI provides amodel to represent resources and an API to manage them.

The OCCI model can be extended to cover different lev-els in the cloud (i.e. IaaS, PaaS,etc.). OCCI specificationconsist essentially of three documents. The first is OCCICore [Nyren et al., 2011] and it formally describes the OCCICore Model. The second document is OCCI HTTP Rendering[Metsch and Edmonds, ]and it describes how to interact withOCCI Core using HTTP protocol. The third document is OCCIInfrastructure [Metsch and Edmonds, 2011] and it representsan extension of the Core to include new resources representingthe cloud infrastructure layer.

OCCI represents the real world as Entities. Entities areResources related with Links. These Entities (Resources andLinks) are typed using Kinds. Entities are extensible usingMix-ins. Mix-ins and Kinds inherit Category base type definedin OCCI. Each Category can have one or more actions.The diagram representing OCCI core base types is shown inFigure 1.

III. MONITORING AND RECONFIGURATION RESOURCESDESCRIPTION

In this section, we will define the different types that weneed to enable monitoring and reconfiguration based on OCCI.

Monitoring is usually used to get information to verifywhether an SLA is met or not. This latter may concern one ormore resources. We can assume that each resource has its ownSLA. We propose a new OCCI resource (Autonomic Manager)that extracts the needed metrics to monitor from a specificSLA. To cover all the SLA description languages, we proposeto use an SpecificSLA Mix-in that describes in a specific wayhow to extract the metrics from the SLA. Accordingly, thisresource establish the needed infrastructure to monitor andreconfigure related resources. It adds the needed monitoringfacilities to resources. Based on monitoring information, thereconfiguration infrastructure can take decisions to triggerreconfiguration actions to apply on Cloud resources. To offera Monitoring and Reconfiguration infrastructure on-demand,The provider needs to define the following types:

• Autonomic Manager resource: it represents a re-source that handles an SLA and activates the neededresources for monitoring and reconfiguration function-alities;

• Analyzer resource: it processes monitoring informa-tion and triggers reconfiguration actions;

• Reconfiguration Manager resource: it receives or-ders from the Analyzer Resource and applies them onmanaged resources;

He must also define the following Links:

• AgreementLink: it describes the link between anAutonomic Manager and a managed Resource;

• SubscriptionLink: it describes the link between asubscriber and a specific Notification Service of amanaged resource;

• NotificationLink: it describes the link that bringsnotifications from a Notification service of a managedresource to a subscriber;

• AlertLink: it describes the link that brings alerts froman Analyzer resource to a Reconfiguration Managerresource;

• ActionLink: it describes the link that brings reconfig-uration actions from a Reconfiguration Manager to beapplied on a managed resource;

Finally he needs to define the following Mix-ins:

• MetricsTool Mix-in: it describes the specific way toextract metrics from a specific SLA;

• Polling and Reconfiguration Manager Mix-in: itdescribes the needed operations to monitor by pollingor reconfigure a resource;

• Push Manager Mix-in: it describes a channel used tosubscribe on specific monitoring notifications;

• RuleSet Mix-in: it describes the rules applied on mon-itoring information to trigger reconfiguration orderswhen needed;

• SubscriptionTool Mix-in: it describes the subscrip-tions that could be used to subscribe on a Notificationservice of a managed resource;

• NotificationTool Mix-in: it describes the differentnotifications types that could be used to notify sub-scribers;

• AlertTool Mix-in: it describes the alert mechanismsused to alert a Reconfiguration Manager that there isa need to reconfiguration actions;

• StrategySet Mix-in: it describes the different strate-gies that could be used to process an incoming alert;

• ActionTool Mix-in: it describes the reconfigurationactions that could be applied on resources;

A. Resources

To provide a generic solution for monitoring and reconfigu-ration using OCCI, we defined new resources. Basically, theseresources are the Autonomic Manager resource, the Analyzerresource and the Reconfiguration Manager resource. Theseresources inherits the Resource base type defined in OCCIcore [Nyren et al., 2011] (see Figure1).

1) Autonomic Manager Resource: In order to automatizethe establishment of the monitoring and reconfiguration in-frastructure, we defined an Autonomic Manager resource asa generic OCCI resource. This resource inherits the Resourcebase type defined in OCCI Core Model [Nyren et al., 2011]. Itanalyzes a given SLA and carries out the list of actions to buildthe infrastructure. From a given SLA, this resource determinesmonitoring targets (i.e, the needed attributes to be monitored).It is also responsible of extracting the rules that will be used bythe Analyzer resource (see III-A2) and the reconfiguration ac-tions to be used by the Reconfiguration Manager (see III-A3).After inspecting the contract (SLA), the Autonomic Managerstarts the needed Resources and Links. Then, it instantiatesthe needed Mix-ins and eventually configure them with theneeded parameters. Since the SLA can be described usingdifferent specifications (i.e, WS-Agreements, USDL, Linked

USDL, etc), the Autonomic Manager uses a SpecificSLA Mix-in (see III-C1)that describes how to deal with a specific SLA.

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Autonomic Managerattributes (see below)related http://ogf.schemas.sla/occi/core#resource

Set of Attributes for the Autonomic Managername type mut. req. Descriptionocci.autonomicmanager.visibility String yes yes The visibility of the resource to clientsocci.autonomicmanager.scope Enumeration yes no The resources related to the manager

TABLE I. DEFINITION OF THE AUTONOMIC MANAGER RESOURCE

2) Analyzer Resource: In order to provide a reconfig-uration infrastructure, we defined an Analyzer resource asa generic OCCI resource. This resource allows to analyzemonitoring data and eventually generate alerts. This resourceinherits the Resource base type defined in OCCI Core Model[Nyren et al., 2011]. To get monitoring data, the Analyzerresource may subscribe in a Notification service of a managedresource. Subscription is possible using an instance of theSubscriptionLink (described in III-B2). Based on the typeof the needed subscriptio, theAnalyzer may receive periodicnotifications if the subscription is on interval, and it mayreceive notifications whenever the monitored metric changed ifthe monitoring is on change. Notifications are received throughan instance of the NotificationLink (described in III-B3). TheAnalyzer resource is an abstract description that would bespecified using RuleSet Mix-in collection (described in III-C4).The Analyzer resource uses RuleSet Mix-in to specify rules toapply on monitoring data. The role of the Analyzer resourceis to compare monitoring data against previously establishedSLA. If the date does not meet the SLA, the Analyzer mayraise alerts to the Reconfiguration Managerresource (describedin III-A3).

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Analyzerattributes (see below)related http://ogf.schemas.sla/occi/core#resource

Set of Attributes for the Analyzername type mut. req. Descriptionocci.analyzer.ruleset Enumeration yes yes The list of applicable rulesocci.analyzer.resubscriptionrate number yes no The time needed to resubscribe on resource noti-

fications

TABLE II. DEFINITION OF THE ANALYZER RESOURCE

3) Reconfiguration Manager resource: We defined a Re-configuration Manager resource as a generic OCCI resource.This resource inherits the Resource base type defined in OCCICore Model [Nyren et al., 2011]. It receives alerts from theAnalyzer resource through an Alert Link. To receive alerts,this resource must be the target of one or more Alert Linkinstances (described in III-C7). The Reconfiguration Managerresource is an abstract description that would be specifiedusing StrategySet Mix-in collection (described in III-C8). TheReconfiguration Manager resource uses StrategySet Mix-into specify strategies to apply for each received alert. Therole of the Reconfiguration Manager resource is to generatereconfiguration actions to apply on resources.

Fig. 1. OCCI monitoring and reconfiguration extension.

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Reconfiguration Managerattributes (see below)related http://ogf.schemas.sla/occi/core#resource

Set of Attributes for the Reconfiguration Managername type mut. req. Descriptionocci.reconfigurationmanager.strategies Enumeration yes yes The occurrence time of the alertocci.reconfigurationmanager.activation String yes no The type of the thread associated to the manager

TABLE III. DEFINITION OF THE RECONFIGURATION MANAGERRESOURCE

B. Links

To link the different defined resources, we defined newlinks inheriting the Link base type defined in OCCI Core[Nyren et al., 2011] (see Figure 1).

1) Agreement Link: The Agreement Link is a Link betweenan Autonomic Manager Resource and the managed resource.It allows an Autonomic Manager to inspect the SLA of a man-aged resource. An Agreement Link may link one AutonomicManager to one or more resources.

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Agreementsource URItarget URIattributes (see below)related http://ogf.schemas.sla/occi/core#link

Set of Attributes for the Agreement Linkname type mut. req. Descriptionocci.agreementlink.starttime number yes yes The start time of the Agreementocci.agreementlink.duration number yes yes Duration of the Agreement Link

TABLE IV. DEFINITION OF THE Agreement Link

2) Subscription Link: The Subscription Link is a Linkbetween a managed resource (via its Notification Mix-in) and aconsumer. It models the occurance of subscriptions on specificmetrics. A Subscription Link is related to one consumer thatrequires monitoring information and one managed resourcethat have a Notification Mix-in. A Subscription Link is charac-terized by the subscription type. A Subscription is an a Mix-ininstance from the SubscriptionSet Mix-in collection.

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Subscriptionsource URItarget URIattributes (see below)related http://ogf.schemas.sla/occi/core#link

Set of Attributes for the Subscription Linkname type mut. req. Descriptionocci.subscription.starttime number yes yes The starting time of the Subscriptionocci.subscription.duration number yes no The duration of the Subscriptionocci.subscription.renewable boolean no no Specifies if the subscription can be renewed after

expiration

TABLE V. DEFINITION OF THE SUBSCRIPTION LINK KIND

3) Notification Link: The Notification Link is a Link be-tween a managed resource (via its Notification Mix-in) and asubscriber. It models the activity of notifying subscribers aboutthe state of a monitored metric. This activity is relative to thetype of the subscription. If the subscription is on change, annotification will occur whenever the monitored metric changes.If the subscription is on interval, a notification will occurperiodically based on the period specified in the subscription.A notification is characterized by its type specified by aninstance of the NotificationSet Mix-in collection (described inIII-C6.

The different attributes of the Subscription Link are de-picted in Table VI.

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Notificationsource URItarget URIattributes (see below)related http://ogf.schemas.sla/occi/core#link

Set of Attributes for the Subscription Linkname type mut. req. Descriptionocci.notificationlink.starttime number yes yes The start time of the notification Linkocci.notificationlink.duration number yes no The duration of the Link

TABLE VI. DEFINITION OF THE Notification Link KIND

4) Alert Link: The Alert Link is a Link between theAnalyzer resource and the Reconfiguration Manager resource.The Alert Link inherits the Link base type defined in the OCCICore Model [Nyren et al., 2011].

It models the occurrence of an alert. An alert is generatedwhen the Analyzer resource detects that one rule in the RuleSetMix-in collection is not respected. An alert is specified by aninstance of the AlertSet Mix-in collection (described in III-C7).

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Alertsource URItarget URIattributes (see below)related http://ogf.schemas.sla/occi/core#link

Set of Attributes for the Alert Linkname type mut. req. Descriptionocci.alert.starttime number yes yes The start time of the alert Linkocci.alert.duration string yes no The duration of the Link

TABLE VII. DEFINITION OF THE Alert Link KIND

5) Action Link: The Action Link is a Link between anReconfiguration Manager Resource and another resource onwhich the latter applies reconfiguration actions. It models thetransfer of actions from a Reconfiguration Manager Resourceto be applied on a managed resource. The Action Link isrelated to one Reconfiguration Manager from which it bringsactions, and to one Resource on which it applies these actions.An Action Link is characterized by the activity that appliesreconfiguration actions on other Resources. This activity isdescribed as a Mix-in instance from the ActionToolSet Mix-in collection. An Action Link has as input orders from anReconfiguration Manager Resource. Every action entry MUSTbe related to a Mix-in instance of the ActionToolSet Mix-incollection (described in III-C9).

Model attribute valuescheme http://ogf.schemas.sla/occi/reconfiguration#term Actionsource URItarget URIattributes (see below)related http://ogf.schemas.sla/occi/core#link

Set of Attributes for the Action Linkname type mut. req. Descriptionocci.action.starttime number yes yes The start time of the Action Linkocci.action.duration number yes yes Duration of the Linkocci.action.type string yes no Type specifying if the actions can be executed

online or offline

TABLE VIII. DEFINITION OF THE Action Link KIND

C. Mix-ins

To customize the different resources and the links betweenthem, we defined different Mix-ins. These latter inherits theMix-in base type defined in OCCI Core [Nyren et al., 2011](see Figure 1).

1) MetricsTool Mix-in: A Mix-in instance of the Metric-sTool Mix-in models the needed tools that allows an Auto-nomic Manager can extract the needed information from aspecific SLA. This Mix-in proposes basically two actions. Thefirst action allows the Autonomic Manager to get the metricsthat need to be monitored. Based on these metrics, the secondaction allows to establish the needed resources for monitoringand reconfiguration. The MetricsTool Mix-in inherits the Mix-in base type defined in OCCI Core Model [Nyren et al., 2011].

2) Polling and Reconfiguration Manager Mix-in: We havedefined a Polling and Reconfiguration Manager Mix-in thatprovides the needed functionalities to ensure monitoring andreconfiguration. This Mix-in inherits the Mix-in base typedefined in OCCI Core Model [Nyren et al., 2011]. To managea resource, we associate to it an instance of this Mix-in.For each resource associated with this Mix-in, the first actiongetAttributes() returns the list of the attributes of the managedresource. The getAttributeValue() returns the value of a givenattribute. The setAttributeValue() changes the value of anattribute. The getActions() returns the list of actions that onecould apply on the managed resource. The invokeAction()invokes a given action on the managed resource. To ensurethe consistency of the Resource to be reconfigured, this lattermust be in a reconfiguring state. A resource in a reconfiguringstate do not accept or request any connection. The GeneriProxyMix-in offer a method changeConnectionState() to bind orunbind a managed resource.

3) Push Manager Mix-in: To allow other resources (clients)to get monitoring data, we defined a Push Manager Mix-in.This Mix-in inherits the Mix-in base type defined in OCCICore Model [Nyren et al., 2011]. For each managed resource,we add a Push Manager Mix-in to allow clients to subscribeon specific metrics monitoring data. Notifications may be byinterval so that the client receives a notification periodicallycontaining the state of one or metrics. It may also be bychange, so the Push Manager Mix-in pushes the new state ofthe metric whenever a change occurred. Push Manager Mix-in offers a list of actions to manage clients subscriptions. Thefirst action is subscribe() that allows a client to subscribe toreceive monitoring notifications for one or more metrics. Theunsubscribe() delete a previous subscription. The renewSub-scription() updates a previously established subscription. Aclient may specify aspects related to its subscription (i.e, type,duration, start time, interval).

4) RuleSet Mix-in: A Mix-in instance in the RuleSet Mix-in collection must implement a computation rule that based-on incoming information (monitoring information) triggersspecific alerts. It represents a function applied by the AnalyzerResource to control monitoring information values againsta defined threshold or conditions. Whenever the conditionis verified the Mix-in instance triggers a specific alert. Theattribute of a Mix-in in the RuleSet collection are divided intothree groups: Input attributes: they bind a monitoring inputof the Notification Mix-in of a managed resource with an

input of the rule function. All the inputs of rules functionMUST have a corresponding input in the Analyzer resource.Control attributes: they control the rule function execution;these attributes can be reconfigured to change the behavior ofthe Mix-in instance. Alerts attributes: they correspond to thealerts triggered by the Mix-in instance and to be sent to theReconfiguration Manager resource through an Alert Link kind(described in III-B4).

5) SubscriptionTool Mix-in: A Mix-in in the Subscrip-tionTool Mix-in collection models a Subscription instance.An instance of the ActionToolSet may describe the differentaspects of a subscription (i.e, its type, its duration, eventuallyits filters). The ActionToolSet Mix-in inherits the Mix-in basetype defined in OCCI Core Model [Nyren et al., 2011].

6) NotificationTool Mix-in: A Mix-in in the Notification-Tool Mix-in collection models the needed tools by whichnotifications are sent to subscribers. An instance of the No-tificationTool may enable notification messages by differenttools like email, messages, or simple notifications.

The NotificationTool Mix-in inherits the Mix-in base typedefined in OCCI Core Model [Nyren et al., 2011].

7) AlertTool Mix-in: A Mix-in in the AlertTool Mix-in collection models the needed tools by which alerts canreach a Reconfiguration Manager resource. An instance ofthe AlertTool may represent a simple message containing thedescription of the encountered event. The AlertTool Mix-ininherits the Mix-in base type defined in OCCI Core Model[Nyren et al., 2011].

8) StrategySet Mix-in: A Mix-in instance in the StrategySetMix-in collection must implement a computation strategy thatbased-on incoming alerts triggers reconfiguration actions onspecific Resources. It represents a function applied by theReconfiguration Manager resource to process incoming alerts.The attribute of a Mix-in in the RuleSet collection are dividedinto three groups: Input attributes: they bind an alert inputof the Reconfiguration Manager resource with an input ofthe Strategy function. All the inputs of strategies functionsMUST have a corresponding input in the ReconfigurationManager resource. Control attributes: they control the strategyfunction execution; these attributes can be reconfigured tochange the behavior of the Mix-in instance. Action attributes:they correspond to the Actions triggered by the Mix-in instanceand to be executed by the outgoing Action Link (described inIII-B5).

9) ActionTool Mix-in: A Mix-in in the ActionTool Mix-incollection models the needed tools by which reconfigurationactions are applied on a specific Resource. An instance of theActionTool may represent a simple action as it is defined forthe OCCI Core model [Nyren et al., 2011]. It may also be acomposed action that refers to a list of actions.

D. Example

To push farther the details of our approach, we presentan example describing the sequence of actions needed toestablish a monitoring and reconfiguration infrastructure. Weassume that the different Threshold needed to trigger actionsare extracted from a previously defined SLA contract. Basedon this contract, a monitoring infrastructure is also established

and provides monitoring information over a Notification Link.This latter has as source attribute the Notification Mix-in andas a target attribute the Analyzer Resource.

The following example explains the establishment of themonitoring and reconfiguration infrastructure. Suppose thatwe have a managed resource named DataB that representsa data base instance. The monitoring and reconfigurationinfrastructure consists of an Analyzer Resource that consumesmonitoring information from an incoming NotificationLinkconcerning a FreeDisk attribute. The FreeDisk attribute rep-resents the disk space left in a used partition. If this spaceis less then a given threshold (i.e. 512Mb for this example),the Analyzer must send an alert to a Reconfiguration Managerresource. This latter must generate a scale-up order to extendthe partition disk space. The scale-up order is triggered using aScaleUpDiskRule Mix-in which is an instance of the RuleSetcollection.

To render a resource manageable (i.e, monitorable andreconfigurable), the client should add a GenericProxy mix-into this resource. For our example, we add such a mix-in to theDataB resource.

> POST /GenericProxy/genericproxy / HTTP/1.1>> X-OCCI-Location: http://provider.com/monitoring/DataB

After adding this mix-in, the client can monitor by pollingthe managed resource. But to enable the monitoring by sub-scription, he still needs to add a Notification Mix-in instance.

> POST /Notification/notification / HTTP/1.1>> X-OCCI-Location: http://provider.com/monitoring/DataB> X-OCCI-Attribute: genericProxy=http://provider.com/monitoring/DataB/genericproxy

The monitoring infrastructure is now in place. The fol-lowing actions are related to the reconfiguration infrastructure.They include also, the needed actions to consume monitoringdata. The client starts by instantiating an Analyzer resource.This resource consumes monitoring data and compares themto previously established values ( based on SLA).

> POST /analyzer / HTTP/1.1>< X-OCCI-Location: http://provider.com/reconfiguration/analyzer

The Analyzer resource uses the RuleSet mix-in which is acollection of rules. Each instance is a rule, that verifies a givencondition.

> POST /ruleset/diskrule / HTTP/1.1>> X-OCCI-Location: http://provider.com/reconfiguration/analyzer> X-OCCI-Attribute: threshold=512Mb> X-OCCI-Attribute: attribute= freedisk

In this example, the rule compares the incoming value ofthe attribute freedisk against the given threshold. To receivemonitoring data, the Analyzer must be a subscriber in theNotification mix-in. To do that, it may use a Subscription Linkbetween the Analyzer resource and the managed resource.

> POST /subscriptionlink/ HTTP/1.1> Category: collector;>scheme=http://schemas.ogf.org/occi/monitoring#;>class=kind;> X-OCCI-Attribute: occi.core.target=http://provider.com/monitoring/DataB"> X-OCCI-Attribute: occi.core.source=http://provider.com/reconfiguration/analyzer"> ...

< HTTP/1.1 201 OK< Location: http://provider.com/monitoring/subscriptionlink

In order to specify monitoring aspects, the Subscriptionlink may use a mix-in instance from the SubscriptionSet mix-in collection. In this instance, the user specifies the type of thesubscription and all the needed data.

> POST /subscriptionset/disksizesubscription / HTTP/1.1>> X-OCCI-Location: http://provider.com/monitoring/subscriptionlink> X-OCCI-Attribute: starttime=0> X-OCCI-Attribute: duration= -1> X-OCCI-Attribute: type= "on change"> X-OCCI-Attribute: attribute= "freedisk">...

< HTTP/1.1 201 OK< Location: http://provider.com/monitoring/subscriptionlink/disksizesubscription

In this example, the Analyzer resource subscribes onthe Notification mix-in to receive notifications whenever thefreedisk attribute changes. The subscription is not differed (i.e,starttime=0) and the duration is unlimited (duration= -1). TheAnalyzer resource receives notifications through an instanceof the Notification Link. This link has as source the managedresource and as target the Analyzer resource.

> POST /notificationlink/ HTTP/1.1> Category: NotificationLink;>scheme=http://schemas.ogf.org/occi/monitoring#;>class=kind;> X-OCCI-Attribute: occi.core.target="http://provider.com/reconfiguration/analyzer"> X-OCCI-Attribute: occi.core.source="http://provider.com/monitoring/DataB"> ...

< HTTP/1.1 201 OK< Location: http://provider.com/monitoring/notificationlink

In order to specify the notification aspects, the Notifica-tionLink make use of an instance of the NotificationSet mix-incollection.

> POST /notificationset/disksizenotification / HTTP/1.1>> X-OCCI-Location: http://provider.com/monitoring/notificationlink> X-OCCI-Attribute: timestamp=system.timestamp> X-OCCI-Attribute: attribute= freedisk> X-OCCI-Attribute: value= value> X-OCCI-Attribute: type= httpcallback>...

< HTTP/1.1 201 OK< Location: http://provider.com/monitoring/notificationlink/disksizenotification

In this example, the notification uses a HTTP callback to sendthe notification instance. The notification contains the nameof the attribute, its new value and the occurrence time ofthe change. At this stage, the Analyzer is able to consumemonitoring data and generate alerts if the data do not meet theSLA. Alerts generated by the Analyzer resource are consumedby a Reconfiguration Manager resource. The client needs nowto instantiate a Reconfiguration Manager resource to enablereconfiguration.

> POST /reconfigurationmanager / HTTP/1.1>< X-OCCI-Location: http://provider.com/reconfiguration/reconfigurationmanager

The Reconfiguration Manager resource is able to apply recon-figuration strategies to meet the previously defined SLA. Astrategy is an instance of the StrategySet mix-in collection. Tospecify a strategy, the client may instantiate one of the mix-insprovided by the provider.

> POST /strategyset/scalediskstrategy / HTTP/1.1>> X-OCCI-Location: "http://provider.com/reconfiguration/reconfigurationmanager"> X-OCCI-Attribute: alerttype= lowdisk> X-OCCI-Attribute: attribute= freedisk> X-OCCI-Attribute: action= scale-up-disk> X-OCCI-Attribute: newvalue= freedisk*2>...

< HTTP/1.1 201 OK< Location: http://provider.com/reconfiguration/reconfigurationmanager/scalediskstrategy"

In this example, whenever the Reconfiguration Manager re-source receives an lowdisk alert, it will trigger a reconfigurationaction scale-up-disk. To receive such kind of alerts, there mustbe an Alert Link between the Analyzer and the ReconfigurationManager. This Link is defined in the following listing.

> POST /alertlink/ HTTP/1.1> Category: Alert;>scheme=http://schemas.ogf.org/occi/reconfiguration#;>class=kind;> X-OCCI-Attribute: occi.core.target=http://provider.com/reconfiguration/analyzer"> X-OCCI-Attribute: occi.core.source=http://provider.com/reconfiguration/reconfigurationmanager"> ...

< HTTP/1.1 201 OK< Location: http://provider.com/reconfiguration/alertlink"

To specify how the alerts are going through the Alert Link,the client may use an instance of the AlertSet Mix-in collection.

> POST /alertset/lowdisk / HTTP/1.1>> X-OCCI-Location: http://provider.com/reconfiguration/alertlink> X-OCCI-Attribute: timestamp= system.timestamp> X-OCCI-Attribute: type= lowdisk> X-OCCI-Attribute: actualvalue= value> X-OCCI-Attribute: requiredvalue= slavalue> X-OCCI-Attribute: alerttool= HTTP>...

< HTTP/1.1 201 OK< Location: http://provider.com/reconfiguration/alertlink/lowdisk"

In this example, the Analyzer sends a HTTP message tothe Reconfiguration Manager whenever the monitoring datadoes not meet the SLA. The alert contains the value of themonitoring data and the required value indicated in the SLA.

When the Reconfiguration Manager receives the alert it ap-plies a specific strategy to generate one or more reconfigurationactions. These actions are applied on the managed resourcethrough an Action Link. The following listing shows how tocreate such a link.

> POST /actionlink/ HTTP/1.1> Category: actionlink;>scheme=http://schemas.ogf.org/occi/reconfiguration#;>class=kind;> X-OCCI-Attribute: occi.core.target=http://provider.com/monitoring/DataB/genericproxy"> X-OCCI-Attribute: occi.core.source=http://provider.com/reconfiguration/reconfigurationmanager"> ...

< HTTP/1.1 201 OK< Location: http://provider.com/reconfiguration/actionlink

Every reconfiguration action represents an instance of theActionToolSet Mix-in collection. It details the reconfigurationaction, and how to finalize it.

> POST /ActionToolSet/scaleupdisk/ HTTP/1.1> X-OCCI-Location: http://provider.com/reconfiguration/actionlink>> X-OCCI-Attribute: method= scale-up> X-OCCI-Attribute: requiredsize= size*2

<HTTP/1.1 201 OK< Location: http://provider.com/reconfiguration/actionlink/scaleupdisk

The activation of the scaleupdisk action results on anactivation of the GenericProxy operation (i.e, invokeAction())with the method attribute of the mix-in. In this case, theGenericProxy can reconfigure the DataB resource withoutservice interruption. In other cases, the ActionToolSet instancemay contain an action to replace a resource, in this case, it mayhandle all the bindings incoming or outgoing the resource.

The resulting infrastructure is shown in Figure III-D.

To automatize the establishment of all the infrastructure,the provider allows the user to use an instance of the Auto-nomic Manager resource. Using this instance, the user needsjust to accept the SLA agreement. All the previously describedactions will be carried on successively by the AutonomicManager. It will inspect the SLA to define the metrics that needto be monitored. Then, it will add the GenericProxy and theNotification Mix-ins to the managed resource. The Analyzerresource and the Reconfiguration Manager resources can beinstantiated and all the links can be established. Afterward,the mix-ins can be loaded with their specific values.

IV. STATE OF THE ART

A. Monitoring

In the literature, there are many attempts to providemonitoring in the cloud and in distributed systems. In thissubsection, we present some proposed approaches in this area.We conclude by explaining the limitations of these approachesand giving our objectives to overtake these limits.

Nagios [nag, 2010] is an open-source core system fornetwork monitoring. It allows monitoring IT infrastructure toensure that systems, applications and services are functioningproperly. Monitoring can be applied on private or publicservices (private services are services and attributes of a serverand public services are those available across network). Tomonitor any target, Nagios uses a list of plug-ins that wouldbe executed to poll the target status. A plug-in acts as anabstraction layer between the monitoring daemon and themonitored targets. It enables remote command execution toknow the status of the monitored target. There are several plug-ins for different protocols as SNMP, NRPE or SSH. Monitoringusing Nagios can result in high load on the monitoring serverif applied on a large number of targets.

Ganglia [Massie et al., 2004] is an open-source monitoringsystem for high-performance computing systems. It is basedon a hierarchical design targeted at federations of clusters. Ituses a multicast-based listen/publish protocol within a cluster.Within each cluster, Ganglia uses heart beats messages on awell known multicast address as the basis of a membershipprotocol. Membership is maintained by using the reception of aheartbeat as a sign that a node is available. Each node monitorsits local resources and sends multicast packets containingmonitoring data on a well known multicast address. All nodeslisten for monitoring packets on the agreed multicast addressto collect and maintain monitoring data for all other nodes.Each cluster can be represented with one node, since allthe nodes contain a complete copy of the cluster monitoringdata. Aggregation of monitoring data is done by polling childnodes at periodic intervals. Monitoring data is exported usinga TCP connection to the node being polled followed by aread operation of its monitoring data. Ganglia Monitoring isimplemented by a monitoring daemon, which is organizedas a collection of threads, each assigned a specific task: 1)Collect and publish thread: collects local node informationand publishes it on a well known multicast channel. It sendsperiodic heartbeats, 2) Listening threads: listen on the multicastchannel for monitoring data from other nodes and updatesmonitoring data storage, and 3) XML export threads: acceptand process client requests for monitoring data. Ganglia Mon-itoring system assumes the presence of a native multicastcapability, an assumption which does not hold for the internetin general.

In [Brandt et al., 2009], J. Brandt et al. proposed OVISas a tool for monitoring Cloud resources enhancing high-performance computing in Cloud computing environments.This tool can extract the application and resources state, andbased on that state it can assign new resources or shut downunused ones during the application’s runtime or for nextusages. The data is collected from the resources using datacollectors able to collect information and save it in a distributeddata base. Then, a statistical analysis is necessary to take

Fig. 2. OCCI Monitoring and Reconfiguration example.

decisions to keep or to manually reconfigure the resources’assignment for the application. Authors affirm that scalabilitystill remains an area of concern since the monitoring systemcan be flooded with a big amount of information and thatwould form a bottleneck.

In their work [Katsaros et al., 2011], G. Katsaros et al.proposed an architectural approach spanning over virtualiza-tion and physical levels to collect monitoring data. Theycombined many existing open source solutions (e.g. Lattice[Clayman et al., 2010], Ganglia [Massie et al., 2004], Nagios[nag, 2010]) to get one holistic application that cover differentlayers. They use collectors to extract data from different layers(virtual and physical) and externalize it to the upper layer usingan external data collector. Moreover, a monitoring managerserves as the orchestrator of the whole monitoring process bycontrolling and providing the needed interfaces to add or toconsume monitoring information. In this approach, only oneaggregator is responsible of aggregating and storing all thecollected data.

Almost all of these monitoring approaches target moni-torable components and do not tackle the case where com-ponents are not designed to be monitored. In contrast, in ourapproach, we provide the needed elements to render resourcesmonitorable even if they were not designed with monitoring fa-cilities. Moreover, in the stated works, the monitoring systemsdo not address scalability issues. All these works are relatedto a specific use case or a specific architecture. What we areproposing is a generic solution based on OCCI standards. Ourapproach can encapsulate all the here presented works.

B. Reconfiguration

In the literature, there are different proposed approachesfor dynamic reconfiguration. In this section we will present alist of these approaches that influenced our research.

Authors of [Pellegrini, Jul] presented an extension toCORBA programming model to enable component reconfigu-ration with minimal service degradation. The needed action forreconfiguration are objects addition and deletion, object migra-tion and binding modification. Authors defined two states ofobjects: execution state where the objects can accept requestsand reconfiguration state where the state of the object is savedand the object can not accept any request. The state savingof an object is made by saving its internal state includingits data structure and context. To facilitate this task, it isnecessary to verify that there are no threads in execution.SinceCorba Identifier Object Reference (IOR) can change duringthe migration of objects, authors proposed an extension to theCorba naming service to support the use of symbolic namesfor objects to identify them.

In [Hnetynka and Plasil, 2006], authors propose a solu-tion to address dynamic reconfiguration for component-basedapplications. Authors define dynamic reconfiguration as aruntime modification of an application architecture. A firsttype of reconfiguration is the replacement of a component byanother one having compatible interfaces. The second type isthe replacement of a subtree of the application componentshierarchy. Dynamic reconfiguration can be initiated by theapplication itself as well as from the outside of the application.Authors propose to use the Nested Factory Pattern whichcovers adding components and connections to the architecture.This pattern implies that the newly created component is

a result of a method invocation on factory component. Toallow Adding/ Removing interfaces, authors introduce ”utilityinterface” which is a interface that could be used by all thecomponents. The connection to this interface is establishedorthogonally to the architecture hierarchy. This interface canbe seen as a an external service.

Ruz et al [Ruz et al., 2010] introduced a framework thataddress monitoring, SLA management and adaptation strate-gies for component-based applications.

In their approach, authors separate Monitoring, Analysis,Decision and Execution concerns by implementing each ofthem as separate components that could be attached to acomponent to manage it. These components can be addedor removed when needed. Each component can communicatewith other components (i.e, monitoring component can usemonitoring services from other monitoring components ofother managed components).Monitoring component is respon-sible of collecting metrics from the managed component. TheSLA Analysis component is a consumer for monitoring data.It compares these data against previously defined SLA. TheDecision component implements one or more strategies toreact to SLA infraction. This component receives a notificationfrom the SLA Analysis module to know that the managedcomponent does not meet the SLA. It executed the associatedstrategy to this notification and generates a list of actions tobe applied on the managed component to meet the SLA. TheExecution component applies the list of actions provided bythe Decision component.

Almost all of the proposed solutions, are specific to a givenlevel (IaaS, PaaS or SaaS). Therefore, they can not be used inother levels. In our case, since our proposal is based on OCCI,we can apply it on all the levels. The extensibility of our workis guaranteed using the Mix-ins that could specify the technicalaspects for each level separately.

V. CONCLUSIONS

REFERENCES

[nag, 2010] (2010). Nagios Documentation.http://www.nagios.org/documentation.

[Baldoni et al., 2004] Baldoni, R., Beraldi, R., Piergiovanni, S., and Vir-gillito, A. (2004). Measuring notification loss in publish/subscribecommunication systems. In Proceedings of the 10th IEEE Pacific RimInternational Symposium, Dependable Computing, pages 84–93.

[Brandt et al., 2009] Brandt, J., Gentile, A., Mayo, J., Pebay, P., Roe,D., Thompson, D., and Wong, M. (2009). Resource monitoring andmanagement with OVIS to enable HPC in cloud computing environments.In Parallel Distributed Processing, 2009. IPDPS 2009. IEEE InternationalSymposium on, pages 1–8.

[Clayman et al., 2010] Clayman, S., Galis, A., and Mamatas, L. (2010).Monitoring virtual networks with Lattice. In Network Operations andManagement Symposium Workshops, pages 239–246.

[Hnetynka and Plasil, 2006] Hnetynka, P. and Plasil, F. (2006). DynamicReconfiguration and Access to Services in Hierarchical Component Mod-els. In CBSE, pages 352–359.

[Katsaros et al., 2011] Katsaros, G., Gallizo, G., Kubert, R., Wang, T.,Fito, J. O., and Henriksson, D. (2011). A Multi-level Architecture forCollecting and Managing Monitoring Information in Cloud Environments.In Proceedings of the third International Conference on Cloud Computingand Services Science, CLOSER, pages 232–239.

[Massie et al., 2004] Massie, M. L., Chun, B. N., and Culler, D. E. (2004).The ganglia distributed monitoring system: design, implementation, andexperience. Parallel Computing, 30(7):817–840.

[Metsch and Edmonds, ] Metsch, T. and Edmonds, A. Open Cloud Com-puting Interface - RESTful HTTP Rendering. Technical report.

[Metsch and Edmonds, 2011] Metsch, T. and Edmonds, A. (2011). OpenCloud Computing Interface - Infrastructure. Technical report.

[Nyren et al., 2011] Nyren, R., Edmonds, A., Papaspyrou, A., and Metsch,T. (2011). Open Cloud Computing Interface - Core. Technical report.

[Pellegrini, Jul] Pellegrini, N.-C. (Jul). Dynamic reconfiguration of Corba-based applications. In Technology of Object-Oriented Languages andSystems, 1999. Proceedings of, pages 329–340.

[Ruz et al., 2010] Ruz, C., Baude, F., and Sauvan, B. (2010). Component-based generic approach for reconfigurable management of component-based SOA applications. In Proceedings of the 3rd International Workshopon Monitoring, Adaptation and Beyond, MONA ’10, pages 25–32, NewYork, NY, USA. ACM.