...
Main purpose of F-GPS (a.k.a. ONAP-Valet) is, with considering new placement rulespolicies, (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 (VDU) of VNF).
- Placement rules New placement policies include Affinity and Anti-affinity.
- Scopes of placement rules Affinity/Anti-affinity are, in a target Cloud Region, across availabilityAvailability-zones and optionally, across compute hosts.
- Applications of placement rules are workloads Affinity/Anti-affinity are workloads (VDUs) within a VNF or workloads across VNFs.
- Opportunity to standardize many other placement rules policies (e.g., ExclusivityBeside Affinity/Anti-affinity, include Exclusivity, Quorum-Diversity, etc.) in VNFD and Policy.
- Integrated into OOF/HAS (maybe initially as dark mode (PoC) for evaluation in over Dublin).
Owner :
...
Under OOF
Participating Companies: VMware (Architecture/Modelling), Intel (Architecture), IBM, AT&T
Operator Support: OOF/HAS, 5G Use Case (TBD)
...
Showcase VNF | Test Environment | Integration Team Liaison |
---|---|---|
Core/Data plane VNFs in 5G | TBD | OOF |
5G Data Plane Performance use case:
A VNF instance has 2 workloads (e.g., 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.
...
Place 5G VNF in a specific DC location/zone in a distributed cloud for user(s) proximity. A single cloud control plane (Cloud Region) is managing several distributed DC locations/zones.
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
- .
- Checking available capacity of each zone to solve Affinity rule
- .
- Checking available host profiles of each zone to solve flavor matching (i.e., Host-Aggregates) (Stretch Goal).
- 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.
- Distributed cloud modelling immediately relevant to F-GPS - a single cloud control plane (Cloud Region) to be able manage several distributed DC locations/zones.
Leverage capacity alerts (significant change in capacity) from Model-driven Distributed Analytics work.
...
Project | PTL | JIRA Epic / User Story* | Requirements |
---|---|---|---|
OOF | Sarat Puthenpura |
| |
Multi-VIM/Cloud |
| ||
A&AI |
|
...
- Need end-to-end workflows: The overall flow is ready (below), and detailed will be ready soonRefer to the below Workflows.
- Modeling
- Affinity/Anti-affinity: Investigated ETSI NFV-IFA (See section 7.1.8.11 and 7.1.8.12 in https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/03.01.01_60/gs_NFV-IFA011v030101p.pdf) and turns out that it VNFD includes Affinity/Anti-affinity specification per DC (NFVI-PoP), Zone (Availability-zone), and compute server (NFVI-node).
- Distributed cloud: Each Cloud Region has multiple Availability-zones (and DCs)
- Capacity check: Fine grained, per Availability-zone (or DC).
Workflows
Flow architecture
View file | ||
---|---|---|
|
...
|
Capacity check workflow: This can be requested in design time to determine available Availability-zones for VNF.
View file | ||||
---|---|---|---|---|
|
VNF Placement workflow
View file | ||||
---|---|---|---|---|
|
Presentation for Edge Automation Use Case
...