User Guide 17/1553-AXM10104/1 Uen S

VNF Life Cycle Management
Virtual Multimedia Resource Function

Contents


1 Introduction

This document contains information for system administration tasks performed in the VNF Lifecycle Manager (VNF-LCM). VNF-LCM provides a workflow execution environment and a web-based application for managing VNF life cycle procedures.

VNF life cycle procedures are realized by executing ordered sequences of steps, called workflows. Each workflow must be provided with VNF-specific input parameters during execution.

The workflows can be managed and monitored interactively from the VNF-LCM GUI or non-interactively through the Northbound Interface (NBI) REST API. In the latter case, the workflows can be triggered from the Ericsson Orchestrator (EO) through the Or-Vnfm interface.

The following applies for life cycle operations for EO through the Or-Vnfm interface:

  • EO is the only supported NFVO.

  • The only supported workflows are instantiation and termination.

  • The supported VIM is OpenStack.

2 Prerequisites

This section provides information on the tools and conditions that apply to the procedures in this document.

Before performing any VNF-LCM procedure, ensure that the following conditions are met:

  • The software delivery package including vIMS workflows, VNF-specific Heat Orchestration Template (HOT) files, example environment files, and the VNF-LCM scripts is available.

  • VNF-LCM is available using either Operations Support System, Radio and Core (OSS-RC) or Ericsson Network Manager (ENM).

  • EO is available.

  • In EO, the VIM zone, VDC, and SRT are configured, the external VNFM is registered. For more information on configuring EO, see System Administration Guide, Reference [1].

  • The workflow bundle RPM is installed as described in the relevant network management system documentation. For more information, see VNF-Lifecycle Manager System Administration Guide, Reference [1].

  • The following minimum version requirements are met:

    • Virtual Infrastructure Managers (VIMs):

      • CEE: R6 or newer

      • OpenStack: Mitaka or newer

    • vIMS workflows: 1.12.0

    • VNF-LCM: 18.12 or higher (minimum SW media version: 4.7.13)

    • EO: 18.0

  • The VIM is configured in VNF-LCM.

    Note: The VIM configuration in VNF-LCM can be checked with the vnflcm vim list command.

    For more information on configuration and the command, see VNF-Lifecycle Manager System Administration Guide, Reference [2].

  • The cloud environment is prepared for the deployment of the VNF, that is, the following activities are performed:

    • Cloud hardware and software preparation and configuration

    • Flavor creation

    • Network topology creation

    • Subnet creation

    For detailed instructions, see the relevant deployment instructions.

3 Prepare VNF Deployment Parameters

The VNF-LCM uses the parameters of the env.yaml file as input for VNF instantiation, therefore they must be defined to match your network environment.

The mrf_config parameter of the env.yaml file contains the VNF configuration either from a backup of an older VNF, or prepared by Ericsson, to be used for instantiation. This procedure describes how to prepare VNF deployment parameters with detailed instructions on providing the value for the mrf_config parameter.

Note: The yaml files included in the examples folder of the software delivery package serve as examples for a possible network configuration. They can be modified to match your network environment.

Steps

  1. Extract the node_configuration/is.xml file from the compressed configuration file.
    Note: The compressed configuration file can either be a tar or a zip file.
  2. Pack the is.xml file to the mrsv-config.tar.gz file using the vmrs_config_update.py script from the software delivery package:
    ./vmrs_config_update.py -c mrsv-config.tar.gz -sxf is.xml
    Note: The mrsv-config.tar.gz file must exist before using this command; running vmrs_config_update.py does not create the tar.gz file. If there is no previous backup file available, use the example configuration file (example_config.tar.gz) from the software delivery package.

    For more information on the example configuration file, see Initial Configuration Guide.

  3. Generate a Base64-encoded value of the VNF configuration for the mrf_config parameter using the following command:
    base64 -w 0 <file_path_of_mrsv-config.tar.gz> > <file_for_Base64_encoded_string>
  4. Add the Base64-encoded string from the <file_for_Base64_encoded_string> file as a value of the mrf_config parameter to the following file:

    • In the case of small stack setup, to the env.yaml file

    • In the case of full stack setup, to the VNFD_Wrapper.json file

  5. Ensure that all deployment HOT file parameters are assigned a correct value:

    • In the case of small stack setup: parameters specified in /vnflcm-ext/current/vnf_package_repo/<vnfdId_as_directory_name>/configurations/<example_configuration_1>/env.yaml

    • In the case of full stack setup: parameters specified under instantiateVnfOpConfig of /vnflcm-ext/current/vnf_package_repo/<vnfdId_as_directory_name>/Resources/VnfdWrapperFiles/VNFD_Wrapper.json

  6. Ensure that all deployment HOT file parameters specified in the /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/configurations/example_configuration_1/env.yaml folder are assigned a correct value.
  7. Add any missing deployment parameters and their default values to the env.yaml file.

