summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPawel Pawlak <pawel.pawlak3@orange.com>2018-06-12 10:34:22 +0200
committerPawel Pawlak <pawel.pawlak3@orange.com>2018-06-12 10:48:01 +0200
commit581d43cb6252aa94326931e8b049f54b942e4b63 (patch)
tree955e6fa98f48264ef611d6299c7e78d200d2ba56
parent669c13eaf0915c5c23f36d88d9310bc9e75b3aba (diff)
Fix of typos and modules description addonsbeijing
patch description: DCAE and Openstack typos corrected + few lines of additional description for DCAE components Issue-ID: DCAEGEN2-544 Change-Id: I575ddc1b92b40cc55b288a2d6c3eec675d561d7b Signed-off-by: Pawel Pawlak <pawel.pawlak3@orange.com>
-rw-r--r--docs/sections/architecture.rst26
1 files changed, 13 insertions, 13 deletions
diff --git a/docs/sections/architecture.rst b/docs/sections/architecture.rst
index 11baa0e1..5bb2c1e3 100644
--- a/docs/sections/architecture.rst
+++ b/docs/sections/architecture.rst
@@ -1,6 +1,6 @@
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (c) 2017-2018 AT&T Intellectual Property. All rights reserved.
+.. Copyright (c) 2017-2018 AT&T Intellectual Property. All rights reserved.
Data Collection, Analytics, and Events (DCAE)
@@ -11,23 +11,23 @@ Architecture
Data Collection Analytics and Events (DCAE) is the data collection and analysis subsystem of ONAP. Its tasks include collecting measurement, fault, status, configuration, and other types of data from network entities and infrastructure that ONAP interacts with, applying analytics on collected data, and generating intelligence (i.e. events) for other ONAP components such as Policy, APPC, and SDNC to operate upon; hence completing the ONAP's close control loop for managing network services and applications.
-The design of DCAE separates DCAE Services from DCAE Platform so that the DCAE system is flexible, elastic, and expansive enough for supporting the potentially infinite number of ways of constructing intelligent and automated control loops on distributed and heterogeneous infrastructure.
+The design of DCAE separates DCAE Services from DCAE Platform so that the DCAE system is flexible, elastic, and expansive enough for supporting the potentially infinite number of ways of constructing intelligent and automated control loops on distributed and heterogeneous infrastructure.
DCAE Service components are the virtual functional entities that realize the collection and analysis needs of ONAP control loops. They include the collectors for various data collection needs, the analytics that assess collected data, and various auxiliary microservices that assist data collection and analytics, and support other ONAP functions. Service components and DMaaP buses form the "data plane" for DCAE, where DCAE collected data is transported among different DCAE service components.
-On the other hand DCAE Platform components enable model driven deployment of service components and middleware infrastructures that service components depend upon, such as special storage and computation platforms. That is, when triggered by an invocation call, DCAE Platform follows the TOSCA model of the control loop that is specified by the triggering call, interacts with the underlying networking and computing infrastructure such as OpenSatck installations and Kubernetes clusters to deploy and configure the virtual apparatus (i.e. the collectors, the analytics, and auxiliary microservices) that are needed to form the control loop, at locations that are requested by the requirements of the control loop model. DCAE Platform also provisions DMaaP topics and manages the distribution scopes of the topics following the prescription of the control loop model by interacting with controlling function of DMaaP.
+On the other hand DCAE Platform components enable model driven deployment of service components and middleware infrastructures that service components depend upon, such as special storage and computation platforms. That is, when triggered by an invocation call, DCAE Platform follows the TOSCA model of the control loop that is specified by the triggering call, interacts with the underlying networking and computing infrastructure such as OpenStack installations and Kubernetes clusters to deploy and configure the virtual apparatus (i.e. the collectors, the analytics, and auxiliary microservices) that are needed to form the control loop, at locations that are requested by the requirements of the control loop model. DCAE Platform also provisions DMaaP topics and manages the distribution scopes of the topics following the prescription of the control loop model by interacting with controlling function of DMaaP.
-DCAE service components operate following a service discovery model. A highly available and distributed service discovery and Key-Value store service, embodied by a Consul cluster, is the foundation for this approach. DCAE components register they identities and service endpoint access parameters with the Consul service so that DCAE components can locate the API endpoint of other DCAE components by querying Consul with the well know service identities of other components.
+DCAE service components operate following a service discovery model. A highly available and distributed service discovery and Key-Value store service, embodied by a Consul cluster, is the foundation for this approach. DCAE components register they identities and service endpoint access parameters with the Consul service so that DCAE components can locate the API endpoint of other DCAE components by querying Consul with the well know service identities of other components.
-During the registration process, DCAE components also register a health-check API with the Consul so that the operational status of the components are verified. Consul's health check offers a separate path for DACE and ONAP to learn about module operation status that would still be applicable even when the underlying infrastructure does not provide native health-check methods.
+During the registration process, DCAE components also register a health-check API with the Consul so that the operational status of the components are verified. Consul's health check offers a separate path for DCAE and ONAP to learn about module operation status that would still be applicable even when the underlying infrastructure does not provide native health-check methods.
-More over, Consul's distributed K-V store service is the foundation for DCAE to distribute and manage component configurations where each key is based on the unique identity of a DACE component, and the value is the configuration for the corresponding component. DCAE platform creates and updates the K-V pairs based on information provided as part of the control loop blueprint, or received from other ONAP components such as Policy Framework and SDC. Either through periodically polling or proactive pushing, the DCAE components get the configuration updates in realtime and apply the configuration updates. DCAE Platform also offers dynamic template resolution for configuration parameters that are dynamic and only known by the DCAE platform, such as dynamically provisioned DMaaP topics.
+Moreover, Consul's distributed K-V store service is the foundation for DCAE to distribute and manage component configurations where each key is based on the unique identity of a DCAE component, and the value is the configuration for the corresponding component. DCAE platform creates and updates the K-V pairs based on information provided as part of the control loop blueprint, or received from other ONAP components such as Policy Framework and SDC. Either through periodically polling or proactive pushing, the DCAE components get the configuration updates in realtime and apply the configuration updates. DCAE Platform also offers dynamic template resolution for configuration parameters that are dynamic and only known by the DCAE platform, such as dynamically provisioned DMaaP topics.
DCAE R2 Components
------------------
-The following list displays the details of what are included in ONAP DCAE R2. All DCAE R2 components are offered as Docker containers. Following ONAP level deployment methods, these components can be deployed as Docker containers running on Docker host VM that is launched by OpenStack Heat Orchestration Template; or as Kubernetes Deployments and Services by Helm.
+The following list displays the details of what is included in ONAP DCAE R2. All DCAE R2 components are offered as Docker containers. Following ONAP level deployment methods, these components can be deployed as Docker containers running on Docker host VM that is launched by OpenStack Heat Orchestration Template; or as Kubernetes Deployments and Services by Helm.
- DCAE Platform
- Core Platform
@@ -45,21 +45,21 @@ The following list displays the details of what are included in ONAP DCAE R2. A
- DCAE Services
- Collectors
- - Virtual Event Streaming (VES) collector
+ - Virtual Event Streaming (VES) collector. Validates, filters, and packages the received measurement data, and publishes the data to the "measurement data" topic of DMaaP.
- SNMP Trap collector
- Analytics
- Holmes correlation analytics
- - Threshold Crosssing Analytics (TCA)
+ - Threshold Crosssing Analytics (TCA). Contains CDAP but in R2 without Hadoop cluster as not required by ONAP use cases.
- Microservices
- - PNF Registration Handler
- - Missing Heartbeat analytics
- - Universal Data Mapper service
+ - PNF Registration Handler. Creates PNF entry in A&AI.
+ - Missing Heartbeat analytics. Microservice that monitors heart beat messages from VNFs, alert event is generated when HB is missing.
+ - Universal Data Mapper service. Converts other caps data (SNMP) into VES data.
The fingure below shows the DCAE R2 architecture and how the components work with each other. Among the components, blue boxes represent platform components; white boxes represent service components; purple boxes represent other ONAP components that DCAE Platform interfaces with; and orange pieces represent operator or operator like actors.
.. image:: images/architecture.gif
-
+
Deployment Scenarios
--------------------