思考与实践: 面向5G的电信基础网络

今天分享的议题是面向5G的电信基础网络的思考和实践，记忆红帽近年来，在电信行业的策略和展望。

先介绍下5G的应用场景，基站和核心网的演进路线，以及两个关键技术的特性和需求。

5G的应用场景多种多样，既有针对传统用户的移动宽带业务，也有面向各行业的垂直应用，还有IOT业务的广域互联。各类应用场景，对带宽、时延的要求不一样，好比传感器和VR就是两种彻底不一样的业务。

首先RAN侧的演进路线：继续解耦（5G从vBBU解耦为DU和CU）

从性能上看：

一、高带宽致使每站点须要的数据吞吐量更大，须要智能网卡、FPGA等加速技术。

二、毫秒级甚至更短的时延，对实时性提出了很高的要求。

而后核心网测，也是逐渐解耦，从EPC虚拟化，引入数据面和转发面分离，支持SBA架构，应用微服务化，构建新一代CORE。

5G Core细粒度的功能单元愈来愈多，不只须要微服务来保证灵活性，服务网格来保证交互的有效性，也须要统一的编排引擎，统一负责全网的部署、上线、升级、扩容等生命周期管理。

除了基站和核心网的演进路线，还有两个关键技术也很重要。其中MEC能够应对低时延、高带宽的应用。

去年MEC进入快速通道，新的社区、项目、标准逐一涌现。图上红框范围内能够认为是广义上的MEC，能够看到须要众多的服务器/站点，各站点服务器数量区别很大，从几个到上千个，中国移动、AT&T的例子。

面对这些数量众多、形态万千的站点：须要统一的编排、管理、运维；全生命周期的自动管理（基础架构和应用都须要），有助于下降人力成本；针对中小站点须要更高的资源利用率；以及全局可视化，便于维测。

另外一个关键技术是网络分片。5G的无线宽带、IOT和URLLC，须要不一样的时延和带宽，也须要不一样的网络分片。网络分片能够在统一的或者有限个基础设施上，实现这些多样化的需求。网络分片的主要特征：从Edge到核心网的资源划分；带宽、抖动、时延的管理；分布式的部署模式；监控，QOS保障；以及多租户等等。

基于以上的分析，红帽的应对策略、解决方案是什么，有什么样的具体案例。下面的时间主要来分享这些内容。

5G场景中，为了知足各项业务要求，不一样应用须要部署在不一样的地点。好比视频点播业务的Cache，要贴近用户存放热点视频。同时多厂商、多业务、多节点集成，也给运维带来了极大的压力。咱们建议使用一个统一的NFVi层，来高效、快速、可靠的管理这些业务和服务，也能够节省成本。该层须要同时支持VM和容器，该层之上，根据不一样的应用场景，能够选择不一样厂商的不一样的技术。

同时，须要构建一套标准的监控、实时总线系统，来确认不一样厂商的服务能力和水平是否知足要求。

另外，一套自动化管理系统，快速部署数量众多的应用，能够节省人力。这就是统一的基础架构。

根据红帽的策略，展开到红帽的解决方案，统一的NFVi咱们基于两大组件来构建，OpenShiftover OpenStack。OpenShift（提问）是红帽的容器/Pass平台，基于K8S、Docker、CoreOS以及RHEL，与OpenStack有紧密的集成，具体到：

网络上，Kuryr组件，提供网络侧的OSP和OCP集成能力，使用CNI接口，避免两次封装，下降网络开销。Octavia是OpenStack的负载均衡组件，能够在OCP里应用。

存储上，目前使用Cinder-Provioner来提供存储需求，对接后端Ceph。Ceph可使用OSP的，也能够单独提供。原有的CNS有两层复制的问题，已不建议使用，未来会支持Manilabacked by CephFS，能够避免两层复制的问题。

部署上，能够应用OSP的生命周期管理工具Director，进行统一部署，扩展节点，并支持在OSP裸机上部署OCP。

监控与实时总线，以及自动化解决方案，在后面会提到。

OpenShift over OpenStack在物理部署形式上，支持全栈部署和分布式部署

Option1，在核心网和MEC侧全栈部署

Option2，核心网测全栈部署，MEC侧仅部署远端节点。远端节点能够是OpenStack节点，K8S节点，或者二者的混合。

Option3，混合组网

后面会分享远端节点的技术。

这个表格，归纳了咱们针对5G场景和特性的技术储备，包括MEC、网络分片、高带宽、高吞吐量、IOT、低时延等方面。受限于时间，不彻底展开了，举几个例子：

控制面分离：须要MEC技术，咱们提供统一的编排引擎，生命周期自动化管理工具，OpenStack支持在Edge侧的部署，运维和监控能力，网卡资源分片，分布式HCI（超融合），等等。

网络分片：咱们会支持分布式部署模式、基础架构的分区，QOS管理，SA

