Skip to content

Home

Jump to bottom Edit New page
moldovanus edited this page Oct 21, 2014 · 23 revisions

Decision Module Deployment & Configuration

The Decision Module exposes a RESTful API for interaction with the users, the lifecycle of an interaction being presented below, the service being produced by rSYBL Analysis component

User interaction with rSYBL *** ## Decision Module Deployment ### MELA Analysis Service Deployment * Configure if required the options presented in "./config/mela-analysis-service.properties". * If compiled with "mvn clean package -P Release", extract the "tar.gz", perform necessary configurations, and start the MELA-AnalysisService using the provided script by executing "mela-analysis-service start". With "mela-analysis-service stop" the MELA-AnalysisService can be shut down. * If compiled with the standard profile, run from the target directory the MELA-AnalysisService as any simple jar with "java -DLOG_DIR=dir_to_store_logs -jar ./MELA-AnalysisService ", as it is packaged with an embedded Apache Tomcat 7.

As MELA-AnalysisService is packaged with an embedded Apache Tomcat 7, it will try to start on a standard HTTP 8080 port. If that port is occupied, change the "mela-analysis-service" script to include in the java -jar ./MELA-AnalysisService -httpPort=port", or add "-httpPort=port" if running from command line.

rSYBL Deployment

For deploying and starting rSYBL, there are two options:

  1. Deploy the war artifact generated by the rSYBL-analysis-engine component in an existing Web Server (e.g., Tomcat)

  2. Start the executable war artifact which also contains the web server

  3. Run rSYBL-service which can be found on the root of rSYBL repo (this works in Linux-based systems)

Note: in case Java version is less than 7, the following jvm options are needed -Djsse.enableSNIExtension=false -Djavax.xml.bind.JAXBContext=com.sun.xml.internal.bind.v2.ContextFactory

Decision Module Bootstrapping

For bootstrapping the Decision Module, the rSYBL service exposes the following web methods to be called in this order:

  1. prepareControl(cloudServiceID) (PUT method, accepting xml/application)- prepare cloudServiceID cloud service for control

  2. serviceDescription(descriptionInfo) (PUT method, accepting xml/application) - example of such a description is available here and is described on the rSYBL webpage.

  3. serviceDeployment(deploymentInfo) (PUT method, accepting xml/application) - example of such a description is available here and is described on the rSYBL webpage.

  4. Optional: metricsCompositionRules(metricsCompositionRules) (PUT method, accepting xml/application) - example of such a description is available here and is described on the MELA webpage.

  5. Optional: elasticityCapabilitiesEffects(elasticityCapabilitiesEffects) (PUT method, accepting json/application) - example of such a description is available here and is described on the rSYBL webpage.

  6. startControl(cloudServiceID) (PUT method, accepting xml/application)- start cloudServiceID cloud service control

  7. When done, gracefully shut down rSYBL control service: stopControl(cloudServiceID) (PUT method, accepting xml/application)- stop cloudServiceID cloud service control

  8. During runtime, replace existing requirements: replaceRequirements(cloudServiceID,cloudServiceRequirements) (PUT method, accepting xml/application)- replace existing requirements with others cloudServiceID cloud service control

Note: We offer examples of the needed sequence of calls in order to successfully initialize the control for a cloud service, both multi-cloud and single cloud here.

The table bellow details the web methods presented above:

