IHS 近期發布的報告顯示，包括硬件、軟件和服務在內的全球NFV市場規模，將在2020年達到155億美元。近年來，移動運營商在軟件領域的投入要遠遠大于在服務器、存儲以及交換機硬件方面的投入，足以見得電信行業想通過NFV技術將重心從硬件轉移到軟件的決心。

不過運營商在發展NFV的過程中，由于對新興技術理解不足、現網商用經驗匱乏等原因，會產生諸多誤區。比如，很多運營商認為NFV需要用虛擬機承載，并且只能用某家設備廠商提供的軟件虛擬出來的虛擬機。這就造成很多設備廠商打著“底層優化”的幌子，對運營商進行產品的“捆綁銷售”。本文將針對“NFV與虛擬機的誤區”進行詳細解析。

虛擬機應按需求部署

在網絡架構中，虛擬機的出現是因為物理服務器處理能力太強，某個應用獨立占用過于浪費，所以將物理機的處理能力“一分為N”，在物理服務器上部署一個虛擬化軟件，將物理服務器的CPU、內存和I/O設備進行“虛擬化”后再次共享，模擬出多臺虛擬的服務器。

[[190291]]

但是虛擬化的過程本身是需要消耗不小的性能。為了模擬出一個“虛擬機”，也需要額外的附件，這些附件包括虛擬化軟件、東西防火墻、防病毒軟件等。這些附件都是需要額外購買的產品，并且運行這些軟件還需要占用物理服務器的計算資源，并且消耗資源。

