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.
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.
- 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
autoscaling/pluginsto let it start automatically; or started manually. (if Zabbix is the monitoring system of choice)
How to install AutoScaling Engine
If you have the bootstrap procedure and selected the installation of the ASE component, you could skip this section, and move to the How to use AutoScaling Engine one.
Otherwise, please continue with this section. Different options are available for the installation of the AutoScaling Engine. Either you use the fully automated bootstrap where all configurations are done automatically choosing between either the debian based installation or the source code one. In case you don't use the bootstrap procedure, you can still install the ASE component individually either via apt-get or gradle.
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:
Now you can install the NSE by executing:
apt-get install openbaton-ase
Installation from the source code
The latest version of the 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 and start as done below:
./autoscaling-engine.sh compile start
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.
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.
This chapter describes the parameters that must be considered for configuring the AutoScaling Engine.
|location of the logging file
|logging levels of the defined modules
|IP 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.
|Port where the System is reachable
|IP of the machine where RabbitMQ is running. This is needed for communicating with the monitoring plugin.
|Service Key obtained when registering the
autoscaling-engine service via the NFVO.
|username for authorizing towards RabbitMQ
|password for authorizing towards RabbitMQ
|IP of the NFVO
|Port of the NFVO
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 on the way you installed this component.
If you installed the ASE with the debian packages you can start it with the following command:
For stopping it you can just type:
If you are using the source code you can start the ASE easily by using the provided script with the following command:
Once the AutoScaling Engine is started, you can access the screen session by executing:
screen -r openbaton
For stopping you can use:
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.
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.
An example using the TOSCA YAML descriptors can be found here.
This AutoScalePolicy indicates a 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.
|This is the human-readable name of the AutoScalePolicy used for identification.
|Is 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.
|This 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.
|This 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.
|This 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.
|This defines the mode of the AutoScalePolicy. This is mainly about the way of recognizing alarms and conditions, like:
PREDICTIVE. At this moment
REACTIVE is provided only.
|The type defines the meaning and the way of processing alarms. Here we distinguish between
SIMPLE. Currently supported is
|The 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.
|The 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.
An alarm defines the conditions in order to trigger the automatic scaling.
|This 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.
|This defines the way of calculating the final measurement result over the group of instances. Possible values are: avg, min, max, sum, count.
|The comparisonOperator defines how to compare the final measurement result with the threshold. Possible values are:
|The threshold defines the value that is compared with the final measurement of a specific metric.
|The 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.
An Action defines the operation that will be executed (if possible) when the scaling conditions are met that are defined in the Alarms.
|The 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.
|The value is related to the type of action.
SCALE_IN expects a value that defines how many instances should be scaled-out or scaled-in,
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
|[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.
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.
|scaling-out a specific number of instances
|scaling-in a specific number of instances
|scaling-out to a specific number of instances
|scaling-in to a specific number of instances