7 About Network Function Virtualization
This chapter describes the concepts and implementation of network function virtualization for Oracle Communications Evolved Communications Application Server (OCECAS), which is pre-integrated with Oracle Communications Application Orchestrator (OCAO) to centrally manage and automate your virtual network deployment.
For information on configuring and administering network function virtualization, see "Managing Network Function Virtualization" in Oracle Communications Evolved Communications Application Server System Administrator's Guide. For information on using Oracle Communications Application Orchestrator, see Oracle Communications Application Orchestrator User Guide.
Overview
Network function virtualization (NFV) virtualizes network node functions into building blocks that you can connect to create communication services. A virtualized network function (VNF) consists of one or more virtual machines running software and processes on industry-standard, high-volume servers, switches, storage, or even cloud computing infrastructure, instead of using custom hardware appliances for each network function.
NFV requires running OCECAS as a series, or cluster, of virtual machines. A VNF manager controls the automatic deployment and shutdown of VMs, based on various load conditions. Oracle Communications Application Orchestrator is a VNF manager.
OCAO supports Oracle OpenStack for Oracle Linux 1.0 and vCloud Director 5.5.x (VMware) and as Virtual Interface Managers (VIMs)/Network Function Virtualization Infrastructure (NFVI) interface. OCAO supports KVM, OVM_PV and OVM_HVM hypervisors under Oracle OpenStack and ESXi hypervisor under vCloud Director. For more information on which environments are supported by your version of OCAO, please refer to the product documentation.
Figure 7-1 illustrates the OCECAS NFV architecture.
Figure 7-1 Figure 7-1 OCECAS NFV Architecture
Description of ''Figure 7-1 Figure 7-1 OCECAS NFV Architecture''
Table 7-1 describes the major NFV components:
| Component | Description | Example |
|---|---|---|
|
VNFx |
The running network application |
OCECAS |
|
CNF |
A composite network function, which is a network function that can be physical or virtual, or both. This is the main configuration element for an AO plugin. This is the closest equivalent to the ETSI VNF definition. For OCECAS, there is one CNF for each domain. |
Managed Server |
|
EMS |
The management function of the VNF. |
Oracle Communications Session Element Manager. Also known as Net-Net Central or OC Session Delivery Manager |
|
NFVI |
The physical resources and the VM software |
VMWare, OpenStack, or Oracle Virtual Machine |
|
VIM |
The orchestration manager, which controls the NFVI resources and the interaction of the VMs with them. |
Oracle Enterprise Manager Orchestration Engine or OpenStack |
|
VNF Manager |
Gathers statistics from the VNFs and instructs VIM to alter VMs. Automates deployment and shutdown of VMs. |
Oracle Communications Application Orchestrator |
In a traditional implementation, an element manager collects application statistics from the VMs and reports them as key performance indicators (KPIs) to OCAO. OCAO collects statistics from the VNFs (via the EMS) and applies configured logic to decide if more VNFs should be added or removed.
For OCECAS there is no physical element manager. A combination of the administration or managed server and the OCAO adapter performs the role of element management.
About the OCECAS NFV Topology
OCECAS is divided into multiple CNFs based on various factors like KPI rules, policies, deployment environments and logical functionality. These CNFs consist of a single management CNF and multiple runtime CNFs, one for each testing, staging and production environment.
Figure 7-2 illustrates the OCECAS NFV topology.
About the Management CNF
By design, the management platform is not a good candidate for horizontal scaling based on KPIs. The management platform is used primarily by service designers and does not expand beyond a predictable limit. Scaling for the future needs of database storage and throughput can be accomplished within a single VM.
The management CNF does not need runtime scaling but does require a separate VM. For more information, see "Configuring the Domain and CNF and "Example CNFD Parameters for a Management Domain" in Oracle Communications Evolved Communications Application Server System Administrator's Guide.
About the Runtime CNF
The runtime CNF consists of two network function groups, the engine group and the UDR group. Each group can scale independently.
For information about the CNF description parameters, see "Configuring the Domain and CNF" in Oracle Communications Evolved Communications Application Server System Administrator's Guide.
About the Engine Group
The engine forms the runtime environment for OCECAS. The runtime environment is where live calls execute the control flows that are designed and stored on the management platform. Data from the management platform is replicated to a Coherence cache that the engines read.
Any updates to a Coherence cache are replicated across all of the caches so scaling does not adversely affect the Coherence cache.
About the UDR Group
The UDR is a NoSQL database that holds subscriber and service information that you provision through the RESTful API. NoSQL provides for scaling of nodes and supports the scaling philosophy. For more information about the NoSQL database, see "About Managing and Using Subscriber Data" in this guide and "Working with Subscriber Data" in Oracle Communications Evolved Communications Application Server Operator's Guide.
For information on administering NoSQL, see the Oracle NoSQL Database Administrator's Guide.
About the OVA File
The OCECAS AO adapter requires an Open Virtualization Archive (OVA) image of a virtual device to apply VM configuration and deploy instances. The OCECAS AO adapter uploads a separate OVA file into OCAO for each NF group. The file contains application-specific configuration information for OCECAS, such as Java Message Service (JMS), data source, and so on. For the procedure to create the OVA file, see "Creating the OVA Image File", in Oracle Communications Evolved Communications Application Server System Administrator's Guide.
Table 7-2 describes the components that OVA files must have installed and configured for each type of NF group.
Table 7-2 Installed Components for Each NF Group
| NF Group (Domain) | Components |
|---|---|
|
Management |
OCECAS Management platform installed Managed server, machines and node manager created and configured Note: Oracle database is not installed on management image. The database has to be installed separately before activating management administration because of OPSS. When management administration is activating it needs to create the schema for OPSS. |
|
Runtime |
Runtime needs an image with SCF template installed AO will add and configure the managed servers, machines and node manager |
|
UDR |
Oracle NoSQL Database, NoSQL should not be configured as it will be done by AO Adaptor OCECAS UDR from UDR template AO will add and configure the managed servers, machines and node manager |
For more information about the OVA file, see Oracle Communication Application Orchestrator User Guide.
About Deployment
Table 7-3 describes the deployment policy that OCECAS enforces for each type of deployment unit.
About Bootstrapping
The OCECAS AO adapter facilitates the specific configuration that must be made on a device at the time of deployment for each deployment unit. For more information see "Specifying Boot Parameters" in Oracle Communications Evolved Communications Application Server System Administrator's Guide.
About the AO Adapter
OCECAS provides a customized adapter that plugs into the OCAO framework to interface with OCECAS. The adapter is contained in a .zip file that is deployed into the OCAO plugins directory. For OCECAS, this file is ocecasaoAdaptor.zip.
The adapter uses the OCCAS-layer interface for communication with the administration server to gather KPI information. This OCCAS layer uses ssh commands to execute WebLogic Scripting Tool scripts that are delivered as part of OCCAS, which is embedded in OCECAS.
Figure 7-3 illustrates the interface between the OCAO adapters and the CNF.
Figure 7-3 Interface Between OCAO and CNF
Description of ''Figure 7-3 Interface Between OCAO and CNF''
About Key Performance Indicators
OCECAS makes the following VM-hardware key performance indicators (KPIs) available:
-
CPU
-
Memory
-
Threads
-
TCP connections or ports used
-
Disk utilization (network I/O)
-
JVM statistics
By default, the OCECAS installation configures KPIs for CPU, memory and disk usage. OCECAS configures the engine and UDR VMs to scale on these three statistics. OCECAS does not configure the administration servers or the management VMs to scale.
For information on monitoring and managing overload conditions, see "Monitoring and Managing Overload Conditions" in Oracle Communications Evolved Communications Application Server System Administrator's Guide.
About Capacity and Scaling
The OCECAS AO adapter determines what CNF resources are needed for any given input criteria, allowing it to deploy a CNF based on that criteria. Using available key performance indicators, the adaptor determines if capacity is over a threshold criteria and decides whether scaling is required, including whether horizontal or vertical scaling is needed.