diff options
| author |   Tschaen, Brendan <ctschaen@att.com> | 2018-10-16 20:22:35 -0400 |
|---|---|---|
| committer | Tschaen, Brendan <ctschaen@att.com> | 2018-10-16 20:27:37 -0400 |
| commit | 46350c084766789ea59e83f1917c57c81d653048 (patch) | |
| tree | 3463279fcee9c26d190d854324bbd7f86422fe2e /README.md | |
| parent | 287bdcbb5482f94df091c3b7b766fed0007efa2e (diff) | |
Include Cassandra locking
Change-Id: I085acf8336d5f27782ee12768846a5befd3ee60d
Issue-ID: MUSIC-148
Signed-off-by: Tschaen, Brendan <ctschaen@att.com>
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 4 |
1 files changed, 2 insertions, 2 deletions
@@ -1,5 +1,5 @@ -## MUSIC - Multi-site State Coordination Service - +xxxtest## MUSIC - Multi-site State Coordination Service +123 To achieve 5 9s of availability on 3 9s or lower software and infrastructure in a cost-effective manner, ONAP components need to work in a reliable, active-active manner across multiple sites (platform-maturity resiliency level 3). A fundamental aspect of this is state management across geo-distributed sites in a reliable, scalable, highly available and efficient manner. This is an important and challenging problem because of three fundamental reasons: * Current solutions for state-management of ONAP components like MariaDB clustering, that work very effectively within a site, may not scale across geo-distributed sites (e.g., Beijing, Amsterdam and Irvine) or allow partitioned operation (thereby compromising availability). This is mainly because WAN latencies are much higher across sites and frequent network partitions can occur. |