Method Name | Path | Type | Input | Output :-- | :--: | --: | --: | --: | --: prepare control | /{id}/prepareControl | PUT | id - application id | set application description | /{id}/description | PUT | application/xml xml application description | set application description | /{id}/description/tosca | PUT | application/xml tosca application description | update application description | /{id}/description | POST | application/xml xml application description | get application description | /{id}/description | GET | id - the application id | application/xml xml application description | set application deployment | /{id}/deployment | PUT | application/xml xml application deployment | update application deployment | /{id}/deployment | POST | application/xml xml application deployment | set expected control effects | /{id}/elasticityCapabilitiesEffects | PUT | application/json json effects description | update expected control effects | /{id}/elasticityCapabilitiesEffects | POST | application/json json effects description | set composition rules |/{id}/compositionRules | PUT | application/xml xml composition rules for MELA | update composition rules | /{id}/compositionRules | POST | application/xml xml composition rules for MELA | update elasticity requirements | /{id}/elasticityRequirements | POST | application/xml xml SYBL requirements | start the application control | /{id}/startControl | PUT | id - application id | stop the application control | /{id}/stopControl | PUT | id - application id |

File-based configuration

  • The cloud service needs to be described, following the structure in the serviceDescription.xml(\analysis-engine\src\main\resources\config) example based on service units and service topologies. SYBL supports elasticity requirements specified either through XML descriptions.

  • Elasticity requirements can be specified in an XML either separately (see ElasticityRequirementsSpecification.xml from analysisEngine\src\main\resources) or integrated in the service description file (as for the serviceDescription.xml). If specified in separate XML description file, this needs to be stated in the config file of the Control Service (SYBLDirectives = ./config/ElasticityRequirementsSpecification.xml).

  • The deployment description path (association between service units and snapshots, for being able to scale out when necessary) - DeploymentDescriptionPath (e.g. config/deploymentDescription.xml)

Monitoring Plugin Configuration

Ganglia Plugin

For working with simple ganglia plugin some information has to be specified:

  • The ganglia plugin class needs to be specified in the config file (MonitoringPlugin = at.ac.tuwien.dsg.sybl.monitorandenforcement.monitoringPlugins.gangliaMonitoring.MonitoringGangliaAPI)

  • Ganglia IP needs to be specified in the config file

  • Ganglia Port needs to be specified in the config file

MELA Plugin

  • The main plugin class implementing MonitoringInterface needs to be specified in the config.properties file:

      MonitoringPlugin =  at.ac.tuwien.dsg.rSybl.dataProcessingUnit.monitoringPlugins.melaPlugin.MELA_API

  MonitoringServiceURL = http://MELA_HOST_IP:MELA_HOST_PORT/MELA/REST_WS

  • The user should consult the configurations needed for running MELA on the MELA wiki.

Enforcement Plugin Configuration

Current version of rSYBL has the following plugins:

  • CELAR Orchestrator, for full CELAR platform flow
  • OpenStack, for your OpenStack-based private cloud
  • Flexiant, for controlling your application with rSYBL on Flexiant cloud, using FCO for controlling resources.
  • DryRun, for testing purposes. It outputs the actions rSYBL would like to enforce, without further enforcement.

The OpenStack enforcement plugin needs to be specified in config.properties

  EnforcementPlugin =  at.ac.tuwien.dsg.rSybl.cloudInteractionUnit.enforcementPlugins.openstack.EnforcementOpenstackAPI 

  CertificateName= e.g., mycert - The name of the certificate used 

  CertificatePath=e.g., config/mycert.pem - The path towards the certificate

  CloudAPIType = e.g., openstack-nova -  Type of the cloud middleware used

  CloudAPIEndpoint= e.g., in this case DSG local cloud 	 http://openstack.infosys.tuwien.ac.at:5000/v2.0 - Endpoint for accessing the cloud infrastructure

  CloudUser= e.g., georgiana.copil - Username for accessing cloud infrastructure 

  CloudPassword= e.g., georgianaPassword - Password for accessing cloud infrastructure

