...
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).
The "OOF Homing Enhanced Capacity Check & Cloud Selection Policy Example" described below is an exemplary policy.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
{ "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
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.
...
- Parse OOF → MC Policy API
- For each cloud region // Public cloud could have different costs in different geographic locations
- Compute net_value based on cost
- net_value = net_value + workload_deployment_cost
- The workload deployment cost is computed per <instance type, cloud region> based on workload deployment cost policy described in Step 5b).
- Instance Type is derived from <Service, VNFC, cloud owner>
- More details are in 5b)
- Implementation Notes:
- It is not mandatory for all plugins to implement this feature since the OOF → MC API has the flexibility of turning on this feature per <cloud owner, cloud region>
- The workload deployment cost is computed per <instance type, cloud region> based on workload deployment cost policy described in Step 5b).
- net_value = net_value + workload_deployment_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
- Private Clouds (OpenStack based)
- Compute net_value based on cost
5b) Workload Deployment Cost Policy Configuration - Configured by the Operator
...
- Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
- Fetch Cloud-Agnostic Workload Deployment Policy (Intent) based on <Service (e.g. vCPE), VNFC (e.g. vGW)>
- Value/Content: <Policy JSON>
- Note: The policy details are in Section 7b).
- Parse Policy JSON
- Modify template according to Intent - intent examples below
- "Infrastructure High Availability (HA) for VNF"
- "Infrastructure Resource Isolation for VNF"
- "Burstable QoS"
- Fetch Cloud-Agnostic Workload Deployment Policy (Intent) based on <Service (e.g. vCPE), VNFC (e.g. vGW)>
- For each VNFC, instance type in the template
Policy (Intent) Realization
- "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 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 with "Guaranteed QoS"
- "flavor-xyz-no-oversubscription"
- vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB
- Same VNFC with "Burstable QoS", 25% over-subscription
- "flavor-xyz-25-percent-oversubscription"
- vCPU (Min) - 16, Mem (Min) - 32GB
- vCPU (Max) - 20, Mem (Max) - 40GB
- VNFC 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
- "Infrastructure High Availability (HA) for VNF"
7b) Cloud-Agnostic Workload Deployment Policy (Intent) Database
- For R3, Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes to simplify implementation.
- An exemplary policy is depicted below.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
//Policy Example 1 - VNFC VGW which is part of vCPE service { "Service": "vCPE" "VNFC": "vgw", //"vgw" is also intechangeably used as "vg" { "cloudOwner": "VMware VIO", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc. "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"} } } } } //Policy Example 2 - VNFC vDNS which is part of vLoadBalancer/vDNS service { "Service": "vDNS", "VNFC": "vDNS", //By default, Policy (Intent) is applicable to all cloud owners/regions unless specified. { "intent": { "name": "Infrastructure High Availability (HA) for VNF", } }, { "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": { {"Guaranteed QoS": "TRUE"} } } } } |
Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)
Value:
- Applicable to all use cases
- Casablanca Targets:
- vCPE (Enable Tiered service offering); 5G Network Slicing (Stretch Goal)
...