Sign inSign up

openbaton/ase

By openbaton

•Updated about 8 years ago

External component provides an NFV-compliant AutoScaling Engine (ASE)

Image
0

1.1K

openbaton/ase repository overview

Copyright © 2015-2016 Open Baton⁠. Licensed under Apache v2 License⁠.

⁠AutoScaling Engine

This external component provides an NFV-compliant AutoScaling Engine (ASE). In the following fundamentals are described such as installing the ASE, configuring it and how to use it such as creating AutoScaling policies.

The autoscaling-engine is implemented in java using the spring.io⁠ framework. It runs as an external component and communicates with the NFVO via Open Baton's SDK.

Additionally, the AutoScaling Engine uses the plugin mechanism to allow whatever Monitoring System you prefer. We use Zabbix⁠ as the monitoring system in the following that must be preinstalled and configured. Additional information about zabbix-plugin⁠ can be found here⁠.

Before starting this component you have to do the configuration of the AutoScaling Engine that is described in the next chapter⁠ followed by the guide of how to start⁠ and how to use⁠ it.

⁠Technical Requirements

  • Preconfigured Open Baton environment (NFVO, VNFMs, VIM drivers)
  • Running Zabbix server (if Zabbix is the monitoring system of choice)
  • Preconfgiured and running zabbix plugin either located in the folder NFVO/plugins or autoscaling/plugins to let it start automatically; or started manually. (if Zabbix is the monitoring system of choice)

⁠How to install AutoScaling Engine

Different options are available for the installation of the AutoScaling Engine. Either you use the fully automated bootstrap where all configurations are done automatically where you can choose between the installation based on the debian package or on the source code which is suggested for development. Apart from the bootstrap you can also use the debian or the source code installation where you need to configure the AutoScaling Engine manually.

⁠Installation via bootstrap

Using the bootstrap gives a fully automated installation of this component including installation and configuration. If you use the bootstrap you should place your monitoring plugin of choice directly in the NFVO/plugins folder before starting the orchestrator to have it already available when starting the AutoScaling Engine.

The only thing to do is to execute the following command and follow the configuration process:

