| Table of Contents | ||
|---|---|---|
|
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.
Minimum Viable Product
MUSIC service that can serve the geo-redundancy needs of ONAP HAS and ONAP Portal while satisfying the platform maturity requirements for the Dublin release.
...
In the long term we hope that MUSIC will be common, shared state-management system for all ONAP components and micro-services to manage geo-redundancy. For example, we envisage the use of MUSIC for multi-site state management in SO (to store Camunda state across sites), <SDN-C, AppC> (to store ODL related state across sites) , A&AI (to store its graph data) and most other ONAP components that need to manage state across sites. Further, we envision that these services will use the MUSIC recipes (mdbc, prom, musicCAS, musicQ) to achieve the goal of a multi-site active-active federated ONAP solution.
...
| Area | Actual Level | Targeted Level for current Release | How, Evidences | Comments |
|---|---|---|---|---|
| Performance | 1 | 1 | This file shows basic performance benchmarks performed for MUSIC on a 10 node cluster. |
|
| Stability | 1 | 1 | As shown in this file, our experimental runs were all over 1 hour. |
|
| Resiliency | 2 | 2 | Within each container we have scripts that will detect failure of MUSIC and restart it. However, if the entire container fails, we will need OOM to bring it up. |
|
| Security | 2 | 2 |
|
|
| Scalability | 1 | 1 | Among the MUSIC components [tomcat, zookeeper, cassandra], new MUSIC nodes with the tomcat and cassandra can be added seamlessly to scale the cluster (MUSIC itself is state-less). Zookeeper nodes ideally should not be scaled since there are major performance implications. However, this can be done with reconfiguration. |
|
| Manageability | 1 | 1 | Using EELF with logback as the logging provider. |
|
| Usability | 1 | 1 | Use SWAGGER for the REST API and Installation Docs. Will need to enhance and update the documentation. |
|
...
None identified so far.
Resources
Udated the Resources Committed to the Release centralized page.
Release Milestone
The milestones are defined at the Release Level and all the supporting project agreed to comply with these dates.
...