4 Onboarding

This section gives information on onboarding options, and contains procedures on onboarding the Virtual Deployment Package on EO and VNF-LCM.

Small stack scenario  

In this case, the HOT and environment yaml files of the software delivery package are onboarded on VNF-LCM, and the cloud environment is prepared for the deployment of the VNF (that is, image upload, flavor and network topology creation are handled in the cloud environment). In this scenario, no orchestrator is involved during onboarding procedure. For more information on the small stack onboarding procedure, see Onboard the Virtual Deployment Package on VNF-LCM.
Full stack scenario  

In this case, besides VNF-LCM and the cloud environment, an orchestrator (namely, the EO) is involved in the onboarding procedure. The cloud environment preparation is the same as in the small stack scenario, while onboarding on VNF-LCM differs slightly from the small stack setup. For more information on the full stack onboarding procedure, see Onboard the Virtual Deployment Package on EO and Onboard the Virtual Deployment Package on VNF-LCM.

4.1 Small Stack Scenario

4.1.1 Onboard the Virtual Deployment Package on VNF-LCM

This section describes how to prepare for workflow-based VNF operations using VNF-LCM. Performing this procedure is a prerequisite for life cycle operations.

Prerequisites

Steps

  1. Create a <VNFType__VNFVersion> directory for the VNF-specific files in /vnflcm-ext/current/vnf_package_repo/.
    mkdir /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>
    Note:

    The directory name in the examples follows the naming convention as above: VNF type and VNF version separated by "__". It is not mandatory to follow this naming convention.

  2. Copy the release-specific zip file provided in the software delivery to the directory created in Step 1.
    cp <release-specific_zip_file_path> /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/
  3. In /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>, unzip the release-specific zip file.
    cd /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/ && unzip <release-specific_zip_file_name>

    Result: The directory Resources and the vmrf.yaml file are created in /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>.

  4. Identify the value of the vnfdId using the following command:
    grep vnfdId Resources/VnfdWrapperFiles/VNFD_Wrapper.json
    "vnfdId": "<vnfdId_in_VNFD_Wrapper.json>"
  5. Rename the directory created in Step 1 to the value of the vnfdId using the following command:
    mv /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion> /vnflcm-ext/current/vnf_package_repo/<vnfdId_from_grep_"vnfdId"_command_printout>
  6. In /vnflcm-ext/current/vnf_package_repo/<vnfdId_from_grep_"vnfdId"_command_printout>, create a configurations subdirectory with write permission for the jboss_user, and a child directory for each VNF configuration. This allows for storing multiple VNF configurations.
    Note: Each directory in configurations shall contain a VNF-specific env.yaml environment file. Each env.yaml file can be used for a different VNF instantiation, depending on, for example, network needs.
  7. Grant the following permissions for jboss_user:

    Directory

    Permission

    Command

    /vnflcm-ext/current/vnf_package_repo/<vnfdId>

    read, execute

    chmod 755 /vnflcm-ext/current/vnf_package_repo/<vnfdId>

    /vnflcm-ext/current/vnf_package_repo/<vnfdId>/configurations

    write, execute

    chmod 777 /vnflcm-ext/current/vnf_package_repo/<vnfdId>/configurations

    /vnflcm-ext/current/vnf_package_repo/<vnfdId>/configurations/<configuration>

    read, execute

    chmod 755 /vnflcm-ext/current/vnf_package_repo/<vnfdId>/configurations/<configuration>

    /vnflcm-ext/current/vnf_package_repo/<vnfdId>/Resources/LcmScripts

    read, execute

    chmod 755 /vnflcm-ext/current/vnf_package_repo/<vnfdId>/Resources/LcmScripts

