Uploaded image for project: 'ONAP Operations Manager'
  1. ONAP Operations Manager
  2. OOM-1175

Shared Database Instances

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: High High
    • Kohn Release
    • None
    • None
    • Shared DB Instances
    • Done

      As an ONAP operator, I want to minimize the number of data-base instances running in an ONAP deployment and have the data-bases operate in a fault tolerant manner. Three phases of development is required (note that not all data-base instances will get to phase three): 

      1. All data-bases deployed by ONAP shall use common Helm deployment charts to ensure best practices are applied.  These charts will be located in the kubernetes/onap/common/ directory of the OOM repository.
      2.  Clustered DB configurations be made available in the same common/ directory and where applicable ONAP components be modified to use the cluster configuration of their chosen DB technology.
      3. One or more central instances of the clustered DB be instantiated and associated components be modified to use this (these) central instances. This phase does not imply any change in DB technology - i.e. both central MariaDB-Galera and Cassandra clusters will be available.

       The following is a list of DB technologies and users: 

      • MariaDB - appc, clamp, nbi, oof, policy, portal, sdnc, so, vfc, vid, dmaap-datarouter
      • Cassandra - aaf, aai, oof, portal, sdc
      • Postgres - dcaegen2, dmaap, vnfsdk
      • Elastic (will be covered in the common ELK Epic) - aai, clamp, log
      • MongoDB (TBD if further work is required) - nbi, dcaegen2
      • Redis - dcaegen2

            sdesbure sdesbure
            rogerm rogerm
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: