Architecture
Deployment
Follow these steps to deploy geo-redundant SDN-C sites:
Deploy 2 SDN-C clusters, each cluster represents 1 site.Setup Sites
Setup 2 Kubernetes VMs (1 Kubernetes master and 1 Kubernetes worker node) for CoreDNS
Setup CoreDNS
Verify ODL Clustering between the 2 sites
Verify ODL Clustering
Setup MySQL Replication
Overview
In ONAP Beijing, the ability to deploy a linked pair of SDN-C sites was introduced in order to facilitate geo-redundancy. (Note: Although code was submitted, this functionality was not officially supported.) With this deployment model, one site would be in an 'active' state while the other acted as a warm standby that could be used should the active site suffer some debilitating fault. In this initial iteration, the operator was made to be responsible for monitoring the health of the active site, identifying failures and initiating a scripted failover. They would also be responsible for updating the DNS server so that clients would direct their messaging towards the now-active site.
Later on, in Casablanca, additional scripts were added that facilitated health checking activities and automatic updating of the DNS server records. A PROM component was also added, which was able to manage all of these scripts, effectively removing the operator dependency. PROM shares the site health with the peer site through MUSIC so both sites' PROM can make informed failover decisions. A human-oriented script was provided in Casablanca to allow for forced failovers initiated by the operator, which allows for maintenance activities to be carried out without disrupting the ONAP system.
Architecture
Gliffy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Topics
Child pages (Children Display) | ||||||
---|---|---|---|---|---|---|
|