虛擬化的目的是提高資源利用率，但不一定節約成本，只有合理的虛擬化才能達到節約成本的目的。虛擬機的一些特性，如HA((High Availability，高可用性)、遷移等，確實會帶來應用管理上的便捷，但這是虛擬化帶來的“副產品”，如果為了“副產品”而選擇采用虛擬機，比如，一個服務器上只開設一臺虛擬機或少量虛擬機，那就是資源浪費。

云計算的理念是按需分配，并不是一味追求全部使用虛擬機。因此我建議，對計算資源需求不大的小應用適合采用虛擬化技術，而對計算能力要求大于服務器能提供能力的四分之一以上的應用，建議采用物理服務器。另外，由于不少傳統運營商的基礎核心網元承擔著基礎通信任務，通俗地說就是“很忙”，對計算、網絡帶寬都有很高的要求，在這種情況下，就要根據不同網元的實際情況，選擇物理機或虛擬機。甚至可以在同一個網元上采用物理機+虛擬機的混合部署模式，比如日常基礎量用物理機承載，突發量采用虛擬機承載。

采用同廠家虛擬化軟件恐再陷壟斷

大多數設備廠商提出，運營商實現NFV所需要的虛擬化軟件必須是本廠提供。這點類似于運營商傳統核心網網元要采用同一個廠家提供的服務器要求，是典型的“捆綁銷售”，是“軟件壟斷”的前奏。

因為應用并不是直接部署在服務器上，而是部署在操作系統上。從架構上來看，物理機和虛擬機的架構完全一樣，虛擬化層只是對原來的硬件做了點“手腳”。除了CPU、網絡等資源是按照“時分”外，其他的如內存、存儲等都是按照“空分”來實現。虛擬化層的“魔術”會讓操作系統完全區分不出用的是物理機還是虛擬機，更何況是加載在操作系統之上的應用。

而虛擬化軟件的差別只在于其本身運行的穩定性、安全性和兼容性。對于一個成熟的虛擬化軟件來說，只要是在x86服務器上能正常運行的操作系統，同樣就可以在虛擬機上運行。目前，很多設備廠商的虛擬化軟件其實就是基于開源的XEN或者KVM(Linux虛擬化技術用戶目前可選擇的兩種免費開源管理程序)上改造而來，但這種類型的虛擬化軟件應用場景少，也沒有經過大范圍的驗證，反而風險更大。另外，如果不同的NFV網元采用不同虛擬化軟件、建設不同的資源池，不但資源共享無從談起，可能再次形成了各種資源池的“豎井”，與傳統的服務器“豎井”架構毫無區別，***結果就是，好不容易打破的硬件“豎井”又改頭換面出現了。

虛擬機遷移功能并非代表高可靠保障

另外，大多數人也會對虛擬機的“遷移”(vMotion)功能產生誤區。遷移是虛擬機帶來的最重要特性。遷移是一項資源管理技術，不能替代原來的高可靠性技術(如HA等)。遷移可以分為“熱遷移”和“冷遷移”。虛擬機的“冷遷移”本質上就是虛擬機的HA，即每臺虛擬機和管理平臺都有“心跳”，當管理平臺發現某臺虛擬機失去“心跳”，就會在合適的物理機上重建這臺虛擬機。這個過程實際上需要中斷業務，而業務恢復的時間也是分鐘級的。

“熱遷移”指的是將一個正常的處于服務中的虛擬機，從一臺物理服務器搬家到另一臺物理服務器的技術。虛擬機的“熱遷移”其實也是虛擬機本身維護手段，分為主動熱遷移和被動熱遷移。主動熱遷移是維護人員為了維護主機等原因將虛擬機遷移到其他服務器上;被動熱遷移是指當虛擬機所在的物理機利用率達到設置的閥值后采取的減負措施，遷移走的是本物理機上最空閑的虛擬機。不管是主動還是被動熱遷移，不是每次遷移都會成功的，CPU和內存利用率高的虛擬機的遷移往往經過長時間的嘗試后失敗。

也就是說，不管是冷遷移還是熱遷移，都無助于應用訪問進行故障切換和快速恢復。遷移的目的是盡可能方便地為維護人員提供資源調度、轉移手段，當物理服務器維護時需要關機重啟，當物理服務器出現繁忙，當數據中心需要擴容重新安排資源，這種時候遷移就有用武之地了，但虛擬機的遷移并不給應用帶來任何的高可靠或自愈特性。

虛擬機無法向應用提供彈性伸縮能力

虛擬機在線“縱向”擴容能力(在線增加CPU、內存等資源)并不是虛擬機的貢獻，而是操作系統的“功勞”。但并不是所有的操作系統都可以支持在線擴容，并且所有的操作系統都不支持在線“縱向”縮容(在線減少CPU、內存等資源)，要完成縮容操作需要重啟虛擬機，也就是需要中斷業務，所以虛擬機并沒有像大家以為的那樣靈活。如果想要簡單地利用虛擬機的“彈性”，是做不到基于實際業務需求進行自動部署、彈性伸縮的。

如果真想實現應用的“橫向”彈性伸縮，可以借助負載均衡模式。負載均衡是網絡設備本身提供的，他們識別的是IP地址和端口號，對于物理機和虛擬機來說效果都是一樣的。只是虛擬機可以更省些資源，因為虛擬機在關機的時候就變成共享存儲里的一個文件，并不需要占用實際的物理資源。

不管是“縱向”還是“橫向”伸縮能力都要結合應用本身的特點，而不是簡單的監控CPU和內存。需要利用一些業務系統收集的日常數據，進行數據分析，建立合適的模型，防止誤判，實現彈性伸縮。實際應用中，特別是“縮容” 可能會影響到內存里的數據和進程，隨便重啟或關機也會中斷或影響業務。

換了“馬甲”的NFV改造意義不大

目前，在運營商NFV改造過程中，出現了很多“為了改造而改造”的現象。比如原來是設備上一張板卡，就對應一臺虛擬機的的改造，把虛擬機直接封裝在容器里進行容器部署的改造。特別是核心網元的改造，因為提供的是普遍服務，日常的業務量巨大，硬件改造成為軟件后，本身的處理能力實際上是下降的，這種情況就需要一個能夠符合軟件定義特點的架構和實現方式。

特別強調的是，“容器”的微服務架構可以幫助解決核心網元長期以來的“升級影響大”、“新業務開發慢”等難題。但是真正采用容器的微服務架構，需要將原來的應用體系完全推倒重來，而且短時間內也達不到現有系統的功能和穩定性。上述成本是運營商不愿意承擔的，所以現在運營商還是喜歡用“新瓶子裝老酒”，但這樣換了“馬甲”的NFV改造意義不大。