You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

vCPEPoliciesAndInformationSources

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
      • [Ethan]: MultiCloud won’t populating that information.
    • Location of existing service instances (or the cloud-region)
      • [Ethan]: The relationship information between VNF and cloud-region was populated by SO if I remember correctly.
      • 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)
      • [Ethan]: Currently we use A&AI/ESR portal to register a new VIM, some basic information like cloud-owner and cloud-region and credentials could be input from this portal and put into A&AI db, but not the complex info. After we nail down the information that OOF might need, we can discuss with ESR team to extend it. What exactly field you need in complex schema?
      • [Shankar] The minimal information required in the complex schema for homing in R2, would be the geographical coordinates (latitude, longitude). But I’m guessing it will be more than that - physical-location-id, complex-name, data-center-code, url, etc.. based on the R1 API of AAI (v11, I think)
  • Cloud Affinity
    • Location of cloud-regions (same as above)
    • [Ethan] If it’s the same as above, this do not fall into the scope of MultiCloud.
  • 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
    • Is this provided by MultiCloud during VIM registration (question)
    • [Ethan] Yes, When a new VIM was registered through ESR portal, ESR will call MultiCloud to update VIM informations like networks or images in A&AI, we could populate HPA during register in R2 release.  What kind of HPA features that might need in R2?
    • [Shankar] The exact HPA attributes relevant in R2 is still being determined. That said, it is most likely to be a list of attributes that are associated with a cloud-instance in AAI. Does that sound a reasonable way to capture capabilities ?
  • 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} 
    • [Ethan] Does software configuration attribute exist in A&AI schema now?
    • [Shankar] This is very similar to the HPA attributes  except that these are more general attributes (as compared to hardware specific attributes).

  • 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 (question)
    • 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 (question)
    • [Ethan] MultiCloud could provide an API for OOF to query available resources information. In my mind, there are two ways, first is OOF check every VIM’s available capacity from MultiCloud, MultiCloud return {vCPU, Memory, Storage}, the second one is OOF send out VNF resources requests of {vCPU: xx, Memory: yy, Storage: zz} to MultiCloud, and MultiCloud return a list of VIMs that capable for this resources requests.
    • [Shankar] I’d probably go with the former, where OOF queries for the available capacity for a given set of VIM IDs. Eg., getCapacities([cpu,mem],[vim-id-1, vim-id-5, vim-id-7]) To me this appears a much more scalable approach, since OOF would have eliminated many VIMs based on other constraints that make them an infeasible choice for a given problem. Please do let me know what you think.
  • 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 (question) 
      • 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. 
    • [Ethan] Since HPA information will be populated into A&AI, and OOF can directly query from A&AI and do the match. Do you still need this API in MultiCloud and MultiCloud return a list of available VIM for you?
    • [Shankar] I think we will still need support for such holistic capacity checks from MultiCloud. As shown in the example above, the  two constraints can independently be satisfied, but may not be satisfiable when looked at in combination. Since the VIM is the only place that has this holistic view, I’m guessing MultiCloud is the right entity capable of making these associations. Please let me know if this is still confusing, and I’ll try to elaborate more on this. 

Reservations (R3 (question) + ):

  • 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 (question) 
  • No labels