ONAP Architecture Chair 2 Analytics Applications Analytics Application use cases Infrastructure analytics Hypervisor Base OS and HW metrics Application level analytics Example CDN RAN EPC IMS IOTGateway ID: 1006676
Download Presentation The PPT/PDF document "Edge Analytics Stephen Terrill," is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. Edge AnalyticsStephen Terrill,ONAP Architecture Chair
2. 2Analytics ApplicationsAnalytics Application use casesInfrastructure analytics (Hypervisor, Base OS and HW metrics)Application level analytics (Example: CDN, RAN, EPC, IMS, IOT-Gateway etc…)Support forThird party analytics frameworks (AFs)Third party analytics applications (AAs)Function specific analytics applicationsGeneric analytics applicationsONAP-community created analytics frameworksONAP-community created analytics applications
3. 3Dublin focusTreat AFs and AAs as use case to ONAP (With no AA specific changes to ONAP)Prove that ONAP can deploy & configure frameworks in various Cloud regionsBig data AF (Spark + OpenTSDB + HBASE + HDFS + Kafka) Prometheus AFProve that ONAP can deploy & configure multiple AAs on top of AFs in various cloud regions, where AAs are brought up at different timesOne example AA: CollectD + CPU/Memory usage anomaly + Correlation + Alarm propagationProving with at least one third party AA (preferably ML based)Activities:Create Helm charts for “Big Data AF”, Create Helm charts for “Prometheus AF” in a way to use them to deploy multiple times (parameterization is the major work)Create example AA and helm charts for the same.Synchronization of Spark images & Machine learning modelsLeverage / Create CRDs/operators to configure AFs and AAs.Like any other use cases, identify any gaps in ONAP and get them fixed via JIRAs.(Stretch) Closed loop on alarms - Integration with drools service of policy framework) – Some AAs may need to talk to ONAP for any closed loops. Some AAs are purely function specific and they would hae their own way to act on.
4. 4Beyond DublinWider support for AFs and AAs descriptionIdentification and creation of AAs by ONAP communityGuidelines for AA developersRepositories for AA images and AA modelsA way to associate AFs and corresponding AAs.Integration with CLAMP for AAs that are related to ONAP Based on architecture discussions, prove ONAP specific AAs using other orchestration mechanisms (such as Cloudify) – This is the discussion point for rest of the presentation.
5. 5Background and PurposeAnalytics at the edge is being considered for the Dublin scope.This has resulted in a good email discussion and debate about how to view it.The purpose of this slide set is to:Capture the discussion and alternatives.Its an input into discussion and highlighting consequences of the approaches
6. 6Note:While this slide deck captures the discussions and options for analytics at the edge, the concluding concept should be able to be applied generally, and analytics is just an example.E.g. the concept should apply to controllers, AAI, SO, multivim, …Consideration is required to be given to the lifecycle beyond instantiationFault casesScaleRemoving from the networkThe next slide summarizes the Edge Architectural Options
7. 7Long-term Edge Architectural Options Summary Input from Ramki/Srini based on various presentations/discussionsCentral ONAPDesign, Deploy, OperateEdge 3rd PartyDistributed OffloadAnalytics - OperateUse Case: Massive Data from/to large number of Devices/Apps/Networks – Data Reduction to CloudsCentral ONAP Design, Deploy, OperateClosed Loop – OperateUse Case: Real-time Network/App performanceCentral ONAP Design, DeployDistributed OrchestrationScalability – Deploy/OperateUse Case: Large number of EdgesCentral ONAP Design
8. 8Key Long-term Edge Architecture Principles Input from Ramki/Srini based on various presentations/discussionsDon’t treat Applications and VNFs differently – creates huge manageability challengesApplications which are dependent on VNFs will be instantiated using the same framework as VNFsLeverage K8S (CRDs etc.) for Distributed Systems ManagementK8S is the (over/under) cloud of choice for edge -> core -> cloud deploymentsSome key aspects of distributed system managementImage management – at scale rolling upgradePolicy/Configuration change – notify only deltas
9. 9Captured Requirements – do we agree?Use OOF to determine placementAbility to bring up dedicated analytics application instance on per VNF instance.Ability to bring up analytics app instance at the same place as VNF instance.Ability to bring up analytics app instance closer to the place where VNF is being instantiated.Need for configuring the VNF workloads that are required for analytics applications
10. 10How to view the Analytics at the edge?i.e. What are we talking about?Edge SiteCentral SiteEdge Infra & StackCenter Infra & StackONAPEdge AnalyticsOther FunctionsONAPManaged by ONAPEdge Analytics is considered as part of ONAPEdge Analytics is considered outside of ONAPONAP internal interfaceEdge SiteEdge Infra & StackCenter Infra & StackONAPEdge AnalyticsOther FunctionsEdge Analytics is considered as part of ONAP that is distributed at the edgeIt is considered part of DCAEEdge Analytics is considered as a VNFOther?Note: Edge analytics that is controlled and provided by the Edge Infrastructure is out of scope for this discussion
11. 11How to treat – New: Management Network FunctionEdge SiteCentral SiteEdge Infra & StackCenter Infra & StackONAPEdge AnalyticsOther FunctionsEdge Analytics is considered as part of ONAP, but as a Management Network FunctionEdge Analytics is considered as part of ONAP that is distributed at the edgeHowever, it is instantiated like network function that doesn’t follow all the
12. 12If “Edge Analytics” was considered a VNFDescription:The Edge analytics is deployed as a separate VNFThe Edge Analytics is deployed as part of a VNFExample (Email from Srini):“For example, I was given this example of CDN. CDN core functionality might require few micro-services, but also need to have fluendD service for collection of logs from core CDN micro-services, which inturn export summation logs elsewhere, performance & resource management related analytics services, DDOS/NGFW kind of micro-service to protect CDN core services and Prometheus kind of monitoring service.”Consequences:If it is part of a VNF, then it is just treated as part of a VNF and nothing special from ONAP.If it is treated as a separate VNF that needs to be used:Included as a VNF package and onboarded to SDC.Must comply to the VNF requirementsChef/Ansible/Netconf/YangVESConfigured by controllers?It must be included in the “Service definition” when describing the service
13. 13If “Edge analytics” was treated as part of DCAEApproaches from Emails:Method 2: Use Cloudify to deploy analytics workloads in Edgesa. Significant work is required here such as integration of OOF, using cloudify to deploy both VNF+analytics application combination etc…b.If we use this, this becomes third orchestrator in ONAP. Current understanding is not to use this for deploying analytics apps in Edge locations.Method 3: SDC, SO, OOF, Cloudifya. Similar to “Analytics as a VNF”, except that SO talks to Cloudify to bring up analytics applications. Multi-Cloud is not leveraged.b. SO team mentioned that Cloudify integration was done before and same can be leveraged. But testing is required.c.DCAE team intends to provide Helm chart support as analytics description in addition to Cloudify-TOSCA.d.Leverage policy based configuration mechanism.Chairs comments: I think that there are variants of these
14. 14Analysis-1 from email -1/2Don’t mix VNF deployments and DCAE/Analytics deploymentsSimilarities1. VNFs and Analytics Applications (short: AA) require certain meta-data (artifacts…), which describe capabilities, requirements and limitations of such applications. There is nothing against brining CSARs for both VNFs and Analytic Applications – especially, when AAs will need more meta-data.2. VNFs and AAs both require some placing mechanisms, essentially when a number of available cloud regions exist, we need to be able to select a region.Differences:1. Practically VNFs usually require specific networking or acceleration capabilities, which are usually not needed for Analytics Applications. Examples (VNFs): SR-IOV, HugePages, HPA – that are somehow valid for NFV environments, but not necessarily essential for AAs.2. The placing mechanisms for VNFs and AAs might probably operate on different inputs, use different filters, aso. VNFs and NFV use-cases come with certain latency/throughput requirements. Due to the required cloud specifics (HPA..), they`re usually deployed in private clouds (NFV-Is). AAs usually do not require any cloud specifics, and I can imagine AA deployments in e.g. public cloud environments.
15. 15Analysis-1 from email 2/2Why not using OOF for both, making sure, that we can apply all needed filters and parameters to satisfy VNFs and AAs, keeping the same mechanism?4. I am not sure, if we really need to bind AAs with VNFs (to the level of sharing a CSAR package).Usually there will be AAs, that are generic to a number of VNFs – they will have VNF or domain specific configuration.Even today, when we provide a CLAMP blueprint, we assign that blueprint to the VNF resource in context of a specific service model. Same VNFs could be used in different context, and probably different things need to be monitored, or we will be looking at different threshold values. There is nothing preventing from association the VNF CSAR, and AA CSAR to a specific service model. Perhaps, we will need here a possibility to define an AA deployment strategy (Central/Distributed), or AA requirements (throughput, latency, capacity). The requirements are actually quite similar to what we`d like OOF to process as input parameters.
16. 16There was more… but started to go beyond the original question
17. 17