From 8f5ee6d60b9858d93dd8b5983ef69df1946b224b Mon Sep 17 00:00:00 2001 From: Manish Kumar Date: Fri, 25 Jan 2019 14:47:15 +0530 Subject: Updated:Typo Issue-ID: DOC-389 Change-Id: I32e5b934056b85f5e94ca299492a4bbedf3713fb Signed-off-by: Manish Kumar --- docs/architecture.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/architecture.rst') diff --git a/docs/architecture.rst b/docs/architecture.rst index f78db7bb..74cb0c40 100644 --- a/docs/architecture.rst +++ b/docs/architecture.rst @@ -7,7 +7,7 @@ Architecture Project Description ------------------- -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: +To achieve five 9s of availability on three 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. -- cgit 1.2.3-korg