OpenStack 企業私有雲的若干需求(7):電信行業解決方案 NFV


<本文原文於 20016/01/11 發表於 CSDN 從OpenStack視角看NFV,作者為本人,編輯記者為陳晨luminous>。

1. NFV 和相關的國際組織和社區

1.1 NFV

1.1.1 定義

   NFV 的全稱是 Network Functions Virtualisation,即網絡功能虛擬化。先來看看它的定義:“網絡功能虛擬化(NFV)是利用在通用的計算、存儲、網絡接口和交換架構之上構建的雲計算虛擬化技術來承載(host)、鏈(chain)和管理(manage)標准化的虛擬網絡功能(virtual network functions (VNFs))的一種可擴展的彈性的網絡服務進化模型。”。

   在解釋之前,先看下面這張圖,你基本就會明白了它的含義:

  上圖中,左邊是傳統的網絡功能,比如防火牆、NAT、負載均衡、DNS、DPI 等等,它們都是由專有的(定制的)、集成的(數據面和控制面在一個設備之中的)的硬件設備提供的;右邊是 NFV,它是開放的彈性的方案,由在構建於標准的硬件(基本上是x86服務器和商用的存儲和網絡設備)上的雲環境中的物理機或者虛機或者容器內的標准化的提供虛擬網絡功能的軟件提供網絡功能。和傳統的方案相比,NFV 中,網絡功能都是虛擬化的,因此都變成了 vFW、vNAT、vLB 等等。

 簡單來說,NFV 是運行在標准雲之上的應用提供虛擬網絡服務的一種新的架構。相比之下,SDN 是承載 NFV 的雲基礎架構層中提供網絡虛擬化的一個組件。因此,NFV 和 SDN 處於NFV架構中的不同的層面,承擔不同的功能。

1.1.2 為什么要 NFV

下圖是 SDxCentral 網絡的一個用戶調查顯示的使用 NFV 的驅動力:

  • 敏捷性和靈活性是主體,占50%比重,這個可以從上面的圖中也能看出來
    • VNF 的安裝部署更方便
    • 測試新的 VNF 會更加的方便和快速
    • 避免升級當前系統來部署新的 NFV
  • 降低運行和投入成本,合計占36%,主要包括:
    • 使用 COTS 硬件,來降低硬件成本
    • 可以使用共享的 VNFI,減少投入
    • 商業硬件的更新周期會更快,能做到更快地提升性能和功能
  • 加速市場適應能力,占 14%

1.2 NFV 相關的國際組織和社區

1.2.1 ETSI’s Industry Specification Group on Network Functions Virtualisation (ISG NFV) 

 ETSI: European Telecommunications Standards Institute  歐洲電信標准化組織 

2012年11月,國際上七大電信網絡運營商選擇 ETSI 作為 NFV 行業規范制定組織,來制定他們所需要的 NFV 標准,並且在成員之間共享經驗和做早期實現。目前,ETSI NFV 已經發展為包括主要電信企業和IT提供商的 超過 270 家企業的一個國際組織。來自國內的幾個參與者:

  • 組織成員:中國電信、中興、華為
  • 參與者:移動、聯通、H3C

ETSI NFV 組的主要工作就是制定 NFV 標准。他們已經發布的 NFV 標准架構為:

   

該架構有三個主體組成部分:

  • NFVI:NFV Infustructure,即運行 NFV 應用的雲基礎設施即服務層。
  • VNFs:Virtual network functions,在 NFV 架構中提供虛擬網絡功能的各種應用。
  • MANO:NFV Management & Orachastration,即 VNFs 管理和編排組件,管理各個 VNF 的生命周期(包括安裝、擴展、升級和卸載等),以及 VNF 需要的虛擬化資源的管理。

1.2.2 OPNFV - Open NFV

OPNFV 是一個開放社區(Open Community),它致力於使用開源的組件來實現符合 ETSI NFV 標准架構要求的運營商級別的、整合的、開放的平台。可見,OPNFV 的目的是整合一些開源方案,做 NFV 開源的產品化。它的實現的幾個特點:

  • 選擇一系列的開源組件來構建一個開放的符合 ETSI ISG NFV 參考架構要求的實現,包括打包、安裝程序、文檔、測試案例和文檔等
  • 向各開源項目提出 NFV 的需求
  • 使用 OpenStack 作為 VNFI(這也是為什么 OpenStack 社區急吼吼地喊出在 NFV 上要實現對 VMware 的彎道超車了)。
  • 使用 Linux 作為各個節點的操作系統
  • 支持 SDN 和標准的 Neutron
  • VNF 可以部署在物理機或者虛擬內(將來可以部署在容器內)
  • 選擇 Apex、Compass、Fuel 和 Joid 作為部署工具

