F-GPS (Dublin Summary)

Owned by Ramki Krishnan
Last updated: Dec 14, 2018 by Gueyoung Jung
3 min read

Purpose:

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

  • New placement policies include Affinity and Anti-affinity.

  • Scopes of Affinity/Anti-affinity are, in a target Cloud Region, across Availability-zones and optionally, across compute hosts.

  • Applications of Affinity/Anti-affinity are workloads (VDUs) within a VNF or workloads across VNFs.

  • Opportunity to standardize many other placement policies (e.g., Beside Affinity/Anti-affinity, include Exclusivity, Quorum-Diversity, etc.) in VNFD and Policy.

  • Integrated into OOF/HAS (maybe initially as dark mode (PoC) for evaluation over Dublin).

Owner :  Under OOF

Participating Companies: VMware (Architecture/Modelling), Intel (Architecture), IBM, AT&T

Operator Support: OOF/HAS, 5G Use Case (TBD)

Parent page: TBD

Use Case Name

Showcase VNF

Test Environment

Integration Team Liaison

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.

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.

5G VNF user(s) aware Placement:

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 OpenStack cloud and evaluate in an OpenStack testbed. Later, extend to the other clouds including Azure.

  • Capacity & Capability checking for an OpenStack cloud: 

    • 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.

Impacted Projects 

Project

PTL

JIRA Epic / User Story*

Requirements

Project

PTL

JIRA Epic / User Story*

Requirements

OOF

Sarat Puthenpura



  • OSDF: support new homing/placement constraints (Affinity, Anti-affinity, and resources per workload (e.g., VM) of VNF) as policies and VNFD model.

  • HAS: 1) implement new placement constraints and interact with F-GPS, 2) deal with new placement decisions returned from F-GPS.

Multi-VIM/Cloud

 @Bin Yang



  • Collect Availability-zone capacity data from Clouds.

  • Open new API to communicate with F-GPS for per Availability-zone capacity checking.

  • Enable the placement decisions (e.g., update Heat env in OpenStack case) to send them to Cloud orchestrator (e.g., OpenStack) via plugins.

A&AI

Jimmy Forsyth



  • Open (new) API for F-GPS to obtain Availability-zone information of each Cloud Region.

  • Distributed cloud modelling immediately relevant to F-GPS - a single cloud control plane to be able manage several distributed DC locations/zones. 



Architecture committee suggestions

On Dec. 4, 2018

  • Need end-to-end workflows: Refer to the below Workflows.

  • Modeling

  • Capacity check: Fine grained, per Availability-zone (or DC).

Workflows

Flow architecture

Capacity check workflow: This can be requested in design time to determine available Availability-zones for VNF.

 

VNF Placement workflow

Presentation for Edge Automation Use Case