Page History

...

• Cloud agnostic placement attributes are targeted to abstract the following cloud specific placement attributes
  • 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
• For the 5G Service/VNF placement example in Note 3
  • 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
  
  
• Cloud Agnostic Placement Example
  • 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 
• Cloud Agnostic Networking Example
  • 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 or other criteria, 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
• Cloud Agnostic Resource Slice Isolation (Tenant) Example

  • 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 

...