思考與實踐: 面向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等等。經過這些組織，咱們能夠了解到電信行業最新的狀態和趨勢，並有計劃的在傳統開源社區和電信相關的社區中，按照社區的方式，逐漸合入相關特性。前面提到的那些特性，都是咱們推進合入到社區中的。