Difference between revisions of "OpenStack Edge Discussions Dublin PTG"

Revision as of 09:51, 22 March 2018

Intro

This page collects the discussed topics of the Edge Worskhop from the Dublin PTG. If there is any error on this page or some information is missing please just go ahead and correcct it.

The discussions were noted in the following etherpads:

• PTG schedule ^[1]
• Gap analyzis ^[2]
• Alans problems ^[3]

Definitions

• Application Sustainability : VMs/Containers/Baremetals (i.e. workload)s already deployed on an edge site can continue to serve requests, i.e. local user can ssh on it
• Control site(s): Sites that host only control services (i.e. theses sites do not aim at hosting compute workloads). Please note that there is no particular interest of having such a site yet. We just need the definition of what is a control site for the gap analysis and the different deployment scenarios that can be considered.
• Edge site(s): Sites where servers may deliver control and compute capabilities.
• Original site: The site to where the operator is connected to.
• Remote site: The site what is managed by some management component and the operator is not directly connected to it
• Site Sustainability: Local administrators/Local users should be able to administrate/use local resources in case of disconnections to remote sites.

Edge use cases

However it was not noted in the etherpads there were lots of discussions about the use cases for edge clouds. As the OpenStack Edge Computing Whitepaper ^[4], which is available from the Edge section of openstack.org ^[5] also describes there are unlimited use cases possible. The most prominents are:

• IoT data aggregation: In case of IoT a big amount of devices are sending their data towards the central cloud. In an edge application this data can be pre processesed and aggregated, so the amount of data sent to the central cloud is smaller.
• NFV: Telecom operators would like to run realtime applications on an infrastructure close to the radio heads to provide low latency.
• Autonomus devices: Autonomus cars and other devices will generate high amount of data a will need low latency handling of this data.

Deployment Scenarios

To support all of the use cases there is a need for different size of edge clouds. During the discussions we recognised the following deployment scenarios:

Small edge

This is a single node deployment with multiple instances contained within it (lives in a coffee shop for instance); there should probably be some external management of the collection of these single nodes that does roll-up.

• Minimum hardware specs: 1 unit of 4 cores, 8 GB RAM, 225 GB SSD
• Maximum hardware specs: 1 unit of ? cores, 64 GB RAM, 1 TB storage
• Physical access of maintainer: Rare
• Physical security: none
• Expected frequency of updates to hardware: 3-4 year refresh cycle
• Expected frequency of updates to firmware: ~monthly
• Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): ~ 6 months, has to be possible from remote management
• Remote access/connectivity reliability (24/24, periodic, ...): No 100% uptime expected.

Medium edge

• Minimum hardware specs: 4RU
• Maximum hardware specs: 20 RU
• Physical access of maintainer: Rare
• Physical security: Medium, probably not in a secure data center, probably in a semi-physically secure; each device has some authentication (such as certificate) to verify it's a legitimate piece of hardware deployed by operator; network access is all through security enhanced methods (vpn, connected back to dmz); VPN itself is not considered secure, so other mechanism such as https should be employed as well)
• Expected frequency of updates to hardware:  ?
• Expected frequency of updates to firmware: ?
• Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): ?
• Remote access/connectivity reliability (24/24, periodic, ...): 24/24

Features and requirements

The discussion happened on two levels 1) on the level of future features of an edge cloud and 2) on the level of concrete missing requirements by the ones who try to deploy edge clouds today. These features and requirements are on a different level, therefore they are recorded in two separate subchapters.

Features

Features are organized into 7 levels starting from the basic level features set to the most advances feature sets.

Base assumptions for the features

• Hundreds edge sites that need to be operated by first a single operator and multiple operators
• Each edge site is composed of at least 5 servers (arbitrary chosen) Note: This is in contradiction with the Small edge Deployment Scenario
• There can be one or several control sites according to the envisioned scenarios (latency between control sites and edge sites can be between a few ms to hundreds ms).

Feature levels

Level 1

Elementary operations on the original site.

Links

1. ↑ [1]
2. ↑ [2]
3. ↑ [3]
4. ↑ [4]
5. ↑ [5]