Page History

...

• MUSIC as a service: while MUSIC was consumed internally by components in the Beijing release, in Cassablanca 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 fully sharded, scale out system, 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 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 Cassablanca

Use Cases

• Targeted goal for for Cassablanca
  • 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 R4Cassablanca: SDN-C will use the MUSIC PROM recipe for automated and consistent failover across sites. 
  
  

...