Purpose:
Main purpose of F-GPS (a.k.a. Valet) is, with considering placement rules, (1) to precisely check capacity & capability of target DC or edge site and then, (2) to determine VNF placements.
- Placement rules include Affinity and Anti-affinity.
- Scopes of placement rules are, in a target DC or edge site, 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.
Owner : TBD
Participating Companies: Intel, VMware, AT&T
Operator Support: TBD
Parent page: TBD
Use Case Name
| Showcase VNF | Test Environment | Integration Team Liaison |
|---|---|---|
| 5G VNF teaming (TBD) | TBD | TBD |
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 DC 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 in OpenStack cloud and evaluate in an OpenStack testbed for this version. 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 DC 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 DC. 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 placement request (Stretch Goal). Until this is ready, evaluate with a manual/hard-coded specification.
Impacted Projects
| Project | PTL | JIRA Epic / User Story* | Requirements |
|---|---|---|---|
| OOF | Sarat Puthenpura | OSDF: support new placement constraints. HAS: 1) implement new placement constraints and interact with F-GPS, 2) deal with new placement result data returned from F-GPS. | |
| Multi-VIM/Cloud | Collect Availability-Zone capacity data from Clouds. API to communicate with F-GPS for Availability-Zone capacity checking. Enable the placement decisions (Heat env in OpenStack case) to send them to Cloud orchestrator. | ||
| A&AI | API to communicate with F-GPS for sending Availability-Zone information of each Cloud Region. | ||
| Policy | Pamela Dragosh | New type of homing/placement policy regarding Affinity, Anti-affinity, required resources is supported in the current interaction with OOF/OSDF. |