Depending on the vIMS workflow version, store the private and public SSH keys:

  • If using vIMS workflow version 1.12.0 or lower, continue with the next step.

  • If using vIMS workflow version 1.13.0 or higher, continue with Step 9.

  1. Add the private SSH key to the /home/jboss_user/.ssh/ folder, and the corresponding public SSH key in the admin_authorized_key parameter of the env.yaml file of each configuration stored.
    Note: If the SSH key is not available yet, create it using the ssh-keygen -t rsa command, as jboss_user:

    sudo -u jboss_user bash -c 'ssh-keygen -t rsa -f ~/.ssh/id_rsa && cat ~/.ssh/id_rsa.pub'

  2. If missing, add the private SSH key to the /vnflcm-ext/backups/private_keys/workflows/default/.ssh folder, and the corresponding public SSH key in the admin_authorized_key parameter of the env.yaml file of each configuration stored.

    The public key can be obtained by using the following command:

    sudo -u jboss_user cat /vnflcm-ext/backups/workflows/private_keys/default/.ssh/id_rsa.pub

    If the SSH key or the .SSH folder is not available, create them using the following command, as jboss_user:

    sudo -u jboss_user bash -c 'cd /vnflcm-ext/backups/workflows/private_keys/default && mkdir .ssh && chmod 0700 .ssh && ssh-keygen -P "" -t rsa -f .ssh/id_rsa'

4.2 Full Stack Scenario

4.2.1 Onboard the Virtual Deployment Package on EO

This section describes how to prepare for workflow-based VNF operations using EO. Performing this procedure is a prerequisite for life cycle operations.

Prerequisites

  • You are logged in to EO.

Steps

  1. In EO, click Resources > Packages.
  2. On the opening Upload VNF Package screen, in New Package File, add the zip file matching the deployment scenario from the software delivery package.
  3. In New Configuration File, upload the Resources/VnfdWrapperFiles/VNFD_Wrapper.json file.

    After this step, the content of VNFD_Wrapper.json is displayed in the New Configuration File Content field.

  4. Copy the value of parameter vnfdId from the configuration file to the New Package Name field.
  5. Fill in the following mandatory fields:

    • Package Version

    • Package Vendor

    • Software Version

    • Package Category

    • Description

  6. In the Managers field, select the VNF-LCM used.
  7. Click Start.

Results

After clicking Start, the onboarded package is visible in EO under Resources > Packages.

4.2.2 Onboard the Virtual Deployment Package on VNF-LCM

This section describes how to prepare for workflow-based VNF operations using VNF-LCM. Performing this procedure is a prerequisite for life cycle operations.

Prerequisites

Steps

  1. Create a <VNFType__VNFVersion> directory for the VNF-specific files in /vnflcm-ext/current/vnf_package_repo/ and copy the deployment-specific .zip file uploaded to EO into it.
    Note: The directory name in the examples follows the naming convention as above: VNF type and VNF version separated by "__". It is not mandatory to follow this naming convention.
    mkdir /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>
    cp <deployment-specific_zip_file_path> /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/
  2. In /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>, unzip the deployment-specific zip file.
    cd /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/ && unzip <deployment-specific_zip_file_name>

    Result: The directory Resources and the vmrf.yaml file are created in /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>.

  3. Identify the value of the vnfdId using the following command:
    grep vnfdId Resources/VnfdWrapperFiles/VNFD_Wrapper.json
    "vnfdId": "<vnfdId_in_VNFD_Wrapper.json>"
  4. Rename the directory created in Step 1 to the value of the vnfdId using the following command:
    mv /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion> /vnflcm-ext/current/vnf_package_repo/<vnfdId_from_grep_"vnfdId"_command_printout>

5 Procedures

The following sections describe how to perform LCM operations.

VNF-LCM procedures utilize workflow instances. Figure 1 shows an example of a workflow instance, where workflow progress can be tracked in the Workflow Diagram view. The Workflow Diagram only represents stages of the various procedures, operations are performed in the Task view.

It is not recommended to execute a workflow instance on a VNF while another one is in progress, as it can lead to unexpected behavior. If a new workflow procedure is needed, the ongoing one must be terminated before starting a new one.

Figure 1   Workflow Instance Overview

5.1 Instantiate VNF

This section describes how to instantiate a VNF using VNF-LCM.
Note: When instantiating a VNF on a VIM running on BSP, make sure there are no active Capture Jobs on BSP, or the instantiation fails.

