Beginning with SBC Core release 12.0, the SBC interoperates with the Ribbon Application Management Platform (RAMP), replacing the Insight EMS.
However, the EMA, CLI and API will continue to include EMS-labeled parameters and screens to facilitate SBC migrations from older releases. Accordingly, any references to "EMS" in this documentation apply to the RAMP platform.
In this section:
The Ribbon Virtual Network Function Manager (VNFM) is an ETSI standards-aligned virtualized application you can use to orchestrate and manage the lifecycle of SBC SWe deployments in an OpenStack cloud environment. VNFM provides an alternative to the use of Heat templates to deploy different types of Virtual Machine (VM) nodes and clusters.
The VNFM processes a VNF Descriptor (VNFD) file to define the main properties and resources required to deploy a VNF. You "onboard" a VNFD file into VNFM for your deployment type as part of a Cloud Service Archive (CSAR) package file.
(SR-IOV only) - additional prerequisites and configuration steps required for SR-IOV deployment are preceded with this notation. If you are implementing SR-IOV interfaces, be sure to complete these steps.
Orchestration using VNFM does not support implementing a second management port for the SBC.
Prior to using VNFM to instantiate SBC Virtual Network Functions. Make sure to:
Due to a current issue with RHEL 7.5, the following procedure must be run once on any compute hosts where SWe instances which require multi-queue virtio interfaces will be deployed. These steps enable such instances to spawn. The procedure confirms that the failure to spawn is due to the underlying RHEL 7.5 issue and then provides steps to work around this issue.
/var/log/audit
audit.log
file and confirm that the following denial is reported by SELinux:avc: denied { attach_queue }
audit2allow -a -M attach_queue
semodule -i attach_queue.pp
The CSAR file you created for your deployment must be onboarded on VNFM before you can orchestrate a new SBC cluster. Make sure the CSAR file is in a location accessible from VNFM. Refer to Performing Onboarding Through the UI for instructions (VNFM documentation).
After the CSAR file is onboarded, the SBC VNF can be deployed. Note that you must have previously created an OpenStack Glance image using the SBC application software .qcow2 file. Refer to Creating a Glance Image within the pre-instantiation requirements for OpenStack.
Click VNF Catalog. The VNF Catalog window opens showing the list of onboarded VNFs.
In the Select Action menu for the VNF you want to deploy, select Instantiate. The Instantiate VNF panel appears. The initial panel is shown in the following figure. The VNF Information section is expanded by default. Click the arrows adjacent to each heading to expand the section and configure its options, as appropriate.
Use the following table to populate or edit the fields. Editing a value overrides the default value in the VNFD file, allowing you to specify the values appropriate for your deployment. Interface values (IF0 to IF3) can be edited, for example, if you need to specify VLAN IDs for your deployment. Take care to use the correct parameter names and maintain the syntax as shown. Refer to the Interface Definition Parameters Table for more information on the parameters that can be used to define the properties of an interface.
Click Instantiate. VNFM begins the process of orchestrating the SBC VNFs. When the process is complete the VNF status changes to Ready.
If you are deploying an N:1 M-SBC, the newly orchestrated VNF remains in a “degraded” state until you configure a Load Balancing Service (LBS). An alarm saying that the VNF cannot connect to VNFM may be triggered. However, once LBS is configured, the active and standby roles for the VMs are determined and the VNF registers successfully with VNFM. Configuring LBS is a part of the initial configuration of an M-SBC. Refer to M-SBC Cluster Configuration using SBC Configuration Manager.
If VNFM shows the SBC status as "Ready," but
By default, during orchestration VNFM creates basic security rules and a security group. These basic rules do not restrict access to and from the SBC nodes. If you have not already created the specific security rules required for your deployment, refer to the following page for the list of rules you should create: Creating Security Group Rules. Alternatively you can enable an option when you create your CSAR package file that creates the recommended security rules automatically. Refer to the "–security_restrict" option described on Creating a CSAR Package File.
After orchestration, the SBC nodes are created but have no associated configuration. Refer to Basic SBC SWe Configuration using SBC Configuration Manager for procedures to configure the SBC.