Casablanca

Updated for Casablanca release.

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

Geo-Redundancy Overview

  • No labels

2 Comments

  1. Is "Active-Active" site configuration an option or only "Active- Warm STDBY"?

    1. For all intents and purposes, the geo feature only supports an active/warm standby model. This is mainly due to ODL clustering behaviours.

      As part of the fail-over to the alternate site, the ODL instances in that site are promoted to voting members while the ODL instances in the original site are demoted to non-voting members (provided the original site remains up, of course).

      Thanks for your interest in this functionality. If you have any other questions, please let us know.