Versions Compared

Key

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

...

OTI Data Flow via API (Use Case 1) - consists of two components: OTI-event-proc microservice and OTI-handler microservice.  This option user case not only can be used for real-time data collection, but also can support load balancing, auto scaling within the Kubernetes Cluster and Geo resiliency cross the regions (future release).  

...

-POST the ‘dcae-collection-event’ to OTI-Handler via API (Option1US1).  Or publish 'dcae-collection-event' to DMaaP-MR (option US 2).

-Store the ‘dcae-collection-event’ into ONAP-PG DB.

  • OTI-handler  can POST/Dispatch the ‘dcae-collection-event’ to a defined Kubernetes Cluster in a DCAE region based on xNF location . There is a with low-latency.  A LB in each K8s cluster sends this xNF collection request to a corresponding collector mS ( with Sidecar)  based on the LB algorithm. More detail.  Below is the high level diagram. Detail diagrams are in late section.


      OTI Data Flow via DMaaP-MR  (Use Case 2) - a simplified solution that includes OTI-event-process microservice only. 

...