OPNFV 於2016年3月發布的最新的 Brahmaputra 版本的架構:

該架構的幾個特點:

  • 使用 OpenStack Liberty 版本
  • 使用 DPDK 和 ODP 做數據平面加速
  • 支持 OpenDaylight、OpenContrail、ONOS 等開源 SDN 以及基於 OVS 的標准 Neutron
  • 使用 KVM 和 Ceph

2. 兩個 NFV 產品的架構

有 ETSI NFV 組負責制定 NFV 標准,有 OPNFV 負責提供開放實現的參考架構,那各個公司就知道自己的在其中的位置了:OpenStack 廠商忙着說自己的產品可以作為 NFVI,電信應用廠商說他們的產品可以提供NVFs,MANO 廠商說他們的產品可以作為 MANO 等等。

2.1 Mirantis NFS 參考架構

Mirantis 在 ETSI NFV、OPNFV 和 OpenStack 等開放組織內都是核心成員,而且它成立了專門的 NFV 部門(部門 Leader Sutapa Bansal 在加入 Mirantis 之前在 Cisco 和 Juniper 都工作過,因此具有深厚的網絡行業背景)。他們在 2015 年9 月份發布的 MOS 7.0 中就增加了對 NFV 的支持,其技術架構為:

該架構的幾個特點:

  • Mirantis 提供運營商級別的 OpenStack 平台作為 NFVI,包括 SDN、數據平面加速以及其它增強
  • Mirantis 聯合許多商業合作伙伴提供 VNFs 和 MANO
  • Mirantis 做整合和測試

該實現架構的特點和他們目前的合作伙伴:

     

以提供 vSBC VNF 的 Metaswitch 公司為例,該公司看起來有相當強的實力:

