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

Compare with Current View Page History

Version 1 Next »

Introduction

The ONAP Operations Manager provides a set of capabilities that facilitate Carrier Grade deployments of ONAP.  ONAP deployments need to be capable of offering service while under adverse conditions typically with overall availability measured at five-nines or 99.999% uptime or about 5 minutes of downtime per year.  This requirement might be strict for an orchestration system, but keep in mind that ONAP’s closed loop control system could be providing monitoring a control for one or more critical VNFs that need to meet stringent up-time requirements as found in the TL 9000 Quality Management System Measurements Handbook.  

The Road to High Availability

The progression of the ONAP project towards a fully Carrier Grade has started and will continue over the Beijing or possibly even subsequent releases.  The steps along this progression are roughly as follows:  

  • Reliable and Repeatable Deployment
  • Backup and Restore
  • Health Monitoring
  • Component Recoverability
  • Centralized Logging
  • Intra Component Clustering
  • Anti-Affinity Rules
  • ONAP S/W Upgrades & Rollbacks
  • Geo-Redundant Deployments

For each of these steps the following sections describe the requirements in more detail and the technologies used to achieve it.

Reliable and Repeatable Deployment

During the Amsterdam release OOM provided a set of capabilities to deploy some or all the ONAP components rapidly and efficiently as a cloud native application with the Kubernetes container orchestration system (note that DCAE is an exception here as DCAE provides its own orchestration system). Each of the components has a deployment specification that describes not only the containers and the container requirements but the relationships or dependencies between the containers.  These dependencies dictate the order in-which the containers are started for the first time such that such dependencies are always met without arbitrary sleep times between container startups.  For example, the SDC back-end container requires the Elastic-Search, Cassandra and Kibana containers within SDC to be ready and is also dependent on DMaaP (or the message-router) to be ready before becoming fully operational. 

Prior to having more advantage carrier grade features available, the ability to at least be able to re-deploy ONAP (or a subset of) reliably provides a level of confidence that should an outage occur the system can be brought back on-line predictably.

Backup and Restore

Health Monitoring

Component Recoverability

Centralized Logging

Intra Component Clustering

Anti-Affinity Rules

ONAP S/W Upgrades & Rollbacks

Geo-Redundant Deployments

  • No labels