Versions Compared

Key

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

1.1 (R1)

Dependencies

https://docs.openstack.org/designate/pike/index.html

TBD
https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/blueprints/DockerHost.html
https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/blueprints/deploymenthandler.html
https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/blueprints/centos_vm.html
https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/blueprints/ves.html

filled
https://onap.readthedocs.io/en/latest/submodules/ccsdk/platform/plugins.git/docs/dnsdesig.html?highlight=designate

http://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/installation.html

https://gerrit.onap.org/r/gitweb?p=dcaegen2/deployments.git;a=blob;f=bootstrap/README-docker.md;h=3fa1b7d4d76b47cb1f1db1eeb2f7424877524e66;hb=refs/heads/master

1.0.0 (Feb 2017)

The Data Collection, Analytics, and Events (DCAE) subsystem, in conjunction with other OpenECOMP ONAP components DCAE gathers , gathers performance, usage, and configuration data for from the managed environment.  This data can is then be fed to various analytic programsapplications, and if anomalies or significant events are detected, the results can trigger appropriate actions, such as publishing to other OpenECOMP ONAP components such as Policy, orchestrationMSO, or the data lakeControllers

The primary functions of the DCAE subsystem are to

  • Collect, ingest, transform and store data as necessary for analysis
  • Provide a framework for development of analytics, and to

These two primary functions enable closed-loop responses by various ONAP components to events or other conditions by various OpenECOMP componentsin the network.

The closed-loop responses are enabled by DCAE, in conjunction with other OpenECOMP components, by providing DCAE provides the ability to detect anomalous conditions in the network. Such conditions, might be, for example,  fault fault conditions that need healing or capacity conditions that require resource scaling. DCAE gathers performance, usage, and configuration data about the managed environment, such as about virtual network functions and their underlying infrastructure. This data is then distributed to various analytic micro-services, and if anomalies or significant events are detected, the results trigger appropriate actions by other OpenECOMP components such as Policy, MSO or other orchestration components, or Controllers. In addition, the micro-services might persist the data (or some transformations of the data) in the storage lake. In addition to supporting closed-loop control, DCAE also makes the data and events available for higher-level correlation by business and operations activities, including business support systems (BSS) and operational support systems (OSS).

...

The following figure provides a functional view of the DCAE platform Platform architecture.



Figure 1. DCAE Platform high-level architecture

...

In large scale deployments, DCAE components are generally distributed in multiple sites that are organized hierarchically.  For example, to provide DCAE function for a large scale OpenECOMP ONAP system that covers multiple sites spanning across a large geographical area, there will be edge DCAE sites, central DCAE sites, and so on.   Edge sites are physically close to the network functions under collection, for reasons such as processing latency, data transport, and security, but often have limited computing and communications resources.  On the other hand, central sites generally have more processing capacity and better connectivity to the rest of the OpenECOMP ONAP system.  This hierarchical organization offers better flexibility, performance, resilience, and security.  

...

This component (known as DMaaP)  facilitates the movement of messages and data between various publishers and interested subscribers that may reside at different sites. While a key component within DCAE, this is also the component that enables data movement between various OpenECOMP ONAP components.

Edge and Central Lake

...

The following figures show the implemented system architecture and flows for the first release of OpenECOMPONAP.  DCAE for this release is "minimalistic" in the sense that it is a single DCAE site with all DCAE functions.

...

  1. The DCAE Controller is instantiated from an OpenECOMP ONAP Heat template.
  2. The DCAE Controller instantiates the rest of the DCAE components, including both infrastructure and service/application components.
  3. The DCAE Controller configures service/application components with static configurations, configuration policies fetched at run-time (for example data processing configurations or alert configurations), and any DMaap topics required for communication.

...

  1. VNFs use REST calls to push measurement data to the DCAE VES collector.
  2. The VES collector validates, filters, and packages the received measurement data, and publishes the data to the "measurement data" topic of DMaaP.
  3. The analytics application receives measurement data from the DMaaP "measurement data" topic.
  4. The analytics application analyzes measurement data, and if alert conditions (defined by the alert policy that was installed by the DCAE Controller) are met, publishes an alert event to the DMaaP "event data" topic. 
  5. Other OpenECOMP ONAP components, for example the Policy or MSO subsystems, receive alert events from the DMaaP "event data" topic and react accordingly.

...

Figure 3. DCAE data flow (Data plane)


References

VES: https://wiki.opnfv.org/display/PROJ/VNF+Event+Stream