Summary: Edge Scoping
ONAP Component | Life Cycle Phase | Enhancements |
---|---|---|
Multi-Cloud | Deploy | Support Distributed Cloud Infrastructure Capability Discovery (Note 1, Note 2) |
A&AI | Deploy | Support Standardized Distributed Cloud Infrastructure Object Hierarchy & Capability Database (Ref. 1)
|
OOF | Deploy | Execute Distributed Cloud Infrastructure Placement Policies for Optimized Service/VNF Placement across Cloud Regions (Note 3, Note 4) |
SO | Deploy | Extend SO ↔ OOF API to support data opaque to SO (Note 5) Extend SO ↔ MC API to support data opaque to SO (Note 6) |
Assumption for Policy, SO, OOF:
Note 1:
Note 2:
Note 3:
5G CU-UP VNF location to be fixed to a specific physical DC based on 5G DU, bounded by a max distance from 5G DU
Choose optimized cloud region (or instance) for the placement of 5G CU UP for subscriber group based on the above constraints
Note 4:
Note 5:
Note 6:
All (especially the data plane VNFs with fine-grained VNF placement and high performance networking requirements)
Improve "workload deployability" by avoiding exposure of "cloud specific" capabilities to several ONAP components and addressing "separation of concerns"
Applicable to all workloads - VM-based or Container-based
Cloud Agnostic Intent (Policy) Execution Workflow - Steps 1- 6
Cloud Agnostic Intent (Policy) Execution Workflow - Step 7
Intent Support
Single realization option per Cloud Region for the specified Intent
The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Scoping Sequence Diagram
2a) OOF Processing - the fetched Policy (example below) is stored in a local data structure and is available for further use (need OOF code changes).
OOF Homing Enhanced Cloud Selection Policy -- JSON Schema with Use Case Examples as runnable python code:
# #Spec Reference: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements#EdgeScopingMVPforCasablanca-ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal) # from jsonschema import validate oof_cloud_selection_policy_schema = { "service": {"type": "string"}, "policyName": {"type": "string"}, "policyDescription": {"type": "string"}, "templateVersion": {"type": "string"}, "version": {"type": "string"}, "priority": {"type": "string"}, "riskType": {"type": "string"}, "riskLevel": {"type": "string"}, "guard": {"type": "string"}, "content": { "type": "object", "required": ["cloud-cost-evaluation", "cloud-deployment-intent"], "properties" : { # VNFC is not used in the OOF->MC path for R3 # This is kept to be consistent with the SO-> MC path # As an example, vDNS VNF in ONAP has 3 VNFCs - DNS, Packet Gen & Load Balancer -- # Each of the VNFCs could have different policies "vnfc": {"type": "string"}, # evaluate cloud cost if set # cost is fixed per cloud type for all workloads -- simplifying assumption for R3 # cost specified in the respective plugin through a configuration file "cloud-cost-evaluation" : {"type" : "boolean"}, # cloud-specific realization of the specified deployment intent # happens in multi-cloud in the cloud-specific plugin "cloud-deployment-intent": { "type": "object", "properties" : { # Cloud Type -- Azure, K8S, OpenStack, VMware VIO, Wind River Titanium # Optionally Accomodate policies per Cloud Type "Cloud Type (Cloud Provider)": {"type", "array"}, "Infrastructure High Availability for VNF": {"type", "boolean"}, "Infrastructure Resource Isolation for VNF": {"type", "string"}, # Infrastructure Resource Isolation for VNF # Only certain pre-defined over-subscription values are allowed to # reflect practical deployment and simplify implementation for R3 "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": {"type": "int"}, }, }, }, }, "resources": {"type", "array"}, #"vgw" is also interchangeably used as "vg" "applicableResources": {"type", "string"}, "identity": {"type", "string"}, "policyScope": {"type", "array"}, "policyType": {"type", "string"} } # #Example 1: vCPE, Burstable QoS #vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS # oof_cloud_selection_policy_instance1 = { "service": "cloudSelectionPolicy", "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF", "policyDescription": "Cloud Selection Policy for vCPE VNFs", "templateVersion": "0.0.1", "version": "oofMulti-cloudCasablanca", "priority": "3", "riskType": "test", "riskLevel": "2", "guard": "False", "content": { "vnfc": "vgw", "cloud-cost-evaluation": True, "cloud-deployment-intent": { "Cloud Type (Cloud Provider)": {"VMware VIO"}, "Infrastructure Resource Isolation for VNF": "Burstable QoS", "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25, }, }, "resources": ["vgw"], #"vgw" is also interchangeably used as "vg" "applicableResources": "any", "identity": "cloud-atrributes", "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"], "policyType": "AllPolicy" } # #Example 2: #vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS # oof_cloud_selection_policy_instance2 = { "service": "cloudSelectionPolicy", "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF", "policyDescription": "Cloud Selection Policy for vCPE VNFs", "templateVersion": "0.0.1", "version": "oofMulti-cloudCasablanca", "priority": "3", "riskType": "test", "riskLevel": "2", "guard": "False", "content": { "vnfc": "vgw", "cloud-cost-evaluation": True, "cloud-deployment-intent": { "Infrastructure Resource Isolation for VNF": "Guaranteed QoS", }, }, "resources": ["vgw"], #"vgw" is also interchangeably used as "vg" "applicableResources": "any", "identity": "cloud-atrributes", "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"], "policyType": "AllPolicy" } # #Example 3: #vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS # oof_cloud_selection_policy_instance3 = { "service": "cloudSelectionPolicy", "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNF", "policyDescription": "Cloud Selection Policy for vDNS VNFs", "templateVersion": "0.0.1", "version": "oofMulti-cloudCasablanca", "priority": "3", "riskType": "test", "riskLevel": "2", "guard": "False", "content": { "vnfc": "vdns", "cloud-cost-evaluation": True, "cloud-deployment-intent": { "Cloud Type (Cloud Provider)": {"VMware VIO", "Azure"}, "Infrastructure High Availability for VNF": True, "Infrastructure Resource Isolation for VNF": "Burstable QoS", "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25, }, }, "resources": ["vDNS"], "applicableResources": "any", "identity": "cloud-atrributes", "policyScope": ["vDNS", "US", "INTERNATIONAL", "vDNS"], "policyType": "AllPolicy" } # # Example 4: # vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF # with Guaranteed QoS # oof_cloud_selection_policy_instance4 = { "service": "cloudSelectionPolicy", "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNF", "policyDescription": "Cloud Selection Policy for vDNS VNFs", "templateVersion": "0.0.1", "version": "oofMulti-cloudCasablanca", "priority": "3", "riskType": "test", "riskLevel": "2", "guard": "False", "content": { "vnfc": "vdns", "cloud-cost-evaluation": True, "cloud-deployment-intent": { "Infrastructure High Availability for VNF": True, "Infrastructure Resource Isolation for VNF": "Guaranteed QoS", }, }, "resources": ["vDNS"], "applicableResources": "any", "identity": "cloud-atrributes", "policyScope": ["vDNS", "US", "INTERNATIONAL", "vDNS"], "policyType": "AllPolicy" } validate(oof_cloud_selection_policy_instance1, oof_cloud_selection_policy_schema) validate(oof_cloud_selection_policy_instance2, oof_cloud_selection_policy_schema) validate(oof_cloud_selection_policy_instance3, oof_cloud_selection_policy_schema) validate(oof_cloud_selection_policy_instance4, oof_cloud_selection_policy_schema) |
3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>. OOF will prune any <cloud owner, cloud region> which is not satisfying the standardized capabilities.
*** Assume: VNFC is equalivent to VM, VNF is equivalent of heat stack.
Request URI: POST http://{msb ip}:{msb port}/api/multicloud/v1/cost_evaluation Request body: [ { "cloud-owner": "owner1", "cloud-region-id": "region1", "directives":[ { "vnfc_directives":[ { "vnfc_id":"<ID of VNFC>", /*optional, but keep aligned to OOF/SO/MC API to make it simple*/ "directives":[ { "directive_name":"<Name of directive,example flavor_directive>", "attributes":[ { "attribute_name":"<name of attribute, such as flavor label>", "attribute_value":"<value such as cloud specific flavor>" } ] }, { "directive_name":"<Name of directive,example vnic-info>", "attributes":[ { "attribute_name":"<name of attribute, such as vnic-type>", "attribute_value":"<value such as direct/normal>" }, { "attribute_name":"<name of attribute, such as provider netweork>", "attribute_value":"<value such as physnet>" } ] } ] } ] }, { "vnf_directives":{ "directives":[ { "directive_name":"<Name of directive>", "attributes":[ { "attribute_name":"<name of attribute>", "attribute_value":"<value>" } ] }, { "directive_name":"<Name of directive>", "attributes":[ { "attribute_name":"<name of attribute>", "attribute_value":"<value >" }, { "attribute_name":"<name of attribute>", "attribute_value":"<value >" } ] } ] } } ] }, { "cloud-owner": "owner2", "cloud-region-id": "region2", "directives": [] } ] Response: [ { "cloud-owner": "owner1", "cloud-region-id": "region1", "net-value": 100 }, { "cloud-owner": "owner2", "cloud-region-id": "region2", "net-value": 101 } ] |
Step 4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance
4a) OOF Processing
The OOF ↔ MC cloud selection API, described below, is filled based on the Cloud Selection Policy for Homing retrieved in step 2) – need OOF code changes.
OOF <-> MC Cloud Selection API -- JSON Schema with Use Case Examples as runnable python code:
//flexibility of having cloud type in the new API provides fine grained control, addresses capacity/cost differences across different cloud owners/regions and ensures backward compatibility Proposed API URL: http://msb:80/api/multicloud/v0/intent_based_cloud_selection # #Spec Reference: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements#EdgeScopingMVPforCasablanca-ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal) # from jsonschema import validate oof_mc_policy_api_request_schema = { #list of VIM ids "Cloud Owner & Cloud Region List (VIM ids)": {"type", "array"}, "oof-mc-policy-api-request": { "type": "array", "items": { "$ref": "#/definitions/xxx1" } }, "definitions": { "xxx1": { "type": "object", "required": ["cloud-cost-evaluation", "cloud-deployment-intent"], "properties" : { # VNFC is not used in the OOF->MC path for R3 # This is kept to be consistent with the SO-> MC path # As an example, vDNS VNF in ONAP has 3 VNFCs-DNS, Packet Gen & Load Balancer # each of the VNFCs could have different cloud policies "vnfc": {"type": "string"}, # evaluate cloud cost if set # cost is fixed per cloud type for all workloads, simplifying assumption for R3 # cost specified in the respective plugin through a configuration file "cloud-cost-evaluation" : {"type" : "boolean"}, # cloud-specific realization of the specified deployment intent # happens in multi-cloud in the cloud-specific plugin "cloud-deployment-intent": { "type": "array", "items": { "$ref": "#/definitions/xxx2" } }, "definitions": { "xxx2": { "type": "object", "properties" : { "Infrastructure High Availability for VNF": {"type", "boolean"}, "Infrastructure Resource Isolation for VNF": {"type", "string"}, # Infrastructure Resource Isolation for VNF # Only certain pre-defined over-subscription values are allowed to # reflect practical deployment and simplify implementation for R3 "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": {"type": "int"}, }, }, }, }, }, }, } oof_mc_policy_api_response_schema = { "oof-mc-policy-api-response": { "type": "array", "items": { "$ref": "#/definitions/xxx" } }, "definitions": { "xxx": { "type": "object", "required": [ "VIM id", "net-value" ], "properties": { # VIM id "VIM id": { "type": "string", }, # For R3, net-value signifies cost per VIM id # Referring to cloud-cost-evaluation in the API from OOF -> MC # cost is fixed per cloud type for all workloads # cost specified in the respective plugin through a configuration file "net-value": { "type": "number", } } } } } # #Example 1: vCPE, Burstable QoS #vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS # oof_mc_policy_api_instance1 = { #list of VIM ids "Cloud Owner & Cloud Region (VIM id)": {"Azure 1", "Azure 2", "VMware VIO 1"}, "oof-mc-policy-request": [ { "vnfc": "vgw", #list of VIM ids "cloud-deployment-intent": [ { "Infrastructure Resource Isolation for VNF": "Burstable QoS", "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25, } ], }, ] } # #Example 2: #vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS # oof_mc_policy_api_instance2 = { #list of VIM ids "Cloud Owner & Cloud Region List (VIM ids)": {"Azure 1", "Azure 2", "VMware VIO 1", "Wind River Titanium 1"}, "oof-mc-policy-request": [ { "vnfc": "vgw", "cloud-cost-evaluation": True, "cloud-deployment-intent": [ { "Infrastructure Resource Isolation for VNF": "Guaranteed QoS", } ], }, ], } # #Example 3: #vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS # oof_mc_policy_api_instance3 = { #list of VIM ids "Cloud Owner & Cloud Region List (VIM ids)": {"Azure 1", "Azure 2", "VMware VIO 1", "Wind River Titanium 1"}, "oof-mc-policy-request": [ { "vnfc": "vdns", "cloud-cost-evaluation": True, "cloud-deployment-intent": [ { "Infrastructure High Availability for VNF": True, "Infrastructure Resource Isolation for VNF": "Burstable QoS", "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25, } ], } ], } # # Example 4: # vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF # with Guaranteed QoS # oof_mc_policy_api_instance4 = { #list of VIM ids "Cloud Owner & Cloud Region List (VIM ids)": {"Azure 1", "Azure 2", "VMware VIO 1", "Wind River Titanium 1"}, "oof-mc-policy-request": [ { "vnfc": "vdns", "cloud-cost-evaluation": True, "cloud-deployment-intent": [ { "Infrastructure High Availability for VNF": True, "Infrastructure Resource Isolation for VNF": "Guaranteed QoS", }, ], }, ], } oof_mc_policy_api_response_instance = { "oof-mc-policy-api-response": [ { "VIM id": "Azure 1", "net-value": 100 }, { "VIM id": "VMware VIO 1", "net-value": 101 }, { "VIM id": "Wind River Titanium 2", "net-value": 102 }, { "VIM id": "Wind River Titanium 1", "net-value": 102 }, ], } validate(oof_mc_policy_api_instance1, oof_mc_policy_api_request_schema) validate(oof_mc_policy_api_instance2, oof_mc_policy_api_request_schema) validate(oof_mc_policy_api_instance3, oof_mc_policy_api_request_schema) validate(oof_mc_policy_api_instance4, oof_mc_policy_api_request_schema) validate(oof_mc_policy_api_response_instance, oof_mc_policy_api_response_schema) |
MC Workload Deployment Cost Policy -- JSON Schema with Use Case Examples as runnable python code:
# #Spec Reference: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements#EdgeScopingMVPforCasablanca-ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal) # from jsonschema import validate mc_workload_deployment_cost_policy_schema = { "cloudProviderWorkloadDeploymentCost": { "type": "array", "items": { "$ref": "#/definitions/xxx" } }, "definitions": { "xxx": { "type": "object", "required": [ "cloudProvider", "workloadDeploymentCost" ], "properties": { # VIM id "cloudProvider": { "type": "string", }, # For R3, netValue signifies cost per VIM id # Referring to cost-intent in the API from OOF -> MC # cost is fixed per cloud type for all workloads # cost specified in the respective plugin through a configuration file "workloadDeploymentCost": { "type": "number", } } } } } mc_workload_deployment_cost_policy_instance1 = { "cloudProviderWorkloadDeploymentCost": [ { "cloudProvider": "Azure", "workloadDeploymentCost": 101 }, ], } mc_workload_deployment_cost_policy_instance2 = { "cloudProviderWorkloadDeploymentCost": [ { "cloudProvider": "Wind River Titanium Cloud", "workloadDeploymentCost": 100 }, ], } validate(mc_workload_deployment_cost_policy_instance1, mc_workload_deployment_cost_policy_schema) validate(mc_workload_deployment_cost_policy_instance2, mc_workload_deployment_cost_policy_schema) |
5a) MC Processing (need MC code changes)
For each cloud owner
5b) Workload Deployment Cost Policy - Configured by the Operator
The operator/service provider who uses ONAP will choose which VIMs to use and include the appropriate MC plugins in his ONAP deployment. For example, let’s assume they pick private Openstack, private VMWare, and public Azure as the platform to run their services on.
For R3, Workload Deployment Cost Policy can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes visible to the relevant MC plugin to simplify implementation. Beyond R3, this could be moved to the Policy DB. The details of the configuration are described below.
"Workload Deployment Cost Policy Example" depicted above has an exemplary description of this.
6a) OOF Processing - cloud_net_value input in Multi-objective Optimization (need OOF code changes)
Casablanca Goal for implementation simplification
Select one of the clouds which meets the cost hard constraint, e.g. cost <= x. This is similar to current capacity check implementation, where one of the cloud which passes the capacity check is selected.
Stretch Goal for Casablanca
Each service specifies an service-specific objective function that is stored as part of the service-specific policy and is used by OOF to evaluate the candidate <cloud owner, cloud region>. For simplicity of the example, let’s consider service that consists only of one VNF instance. The objective function has two components:
- distance from customer location to the VNF - the service designed assigns a weight for the distance: wd
- the cost of deploying the VNF in a location - the service designer assigns a weight for the cost: wc
OOF optimization function: min (wd*distance + wc*cloud_net_value)
If the service does not care about the cost at all, it would set wc = 0. If the service designer wants to minimize cost, he could set wd=0. Note that candidates that are too far can be eliminated by a distance constraint even before the optimization. For example, if the service has a distance constraint of at most 100 kilometers, then only those <cloud owner, cloud region> within 100 kilometers to the customer location would be considered in the objective function evaluation.
If the service designer wants to trade off between distance and cost, for example, they might set wd = 1, wc = 2. This would mean that one $1 increase in price is as valuable as 2 kilometers in distance.
<cloud owner, cloud region> Candidate 1: $100, 100 kilometers => value: 300
<cloud owner, cloud region> Candidate 2: $150, 80 kilometers => value: 380
<cloud owner, cloud region> Candidate 3: $50, 190 kilometers => value: 290 <- pick this one
OOF ↔ SO API extension (VNFC deployment-intent) -- identical in content to SO <-> MC Policy API
7) MC Processing (need MC code changes)
Policy (Intent) Realization
"Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
OpenStack-based VMware VIO Cloud realization
SO ↔ MC API extension - aligned to the SO/MC API defined by SO Casablanca HPA Design to minimize the terminology set
(This data is sent from OOF to SO. SO transparently echoes this data to MC)
# #The same information is opaquely passed from OOF to SO # # #Example 1: vCPE, Burstable QoS #vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS # "oof_directives":{ "directives":[ { "vnfc_directives":[ { "vnfc_id":"vgw", "directives":[ { "directive_name":"Resource-Isolation-Intent-directive", "attributes":[ { "attribute_name": "Infrastructure Resource Isolation for VNF", "attribute_value": "Burstable QoS", }, { "attribute_name": "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage", "attribute_value": "25", }, ] }, ] }, ] }, ] } # #Example 2: #vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS # "oof_directives":{ "directives":[ { "vnfc_directives":[ { "vnfc_id":"vgw", "directives":[ { "directive_name":"Resource-Isolation-Intent-directive", "attributes":[ { "attribute_name": "Infrastructure Resource Isolation for VNF", "attribute_value": "Guaranteed QoS", }, ] }, ] }, ] }, ] } # #Example 3: #vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS # "oof_directives":{ "directives":[ { "vnfc_directives":[ { "vnfc_id":"vdns", "directives":[ { "directive_name":"Resource-Isolation-Intent-directive", "attributes":[ { "attribute_name": "Infrastructure Resource Isolation for VNF", "attribute_value": "Burstable QoS", }, { "attribute_name": "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage", "attribute_value": "25", }, ] }, { "directive_name":"Infrastructure-HA-Intent-directive", "attributes":[ { "attribute_name": "Infrastructure High Availability for VNF", }, ] }, ] }, ] }, ] } # # Example 4: # vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF # with Guaranteed QoS # "oof_directives":{ "directives":[ { "vnfc_directives":[ { "vnfc_id":"vdns", "directives":[ { "directive_name":"Resource-Isolation-Intent-directive", "attributes":[ { "attribute_name": "Infrastructure Resource Isolation for VNF", "attribute_value": "Guaranteed QoS", }, ] }, { "directive_name":"Infrastructure-HA-Intent-directive", "attributes":[ { "attribute_name": "Infrastructure High Availability for VNF", }, ] }, ] }, ] }, ] } |
Follow ups:
Implementation trade offs for Casablanca (R3) and potential Dublin (R4) plan:
Casablanca Plan
VM Instance type/VM Feature Group dollar-cost-based cloud selection is optional for all Multi-Cloud Plugins
Dublin & Beyond Potential Plan
Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)
Support three types of slices in the Cloud Infrastructure (Definition Reference: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)
Implementation:
References:
Driving Superior Isolation for Tiered Services using Resource Reservation -- Optimization Policies for Residential vCPE
-https://jira.onap.org/browse/OPTFRA-240
Note:
ONAP Component | Life Cycle Phase | Enhancements |
---|---|---|
Policy | Design | Configuration Policies for Guaranteed, Burstable & Best Effort Cloud Infrastructure Resource Slices (this will apply to VMs/Containers also) Placement Policies for Resource Slices
|
Multi-Cloud | Deploy | Resource Slice Capability Discovery |
A&AI | Deploy | Resource Slice Capability per Cloud Region
Resource Slice Type
|
OOF | Deploy | Execute Resource Slice Placement Policies for Optimized Service/VNF Placement across Cloud Regions |
Edge Infrastructure Analytics complementing VNF Analytics
ONAP, as in R2, collects the statistics/alarms/events from workloads (VMs) and take any close loop control actions such as Heal a process, scale-out, restart etc.. In R3 and beyond, infrastructure related statistics/alarms/events will be collected, generate actionable insights and take life cycle actions on the workloads. Infrastructure statistics normally include performance counters, NIC counters, IPMI information on per physical server node basis. To reduce the load on the ONAP, it is necessary that aggregated (summarized) information is sent to the ONAP from edge-clouds.
As part of this activity, intention is to create aggregation micro-service that collects the data from physical nodes (over collected and other mechanisms), aggregate the information (time based aggregation, threshold based aggregation, silencing etc.,..) based on the configurable rules and export the aggregate data to DCAE. This micro service can be instantiated by ONAP itself - one or more instances for edge-clouds at the ONAP-central itself using OOM, it could be instantiated at the edge-cloud using their own deployment tools or it could be deployed edge service providers at the regional site level.
In R3, functionality is limited to HPA features and visualization. R3 stretch goal: It collects information from each compute node for all HPA features and keeps track of health and resource information. It would use this information in placement decisions by OOF for accurate results.
Even though the aggregation service is being developed in Multi-Cloud project, it is expected that this can be deployed at various places. The decision to deploy at various levels can be due to performance and regulatory reasons. Following deployments are envisaged at this time:
Impacted projects (development activities)
ONAP Component | Enhancements |
---|---|
Overall |
|
Multi-Cloud |
|
AAI & ESR |
|
PORTAL | ESR portal related changes to take information about the edge-cloud (CA Cert and UN/PWD information) - Future when the edges started to send aggregate data) |
OOF | HPA Enhancements
|
Life Cycle stages related functions
ONAP Component | Life cycle phase | Activities |
---|---|---|
AAI and ESR | Deploy & Run time |
|
AAI and ESR | Run time |
|
Multi-Cloud | Run time |
|
OOF | Run time |
|
High level architecture slides:
ONAP Component | Life cycle phase | Enhancements |
---|---|---|
OOM - ONAP Central | Deploy |
|