Day 2: VNF Runtime Operations¶
Description of this phase¶
The objective of this section is to provide the guidelines for including all the necessary elements in the VNF Package so that it can be operated at runtime and therefore, reconfigured on demand at any point by the end-user. Typical operations include reconfiguration of services, KPI monitoring and the enablement of automatic, closed-loop operations triggered by monitored status.
The main mechanisms to achieve reconfiguration in OSM is to build a Proxy Charm and include it in the descriptor. On the other hand, monitoring and VNF-specific policy management can be achieved by specifying the requirements at the descriptor (modifying monitored indicators and policies at runtime is not supported in OSM as of version 9)
Day-2 Onboarding Guidelines¶
Adding Day-2 primitives to the descriptor¶
Day-2 primitives are actions invoked on demand, so the config-primitive
block is used instead of the initial-config-primitive
block at the VNF or VDU level.
For example, a VNF-level set of Day-2 primitives would look like this:
vnfd:
...
df:
- ...
# VNF/VDU Configuration must use the ID of the VNF/VDU to be configured
lcm-operations-configuration:
operate-vnf-op-config:
day1-2:
- id: vnf_id
execution-environment-list:
- id: operate-vnf
connection-point-ref: vnf-mgmt
juju:
charm: samplecharm
config-primitive:
- execution-environment-ref: operate-vnf
name: restart-service
parameter:
- name: offset
default-value: 10
data-type: STRING
- name: clean-cache
parameter:
- name: force
default-value: true
data-type: BOOLEAN
### Building Juju-based (charms) or Helm-based execution environments
Juju-based execution environments (charms), or helm-based ones for implementing Day-2 primitives are built exactly in the same way as when implementing Day-1 primitives.
### Adding monitoring parameters
#### Collecting NFVI metrics
In order to collect NFVI-level metrics associated to any given VDU and store them in the OSM TSDB (using Prometheus software), a set of `monitoring-params` should be declared both globally and at the VDU level.
Only CPU, Memory and Network metrics are supported as of OSM version 9. For example:
```yaml
vnfd:
vdu:
- ...
monitoring-parameter:
- id: vnf_cpu_util
name: vnf_cpu_util
performance-metric: cpu_utilization
- id: vnf_memory_util
name: vnf_memory_util
performance-metric: average_memory_utilization
- id: vnf_packets_sent
name: vnf_packets_sent
performance-metric: packets_sent
- id: vnf_packets_received
name: vnf_packets_received
performance-metric: packets_received
Collecting VNF indicators¶
As of OSM version 9, collection of VNF indicators is done by using Prometheus Exporters running as “execution environments”, which translate into PODs instantiated in the same K8s cluster where OSM runs. These PODs follow the VNF lifecycle (as charms do) and are dedicated to the collection of metrics. A first implementation supports SNMP Exporters, to grab scalar provided by any SNMP MIB/OID.
At the VNF package level:
The only file that needs to be created before building it is the “generator.yaml” file at the
helm-charts/chart_name/snmp/
folder, just as in this sample VNF Package, where the chart is calledeechart
.Required MIBs should be included in the
helm-charts/chart_name/snmp/mibs
folder.The rest of the structure inside the
helm-chart
folder shown in the example above needs to be included.
The generator.yaml
file follows the same format as in the open-source Prometheus SNMP Exporter project which we use, documented here
In this example, the interfaces metrics from IF-MIB are collected, using the “public” SNMP community.
# generator.yaml file
modules:
osm-snmp:
walk: [interfaces]
lookups:
- source_indexes: [ifIndex]
lookup: ifAlias
- source_indexes: [ifIndex]
lookup: ifDescr
- source_indexes: [ifIndex]
# Use OID to avoid conflict with Netscaler NS-ROOT-MIB.
lookup: 1.3.6.1.2.1.31.1.1.1.1 # ifName
auth:
# Community string is used with SNMP v1 and v2. Defaults to "public".
community: public
Once the generator.yml
has been created and included in the VNF Package, the descriptor needs to define the helm-based monitoring that will be launched, and running the generate_snmp
primitive, which compiles the MIBs and builds the SNMP Exporter POD configuration.
vnfd:
...
df:
- ...
vnf-configuration-id: default-vnf-configuration
vnf-configuration:
- id: default-vnf-configuration
execution-environment-list:
- connection-point-ref: vnf-mgmt
helm-chart: eechart
helm-version: v2
id: monitor
metric-service: snmpexporter
initial-config-primitive:
- execution-environment-ref: monitor
name: generate_snmp
seq: 2
config-primitive:
- execution-environment-ref: monitor
name: generate_snmp
Adding scaling operations¶
Scaling operations happen at a VDU level and can be added with automatic triggers (closed-loop mode triggered by monitoring-parameters thresholds), or with a manual trigger.
In both cases, a scaling-aspect
section must be added to the VNF Deployment Flavour. The following example enables VDU scaling based on a manual trigger (OSM API or CLI).
vnfd:
df:
- ...
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: 120
name: cpu_util_above_threshold
scaling-type: manual
The following example defines a closed-loop scaling operation based on a specific monitoring parameter threshold.
In this case, the vdu-profile
should specify both min-number-of-instances
and max-number-of-instances
to limit the sum of the original and the scaled instances.
vnfd:
df:
- ...
vdu-profile:
- ...
max-number-of-instances: "2"
min-number-of-instances: "1"
scaling-aspect:
- aspect-delta-details:
deltas:
- id: vdu_autoscale-delta
vdu-delta:
- id: hackfest_basic_metrics-VM
number-of-instances: "1" # how many instances will be added / removed
id: vdu_autoscale
max-scale-level: 1
name: vdu_autoscale
scaling-policy:
- cooldown-time: 120
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: 10
More information about scaling can be found in the OSM Autoscaling documentation
Testing Instantiation of the VNF Package¶
Each of the objectives of this phase can be tested as follows:
Enabling a way of re-configuring the VNF on demand: primitives can be called through the OSM API, dashboard, or directly by running the following OSM client command:
osm ns-action [ns-name] --vnf_name [vnf-index] --action_name [primitive-name] --params '{param-name-1: "param-value-1", param-name-2: "param-value-2", ...}
Monitor the main KPIs of the VNF: if correctly enabled, metrics will automatically start appearing in the OSM Prometheus database. More information on how to access, visualize and troubleshoot metrics can be found in the OSM Performance Management documentation
Enabling scaling operations: automatic scaling should be tested by making the metric reach the corresponding threshold, while manual scaling can be tested by using the following command (which also works when the “scaling-type” has been set to “automatic”):
osm vnf-scale [ns-name] [vnf-name] --scaling-group [scaling-group name] [--scale-in|--scale-out]