bash <(curl -fsSkl https://raw.githubusercontent.com/openbaton/autoscaling-engine/master/bootstrap)

Once you started the bootstrap you can choose between different options, such as installing this component via debian packages or via the source code (mainly for development)

⁠Installation via debian package

When using the debian package you need to add the apt-repository of Open Baton to your local environment with the following command if not yet done:

wget -O - http://get.openbaton.org/keys/public.gpg.key | apt-key add -
echo "deb http://get.openbaton.org/repos/apt/debian/ stable main" >> /etc/apt/sources.list

Once you added the repo to your environment you should update the list of repos by executing:

apt-get update

Now you can install the NSE by executing:

apt-get install openbaton-ase

⁠Installation from the source code

The latest stable version AutoScaling Engine can be cloned from this repository⁠ by executing the following command:

git clone https://github.com/openbaton/autoscaling.git

Once this is done, go inside the cloned folder and make use of the provided script to compile the project as done below:

./autoscaling-engine.sh compile

⁠Manual configuration of the AutoScaling Engine

This chapter describes what needs to be done before starting the AutoScaling Engine. This includes the configuration file and properties, and also how to make use of monitoring plugin.

⁠Configuration file

The configuration file must be copied to /etc/openbaton/openbaton-ase.properties by executing the following command from inside the repository folder:

cp src/main/resources/application.properties /etc/openbaton/openbaton-ase.properties

If done, check out the following chapter in order to understand the configuration parameters.

⁠Configuration properties

This chapter describes the parameters that must be considered for configuring the AutoScaling Engine.

ParamsMeaning
logging.filelocation of the logging file
logging.level.*logging levels of the defined modules
ase.server.ipIP where the AutoScaling Engine is running. localhost might fit for most in the case when the System is running locally. If the System is running on another machine than the NFVO, you have to set the external IP here in order to subscribe for events towards the NFVO properly.
ase.server.portPort where the System is reachable
ase.rabbitmq.brokerIpIP of the machine where RabbitMQ is running. This is needed for communicating with the monitoring plugin.
ase.service.keyService Key obtained when registering the autoscaling-engine service via the NFVO.
spring.rabbitmq.usernameusername for authorizing towards RabbitMQ
spring.rabbitmq.passwordpassword for authorizing towards RabbitMQ
nfvo.ipIP of the NFVO
nfvo.portPort of the NFVO

⁠Monitoring plugin

The montoring plugin must be placed in the folder plugins. The zabbix plugin can be found here⁠ with additional information about how to use and how to compile it. If the plugin is placed in the folder mentioned before, it will be started automatically when starting the AutoScaling Engine. Additionally, you can place the plugin also in the NFVO/plugins folder to let it start automatically.

Note If the NFVO is already in charge of starting the plugin, you should avoid to start it a second time from the AutoScaling Engine. Once started it can be used by all components.

⁠Starting the AutoScaling Engine

How to start the ASE depends of the way you installed this component.

⁠Debian packages

If you installed the ASE with the debian packages you can start it with the following command:

openbaton-ase start

For stopping it you can just type:

openbaton-ase stop
⁠Source code

If you are using the source code you can start the ASE easily by using the provided script with the following command:

./autoscaling-engine.sh start

Once the AutoScaling Engine is started, you can access the screen session by executing:

screen -r openbaton

For stopping you can use:

./autoscaling-engine.sh kill

Note Since the AutoScaling Engine subscribes to specific events towards the NFVO, you should take care about that the NFVO is already running when starting the AutoScaling Engine. Otherwise the AutoScaling Engine will wait for 600 seconds for the availability of the NFVO before terminating automatically.

⁠How to use the AutoScaling Engine

This guide shows you how to make use of the AutoScaling Engine. In particular, it describes how to define AutoScaling Policies.

⁠Creating AutoScaling Policies

A AutoScaling Policy defines conditions and actions in order to allow automatic scaling at runtime. The list of AutoScalePolicies are defined at the level of the VNFD/VNFR. An example of an AutoScalePolicy can be found below followed by descriptions for each parameter.

"auto_scale_policy":[
  {
    "name":"scale-out",
    "threshold":100,
    "comparisonOperator":">=",
    "period":30,
    "cooldown":60,
    "mode":"REACTIVE",
    "type":"WEIGHTED",
    "alarms": [
      {
        "metric":"system.cpu.load[percpu,avg1]",
        "statistic":"avg",
        "comparisonOperator":">",
        "threshold":0.70,
        "weight":1
      }
    ],
    "actions": [
      {
        "type":"SCALE_OUT",
        "value":"2",
        "target":"<target>"
      }
    ]
  }
]

This AutoScalePolicy indicates an scaling-out operation of two new VNFC Instances if the averaged value of all measurement results of the metric cpu load is greater than the threshold of 0.7 (70%). This condition is checked every 30 seconds as defined via the period. Once the scaling-out is finished it starts a cooldown of 60 seconds. For this cooldown time further scaling requests are rejected by the AutoScaling Engine.

The following table describes the meanings of the parameters more in detail.

ParamsMeaning
nameThis is the human-readable name of the AutoScalePolicy used for identification.
thresholdIs a value in percentage that indicates how many sub alarms have to be fired before firing the high-alarm of the AutoScalePolicy. For example, a value of 100 indicates that all sub alarms have to be fired in order to execute the actions of this AutoScalePolicy.
comparisonOperatorThis comparison operator is used to check the percentages of thrown alarms. 100% means that all weighted alarms must be thrown. 50% would mean that only half of the weighted alarms must be thrown in oder to trigger the scaling action.
periodThis is the period of checking conditions of AutoScalePolicies. For example, a value of 30 indicates, that every 30 seconds all the conditions of the defined AutoScalePolicy are checked.
cooldownThis is the amount of time the VNF needs to wait between two scaling operations to ensure that the executed scaling action takes effect. Further scaling actions that are requested during the cooldown period are rejected.
modeThis defines the mode of the AutoScalePolicy. This is mainly about the way of recognizing alarms and conditions, like: REACTIVE, PROACTIVE, PREDICTIVE. At this moment REACTIVE is provided only.
typeThe type defines the meaning and the way of processing alarms. Here we distinguish between VOTED, WEIGHTED, SIMPLE. Currently supported is WEIGHTED
alarmsThe list of alarms defines all the alarms and conditions that belongs to the same AutoScalePolicy. The list of alarms is affected by the mode and the type of the AutoScalePolicy and influences the final check towards the threshold that decides about the triggering of the AutoScalePolicy. Each alarm is composed as defined here⁠.
actionsThe list of actions defines the actions that shall be executed once the conditions (alarms) of the AutoScalePolicy are met and the corresponding actions of the AutoScalePolicy are triggered. Actions are defined as show here⁠.
⁠Alarms

An alarm defines the conditions in order to trigger the the automatic scaling.

ParamsMeaning
metricThis is the name of the metric that is considered when checking the conditions, e.g., cpu idle time, memory consumption, network traffic, etc. This metric must be available through the Monitoring System.
statisticThis defines the way of calculating the final measurement result over the group of instances. Possible values are: avg, min, max, sum, count.
comparisonOperatorThe comparisonOperator defines how to compare the final measurement result with the threshold. Possible values are: =, >, >=, <, <=, !=.
thresholdThe threshold defines the value that is compared with the final measurement of a specific metric.
weightThe weight defines the weight of the alarm and is used when combining all the alarms of an AutoScalePolicy to a final indicator that defines how many alarms must be fired. In this way prioritized alarms can be handled with different weights. For example, there is an alarm with the weight of three and another alarm with the weight of one. If the Alarm with weight three is fired and the second one is not fired, the final result would be 75% in the meaning of three quarters of the conditions are met.
⁠Actions

An Action defines the operation that will be executed (if possible) when the scaling conditions are met that are defined in the Alarms.

ParamsMeaning
typeThe type defines the type of the action to be executed. For example, SCALE_OUT indicates that resources shall be added and SCALE_IN means that resources shall be released. Currently provided types of actions are listed here⁠.
valueThe value is related to the type of action. SCALE_OUT and SCALE_IN expects a value that defines how many instances should be scaled-out or scaled-in, SCALE_OUT_TO and SCALE_IN_TO expects a number to what the number of instances shall be scaled in or out. Supported types of actions are shown here⁠
target[OPTIONAL] The target allows scaling of other VNFs when conditions are met of the considered VNF that includes the policy. The target points to the type of the VNF that should be scaled. If multiple VNFs has the same type, it will be chosen one of them to execute the scaling action. If the target is not defined, it will be executed scaling actions on the same VNF that includes the policy.
⁠Action types

Actions types are the operations that can be executed when defined conditions are met. The following list shows which actions are supported at the moment and what they will do.

ParamsMeaning
SCALE_OUTscaling-out a specific number of instances
SCALE_INscaling-in a specific number of instances
SCALE_OUT_TOscaling-out to a specific number of instances
SCALE_IN_TOscaling-in to a specific number of instances

⁠Issue tracker

Issues and bug reports should be posted to the GitHub Issue Tracker of this project

⁠What is Open Baton?

Open Baton is an open source project providing a comprehensive implementation of the ETSI Management and Orchestration (MANO) specification and the TOSCA Standard.

Open Baton provides multiple mechanisms for interoperating with different VNFM vendor solutions. It has a modular architecture which can be easily extended for supporting additional use cases.

It integrates with OpenStack as standard de-facto VIM implementation, and provides a driver mechanism for supporting additional VIM types. It supports Network Service management either using the provided Generic VNFM and Juju VNFM, or integrating additional specific VNFMs. It provides several mechanisms (REST or PUB/SUB) for interoperating with external VNFMs.

It can be combined with additional components (Monitoring, Fault Management, Autoscaling, and Network Slicing Engine) for building a unique MANO comprehensive solution.

⁠Source Code and documentation

The Source Code of the other Open Baton projects can be found here⁠ and the documentation can be found here⁠

⁠News and Website

Check the Open Baton Website⁠

Follow us on Twitter @openbaton⁠

⁠Licensing and distribution

Copyright [2015-2016] Open Baton project

Licensed under the Apache License, Version 2.0 (the "License");

you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0⁠

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

⁠Support

The Open Baton project provides community support through the Open Baton Public Mailing List and through StackOverflow using the tags openbaton.

⁠Supported by

Tag summary

Content type

Image

Digest

Size

80.6 MB

Last updated

about 8 years ago

docker pull openbaton/ase