...
- MUSIC/mdbc for efficient state/data replication across geo-distributed sites: ONAP components can maintain and access geo-distributed state in a shared service called MUSIC (multi-site coordination service) that maintains state in a highly scalable replicated key-value store (Cassandra) but also provides a locking service (built on Zookeeper) on top of it through which the ONAP components can obtain stronger consistency on the shared state only when required.
CHAP also provides a recipe on top of MUSIC, called mdbc (multi-site DB cache) that enable ONAP components that maintain state in a SQL database to avail the benefits of MUSIC without changing their SQL DB code. These ONAP components can rely on existing db clustering techniques like MariaDB clustering for replication within a site. mdbc will intercept each of these read/write calls to the db cluster and mirror this state to other geo-distributed sites through MUSIC. HAL for customizable, policy-driven replica-selection and consistent failover across geo-distributed sites: While MUSIC can ensure that state is available across sites, if a site with an ONAP component fails HAL is a cross-site failover service that provides the necessary logic to perform failover to one of the other sites:
Customizable logic for Policy-driven replica-selection and request-redistribution: ONAP components can configure HAL with different policies to decide which of the remaining replicas on other sites must take over on failure of a site and how requests that were handled by the failed site must be redistributed across the remaining replicas.
Consistent view of state on failover: Once the new site/replicas has been selected for failover, HAL, through its interaction with MUSIC, ensures that the ONAP component on that site has the up-to-date view (if required) of the state.
...