There is tremendous interest in development around ONAP. We hear CSPs and vendors talk about activities such as:
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 Networks' 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:
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:
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:
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.
