There is tremendous interest in development around ONAP. We hear CSPs and vendors talk about activities such as:
- Trying out a specific ONAP blueprint e.g. vFW, vDNS, vCPE etc.
- Building a PoC for internal purposes/customer demos
- VNF onboarding (from both a vendor point-of-view and CSP)
- Network service design
- OSS/BSS interfacing
- Policy development
- Closed-loop automation template design
- Alarm correlation
Most developers naturally gravitate towards doing these kinds of development activities on their laptop. However, ONAP cannot be tried out on a typical laptop since it is resource hungry. To solve this problem, we have created our first product -- the Aarna.ml' ONAP Distribution 1.0 Development (or ANOD 1.0 Development for short). We label it "Development" since ANOD 1.0 is not available for production; only for development. Our subsequent releases, of course, will be supported in production deployments. Our ONAP development distribution, based on the ONAP Beijing release, can be installed on GCE or on one single (or more) bare metal server. How did we get it to fit? We have replaced DCAE with CDAP-all-in-one and done some other magic. This way the functionality is intact but the footprint is very light. We have also automated a number of steps to make the distribution very easy to install. Just recently we came across two customers who were stuck at different stages of ONAP installation. One could not get all the containers up, while another one was stuck at vFW deployment (could not complete the closed-loop automation exercise). ANOD 1.0 Development solves issues such as this by being repeatable and simple to use. The one final benefit of ANOD is that it is self-contained with all the working container images for ONAP, so works in environment with limited internet access — something we are finding to be extremely commonplace.
This blog explains how the ONAP can be deployed seamlessly on a bare metal server(s) or on Cloud, using ANOD 1.0 Development.
The ONAP OOM project supports deploying ONAP using Kubernetes. ONAP deployment can be done on a single server (all in one), a single VM (such as Google cloud instance) or multiple servers/VMs. If it is installed on a single server or a Google cloud instance, we will be creating another KVM instance inside this server or VM (using Nested VM feature). If the VM/server requires Openstack too (in addition to ONAP), it is deployed using OPNFV Apex installer. In this case, the number of GCE VMs goes up to 2. We use OOM for deploying ONAP, using Aarna’s pre-built ONAP QCOW images (available on GCloud) for creating ONAP Kubernetes cluster.
ANOD 1.0 Development can be deployed in the following configurations:
- On GCE, using 2 VM’s (one of them running Openstack, and another running ONAP). This can also be supported on other cloud based technologies that support nested VM feature. (Note: This is also used in Aarna’s ONAP Training Labs)
- On single or multiple Bare metal server (that supports nested KVM capabilities), pointing to an external Openstack (not deployed using ANOD)
- On a single Bare metal server (that supports nested KVM capabilities), with Openstack as part of the deployment (all-in-one)
These reference architectures are shown below.
The reference architecture in case of GCE looks as follows:
The reference architecture in case of Bare metal installation (with external Openstack) looks as follows:
The reference architecture in case of a single server (all-in-one) installation looks as follows:
The ONAP deployment is divided into the following steps:
- Deploying OpenStack as a target NFVI cloud for ONAP. This step is optional, in case you already have a Openstack (public or private) deployment that you plan to use for ONAP.
- Downloading KVM images for ONAP that are part of ANOD, which are pre-installed with all the required packages and automation tools.
- Setting up Rancher for Kubernetes environment, which is used to deploy ONAP
- Preparing OpenStack for ONAP, which includes creating the required Cloud resources
- ONAP deployment using Kubernetes/OOM and verifying the functionality
Once these steps are done, the deployment is ready for use, and SDC design and NS/VNF onboarding can be done, using the sample vFW service, or any other custom network service/VNFs.
Each of these steps can be automated, either for deployment in development environment or as part of Jenkins job in Continuous Integration (CI) process. In case of live deployments, the process obviously needs lot more automation and tuning of various components.
In summary, the benefits of ANOD are:
- Able to try out ONAP on 1 GCP VM or single bare metal node
- Easy repeatable installation
- Installation possible without internet connectivity
On GCP: one instance of ANOD is free. Request access here.
On bare metal: ANOD is available on an annual subscription basis. Often times our customers request ANOD with ONAP training. Please contact us for pricing.