如今，運營商對于網絡功能虛擬化 (NFV) 的優勢已經達成普遍的認同。然而傳統的單機部署方式并不能夠幫助NFV所帶來服務所需的敏捷性，這就意味著要采用云平臺這種強有力的基礎設施抽象化方式。OpenStack 在構建 NFV 基礎設施 (NFVI) 方面起著至關重要的作用。但 OpenStack 的設計初衷是管理公有云中的應用負載，因此將其應用在通信行業時，必須對其進行擴展以滿足運營商級需求。
借助云技術體系實現 NFV
虛擬化基礎設施管理器 (VIM) 的作用
在 NFV 情境下，VIM 位于 NFV 管理和編排 (MANO) 體系的最底層（參見圖 1）。ETSI NFV 小組將 NFVI 的虛擬化層（操作系統和虛擬機管理程序）與 VIM 做了區分。
圖1：NFV參考架構
開源與云化基礎設施
云市場中有種日益增長的趨勢，那就是普遍采用開源軟件來實現云化基礎設施。Heavy Reading 的研究表明，有很大比例的運營商都想在虛擬化層中采用開源 Linux 操作系統和 KVM 虛擬機管理程序以及將 OpenStack 用作 VIM。
OpenStack 之所以成為 VIM 主流的開源選擇，是因為 OpenStack 的插件化和可編程架構，這種架構便于添加新特性。許多運營商都設想構建一個基于 Linux-KVM-OpenStack 體系的 NFV 云 (NFVI) 和 NFVI 管理層。
實現基于 OpenStack 的運營商級 VIM
為什么 OpenStack 要具備運營商級特性？
OpenStack 的設計初衷是為那些由全網規模的企業所構建的無狀態 Web 應用管理公有云基礎設施。這些 Web 應用通常稱為“牛群 (cattle)”負載，因為牛是消耗品 — 一頭牛病倒了可以再找一頭牛替代它。因此，牛群負載幾乎不需要維護，如果它們發生了硬件或虛擬機 (VM) 故障，換掉就是了。
VNF 與公有云負載截然不同。許多 VNF 都對 VM 在云基礎設施上的部署方式有著非常具體的、細粒度的要求，這是因為這些 VNF 需要一致的、可預測的性能和極低的延遲。電信網絡的運營商級需求與公有云的需求全然不同，因此 OpenStack 及其處理的虛擬化層需要擴充運營商級特性來支持運營商網絡對響應時間的嚴苛要求。
OpenStack 是一個優秀的開源軟件工程，每個新版本都更穩定、更成熟，但同時它又高度復雜，每半年就會增加數千行代碼，因此更像是一個松散耦合的工具集而非一個經過測試、集成、可立即投入運行的解決方案。開發人員往往醉心于在主干代碼中添加新特性，常會忽視一些普通但重要的問題，如錯誤修復和運營穩定性。因此，OpenStack 需要變得更健壯，能在任何環境供生產使用，當然也包括運營商級場景。而且，在運營商級情境下，OpenStack 必須得有一套適當的運營特性。
幫助 OpenStack 以運營商級方式管理 NFVI 的擴展
在性能方面，OpenStack 的運營商級擴展需要考慮：
·虛擬 CPU (vCPU) 拓撲配置。為了準確地在云資源上部署（或“調度”）VNF，OpenStack 的調度組件 Nova 需要更精細地了解資源以及資源是否配置得當以提供 VNF 所需的性能。該運營商級擴展能讓 OpenStack 以更靈活的方式向客戶機 VM 提供插槽和 vCPU（內核）的組合。
·客戶機 vCPU 綁定物理 CPU (pCPU)。該特性與上一特性互為補充，因為 Nova 需要有個機制來確保所選擇的虛擬拓撲能綁定到特定的物理 CPU 上以保障性能。
·客戶機非一致性內存訪問 (NUMA) 節點部署和拓撲感知能讓 OpenStack 了解服務器資源的分區方式以及 CPU、輸入/輸出 (I/O) 設備和內存等與插槽的連接方式。這可確保在 NUMA 宿主機上執行負載的 CPU 使用本地內存，不會因訪問其他 NUMA 節點上的 RAM 而導致延遲。該擴展還支持跨 NUMA 節點的新 OpenStack 類型模板，從而幫助客戶機 OS 智能地確定如何在這些節點之間分配負載。
·基于 I/O (PCIe) 的 NUMA 調度。基于 I/O 的 NUMA 調度支持對已分配有宿主機 PCI 設備的客戶機 VM 進行智能的 NUMA 節點部署，從而再次避免不必要的、可導致延遲的內存事務。
·為客戶機 RAM 分配大頁面內存。這將啟用在公有云場景中通常禁用的大頁面特性。執行高速 I/O 操作的 VNF 需要持續訪問支持超大頁面的服務器上的內存。這與公有云恰恰相反。
·PCI SR-IOV 網絡直通支持。該特性使 Nova 能夠感知 Neutron 端口可用于調度的相關物理網絡。
下列這組擴展能在 OpenStack 作為虛擬網絡控制點運行時提供 99.9999% 的可靠性：
·雙控制節點架構可確保高可用性。OpenStack 采用單節點控制架構，當控制器發生故障時，實例化的 VM 將繼續運行，但無法監視其運行狀況。運營商級版本則提供一對同步的控制節點，兩者之間可進行亞秒級故障切換。
·改進的 Ceilometer 可擴展性和性能可增強監控以及對當前分散在不同 OpenStack 組件上的監控數據（性能量度、故障和警報）的整合。
·改進的 VM 管理功能，如亞秒級 VM 死機檢測，與之相比，非運營商級 OpenStack 實現執行此操作則需要 60 秒。
·支持軟件滾動升級。該特性是在 OpenStack 主干代碼中逐步實現的，以免每次發布新代碼時都要重新安裝 OpenStack。
·改進的安全特性，如支持 AAA 安全性基礎設施、基于角色的身份驗證和高可用性 (HA) 存儲。
·可擴展性增強：運營商級的 OpenStack 版本需要支持數百個計算節點來實現大規模 VNF 分布，最終通過聯合不同的 OpenStack 域來支持分布式 VNF。
·一鍵安裝。運營商級 OpenStack 的實施應當能簡單、快速地安裝 — 例如，從 U 盤不到 30 分鐘就安裝完成。
實現運營商級 OpenStack 的路徑
對運營商而言，依靠自身力量開發出一套符合運營商級要求的OpenStack顯然需要花費大量的時間和經歷。NFV 市場還處在非常原始的階段，但想要發展，首先需要的就是行動起來。因此在 NFV 建設過程中，選擇適當的 OpenStack 提供商就成了一條更為有效的實現途徑。
只要所選的 OpenStack 提供商參與社區事務并且是開源軟件和開源方案的堅定支持者，那所用的 OpenStack 版本有悖標準的風險還是很低的。就 NFV 而言，OpenStack 實現的穩定性、性能和支持水平與其跟主干代碼的一致性同樣重要。
運營商應當注意其選擇的運營商級 OpenStack 提供商不能僅僅是為社區提供專有開發。它們應當評估供應商在社區中的活躍度，包括加入時間、提交記錄、既往貢獻與其在社區中認可度的相關性，例如供應商員工被選為社區領導。雖然供應商可以先于社區滿足市場需求從而增強自己在 OpenStack 方面的差異化競爭，但只要供應商快速用更先進的軟件版本替代其專有開發并向上游流程提交自己開發的功能，那其運營商級 OpenStack 實現就會逐漸成為標準。
據惠普企業 (HPE) NFV 技術顧問陳艷慶介紹，HPE 是 OpenStack 項目的主要領導者，擁有2名董事會成員和3名技術委員會成員，是 OpenStack 社區的首席貢獻著。在 OpenStack 領域，HPE 提供三種產品以滿足不同用戶的需求：
·社區版：基于原生 OpenStack 代碼構建，同時 HPE 在此基礎上進行了自動化安裝、基本的功能測試、bug修復和系統加固等工作。
·企業版：HPE 進行了充分的測試和系統加固工作，完善了平臺功能，提高了穩定性和性能，旨在滿足企業級應用在按群星、高可用性、高可擴展性方面的要求。
·電信版：基于企業版構建，擴展了對電信級應用（如：NFV）的支持，包括多樣的數據面和虛擬化層的加速方案、高效的故障檢測和恢復機制、以及智能的虛擬化網元管理功能。
總結
OpenStack 是 ETSI NFV 架構的一個重要組成部分，在將物理基礎設施抽象化為可編程的云平臺以及在云上管理負載方面發揮著關鍵作用。盡管從運營商級性能的角度來看，OpenStack 作為云管理層尚有些不足，但 OpenStack 社區正通過多種途徑為其增加至關重要的運營商級功能，包括由供應商、OPNFV 聯盟和 NFV 子小組等開發的功能。
不過，相關供應商不僅應致力于通過上游流程為 OpenStack 社區提供擴展，還應在第一時間采納社區認可的運營商級特性。選擇 OpenStack 供應商的一個關鍵標準就是供應商在 OpenStack 社區中的影響力。這要看供應商的貢獻記錄、其 OpenStack 實施的參與度以及因服務社區而獲得的尊重程度。
供應商圍繞 OpenStack 所做的創新將使運營商能夠盡早享受 NFV 的優勢。隨著主流運營商掌握 NFV 并建立新的服務敏捷性基準，那些希望保持競爭力的運營商將不得不緊跟步伐。只要 OpenStack 的運營商級特性越來越標準化，其作為運營商首選 VIM 的前景將一片光明。
京公網安備 11010502049343號