The Flexiant enforcement plugin needs to be specified in config.properties

  EnforcementPlugin =  at.ac.tuwien.dsg.rSybl.cloudInteractionUnit.enforcementPlugins.flexiant.EnforcementFlexiantAPI

  UserEmailAddress = [email protected] - Email address of Flexiant user

  [email protected] - User name of Flexiant user (usually matches e-mail address)

  CustomerUUID =XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - customer UUID on the FCO platform, can be obtained from user interface -> settings

  Password =georgianaPassword - your password on Flexiant cloud

  ENDPOINT_ADDRESS_PROPERTY=https://api.sd1.flexiant.net:4442  -current endpoint exposed by Flexiant

  VdcUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - the virtual datacenter where your application will be deployed & controlled

  DefaultProductOfferUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - the default type of VM which you would like to start (e.g., 886ae014-0613-3cc8-a790-16251471e624)

  DeploymentInstanceUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - the deployment instance to which the resources will be added

  ClusterUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - the current cluster where the application is deployed

  NetworkUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - the network which the application is using

  SSHKey=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - the UUID of the ssh key with which the VMs need to start (in case one needs passwordless access to them)

The DryRun enforcement plugin, used for testing purposes, needs to be specified in config.properties

  EnforcementPlugin =  at.ac.tuwien.dsg.rSybl.cloudInteractionUnit.enforcementPlugins.dryRun.DryRunEnforcementAPI

Application Specific Configurations

The application-specific configuration can be sent to the rSYBL in three ways, depending on the information structure.

Multiple enforcement mechanisms/ Multi-cloud control configuration

rSYBL can control services which have different service parts (e.g., service topologies/composite components) deployed on different cloud providers. Moreover, rSYBL can also use user-defined control, which can be defined following the steps in the next section, in order to control cloud services.

An example of a client which follows this entire lifecycle, with two clouds, as presented in the figure below, is available here. The description of the cloud service together with its requirements stays the same, for the case the cloud service is deployed on two clouds with similar functionalities.

User interaction with rSYBL *** The configuration of enforcement mechanisms for the case above is (complete config file available here)

MultipleEnforcementPlugins = flexiant:at.ac.tuwien.dsg.rSybl.cloudInteractionUnit.enforcementPlugins.flexiant.EnforcementFlexiantAPI, openstack:at.ac.tuwien.dsg.rSybl.cloudInteractionUnit.enforcementPlugins.openstack.EnforcementOpenstackAPI

This way, we say that we will refer to the EnforcementFlexiantAPI as flexiant, and to EnforcementOpenstackAPI as openstack, and we will use them both.

However, there are some differences in terms of effects description and deployment description. The single difference, next to adding extra plugins in config.properties, is that when specifying capabilities of different nodes, one needs to specify which enforcement mechanism comes from which plugin:

<AssociatedVM IP="109.231.122.250" UUID="131627fe-d5f3-3518-8bf5-7d16a932df8c"/>

<AssociatedVM IP="109.231.122.251" UUID="9c99d99b-b2c4-30ee-a87f-67e7370291ad"/>	

<ElasticityCapability Name="flexiant.scaleIn"/>

<ElasticityCapability Name="flexiant.scaleOut"/>

<AssociatedVM IP="10.99.0.91"/>

<ElasticityCapability Name="openstack.scaleIn"/>

<ElasticityCapability Name="openstack.scaleOut"/>

The description above is normally introduced not by the user, but by the deployment/configuration framework (e.g., SALSA) as the deployment should be done automatically.

Development Guide

For customizing r-SYBL in what Monitoring and Enforcement is concerned, the following steps need to be followed.

For creating new plugins, an API of the plugin needs to implement the MonitoringInterface and respectively EnforcementInterface. The basic metrics and actions appear by name, while the ones which are specific to the applications/plugins are to be interfaced through getMetric and enforceAction actions. Moreover, the needed configuration data needs to be added and processed from the config file of the Analysis Engine, which is the main module of rSYBL tool.

After adding new plugins, the rSYBL tool needs to be recompiled and re-deployed, and these plugins need to be specified in config.properties and associated, in the case of the enforcement plugin, in the deployment description, with the node (e.g., service unit, service topology) which exposes this implemented capability.

Add a custom footer
Add a custom sidebar
Clone this wiki locally