From 3821e7480016b380e02e74026fc1c15ed7435468 Mon Sep 17 00:00:00 2001 From: qihuiz Date: Mon, 25 Jun 2018 11:25:11 +0800 Subject: Merging deployment scenarios Deployment scenarios defined in the OpenStack Edge Computing Groups Dublin workshop notes [1] and in the initial change set of OPNFV Edge Cloud requirements document [1]. As the definition of deployment scenarios should be maintained only in one place OpenStack Edge Computing Group agreed [3] to merge the Dublin deployment scenarios to the OPNFV Edge Cloud requirements document in a way that in case of small and middle edge clouds the Dublin definitions are valid while in case of large edge clouds the OPNFV Edge Cloud definition is calid. This change implements this decision on top of [2]. [1]: https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Deployment_Scenarios [2]: https://gerrit.opnfv.org/gerrit/#/c/58959/ [3]: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-07-10-14.03.html Change-Id: Id647cbf2cc6af1ea53412616d622e06b349b6279 Signed-off-by: Gergely Csatari --- docs/development/requirements/requirements.rst | 138 +++++++------------------ 1 file changed, 37 insertions(+), 101 deletions(-) (limited to 'docs/development') diff --git a/docs/development/requirements/requirements.rst b/docs/development/requirements/requirements.rst index 9706dd7..325fedf 100644 --- a/docs/development/requirements/requirements.rst +++ b/docs/development/requirements/requirements.rst @@ -199,10 +199,6 @@ Related project about acceleration: https://wiki.openstack.org/wiki/Cyborg Edge Sites Conditions/ Deployment Scenarios =========================================== -.. - Editors note: Any comments to this section should be added to https://gerrit.opnfv.org/gerrit/#/c/58959 - and not to this other reviews. - Latency and distance to customer are taken as two main characters to separate different sites. The following figure shows three different sites. @@ -210,16 +206,11 @@ different sites. The following figure shows three different sites. :alt: Edge Sites Structure :align: center - Small Edge ========== - -- Distance to base station: around 10km, closest site to end users / base station - -- E2E delay(from UE to site): around 2ms - +- Distance to base station: around 10 km, closest site to end users / base station +- E2E delay(from UE to site): around 2 ms - Maximum bandwidth can provide: 50 GB/s - - Minimum hardware specs: 1 unit of - 4 cores (two ARM or Xeon-D processors) @@ -232,141 +223,86 @@ Small Edge - 64 GB RAM - 1 * 1 TB storage -- Power for a site: < 10KW - +- Power for a site: < 10 kW - Physical access of maintainer: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine is down - - Physical security: none (Optionally secure booting is needed) - - Expected frequency of updates to hardware: 3-4 year refresh cycle - - Expected frequency of updates to firmware: 6-12 months - - Expected frequency of updates to control systems (e.g. OpenStack or - Kubernetes controllers): ~ 12 - 24 months, has to be possible from - remote management - -- Physical size: Not all the sites will have 36 depth capability. Some sites - might be limited to 12 depth. - + Kubernetes controllers): ~ 12 - 24 months, has to be possible from remote + management +- Physical size: Not all the sites will have 36 inch depth capability. Some sites + might be limited to 12 inch depth. - Number of edge cloud instances: depends on demands (3000+) - - Services might be deployed here: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference - - Remote network connection reliability: No 100% uptime and variable connectivity expected. - -- Orchestration: no orchestration component. MANO deployed in core site - provide remote orchestration - -- Degree of virtualization: it is possible that no virtualization - technology would be used in small edge site if virtualization - increases structure/network complexity, reduce service performance, - or cost more resources. Bare-metal is common in small edge sites. - Container would also be a future choice if virtualization was needed - -- Storage: mainly consider local storage. Distributed storage would be - used depending on services’ needs and site conditions. +- Orchestration: no orchestration component. MANO deployed in core site provide + remote orchestration +- Degree of virtualization: it is possible that no virtualization technology would + be used in small edge site if virtualization increases structure/network complexity, + reduces service performance, or costs more resources. Bare-metal is common in small + edge sites. Container would also be a future choice if virtualization was needed +- Storage: mainly local storage. Medium Edge =========== - Distance to base station: around 50 km - -- E2E delay (from UE to site): less than 2.5ms - +- E2E delay (from UE to site): less than 2.5 ms - Maximum bandwidth can provide: 100 GB/s - -- Minimum hardware specs: 2 RU - -- Maximum hardware specs: 20 RU - +- Minimum hardware specs: 2 Rack Unit (RU) +- Maximum hardware specs: 20 Rack Unit - Power for a site: 10 - 20 10 kW - - Physical access of maintainer: Rare - -- Physical security: Medium, probably not in a secure data center, - probably in a semi-physically secure environment; 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) - +- Physical security: Medium, probably not in a secure data center, probably in + a semi-physically secure environment; 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: 5-7 years - -- Expected frequency of updates to firmware: Never unless required to - fix blocker/critical bug(s) - -- Expected frequency of updates to control systems (e.g. OpenStack or - Kubernetes controllers): 12 - 24 months - +- Expected frequency of updates to firmware: Never unless required to fix blocker/critical bug(s) +- Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): 12 - 24 months - Physical size: TBD - - Number of edge cloud instances: 3000+ - - Services might be deployed here: MEC, RAN, CPE, etc. - -- Remote network connection reliability: 24/7 (high uptime but connectivity - is variable), 100% uptime expected - +- Remote network connection reliability: 24/7 (high uptime but connectivity is + variable), 100% uptime expected - Orchestration: no orchestration component. MANO deployed in core site provide remote orchestration. - - Degree of virtualization: depends on site conditions and service requirements. VM, container may form hybrid virtualization layer. Bare-metal is possible in middle sites - -- Storage: local storage and distributed storage, which depends on site - conditions and services’ needs - +- Storage: local storage and distributed storage, which depends on site conditions + and services’ needs Large Edge ========== -- Distance to base station: 100*x km (0.8