高吞吐量：咱们会支持智能网卡、OVS硬加速、FPGA等等

下面介绍几个关键的技术储备。

高带宽：OpenStack支持分布式部署，能够部署在CO，也能够部署在本地

IOT：须要混合网支撑，红帽的OpenShift能够支持

低时延：RT-KVM、RT-Kernel

首先介绍：在MEC场景下的OpenStack部署特性

针对多个OpenStack的部署场景，红帽提供三种部署方式：应用场景依次减小，远端节点的独立性依次提升。

第一种是DistributedCompute Nodes，将多个OpenStack的控制节点集中在一块儿，远端只有计算资源池；第二种是Multiple Control Plane，由统一的部署节点部署多个OpenStack，这些OpenStack共享Keystone、存储、元数据等等；第三种是Multiple Remote Standalone，与第二种相似，也是由统一的部署节点部署多个OpenStack，只是各个远端站点日常独立运做，只在须要的时候从中央站点同步元数据。

DCN：测试时延50ms

第二个是OSP的分布式HCI。红帽OSP已经支持HCI，在同一个节点上支持计算和Ceph的能力。随着MEC的到来，咱们会在Distributed Compute Nodes部署方式中，支持远站点从单纯的计算节点扩展为HCI节点，这就是分布式HCI。

第三个是Service Mesh，服务网格。3GPPR15的5G网络规范中，控制面引入了基于服务的体系架构SBA，每一个网络功能对外提供服务化的接口，国内外运营商开始借鉴IT行业的云原生、微服务架构，将紧耦合的单体网元架构拆分为松耦合的多个微服务，来实现自身网络功能的重构。昨天上午韦总也提到，IT解耦启动的很早，1980年开始。

当谈到微服务，会想到细粒度，去中心化，以及容器。容器技术更加轻量级，更符合以微服务架构设计的分布式系统。做为业界领先的容器/Pass平台的OpenShift，能够实现各个业务的快速上线、动态扩展、弹性升级，有利于实现业务的快速迭代和创新。随着微服务的数量、种类愈来愈多，互相通讯逐渐成为一个棘手的问题，OpenShift会支持服务网格Istio，分布式服务架构来解决这个问题。Istio也被称为新一代的微服务架构，经过在每一个Pod部署一个轻量级分布式代理Envoy，造成分布式的控制平面，代理路由，管理服务请求。Istio会让服务更关注业务自身逻辑的实现，而没必要考虑故障管理、服务安全、动态路由、分布式跟踪等通用的特性。

以上是统一NFVi平台的介绍，下面分享统一基础架构的另外两部分：监控和实时总线，以及自动化管理框架。

网络分片，须要引入监控手段，来实时监控各类分片的性能是否知足要求；MEC，也须要全局的可视化。基于这个需求，红帽提出了Service Assurance方案。该方案是准实时的事件和信息的收集、分发框架。方案分为三层：监控层使用Prometheus，分发层使用AMQP，收集层使用Collectd，这三者都是在业界普遍使用的开源软件。例图中能够看到，能够和Kernel、VM、VNF Manager、ONAP、网络组件、基础架构、第三方组件等等交互信息、事件和配置。只要collectd在的地方，就能够获取信息，应用很是普遍。

须要注意的是：这个框架并不提供诸如故障恢复、根因分析等等的管理措施。

自动化场景，可依赖红帽的Satellite、Ansible和Insight三个产品来实现SOE，标准操做环境。

Satellite支持软件的分发、安装、配置、运行、升级的全过程自动化、智能化动态管理。

Ansible是应用很是普遍的自动化框架，支持跨平台、跨做业段的批量做业协同调度操做，下降管理维护成本。

Insight能够在线掌控全局信息，完成多维度的在线管控，实现事前反应和处理，下降对业务的影响。

前面是咱们面向5G的投入策略和解决方案，接下来分享一个咱们目前正在实施的案例：

这个案例昨天思科也提到了，是日本的Rakuten，拿到了日本的第四张电信运营牌照。

能够看到这个案例中，在MEC和Core两边均使用了OpenStack和Ceph做为NFVi实现方案，展现了咱们构建统一的网络基础设施的总体架构。

最后，分享咱们在5G社区的投入状况

红帽在不少传统的开源社区都有投入，好比Linux、OpenStack、K8S、KVM、DPDK、OVS等等。另外咱们也参与了一些电信行业相关的社区，好比OPNFV、ONAP、ORAN、Akraino等。除此以外，你们可能不太了解的是，咱们也是部分电信的标准组织、协会成员之一，好比3GPP，GSMA，IEEE的NGFI、TSN、PTP，ETSI的NFV、MEC、ZSM等等。经过这些组织，咱们能够了解到电信行业最新的状态和趋势，并有计划的在传统开源社区和电信相关的社区中，按照社区的方式，逐渐合入相关特性。前面提到的那些特性，都是咱们推进合入到社区中的。