2.2 HP 的 NFV 參考架構

 (來源

幾個特點:

  • HP 自己提供 OpenStack 和 SDN 作為 VNFI
  • HP 自己有 VFN Director 作為 MANO
  • 沒有說明 VNF 和 VNF managers 的來源

3. NFV 對 OpenStack 的需求

類別 需求 說明
總體

1. 可靠性

2. 擴展性:需要跨地域的擴展性

3. 穩定性

4. 彈性

1. RAS 需要滿足運營商級別的要求:VNF 的可靠性必須達到 99.999%;安全性和QoS比如和物理網絡相同等。

2. https://wiki.opnfv.org/display/multisite (有看到華為的級聯OpenStack 方案)

網絡

1. SR/IOV 支持

2. OVS 性能優化和 DPDK 支持

3. 多通道 (multi-queue)vhost-user

4. 支持 Service Function Chains (SFC)

5. IPv6 支持

1. 關於 SRIOV 本身,可以參考我的 KVM 介紹(4):I/O 設備直接分配和 SR-IOV [KVM PCI/PCIe Pass-Through SR-IOV];關於 Nova 和 SRIOV,可以參考我的 OpenStack 企業私有雲的若干需求(1):Nova 虛機支持 GPU

2. OVS 性能優化 

3. 服務功能鏈(SFC)

計算

1. NUMA/CPU pinning 支持

2. Anti-affinity groups 支持

3. KVM Huge pages 支持

4. Nova scheduler 性能優化

https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement

 

其它配套項目

1. MANO - OpenStack Tacker 項目

2.  Congress: Policy-as-a-Service 

3. Mistral: Workflow service 

4. Neutron “Stadium” subprojects: 包括一些了 NFV 相關的項目

5. Senlin:集群即服務 

https://wiki.openstack.org/wiki/Tacker

https://wiki.openstack.org/wiki/Congress

https://wiki.openstack.org/wiki/Mistral

http://governance.openstack.org/reference/projects/neutron.html

https://wiki.openstack.org/wiki/Senlin

OPNFV 成員企業提出的部分 OpenStak 需求對應的 blueprint:

ETSI NFV 提出的部分 OpenStack 需求以及狀態:

4. 展望和個人觀點

4.1 前景展望

    通信業已進入4.0時代,這是一個IT與CT充分融合的時代,NFV和SDN技術是實現自動部署和敏捷運營的關鍵技術。NFV 代表將來,應該是比較確定的。因為隨着 x86 服務器性能的進一步增強,和 IaaS 層面的雲計算的進一步完善,特別是 SDN 的出現,NFV 在技術上的障礙將會逐一消除。因此,隨着 NFV 一步一步落地,各大網絡設備提供商和網絡服務提供商在行業內的定位,將會可能出現重新洗牌的可能。

    同時,也應該看到,作為 NFVI 的 OpenStack 目前在穩定性、擴展性、可用性和性能方面,離 NFV 生產系統的需求還有相當長的距離。特別是考慮到電信行業運營商級別在這些方面的非常高的要求,NFV 離真正進入生產系統時間將比較長。在 VNF 應用上,也將會是按照一定的步驟分布進行。

    因此,目前階段,更多的是在標准制定、應用案例和需求甄別階段,因此,各個參與方需要做的,就是明確自己的期望再進行長期布局。近期的主要參與者,應該是以大的運營商、網絡軟件提供商和 OpenStack 提供商為主,他們將會通過彼此的協作去推動行業和標准。

這是 SDxCentral 的一些調查結果:

(1)如何看到 OPNFV:對 NFV Vendors、運營商和 OpenStack 等開源項目都很重要

(2)NFV 使用現狀:很多人在觀望,部分人在測試,還有相當一部分人沒動靜

網上公開可以搜索到的 NFV 測試案例包括:

  • 2014 年 10 月韓國最大的通信服務提供商 KT 宣布將和 Alcatel-Lucent 一起在韓國測試 NFV  (來源
  • Deutsche Telekom 同 A10 Networks 一起搭建 NFV 測試環境 (來源
  • 2015 年6月,中興通訊宣布  ”中興通訊獨家承建的中國移動RCS項目是世界最大的基於vIMS的RCS項目,預計2015年底達到1億用戶,可以提供IMS + RCS + VoWiFi +VoLTE 融合業務。同時,它也是世界最大的NFV商用網絡“。(來源
  • 2016 年 OpenStack Austin Summit 上,NFV 將會是討論的重點之一,當時候應該會有更多的測試案例被披露出來。 

(3)實施阻力:多供應商方案的整合難度、ROI 不清晰、商業方案不成熟、軟件的穩定性、安全性顧慮和轉換成本等是主要阻力

4.2 對國內NFV行業的個人觀點

(1)移動、電信等運營商和華為、中興、H3C 等網絡設備提供商來說,需要更多地參與 NFV 標准制定,以獲得影響力和推動力。在目前的 ETSI NFV 組織中,只有中國電信、中興和華為是成員,這應該說是遠遠不夠的,而且這些成員到底投入多少,還是不得而知。

  • 華為作為國內唯一、國際上也為數不多的兼具網絡設備提供商和 OpenStack 產品提供商身份的公司,具有非常好的基礎去推進 NFV;當然,NFV 和其當前的傳統網絡,也會存在左右手互搏的問題,因此可能給其策略帶來不確定性。
  • 中興作為國內主要的網絡提供商之一,能看到它在 ETSI NFV 和 OPNFV 等組織中的參與,但是,它缺乏自己的 OpenStack 產品,這在將來可能會是個潛在的問題。
  • 移動、電信、聯通等運營商,需要更多的參與 NFV 標准制定、方案測試和實施。”2016年2月23日,在西班牙巴塞羅那召開的世界移動通信大會期間,Linux基金會、中國移動、華為聯合發起OPEN-Orchestrator (OPEN-O)項目倡議“,來加速 NFV 編排器的成熟度和商業落地 (來源)。

(2)對國內初創 OpenStack 公司來說,當前,在 NFV 離進入生產系統還有相當長的一段距離,特別是國內 NFV 生態成熟度還很低的情況下,一方面,需要務實地踏踏實實地把 OpenStack 私有雲做好,把產品的 RAS 提高到能滿足 NFV 要求的程度;另一方面,需要制定自己的NFV策略,關注NFV 的成熟度推進和商業落地情況,在適當的時機再切入。

 

參考資料:


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM