Skip to content

Scaling Network Services and VNF Instances

Reference diagram

The following diagram summarizes the feature:

Diagram explaining auto-scaling support

  • Scaling descriptors can be included and be tied to automatic reaction to VIM/VNF metric thresholds.
  • Supported metrics are both VIM and VNF metrics. More information about metrics collection can be found at the Performance Management documentation
  • An internal alarm manager has been added to MON through the 'mon-evaluator' module, so that both VIM and VNF metrics can also trigger threshold-violation alarms and scaling actions. More information about this module can be found at the Fault Management documentation

Scaling Descriptor

The scaling descriptor is part of a VNFD. Like the example below shows, it mainly specifies:

  • An existing metric to be monitored, which should be pre-defined in the monitoring-param list (vnf-monitoring-param-ref).
  • The VDU to be scaled (aspect-delta-details:deltas:vdu-delta:id) and the amount of instances to scale per event (number-of-instances)
  • The thresholds to monitor (scale-in/out-threshold)
  • The VDU's (vdu-profile:id) minimum and maximum amount of scaled instances to produce
  • The minimum time it should pass between scaling operations (cooldown-time)
  • The minimum amount of scaled instances to produce (max-scale-level)
    scaling-aspect:
    - aspect-delta-details:
        deltas:
        - id: vdu_autoscale-delta
          vdu-delta:
          - id: hackfest_basic_metrics-VM
            number-of-instances: 1
      id: vdu_autoscale
      max-scale-level: 1
      name: vdu_autoscale
      scaling-policy:
      - cooldown-time: 5
        name: cpu_util_above_threshold
        scaling-criteria:
        - name: cpu_util_above_threshold
          scale-in-relational-operation: LT
          scale-in-threshold: 10
          scale-out-relational-operation: GT
          scale-out-threshold: 60
          vnf-monitoring-param-ref: vnf_cpu_util
        scaling-type: automatic
        threshold-time: 1
    vdu-profile:
    - id: hackfest_basic_metrics-VM
      max-number-of-instances: 2
      min-number-of-instances: 1

How to enable/disable autoscaling

With the previous SA architecture based on POL and MON, it is possible to enable/disable autoscaling by patching the POL deployment in kubernetes:

The steps are given below:

  1. To enable the autoscaling feature, modify the env OSMPOL_AUTOSCALE_ENABLED to True in pol deployment:
kubectl -n osm edit deployment pol

OSMPOL_AUTOSCALE_ENABLED: True
  1. To disable the autoscaling feature, modify the env OSMPOL_AUTOSCALE_ENABLED to False in pol deployment:
kubectl -n osm edit deployment pol

OSMPOL_AUTOSCALE_ENABLED: False

With the new architecture, Airflow DAGs for scaling can be selectively disabled in Airflow UI by pressing the toggle next to the DAG to pause/unpause it:

  • scalein_vdu, to enable/disable auto-scale-in
  • scaleout_vdu, to enable/disable auto-scale-out

Example

This will launch a Network Service formed by an HAProxy load balancer and an (autoscalable) Apache web server. Please check:

  1. Your VIM has an accesible 'public' network and a management network (in this case called "PUBLIC" and "vnf-mgmt")
  2. Your VIM has the 'haproxy_ubuntu' and 'apache_ubuntu' images, which can be found here

Get the descriptors:

git clone --recursive https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages.git

Onboard them:

cd osm-packages
osm vnfd-create wiki_webserver_autoscale_vnfd
osm nsd-create wiki_webserver_autoscale_nsd

Launch the NS:

osm ns-create --ns_name web01 --nsd_name wiki_webserver_autoscale_ns --vim_account <VIM_ACCOUNT_NAME>|<VIM_ACCOUNT_ID>
osm ns-list
osm ns-show web01

Testing:

  1. To ensure the NS is working, visit the Load balancer's IP at the public network using a browser, the page should show an OSM logo and active VDUs.
  2. To check metrics at Prometheus, visit http://[OSM_IP]:9091 and look for osm_cpu_utilization and osm_average_memory_utilization (initial values could take some some minutes depending on your telemetry system's granularity).
  3. To check metrics at Grafana, just visit http://[OSM_IP]:3000 (admin/admin), you will find a sample dashboard (the two top charts correspond to this example).
  4. To increase CPU in this example to auto-scale the web server, install Apache Bench in a client within reach (could be the OSM host) and run it towards test.php.
sudo apt install apache2-utils
ab -n 5000000 -c 2 http://<load-balancer-ip>/test.php
# Can also be run in the HAproxy machine.
ab -n 10000000 -c 1000 http://<Private IP of Apache webserver>:8080/
# This will stress CPU to 100% and trigger a scale-out operation in POL.
# In this test, scaling will usually go up to 3 web servers before HAProxy spreads to load to reach a normal CPU level (w/ 60s granularity, 180s cooldown)

If HA proxy is not started

service haproxy status
sudo service haproxy restart

Any of the VMs can be accessed through SSH (credential: ubuntu/osm2021) to further monitor (with htop, for example), and there is an HAProxy UI at port http://[HAProxy_IP]:32700 (credential: osm/osm2018)