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 deployments in an OpenStack environment. Beyond the initial orchestration of a VNF, you can use VNFM to manage the remainder of the VNF's lifecycle. VNFM regularly monitors the health of VNFs through a heartbeat mechanism and regularly reports VNF status on its VNF Status page. VNFM can also be used to migrate, manually heal, and upgrade VNFs. For general information on VNFM and its VNF lifecycle management capabilities refer to the VNFM User Guide. The following sections provide details on lifecycle management of SBC VNFs deployed using VNFM.
As the SBC VNF completes orchestration and initializes for the first time, it registers with VNFM and they begin to exchange heartbeat messages. This heartbeat mechanism regularly monitors the connection between the SBC nodes and VNFM. If the SBC fails to receive a heartbeat message for greater than 30 seconds it triggers an SNMP trap and alarm. The trap is cleared when the SBC resumes receiving the heartbeat messages. Refer to VNFM Alarms for more information on the alarms.
VNFM provides an option to move an SBC node from one cloud location to another in a process referred to as migration. Migrating might be needed when a host system is undergoing maintenance. During the migration procedure you must select a flavor size for the migrated VM. The flavor you select must be different than the current flavor.
An SBC node should only be migrated when it is in standby mode. Use the EMS to determine whether the node you want to migrate is active or standby, or log into the CLI and issue the following command to check the output for the parameter currentRole:
show status system rgStatus
If the node is active, then switch over the node so it becomes the standby node before initiating the migration.
To migrate an SBC VM:
Click on the cluster containing the VM node you want to migrate. The Deployed VNF Summary window opens showing a Generic VM Details section that contains detailed information on the VM nodes within the VNF.
VNFM shows the current, overall status for any deployed SBC VNFs in its VNF Status window. Click on the VNF to open the Generic VM Details window (shown in the preceding figure) where the status of the individual VMs is shown.
When the SBC application goes out of service on a VM, the status of that VM initially changes to "Maintenance." If the VM status remains as "Maintenance" for longer than 10 minutes, its status transitions to "Failed." The overall status of the VNF changes to "Degraded" if any of the VMs within it have a status of "Maintenance or "Failed." Thus, when the status of the VNF changes to "Degraded," it is an indication that there could be an issue with one of its VMs. If needed, VNFM can rebuild the impacted VM node in a process referred to as healing. The healing process offers multiple options you can use to repair the SBC VM node in an effort to restore it to service.
To heal an SBC VM when the VNF status appears as degraded:
Click on the degraded cluster in the VNF Status window. The Deployed VNF Summary window opens showing a Generic VM Details section that contains detailed information on the VM nodes within the VNF. In the following figure the status of the "ribbon-sbc-2" node appears as "Failed."
In the Select Action list adjacent to the failed node, click Heal VM. The Heal VM window appears. There are five options offered for how to repair the VM. The options are shown and explained in the following figure:
You can use VNFM to perform software upgrades on the SBC VNFs you orchestrate through VNFM. Refer to: Upgrading SBC SWe Cloud Instances using VNFM.