Purpose:

Main purpose of F-GPS (a.k.a. Valet) is, with considering placement rules,  (1) to precisely check capacity & capability of target Cloud Region and then, (2) to determine VNF placements (i.e., target zone or compute host for each workload of VNF).

• Placement rules include Affinity and Anti-affinity.
• Scopes of placement rules are, in a target Cloud Region, across availability-zones and optionally, across compute hosts.
• Applications of placement rules are workloads within a VNF or workloads across VNFs.
• Opportunity to standardize many other placement rules (e.g., Exclusivity, Quorum-Diversity) in VNFD and Policy.
• Integrated into OOF/HAS (maybe initially as dark mode for evaluation in Dublin).

Owner :  TBD

Participating Companies: Intel, VMware, AT&T

Operator Support: TBD

Parent page: TBD

Use Case Name

5G VNFs teaming use case: A VNF instance has 2 workloads (2 VM instances) that must be placed in a same zone (or compute host) because of the high throughput requirement between workloads. Meanwhile, 2 more replicas of the VNF instance must be placed in different zones (or different compute hosts) of the same Cloud Region because of the high-reliability requirements for the VNF.

To meet these requirements, each VNF instance must specify an Affinity rule for its 2 workloads. Meanwhile, the same type of workloads in those 3 VNF instances must specify an Anti-affinity rule.

Dublin Focus:

• Seed code for placement decisions for OpenStack cloud and evaluate in an OpenStack testbed. Later, extend to the other clouds including Azure and AWS.
• Capacity & Capability checking for an OpenStack cloud: 1) Checking the number of zones of the target Cloud Region to solve the Anti-affinity rules, 2) Checking available capacity of each zone to solve Affinity rule, 3) Checking available host profiles of each zone to solve flavor matching (i.e., Host-Aggregates).
• Placement decisions for Affinity and Anti-Affinity among zones of target Cloud Region. Optionally, decisions go into compute hosts (for private cloud case).
• Defining Affinity and Anti-affinity rules in Policy (Stretch Goal). Until this is ready, evaluate with a manual/hard-coded policy.
• Specifying Affinity and Anti-affinity rules in homing/placement request (Stretch Goal). Until this is ready, evaluate with a manual/hard-coded specification.

Impacted Projects 

Testing

Current Status

Workflow