Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Warning: Draft Content

This wiki is under construction

Introduction

The ONAP Operations Manager (OOM) is responsible for life-cycle management of the ONAP platform itself; components such as MSO, SDNC, etc. It is not responsible for the management of services, VNFs or infrastructure instantiated by ONAP or used by ONAP to host such services or VNFs. OOM uses the open-source Kubernetes container management system as a means to manage the Docker containers that compose ONAP where the containers are hosted either directly on bare-metal servers or on VMs hosted by a 3rd party management system. OOM ensures that ONAP is easily deployable and maintainable throughout its life cycle while using hardware resources efficiently. There are two deployment options for OOM:

  • A minimal deployment where single instances of the ONAP components are instantiated with no resource reservations, and
  • A production deployment where ONAP components are deployed with redundancy and anti-affinity rules such that single faults do not interrupt ONAP operation.
    When deployed as containers directly on bare-metal, the minimal deployment option requires a single host (32GB memory with 12 vCPUs) however further optimization should allow this deployment to target a laptop computer. Production deployments will require more resources as determined by anti-affinity and geo-redundancy requirements.

OOM deployments of ONAP provide many benefits:

  • Life-cycle Management Kubernetes is a comprehensive system for managing the life-cycle of containerized applications. Its use as a platform manager will ease the deployment of ONAP, provide fault tolerance and horizontal scalability, and enable seamless upgrades.
  • Hardware Efficiency ONAP can be deployed on a single host using less than 32GB of memory. As opposed to VMs that require a guest operating system be deployed along with the application, containers provide similar application encapsulation with neither the computing, memory and storage overhead nor the associated long term support costs of those guest operating systems. An informal goal of the project is to be able to create a development deployment of ONAP that can be hosted on a laptop.
  • Rapid Deployment With locally cached images ONAP can be deployed from scratch in 7 minutes. Eliminating the guest operating system results in containers coming into service much faster than a VM equivalent. This advantage can be particularly useful for ONAP where rapid reaction to inevitable failures will be critical in production environments.
  • Portability OOM takes advantage of Kubernetes' ability to be hosted on multiple hosted cloud solutions like Google Compute Engine, AWS EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more.
  • Minimal Impact As ONAP is already deployed with Docker containers minimal changes are required to the components themselves when deployed with OOM.

Features of OOM:

  • Platform Deployment Automated deployment/un-deployment of ONAP instance(s) / Automated deployment/un-deployment of individual platform components using docker containers & kubernetes
  • Platform Monitoring & healing Monitor platform state, Platform health checks, fault tolerance and self-healing using docker containers & kubernetes
  • Platform Scaling Platform horizontal scalability through using docker containers & kubernetes
  • Platform Upgrades Platform upgrades using docker containers & kubernetes
  • Platform Configurations Manage overall platform components configurations using docker containers & kubernetes
  • Platform migrations Manage migration of platform components using docker containers & kubernetes
    Please note that the ONAP Operations Manager does not provide support for containerization of services or VNFs that are managed by ONAP; the OOM orchestrates the life-cycle of the ONAP platform components themselves.

Container Background

Linux containers allow for an application and all of its operating system dependencies to be packaged and deployed as a single unit without including a guest operating system as done with virtual machines. The most popular container solution is Docker which provides tools for container management like the Docker Host (dockerd) which can create, run, stop, move, or delete a container. Docker has a very popular registry of containers images that can be used by any Docker system; however, in the ONAP context, Docker images are built by the standard CI/CD flow and stored in Nexus repositories. OOM uses the "standard" ONAP docker containers and three new ones specifically created for OOM.

Containers are isolated from each other primarily via name spaces within the Linux kernel without the need for multiple guest operating systems. As such, multiple containers can be deployed with little overhead such as all of ONAP can be deployed on a single host. With some optimization of the ONAP components (e.g. elimination of redundant database instances) it may be possible to deploy ONAP on a single laptop computer.

Life Cycle Management via Kubernetes

As with the VNFs deployed by ONAP, the components of ONAP have their own life-cycle where the components are created, run, healed, scaled, stopped and deleted. These life-cycle operations are managed by the Kubernetes container management system which maintains the desired state of the container system as described by one or more deployment descriptors - similar in concept to OpenStack HEAT Orchestration Templates. The following sections describe the fundamental objects managed by Kubernetes, the network these components use to communicate with each other and other entities outside of ONAP and the templates that describe the configuration and desired state of the ONAP components.

ONAP Components to Kubernetes Object Relationships

Kubernetes deployments consist of multiple objects:

  • nodes - a worker machine - either physical or virtual - that hosts multiple containers managed by kubernetes.
  • services - an abstraction of a logical set of pods that provide a micro-service.
  • pods - one or more (but typically one) container(s) that provide specific application functionality. 
  • permanent volumes - One or more permanent volumes need to be established to hold non-ephemeral configuration and state data.

