Scaling using Offloads

Owned by Srinivasa Addepalli
Last updated: May 07, 2018
2 min read

Background:

ONAP can be used to implement service orchestration

Akraino can be used to implement self-contained edges or edges that work along with regional sites.

Though Akraino was taken as an example here,  one can replace Akraino with any edge stack.

As discussed in the parent page,  there is a need for large number of edges for various use cases including 5G IOT, AR/VR and Live gaming.

it is expected that the number of edges could be in thousands.

ONAP was enhanced in Beijing release with S3P (that includes scaling).  OOM with the help of K8S controllers can bring up multiple instances of each service based on load and also can bring up services across geographical locations for redundancy. MUSIC project and distributed KV store project help in ensuring that stateful data/configuration data is available across all instances.

Though horizontal federation scaling solves many scaling issues,  external controllers which takes of the load off of ONAP are needed for following reasons

  •  Horizontal federation may not scale out thousands of edges. 

  •  Extending ONAP to edge-sites and regional sites (as part of horizontal scaling) can have security issues as all instances share the same information.

  •  value additions by edge stack projects/vendors.

  •  Specifc extensions required at the edge sites/regional-sites

ONAP, to most part, today assumes that the interface to remote sites is mostly via Multi-Cloud project.  Multi-Cloud project scope currently is limited to communicating with external VIMs (resource orchestrators). 

Current thinking is that external controllers do following to take some load off of central ONAP

  • VNF Life Cycle managemnet

  • Fabric Management

  • CE/PE Gateway management

  • Analytics and Closed loop control

Following picture shows AOP suite of external controllers, which is being discussed as part of Akraino project.

To allow AOP to do offload job,  ONAP needs to expose set of interface points for external controllers to hook into.









Above picture shows Akraino WIP initial architecture blocks implementing external controller functionality.

Some points to note:

  • AOP is brought up independent of ONAP.  When AIOP is brought up, it registers with offload interface points of ONAP.

    • AOP is expected to be configured with ONAP-Central FDQN.

    • AIOP controllers connect to ONAP-Central.  If connection does not go through, they continue to attempt connections forever.

  • ONAP OOM does not bring up external controllers (AOP in this case)