Summary: Edge
...
Architecture & Work Items#ONAPEdgeMVP
...
Table of Contents |
---|
...
Distributed Edge Cloud Infrastructure Object Hierarchy
...
(Stretch Goal - Beyond Casablanca)
Value:
- Fine grained resource management & analytics for Distributed Edge Clouds
- VNF Placement & High Performance Networking (5G and beyond)
- Improve Workload Deployability through Cloud-Agnostic Intent for Intra-DC Placement & Networking
References:
- 1. Infrastructure Infrastructure Modelling: ONAP R3+ Cloud Infrastructure Modeling; Cloud Infrastructure Aggregate Representation Classes 2. Intra-DC Networking:
https://wiki.onap.org/download/attachments/28379482/ONAP-mc-sdn-v2.pptx?api=v2; https://wiki.onap.org/download/attachments/11928197/ONAP-mc-sdn.pdf?version=1&modificationDate=1506518708000&api=v2
Jira | ||||||
---|---|---|---|---|---|---|
|
ONAP Component | Life Cycle Phase | Enhancements | Policy
---|---|---|
Multi-Cloud | DesignDeploy | DefineSupport Distributed Cloud Infrastructure Capability Discovery (Note 1, Note 2) |
A&AI | Deploy | Support Service Placement Policies (Note 3) – No enhancement needed to Policy FrameworkLeverageStandardized Distributed Cloud Infrastructure Object Hierarchy & Capability Database (Ref. 1)
|
OOF | Deploy | SupportExecute 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 4) OOF ↔ MC Runtime Check API (Note 8 "Execution Workflow") Resource Reservation Mechanism |
SO | Deploy | Extend SO ↔ OOF API to support cloud agnostic intent (Note 5) Extend SO ↔ MC API to support cloud agnostic intent (Note 6) |
Assumption for Policy, SO, OOF:
- This uses the current Generic VNF workflow in SO
Note 1:
- Configured Capacity and Utilized (or Currently Used) Capacity are managed by the specific cloud.
Note 2:
- Cloud SW Capability example
- Cloud region "x" with SR-IOV, GPU, Min-guarantee support
- Cloud region "y" with SR-IOV support
- Cloud HW Capability example
- Resource cluster "xa" in Cloud region "x" with SR-IOV and GPU support
- Resource cluster "xb" in Cloud region "x" with GPU support
- Resource cluster "ya" in Cloud region "y" with SR-IOV support
Note 3:
- 5G Service/VNF placement example
- Constraints used by Optimization Framework (OOF)
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
- Optimization Policy used by OOF
Choose optimized cloud region (or instance) for the placement of 5G CU UP for subscriber group based on the above constraints
- Constraints used by Optimization Framework (OOF)
Note 4:
- For the 5G Service/VNF placement example in Note 3
- 5G CU-UP VNF preferably maps to a specific Cloud region & Physical DC End Point
Note 5:
- For the 5G Service/VNF placement example in Note 3
- OOF will pass the Physical DC End Point to SO as a cloud agnostic intent
Note 6:
- For the 5G Service/VNF placement example in Note 3
- SO passes the Physical DC End Point to Multi-Cloud as a cloud agnostic intent, besides the Cloud Region
Note 7:
...
- HPA attributes (e.g. Smart NIC Family, GPU Family) based on Cloud specific HW/SW support
- Normalized CPU capacity for VMs/Containers based on Cloud specific HW support
- Reference for CPU Normalization: https://d1.awsstatic.com/whitepapers/Demystifying_vCPUs.df200b766578b75009ad8d15c72e493d6408c68a.pdf
- Fine-grained Placement attributes based on Cloud specific SW support
- e.g., Rack-level Anti-affinity-> Azure: Fault-Domain, AWS: Placement-Group
- e.g., Exclusivity -> Azure: Isolated VM, AWS: Dedicated Host
- e.g., Fine grained QoS -> VMware Minimum guarantee, Kubernetes Burstable Class
...
- Multi-Cloud interprets cloud agnostic intent as Physical DC Endpoint and translates to cloud-specific placement attribute such as Availability Zone
- For this example, each distributed physical DC is in a separate Availability Zone for a OpenStack-based Cloud
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:
- This uses the current Generic VNF workflow in SO
Note 1:
- Configured Capacity and Utilized (or Currently Used) Capacity are managed by the specific cloud.
Note 2:
- Cloud SW Capability example
- Cloud region "x" with SR-IOV, GPU, Min-guarantee support
- Cloud region "y" with SR-IOV support
- Cloud HW Capability example
- Resource cluster "xa" in Cloud region "x" with SR-IOV and GPU support
- Resource cluster "xb" in Cloud region "x" with GPU support
- Resource cluster "ya" in Cloud region "y" with SR-IOV support
Note 3:
- 5G Service/VNF placement example
- Constraints used by Optimization Framework (OOF)
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
- Optimization Policy used by OOF
Choose optimized cloud region (or instance) for the placement of 5G CU UP for subscriber group based on the above constraints
- Constraints used by Optimization Framework (OOF)
Note 4:
- For the 5G Service/VNF placement example in Note 3
- 5G CU-UP VNF preferably maps to a specific Cloud region & Physical DC End Point
Note 5:
- For the 5G Service/VNF placement example in Note 3
- OOF will pass the Physical DC End Point to SO as a opaque data
Note 6:
- For the 5G Service/VNF placement example in Note 3
- SO passes the Physical DC End Point to Multi-Cloud as a opaque data, besides the Cloud Region
Cloud-agnostic Placement/Networking & Homing Policies (Phase 1 - Casablanca MVP, Phase 2 - Stretch Goal)
End-to-end use case Applicability:
All (especially the data plane VNFs with fine-grained VNF placement and high performance networking requirements)
Value:
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
Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key MULTICLOUD-272
Phase 1 (Casablanca MVP) Summary:
- Multi-Cloud Policy Framework
- Assist OOF in target cloud region selection for VNF placement (aka homing) through intent
Cloud Agnostic Intent (Policy) Execution Workflow - Steps 1- 4
- Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent (e.g. Infra HA for VMs within a VNF could have different realizations across different clouds)
Cloud Agnostic Intent (Policy) Execution Workflow - Step 5
- Assist OOF in target cloud region selection for VNF placement (aka homing) through intent
Intent Support
Single realization option per Cloud Region for the specified Intent
- Impact Projects:
- Multi-Cloud (Highest), OOF, SO (Minimal)
- End-to-end use case demonstration:
- vCPE (no additional implementation dependency), vDNS
- Types of intent supported (through OOF Policy)
- "Infrastructure High Availability for VNF"
- "Infrastructure Resource Isolation for VNF": "Burstable QoS"
- "Infrastructure Resource Isolation for VNF": "Guaranteed QoS"
- Related Specs/Jiras:
- OOF
- SO
- SO Casablanca HPA design spec with cloud agnostic intent -- https://wiki.onap.org/display/DW/SO+Casablanca+HPA+Design
- Multi-Cloud
- Generic API for SO to talk to different Multi cloud plugins to be updated with cloud agnostic intent -- https://gerrit.onap.org/r/#/c/60691/
- HPA Cloud specific (flavor etc.) Mapping for R3 – HPA Policies and Mappings
- Intent Cloud specific (flavor etc.) Mapping for R3 – Cloud Agnostic Intent and Mappings
- End-to-end use case
- Support homing through OOF for vFW, vDNS –
Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-745
- Support homing through OOF for vFW, vDNS –
- Useful Links:
- R2 HPA Integration testing – vCPE Use Case + OOF + HPA Tutorial: Design and Deploy based on ONAP#PrepareHEATtemplates
Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):
- Multi-Cloud Policy Framework
- Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent – Impact to VNF configuration
- E.g. High performance Intra-DC data plane networking with several realization choices
- Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent – Impact to VNF configuration
- Intent Support
- Multiple realization options per Cloud Region for the specified Intent
- Major Impact Projects:
- Multi-Cloud
- Minor Impact Projects:
- SO, OOF, GNF Controller
- Wiki Link:
References:
The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Architecture & Work Items Sequence Diagram
Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):
Gliffy Diagram size 1200 name Cloud Agnostic Intent Execution Workflow pagePin 42
Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):
Private Cloud Setup - OpenStack-based
- Pre-defined (including custom) flavors map to Instance types in Public Clouds
- Pre-defined flavors are created by the Cloud Admin before the Cloud is used by ONAP for workload deployment
- VMware VIO Configuration for Min Guarantee feature
- Create necessary tenants per <cloud owner, cloud region>
- Mapping of VNFC, VNF (VF module), Service (e.g. vCPE) to the corresponding tenant happens in the respective Multi-Cloud plugin.
VNFC to Instance Type Mapping
- One or more VNFCs (e.g. vCPE VGW) could map to an Instance Type
- Use Case: Residential Broadband vCPE (Approved)
- OpenStack-based Clouds
- Instance type maps to pre-defined Flavors
- Microsoft Azure
- Pre-defined Instance Types
Step 1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances (no code changes for R3)
Step 2. OOF → Policy - Fetch Cloud Selection Policy for Homing
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 for R3)
OOF Homing Enhanced Cloud Selection Policy based on Intent -- Schema with Use Case Examples as runnable python code:
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
#
#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-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"},
# 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-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-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-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-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)
|
Step 3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance (no code changes for R3)
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.
Step 4. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance + deployment-intent per vnfc (code changes in OOF for R3)
OOF ↔ SO API extension - aligned to the OOF/SO API defined by SO Casablanca HPA Design to minimize the terminology set. The data between OOF to SO and SO to MC is identical -- details of the API are in section 5.
Step 5. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (code changes in Multi-Cloud for R3)
5) MC Processing (need MC code changes)
- Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
- Parse Policy JSON coming in the SO ↔ MC directives API
- Modify template (if needed) according to Intent
- Intent examples of interest for R3
- "Infrastructure High Availability (HA) for VNF"
- "Infrastructure Resource Isolation for VNF"
- "Burstable QoS"
- "Infrastructure Resource Isolation for VNF"
- "Guaranteed QoS"
- Intent examples of interest for R3
- For each VNFC, instance type in the template
Policy (Intent) Realization
- Determining the flavor (OpenStack-based VIMs) # same logic applies for instance type in Azure
- Each VNFC uniquely maps to a Flavor - for e.g. VNFC "vgw" maps to "vgw-base", "vDNS" maps to "vDNS-base"
- Beyond Casablanca
- VNFC intent to realization mapping happens through A&AI.
- "Infrastructure High Availability (HA) for VNF"
- OpenStack-based Cloud realization
- For R3, Host-based anti-affinity using server groups //Beyond R3, Support other anti-affinity models at availability zone level etc.
- Implementation Notes:
- Instance "count" in heat template specifies VNFC scale out factor
- While dynamic injection of server group into heat template is ideal, a simple starting point could be just switching to an alternate heat template which is identical to the deployment template and additionally has server group
- Azure realization
- Availability Set?
- OpenStack-based Cloud realization
"Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
OpenStack-based VMware VIO Cloud realization
- This can be achieved through min guarantee -- Max or limit (upper bound) & Min or Reservation (guarantee) are part of OpenStack flavor metadata
- Example
- VNFC "vgw" with "Guaranteed QoS"
- vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB
- Maps to "vgw-Guaranteed-QoS" flavor for OpenStack-based VIMs
- Same VNFC with "Burstable QoS", 25% over-subscription
- vCPU (Min) - 16, Mem (Min) - 32GB
- vCPU (Max) - 20, Mem (Max) - 40GB
- Maps to "vgw-Burstable-QoS-25-percent-oversubscription" flavor for OpenStack-based VIMs
- VNFC "vDNS" with "Guaranteed QoS" & "Infrastructure High Availability"
- Maps to "vDNS-Guaranteed-QoS" flavor and "vDNS-infrastructure-high-availability" heat template
- VNFC "vgw" with "Guaranteed QoS"
- Only certain pre-defined over-subscription values are allowed to simplify implementation
- Implementation Notes:
- While dynamic injection of limit/reservation into flavor is ideal, a simple starting would be to be to switch to a pre-defined flavor in the environment file
- For aforementioned example
- Original flavor - "flavor-xyz-no-oversubscription"
- Modified flavor based on Policy - "flavor-xyz-25-percent-oversubscription"
- For aforementioned example
- While dynamic injection of limit/reservation into flavor is ideal, a simple starting would be to be to switch to a pre-defined flavor in the environment file
- Example
- Implementation Notes:
- From an implementation stand point, MC would be exposing a Workload Deployment Policy (Intent) API
- Input : deployment-intent, cloud owner, cloud region, deployment template, deployment environment file, ...
- Output : Success or Failure with reason, modified deployment template, modified deployment environment file, ...
- From an implementation stand point, MC would be exposing a Workload Deployment Policy (Intent) API
- Determining the flavor (OpenStack-based VIMs) # same logic applies for instance type in Azure
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)
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
#
#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:
- Use Cases for Integration testing
- vCPE
- In the current state, this use case cannot support the intent "Infra HA for VMs in a VNF"
- This use case has been tested in R2 with OOF↔MC capacity check API
- vDNS
- Can support intent "Infra HA for VMs in a VNF" and "Infrastructure Resource Isolation for VNF"
- Nothing additional needed in OOF or MC
- Changes needed in SO to call OOF API
- Marcus from Intel is driving this
- vCPE
- Policy DB – is there any restriction on the type of json objects that can be stored?
- Matti to follow up with Ankit
Implementation trade offs for Casablanca (R3) and potential Dublin (R4) plan:
- Deployment-Intent
- 1. "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
- Casablanca Plan
- Only certain pre-defined over-subscription values are allowed to reflect practical deployment and simplify implementation
- Dublin & Beyond Potential Plan
- Creating instance types on demand for private clouds - to study
- Casablanca Plan
- 2. Cloud-agnostic Workload Deployment Policy (Intent)
- Casablanca Plan
- Cloud-Agnostic Workload Deployment Policy (Intent) can be directly mapped to specific realization (e.g. OpenStack Flavor, Azure Instance Type) to simplify implementation.
- Dublin & Beyond Potential Plan
- VIM Capability Discovery to populate Intent in A&AI aligning taking into account Cloud selection policy based on cost specific to Intent (leverage similarities to HPA label discovery supported since R2)
- VIM selection – Intent to be populated in A&AI for capability matching
- VIM Deployment realization - Intent(s) to specific realization mapping (e.g. OpenStack Flavor, Azure Instance Type) to be populated in A&AI
- VIM Capability Discovery to populate Intent in A&AI aligning taking into account Cloud selection policy based on cost specific to Intent (leverage similarities to HPA label discovery supported since R2)
- Casablanca Plan
- 1. "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)
...
- Intent: Rack-level Anti-affinity for VMs within a VNF
- Different Realization for different clouds
- OpenStack-based (open source, Wind River, VMware VIO)
- Heat Template – policy-group, anti-affinity policy
- Azure
- Fault-domain
- AWS
- Placement group
- OpenStack-based (open source, Wind River, VMware VIO)
...
- Intent: High Performance Intra-DC data plane networking
- Several Realization Options per Cloud – the final realization choice could be based on least current resource usage, cloud capability, cost etc.
- Overlay in SmartNIC
- Gateway in SmartNIC
- Overlay in DPDK-based switch/router
- Gateway in DPDK-based switch/router
- Overlay in ToR
- Gateway in a ToR
- Gateway in a HW appliance
- Realizations which are fixed
- Underlay maps to ToR/Network Fabric
- No CPU usage for data plane networking maps to VMs/Containers with SR-IOV support
...
Intent: Resource Slice (Tenant) Isolation
Details in next section on "Cloud Resource Partitioning for Differentiated QoS"
- Several Realization Options per Cloud – the final realization choice could be based on least current resource usage, cloud capability, cost etc.
- Guaranteed Resource Slice (hard isolation) for various infra Resources (CPU/Memory/Network)
- Burstable Resource Slice (soft isolation) for various infra Resources
Note 8:
- Cloud Agnostic Intent Execution Workflow
- 1) OOF → MC runtime check for a specific cloud region which can support capability/capacity/cost metrics (enhance current capacity check API appropriately)
- 2) MC processes request from OOF
- Retrieve target Cloud Region specific policy from "Policy"
- Evaluate each of the cloud specific options in the policy from a perspective of resource allocation, utilization and cost
- Return to OOF the option which minimizes <resource allocation, utilization and cost> and the net value of the option
- In case the requirement cannot be met, return appropriate error
- Cache the option in MC for the specific cloud region as part of the VNF deployment workflow
- 3) OOF processes request from MC and picks the target cloud region which maximizes the net value
- 4) SO → MC VNF deployment request is processed by MC
- MC looks up the cache for the target cloud request with the VNF deployment request details
- MC replaces appropriate details in the cloud specific template (Heat, ARM etc.) based on the chosen option in the cache
- MC deploys workload on target cloud region with dynamically modified cloud specific template
- MC removes the cache entry for the specific cloud region for the specific VNF deployment
Gliffy Diagram | ||||
---|---|---|---|---|
|
...
Value:
- Applicable to all use cases
- Casablanca Targets:
- vCPE (Enable Tiered service offering); 5G Network Slicing (Stretch Goal)
References:
Edge Automation Requirement:
...
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 |
Aggregated Infrastructure Telemetry Streams
Value
...
| ||
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 |
Aggregated Infrastructure Telemetry Streams (Aligns with HPA requirements, Combining efforts with HPA)
Value
Edge Infrastructure Analytics complementing VNF Analytics
- Increase the accuracy of placement decisions
- Addresses gap in cloud provider solution – e.g. open source OpenStack does not have a comprehensive telemetry solution
Casablanca MVP
- HPA metrics visualization
- End-to-end use cases: vCPE, vDNS
Casablanca Stretch Goal
- OOF to use aggregated telemetry information for fine-grained optimization
Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key MULTICLOUD-254
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, 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. , 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:
- At the edge site level.
- At the regional site level (on behalf of set of edge sites).
- At the ONAP level (on behalf of set of edge sites)
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?? |
| |
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:
View file | ||||
---|---|---|---|---|
|
ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Stretch Goal - Beyond Casablanca)
Value
- 5G Analytics
ONAP Component | Life cycle phase | Enhancements |
---|---|---|
OOM - ONAP Central | Deploy |
|
Multi-Cloud Deployment in Edge Cloud (Stretch Goal - Beyond Casablanca)
Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key MULTICLOUD-262
Value:
- Multi-Cloud service to assist in central A&AI scaling by caching A&AI data locally and syncing up with A&AI periodically