Page History

Summary: Edge ScopingArchitecture & Work Items#ONAPEdgeMVP 

...

...

Distributed Edge Cloud Infrastructure Object Hierarchy (Stretch Goal - Beyond Casablanca)

Value:

• Fine grained resource management & analytics for Distributed Edge Clouds 
  

...

• 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- 64

  • 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 75

• 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 (higher priority – 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"

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

• Related Specs/Jiras:
  • OOF
    • OOF Policy spec -- https://wiki.onap.org/display/DW/OOF+Cloud+Agnostic+Policies; Policy Specification and Retrieval for 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

• 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-
  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
• 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:
  • Edge Scoping - Casablanca Stretch Goal/Beyond Casablanca

...

 The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge ScopingArchitecture & Work Items Sequence Diagram

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

...

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)

...

• Parse Template (e.g. OpenStack Heat Template)
  
  • For each VNFC, instance type in the template
    Fetch Cloud-Agnostic Workload Deployment Policy (Intent) based on VNFC (e.g. vGW)
    
    • Value/Content: <Policy JSON> 
    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"

• 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?

  • "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

        • https://docs.openstack.org/horizon/latest/admin/manage-flavors.html

        • https://blogs.vmware.com/openstack/resources-guarantee-openstack-and-vmware-integrated-openstack/

  • • • 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
      • 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" 
  • 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, ...

...

ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Stretch Goal - Beyond Casablanca)

Value

• 5G Analytics
  
  

Multi-Cloud Deployment in Edge Cloud (Stretch Goal - Beyond Casablanca)

...