Table of Contents | ||
---|---|---|
|
Overview
...
This release of MUSIC provides a shared 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 geo-redundancy (platform-maturity resiliency level 3).
Use Cases
...
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 | 12 | 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 | 01 | 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). However, our current version of Zookeeper (3.4.0) does not support dynamic reconfiguration. Will move to Zookeeper 3.5.0 that supports dynamic reconfiguration and test MUSIC sclability. We will also need to work with OOM support to spin new containers on demand for the scalability needsZookeeper 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. |
|
...