OOM uses these kubernetes objects as follows.

...

OOM Networking with Kubernetes

  • DNS
  • Ports - Flattening the containers also expose port conflicts between the containers which need to be resolved.
  • Name Spaces

Kubernetes Deployment Specifications for ONAP

Initialization Containers - ONAP has built-in temporal dependencies between containers on startup. Supporting these dependencies will likely result in multiple Kubernetes deployment specifications.

Container Dependencies

Deployment Specs

Development Deployments

Production Deployments

  • Load Balancers
  • Horizontal Scaling
  • Stateless Pods

Kubernetes Deployments

The automated ONAP deployment depends on a fully functional kubernetes environment being available prior to ONAP installation. Fortunately, kubenetes is supported on a wide variety of systems such as Google Compute Engine, AWS EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more.  If you're setting up your own kubernetes environment, please refer to ONAP on Kubernetes for a walk through of how to set this environment up on several platforms.

ONAP 'OneClick' Deployment Walk-though

Once a kubernetes environment is available and the deployment artifacts have been customized for your location, ONAP is ready to be installed. 

The bash script createAll.bash is used to create an ONAP deployment with kubernetes. It has two primary functions:

  • Creating the namespaces used to encapsulate the ONAP components, and
  • Creating the services, pods and containers within each of these namespaces that provide the core functionality of ONAP.

Namespaces provide isolation between ONAP components as ONAP release 1.0 contains duplicate application (e.g. MariaDB) and port usage. As such createAll.bash requires the user to enter a namespace prefix string (e.g. createAll.bash -n onap) that can be used to separate multiple deployments of onap. The result will be set of 10 namespaces (e.g. onap-sdc, onap-aai, onap-mso, onap-message-router, onap-robot, onap-vid, onap-sdnc, onap-portal, onap-policy, onap-appc) being created within the kubernetes environment.

Within the namespaces are kubernete's services that provide external connectivity to pods that host Docker containers. The following is a list of the namespace and the services within:

  • onap-aai
    • aai-service
    • hbase
    • model-loader-service
  • onap-appc
    • dbhost
    • dgbuilder
    • sdnctldb01
    • sdnctldb02
    • sdnhost
  • onap-message-router
    • dmaap
    • global-kafka
    • zookeeper
  • onap-mso
    • mariadb
    • mso
  • onap-policy
    • brmsgw
    • drools
    • mariadb
    • nexus
    • pap
    • pdp
    • pypdp
    • portalapps
    • portaldb
    • vnc-portal
  • onap-robot
    • robot
  • onap-sdc
    • sdc-be
    • sdc-cs
    • sdc-es
    • sdc-fe
    • sdc-kb
  • onap-sdnc
    • dbhost
    • sdnc-dgbuilder
    • sdnc-portal
    • sdnctldb01
    • sdnctldb02
    • sdnhost
  • onap-vid
    • vid-mariadb
    • vid-server

Note that services listed in italics are local to the namespace itself and not accessible from outside of the namespace.

FAQ (Frequently Asked Questions)

Does OOM enable the deployment of VNFs on containers?

  • No. OOM provides a mechanism to instantiate and manage the ONAP components themselves with containers but does not provide a Multi-VIM capability such that VNFs can be deployed into containers.  The Multi VIM/Cloud Project may provide this functionality at some point.

DCAE has its own controller - how is this managed with OOM?

  • The DCAE controller will merge with OOM during the Amsterdam release as described in the Data Collection Analytics & Events Project.  In the short term the DCAE controller is problematic in a container environment as it directly interfaces to OpenStack and request multiple VMs (e.g. CDAP, etc). The short term proposal is to containerize the DCAE components and statically create them as part of the larger ONAP deployment. Advanced DCAE controller features like hierarchical and geographically diverse deployments need further investigation.  

Related Tools


Current Limitations and Feature Requests

  • DCAE - The DCAE component not only is not containerized but also includes its own VM orchestration system. A possible solution is to not use the DCAE Controller but port this controller's policies to Kubenetes directly, such as scaling CDAP nodes to match offered capacity.
  • Single Name Space
  • Deployment Parameter Optimization

Configuration Parameters

Currently ONAP configuration parameters are stored in multiple files; a solution to coordinate these configuration parameters is required. Kubernetes Config Maps may provide a solution or at least partial solution to this problem.

  • Centralized Parameter Control

  • Component Rationalization
    Duplicate containers - The VM structure of ONAP hides internal container structure from each of the components including the existence of duplicate containers such as Maria DB.

Jira Stories


References

Docker
Kubernetes

  • No labels