Homing Policies and corresponding information required from MultiCloud for Homing in R2:
- Latency (air distance)
- Location/Coordinates of customer
- MultiCloud may not have an active role in providing this information, which would come from SO as a part of the customer order
- Location of existing service instances (or the cloud-region)
- In AAI, each cloud-region (GET /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}) record points to a complex (GET /cloud-infrastructure/complexes/complex/{physical-location-id}) and the complex relates to a lat and long. Is it correct that a VIM needs to register with MultiVIM? Does that registration have enough information for MultiVIM to create the region and complex data in A&AI?
- Example: service instance → cloud-region → complex → (lat,long)
- Location/Coordinates of customer
- Cloud Affinity
Location of cloud-regions (same as above)
- HPA capabilities, indirectly, through AAI
- CPU Pinning, NUMA as key value pairs
Example: cloud-region-id: {CPU Pinning: True, NUMA: False, Large Pages: True}
- required for evaluating HPA constraints
- provided by MultiCloud during VIM registration
- Min-guarantee capability, indirectly through AAI
- Boolean (Yes/No) for a given cloud instance.
- This can be treated similar to other capabilities (as a key value pair)
Example: cloud-region: {min-guarantee: True}
- Available Capacity, directly, through MultiCloud
- CPU, Mem, Network, Disk, etc
- required for evaluating instantaneous/available capacity check constraints
- provided by MultiCloud through a Query or DMaaP
- Example: available_capacity(cloud_region_id) -> {x: vCPU, y: memory, z: storage}
- If a public cloud does not want to reveal exact numbers, they could return ranges of capacities.
- Which of these metrics (cpu, mem, disk, network) are relevant to vCPE
- Aggregate capacity, indirectly, through AAI
- CPU, Mem, Network, Disk, etc
- Does this fold naturally under the aggregate utilization - when do we actually need aggregate static capacity for decision making ?
R3 and beyond:
- Host-level affinity/anti-affinity capability, indirectly through AAI
Open Questions:
- Is it possible to get capacities and capabilities for logical groups of resources (like host aggregates)
- Example: available_capacity(cloud_region, host_aggregate)?
- Would there be a logical group for every combination of capabilities
- grows into a large # of combinations very quickly!
- Evaluating constraint combinations:
- Example: consider the following two constraints
- Is there sufficient number of CPUs in the (cloud) cluster ? - (Yes)
- Does the (cloud) cluster support NUMA ? - (Yes)
- But, is there sufficient number of CPUs that support NUMA ? - Maybe not !
- Example Query: available_capacity(cloud_region, {HPA1, HPA2}) and the output should give the available capacity where the two HPA attributes are satisfied.
- Example: consider the following two constraints
Reservations (R3 + ):
- Based on prior discussions with SO, OOF and MultiCloud, reservations may be a desirable feature.
- Actual orchestration of resources may take long enough during the SO service instantiation workflows, during when homing recommendations provided by OOF may become potentially infeasible. It is highly desirable to reduce this window of vulnerability.
- Infeasibility may happen even if a "capacity check" is performed by OOF
- A possible solution is to have soft reservations, which is made by OOF to MultiCloud. The response to soft reservation requests can be binary (Success/Failure) from MultiCloud. OOF would be responsible rollback of resources when only a part of reservation succeeds. Soft reservations have a timeout which bounds the time for which resources are locked by MultiCloud.
Open Questions:
- Trade-off: cost of implementing soft reservations in MultiCloud vs cost of failed orchestration attempts at SO
- Do all VIMs support reservations ?
- Start with Openstack reservations