Steps

  1. In the VNF-LCM Workflows screen, select Instantiate VNF, and click the Start a New Instance button.
    Figure 2   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, add VNF Name and VNF Instance Description, select VNF to instantiate, and click Submit.

    Select the Add Network Element in ENM/OSS-RC check box to add the new VNF in the network management application.

    Note: The VNF Name is also used as the Heat stack name. It is not recommended to add version information in this field, as the name is unchanged after VNF upgrades.

    The Select VNF descriptor Id field displays VNF releases available for instantiation in the /vnflcm-ext/current/vnf_package_repo/ directory.

    Figure 3   Instantiate VNF
  5. On the Select VIM screen, select the VIM to be used, and click Submit.
    VNF_LAF_01-inst-3-vim2_edit.png Figure 4   Select VIM
  6. On the Select Tenant screen, select the tenant to be used, and click Submit.
    VNF_LAF_01-inst-4-tenant_edit.png Figure 5   Select Tenant
  7. On the Get Instance Configuration screen, select a VNF configuration to instantiate, and click Submit.
    Note: The Select Configuration for the VNF instance field displays VNF configurations available for instantiation in the /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/configurations directory.
    Figure 6   Get Instance Configuration

If the Add Network Element in ENM/OSS-RC check box was selected in Step 4:

  1. If the ENM network management application is used, provide VNF-related parameters for ENM, and click Submit.
    Note: To fill out the Network element version supported by OSS/ENM field, check the supported VNF version with the following command:

    cmedit describe --netype <VNF_type>

    Figure 7   Get OSS or ENM Parameters

Results

The VNF is instantiated, it starts handling traffic after configuration data is provided. For more information on providing configuration data, see Deployment Guide for OpenStack or Deployment Guide for Cloud Execution Environment (CEE), and Initial Configuration Guide.

5.2 Upgrade VNF

This section describes how to upgrade a VNF using VNF-LCM.

To perform this procedure without traffic stoppage, it is required that two VNFs are available in parallel during normal operation. During the upgrade process, configuration data is exported from the VNF selected to be upgraded. The VNF then is locked and removed. A new version of the VNF is deployed with configuration data of the previously removed VNF.

Prerequisites

  • All parameters are transferred from the old VNF, except for mrf_image and mrf_flavor.

  • The configuration file (env.yaml) of the new VNF contains the parameters mrf_image and mrf_flavor with the new image version ID from OpenStack.

  • Parameters introduced in the new VNF version are set in the configuration file.

    Note: Other parameters in the target configuration file are overwritten by the exported ones.

Steps

To use the optional customer security layer between LM and NeLS in the new VNF, perform the following step before starting the upgrade VNF-LCM operation:

  1. Back up the following files from the /storage/system/config/lm-apr9010503/certs folder:

    • The Certificate Authority (CA) file

    • The Client Certificate file

    • The Client Private Key file

    • certificate_config.xml

  2. In the VNF-LCM Workflows screen, select NR-Upgrade VNF, and click the Start a New Instance button.
    Figure 8   Select Workflow
  3. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  4. Select the newly created workflow from the Instance Activity panel.
  5. On the Workflow Instance screen, select the VNF to upgrade, termination options, and set automatic rollback timer, and click Submit.
    VNF_LAF_select_VNF_to_upgrade.png Figure 9   Select VNF to Upgrade
    The following termination options are available:
    Graceful  

    The VMs in the cluster are gracefully locked, the VNF instance gradually stops processing traffic. The VNF is terminated after the expiration of the graceful termination period.
    Forceful  

    The VNF is terminated immediately, all ongoing traffic is lost. This option must be confirmed on the next screen, as it stops all traffic.
    Graceful termination timeout (sec)  

    The graceful termination timeout value defines after how many seconds the VNF is terminated when graceful termination has been applied but there is still ongoing traffic. Default value: -1, meaning that there is no graceful termination period, that is, the VNF is terminated only after all VMs stopped processing traffic.
  6. On the Set VNF and target VNF version screen, add new VNF name, description, and version descriptor ID.
    Figure 10   Set VNF and Target VNF Version
  7. On the Select Target Instance Configuration Data screen, select configuration data for the new VNF.

If the Add Network Element in ENM/OSS-RC check box was selected during VNF instantiation:

  1. If the ENM network management application is used, provide VNF-related parameters for ENM, and click Submit.
    Note: To fill out the Network element version supported by OSS/ENM field, check the supported VNF version with the following command:

    cmedit describe --netype <VNF_type>

After this step, the old VNF is terminated according to the termination method chosen in Step 5, and the new version is instantiated with the configuration data selected in Step 7.

