Table of Contents
outline true

Overview

...

MUSIC was released in the ONAP Beijing release and provides a service with recipes that individual ONAP components and micro-service can use for state replication, consistency management and state ownership across geo-distributed sites. This is a crucial component enabling ONAP components to achieve S3P in terms of resiliency both within and across sites (platform-maturity resiliency level 3). 

In this release we plan to provide to address the following items:

• MUSIC as a service: while MUSIC was consumed internally by components in the Beijing release, in Dublin we intend to provide MUSIC as an independent multi-site clustered service
• Enable automated failure detection and consistent failover across sites for ONAP components using MUSIC through the PROM recipe. It will require no change to the code of the ONAP components and just a few scripting/configuration steps to achieve single-step automated failover while ensuring that the new leader/owner has access to the latest state information.
• Provide the design to make MUSIC a Provide MUSIC as a fully sharded, scale out systemcommon service, where as many ONAP sites/component replicas can be added as required for performance. The significant technical challenge is to eliminate the need for Zookeeper and build  MUSIC completely based on Cassandra while preserving all its guarantees. We expect this change to improve both deployabiity (just one tool – Cassandra) and performance (initial benchmarks indicate a factor of at least 4-5 times in terms of throughput). This is a crucial precursor for its use in edge computing and as the state management service for a federated ONAP.
• Provide the design seed code to allow MUSIC to support database (RDBMS) clustering across sites using the mdbc recipe wherein ONAP components that require it can continue using a SQL database within a site while using MUSIC is as the underlying transport layer across sites, with much better performance than standard solutions like Gallera clustering. 
• Continued adherence to ONAP S3P requirements in Dublin

...

• Targeted goal for Dublin
  • OOF-Homing Optimizer (HAS) uses MUSIC for its state persistence (as a queue) and as a highly available distributed messaging service. (2) 
  • ONAP Portal will use MUSIC to store its http session state across sites in a persistent manner.  
• Stretch goal for Dublin: SDN-C will use the MUSIC PROM recipe for automated and consistent failover across sites. 
  
  

...