Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • For each VM flavor, the cost of that VM to the operator. Note that this costs includes the (potentially discounted) list price for the VM, support cost, and operations cost. The last one is definitely operator specific.
  • Operator also specify the cost for each feature: HA, etc
  • Note that the operator is free to choose what time duration the cost metric is specified for each of the MultiVIM plugins (e.g., cost per hour, cost per month) since they will do it consistently for each of the VIMs. 

Workflow Details

1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances

2. OOF → Policy - Fetch Enhanced Capacity Check & Cloud Selection Policy for Homing 

2a) OOF Processing - the fetched Policy is stored in a local data structure and is available for further use (need OOF code changes).

Code Block
languagepy
themeEmacs
titleOOF Homing Enhanced Capacity Check & Cloud Selection Policy Example
linenumberstrue
collapsetrue
{

"service": "cloudSelectionPolicy",
"policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
"description": "Cloud Selection Policy for vCPE VNFs",
"templateVersion": "0.0.1",
"version": "oofMulti-cloudCasablanca",
"priority": "3",
"riskType": "test",
"riskLevel": "2",
"guard": "False",

"content": 
{
	{
		"cloudOwner": "All", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"cloudRegion": "All", //can be a specific cloud region for a cloud owner
		"capacityCheck": "TRUE", //perform capacity check per <cloud owner, cloud region>
		"dollarCostEvaluationVM-Type": "TRUE", //evaluate dollar cost per VM type if operator has configured a policy
		"dollarCostEvaluationVM-FeatureGroup": "TRUE" //evaluate dollar per feature/group of features if operator has configured a policy
	},		 			  	
}

"resources": ["vgw", "vgmux"], //"vgw" is also interchangeably used as "vg"
"applicableResources": "any",
"identity": "cloud-atrributes",
"policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],
"policyType": "AllPolicy"

}

3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance

3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>

4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance -  perform Cloud Specific Check (capability/capacity/cost metrics) for each registered Cloud Region in Multi-Cloud

4a) OOF Processing

The enhanced OOF ↔ MC capacity check API, described below, is filled based on the enhanced Capacity Check & Cloud Selection Policy for Homing retrieved in step 2) – need OOF code changes.

...

  •  Instance Type Handling
    • Instance Type is passed in the capacity check API from OOF (Discuss) //Note, SO → MC passes OpenStack flavor name in the Heat Template/Env file
    • Convert to appropriate instance type based on intent //e.g. "Infrastructure Resource Isolation for VNF" may result in a different instance type if the cloud owner supports "Burstable QoS"
  • Parse OOF → MC Policy API 
  • For each cloud region // Public cloud could have different costs in different geographic locations
    • net_value_cost = net_value_cost + cost_instance_type // cost per instance type is based on policy (for R3, it is picked up from Multi Cloud configuration file)
    • net_value_cost = net_value_cost + cost_intent //e.g. "Infrastructure High Availability (HA) for VNF" may have additional cost
    • Capacity Check 
      • Private Clouds (OpenStack based)
        • Perform capacity check per specified Tenant (OpenStack Project)
        • If Capacity check fails, drop the cloud region out of the candidate list
      • Public Clouds or Other Clouds
        • Capacity check always succeeds //assumption: public cloud has infinite capacity

5. MC →  OOF – Return a net value cost for each <cloud owner, cloud region> if the capacity check succeeds

6a) OOF Processing - Multi-objective Optimization (need OOF code changes)

...

<cloud owner, cloud region> Candidate 3: $50, 190 kilometers => value: 290  <- pick this one

6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance

7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance

MC Processing (need MC code changes)

...

Code Block
languagepy
themeEmacs
titleMC Inter-Cloud Placement (aka Homing) Policy
linenumberstrue
collapsetrue
		"intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
				//realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"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": "25"}
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenant
				// Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

...

  • Same as R2

SO → MC API

  • Same as R2

SO → MC Processing

MC Workload Deployment Policy

Code Block
languagepy
themeEmacs
titleMC Workload Deployment Policy
linenumberstrue
collapsetrue
		"intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
				//realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"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": "25"}
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenant
				// Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

...

  • Store VNFC Policy in Multi-Cloud as a Configuration file 
    • Policy file naming: <VNFC (e.g. vGMux), Cloud Owner>
    • Content: 
      • <Policy JSON - only Intent portion> 
      • InstanceType 

...

Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)

...