If the new VNF fails to instantiate, it is automatically terminated and the old VNF is recreated with the _r suffix in its stack name.

If the new VNF is instantiated successfully, the Confirm upgrade screen is displayed, and the automatic rollback timer set in Step 5 is started.

  1. Check that traffic processing in the new VNF version is working properly.

    • If the operation of the new version is considered acceptable, select Confirm and click Submit.

    • If there are problems with the new version that cannot be solved and that are considered unacceptable, select Rollback and click Submit. The rollback procedure terminates the VNF and recreates the old VNF with the _r suffix in its stack name.

    Figure 11   Confirm Upgrade or Rollback
    Note: If neither option is chosen before the automatic rollback timer expires, the new VNF is removed and the old one is instantiated automatically.

If the optional customer security layer between LM and NeLS is to be used in the new VNF, perform the following step:

  1. Copy the following certificate files to /storage/system/config/lm-apr9010503/certs in the new version:

    • The Certificate Authority (CA) file

    • The Client Certificate file

    • The Client Private Key file

    • certificate_config.xml

Results

After the upgrade procedure is confirmed, the new version VNF continues accepting new incoming traffic.

5.3 Scale VNF

This section describes how to scale a VNF using VNF-LCM.

Continue with this procedure only if the VNF to be scaled was instantiated using the VNF-LCM.

Steps

  1. In the VNF-LCM click Start a Workflow, select Scale VNF, and click the Start a New Instance button.
    Figure 12   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, specify the following details and click Submit:

    • VNF instance to be removed

    • Scaling type

    • Number of VMs to be added or removed

    Figure 13   VNF Scaling Details
  5. If Scale In was selected, specify the needed parameters, on the Collect extra parameters screen. Otherwise, the scaling procedure is completed.
    Note: This step is optional, leave the fields blank if none of these parameters are needed.
    Figure 14   Scale-in VNF Instance
    The following optional scale-in parameters are available:

    • UUIDs of specific VMs to be scaled-in

      Note: If the number of UUIDs specified is lower than the number of VMs given in the previous step, the workflow automatically scales-in the remaining VMs.

    • VM locking method, that is, graceful or forceful

    • If VMs are locked gracefully, a timer for graceful lock

5.4 Heal VNF

This section describes how to heal a VNF using VNF-LCM.

Continue with this procedure only if the VNF to be healed was instantiated using the VNF-LCM.

Steps

  1. In the VNF-LCM Workflows screen, select Heal VNF, and click the Start a New Instance button.
    Figure 15   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, select the VNF to be healed, and click Submit.
    VNF_LAF_Heal_collect_mandatory.JPG Figure 16   Heal VNF
  5. On the Input additional parameters for workflow screen, specify VMs to be removed from the cluster, and click Submit.
    VNF_LAF_Heal_collect_uuid.JPG Figure 17  

Results

The VNF instance is scaled-in, the specified VMs are forcefully removed from the cluster. After this, the VNF instance is scaled-out, the same number of VMs is added to the cluster.

5.5 Terminate VNF

This section describes how to terminate a VNF using VNF-LCM.

Continue with this procedure only if the VNF to be terminated was instantiated using the VNF-LCM.

Steps

  1. In the VNF-LCM Workflows screen select Terminate VNF, and click the Start a New Instance button.
    Figure 18   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, select the VNF to terminate, termination options, and click Submit.
    Figure 19   Terminate VNF
    The following termination options are available:
    Graceful  

    The VMs in the cluster are gracefully locked, the VNF instance gradually stops processing traffic. The VNF is terminated after the expiration of the graceful termination period.
    Forceful  

    The VNF is terminated immediately, all ongoing traffic is lost. This option must be confirmed on the next screen, as it stops all traffic.
    Graceful termination timeout (sec)  

    The graceful termination timeout value defines after how many seconds the VNF is terminated when graceful termination has been applied but there is still ongoing traffic. Default value: -1, meaning that there is no graceful termination period, that is, the VNF is terminated only after all VMs stopped processing traffic.

Results

The VMs in the cluster are terminated with the method selected in Step 4, the VNF instance stops processing traffic, and is terminated.

Reference List

[1]

System Administration Guide, 1543-CNH 160 9180

[2]

VNF-Lifecycle Manager System Administration Guide, 1543-APR 901 0578
Legal |© Ericsson AB 2017–2019