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"
Support capacity check (besides capability check) for HPA resources
Applicable to all workloads - VM-based or Container-based
The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Scoping Sequence Diagram
Cloud Policy Example (under discussion):
{
"service"
:
"cloudPolicy"
,
"policyName"
:
"oofMulti-cloudCasablanca.cloudPolicy_vCPE_VNF"
,
"description"
:
"Cloud Policy for vCPE VNF"
,
"templateVersion"
:
"0.0.1"
,
"version"
:
"oofMulti-cloudCasablanca"
,
"priority"
:
"3"
,
"riskType"
:
"test"
,
"riskLevel"
:
"2"
,
"guard"
:
"False"
,
"content"
: {
//Support the current simple capacity check API besides the intent-based framework for backward compatibility. If a cloud region does not support the policy-based interface, it is given a high net value assuming the current capacity api (yes/no) returns an yes. This ensures smooth migration to the new policy-based framework.
"cloudRegion" : {
"id": "All",
"intent": {
"name": "Infrastructure High Availability (HA) for VNF", //realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or Availability set
// rack-level anti-affinity etc. – ETSI (host-level, rack-level, availability zone ...)
}
"intent": {
"name": "Infrastructure Resource Isolation for VNF", // realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" on how this can help in offering tiered services
{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "10"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
}
"cloudCapacityUtilizaitonAttributes" : {
"current_allocated_capacity" : { {"cpu", "memory", "network"}: {"cloud": {"weight": "0.85", "threshold": "0.9"}, "tenant (resource slice)": {"weight": "0.85", "threshold": "0.9"
}, "host aggregate (resource cluster)": {"weight": "0.85", "threshold": "0.9"} } },
"average_utilization" : { {"cpu", "memory", "network"}: {"cloud": {"weight": "0.13"}, "tenant (resource slice)": {"weight": "0.13"}, "host aggregate (resource cluster)": {"weight": "0.13"} }, "time-window": "24", "unit": "hours" },
"peak_utilization" : { {"cpu", "memory", "network"}: {"cloud": {"weight": "0.02"}, "tenant (resource slice)": {"weight": "0.02"}, "host aggregate (resource cluster)": {"weight": "0.02"} }, "time-window": "24", "unit": "hours" }
//current_allocated_capacity, average_utilization and peak_utilization are normalized to 1
//For a given object such as tenant_cpu, sum of weights across all attributes (current_allocated_capacity, average_utilization & peak_utilization) must be 1
//E.g. net_value = cloud_cpu_current_allocated_capacity*0.85 + cloud_cpu_average_utilization*0.13 + cloud_cpu_peak_utilization*.02 + ...
//For a given object such as cloud_cpu, if the current_allocated_capacity "threshold" exceeds the specified value, return "high net value"
}
}
"capacityProperty": { //enhanced from current capacity check // use cloud provider in – <cloud region id, cloud provider> – different cloud providers may need different capacities ...
// under discussion – "capabilityProperty": {SR_IOV, ...}
// under discussion - host network bandwidth
"controller": "multicloud",
"request": "{\"vCPU\": {\"quantity\": {\"get_param\": \"REQUIRED_VCPU\"}, \"Memory\": {\"quantity\": {\"get_param\": \"REQUIRED_MEM\"}, \"unit\": \"GB\"}, \"Storage\": {\"quantity\": {\"get_param\": \"REQUIRED_DISK\"}, \"unit\": \"GB\"}}" //from R2
},
"
resources
": ["
vGMuxInfra
"
], //R2 support – single VF module assumption per VNF
"applicableResources
": "
any
",
"
identity
": "
distance-vGMuxInfra
",
"
policyScope
": ["
vCPE
", "
US
", "
INTERNATIONAL
", "
ip
", "
vGMuxInfra
"],
"
policyType
": "All
Policy"
}
Follow up for Casablanca:
-- Policy DB – is there any restriction on json objects store? - Matti to follow up with Ankit
-- Current R2 support – single VF module (VNFC) assumption per VNF (to validate) - follow up with Kang Xi
//Support the current simple capacity check API besides the intent-based framework for backward compatibility. //If a cloud region does not support the policy-based interface, it is given a high net value assuming the current capacity api (yes/no) //returns an yes. This ensures smooth migration to the new policy-based framework. { "service": "cloudPolicy", "policyName": "oofMulti-cloudCasablanca.cloudPolicy_vCPE_VNF", "description": "Cloud Policy for vCPE VNF", "templateVersion": "0.0.1", "version": "oofMulti-cloudCasablanca", "priority": "3", "riskType": "test", "riskLevel": "2", "guard": "False", "content": { "cloudOwner" : { "owner": "All", "intent": { "name": "Infrastructure High Availability (HA) for VNF", //realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or //Availability set rack-level anti-affinity etc. – ETSI (host-level, rack-level, availability zone ...) } "intent": { "name": "Infrastructure Resource Isolation for VNF", // realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" // on how this can help in offering tiered services "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "10"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"} } } "cloudCapacityUtilizaitonAttributes" : { "current_allocated_capacity" : //from R2 { {"cpu", "memory", "network"}: {"tenant (resource slice)": {"weight": "0.85", "threshold": "0.9" }, }, // under discussion - elaborate capacity, utilization checks for various objects //"current_allocated_capacity" : //{ // {"cpu", "memory", "network"}: // {"cloud": {"weight": "0.85", "threshold": "0.9"}, // {"tenant (resource slice)": {"weight": "0.85", "threshold": "0.9" }, // {"host aggregate (resource cluster)": {"weight": "0.85", "threshold": "0.9"}, //}, //"average_utilization" : { {"cpu", "memory", "network"}: {"cloud": {"weight": "0.13"}, "tenant (resource slice)": {"weight": "0.13"}, // "host aggregate (resource cluster)": {"weight": "0.13"} }, "time-window": "24", "unit": "hours" }, //"peak_utilization" : { {"cpu", "memory", "network"}: {"cloud": {"weight": "0.02"}, "tenant (resource slice)": {"weight": "0.02"}, "host // aggregate (resource cluster)": {"weight": "0.02"} }, "time-window": "24", "unit": "hours" } //current_allocated_capacity, average_utilization and peak_utilization are normalized to 1 //For a given object such as tenant_cpu, sum of weights across all attributes (current_allocated_capacity, average_utilization & //peak_utilization) must be 1 //E.g. net_value = cloud_cpu_current_allocated_capacity*0.85 + cloud_cpu_average_utilization*0.13 + cloud_cpu_peak_utilization*.02 + ... //For a given object such as cloud_cpu, if the current_allocated_capacity "threshold" exceeds the specified value, return "high net //value" } } //use cloud provider in – <cloud region id, cloud provider> – different cloud providers may need different capacities for the same VNF ... "capacityProperty": { //under discussion – "capabilityProperty": {SR_IOV, ...} //under discussion - host network bandwidth "controller": "multicloud", "request": //from R2 "{\"vCPU\": {\"quantity\": {\"get_param\": \"REQUIRED_VCPU\"}, \"Memory\": {\"quantity\": {\"get_param\": \"REQUIRED_MEM\"}, \"unit\": \"GB\"}, \"Storage\": {\"quantity\": {\"get_param\": \"REQUIRED_DISK\"}, \"unit\": \"GB\"}}" }, } "resources": ["vGMuxInfra"], //R2 support – single VF module assumption per VNF "applicableResources": "any", "identity": "distance-vGMuxInfra", "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"], "policyType": "AllPolicy" } |
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 5G 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, 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.
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) |
DCAE & DMAPP | None expected?? |
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 |
|
ONAP Component | Life cycle phase | Enhancements |
---|---|---|
OOM - ONAP Central | Deploy |
|