Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Across geo-distributed sites (e.g., Beijing, Amsterdam and Irvine) WAN latencies are much higher and frequent network partitions can occur. Hence current solutions for replicating ONAP components and their state like MariaDB clustering, that work very effectively within a site, may not scale across geo-distributed sites or allowed allow partitioned operation. 

  • The resiliency protocols for failure detection, failover, request federation etc, especially across multiple-sites, involves complex distributed system protocols replete with corner cases leading to split-brain problems and network partitions. Currently, each component is building its own handcrafted solution which is  wasteful and worse, can be erroneous.

  • ONAP components often have a diverse range of requirements in terms of replication and resiliency. While some components need to carefully manage state across replicas, others may be stateless. Similarly, some of the ONAP components have strict requirements in terms of how the load should be shared across replicas.

...