最近，mirantis的工程師釋出了最新的基於Mitaka版本的Neutron效能測試結果。得出的結論是：Neutron現在的效能已經可以用生產環境了。

報告的三位作者都是OpenStack社群的活躍開發者，其中一位還是Neutron的core reviewer。並且這份報告出自實際環境（並非各種模擬環境），因此含金量還是很高的。這不禁讓人覺得，或許這才是社群開發的正確開啟方式，同時也佩服mirantis捨得花真金白銀（人力，物力）來做這樣的基礎性驗證。

下面我來給大家解讀一下這篇測試報告。

測試環境

基於MirantisOpenStack 9.0，對應社群Mitaka版本。值得注意的是，社群的Newton版本已經release幾個月了，但是Mirantis的最新發布版還是M版本。其實這麼做是合理的，雖然最新的版本包含了更多的功能，更多的功能對應了更多的程式碼，更多的程式碼意味著更多的bug。所以採用最新的版本往往會有更多的風險。另外，在OpenStack Mainstream開發時，一些重要的bug通常都會backport到之前的版本。通常是之前兩個版本，也就是說雖然現在已經是O版本的開發，但是Mitaka版本還在維護中。所以，在現階段採用的Mitaka版本，是最穩定的版本。當OpenStack進入P版本開發，Mitaka版本將不再維護，相信那個時候Mirantis會推出自己的基於Newton版本的OpenStack。

測試重點關注的是OpenStack Neutron，但是由於是一個完整的系統，其他的元件，例如RabbitMQ，DB，Nova，Ceph，Keystone也跟著被測試了一把。

再看一看Neutron的配置：

• ML2 OVS：使用了Neutron OpenVSwitch agent作為L2 agent
  
• VxLAN/L2 POP：資料網路使用VxLAN，並開啟L2 pop功能。
  
• DVR：L3使用DVR
  
• rootwrap-daemon ON：開啟rootwrap程序
  
• ovsdb native interface OFF：關閉ovsdb nativeinterface。OpenStack Neutron預設是開啟這一項的。關閉這項功能意味這用ovs的外部命令“ovs-vsctl”來配置ovs網絡卡。Ovsdb native interface是通過用tcp連線ovs db來配置ovs網絡卡。通常情況下ovsdb native interface效率更高。Mirantis沒有給出關閉的理由，我估計是想減少tcp連線，以減少對資料轉發層的影響。
  
• ofctl native interface OFF：與上一項類似，關閉ovsOpenFlow controller。Neutron預設也是開啟這一項的。關閉之後，Neutron將使用ovs的外部命令“ovs-ofctl”來下發OpenFlow規則。這也會大大降低控制面的效率。Mirantis同樣沒有給出理由，不過估計理由也是為了減少對資料轉發面的影響。
  
• agent report interval 10s：小於預設值30s
  
• agent downtime 30s：小於預設值75s，這兩項值的調低會增加控制面的負擔，但是能更快的檢驗控制面的有效性。
  

配置項的倒數4項都是為了測試而修改的配置，修改後會影響控制面的效能，實際生產環境還是建議使用Neutron預設值。

Integrity test（連通性測試）

這個測試沒太多可說的，就是同時測試Neutron的L2 domain通訊，L3 domain東西向通訊，L3 南北向floating IP通訊，L3 南北向NAT 通訊，確保這些通訊正常。有兩點值得注意的：

• 測試中的不同虛機在不同的計算節點上。也就是說，測試中的資料包，都經歷了完整的網路路徑，而並不是只在某個計算節點的br-int上走了個來回。
  
• 這裡的測試將伴隨著其他測試進行。在後繼的測試中，這個測試的指令碼仍然會執行著，以檢查其他測試本網路連通性的影響。

Density test（最大容量測試）

這個測試驗證了，OpenStackNeutron最多可以支援多少個虛機。這裡說的支援，是指能給虛機配置網路，並且虛機具有外網訪問許可權。

測試的硬體是200臺主機，其中Compute node有196臺。其他細節報告裡沒有說，但是Mirantis的Controllernode一般是3臺，還有一臺主機估計是輔助測試用的外部伺服器。

測試中的虛機在啟動的時候，會向metadata server申請IP地址，並且會向一個外部伺服器彙報自己的IP地址。也就是說如果虛機的網路正常，外部伺服器可以收到虛機的彙報。

測試中，相關的效能資料如下表：

得出的結論就是，隨著虛機數量的增加，Controller，Compute，DB，網橋上的負擔緩慢增加。這個也比較好理解，因為測試中的虛機只在啟動的時候有網路請求，之後就一直處於idle，沒有網路請求。實際環境中，不可能起了虛機什麼也不幹，所以實際環境中的曲線會更“陡”一些。

最終阻止測試進行下去的是記憶體的限制，而不是OpenStack Neutron的限制。

Mirantis的報告中指出了在測試中遇到的一些問題。

• 調大了ARP表。在建立大概16000個虛機的時候，ARP表爆了，導致虛機網路不可用。調大了ARP表，繼續跑測試就不再出現問題。
  
• 將OpenStack Nova的配置項cpu_allocation_ratio提升至12.0，以防止Compute Node上的nova vCPU的限制。
  
• 在建立了大概20000個虛機的時候，RabbitMQ和Ceph開始出現異常，而到24500個虛機的時候，OpenStack service和agent開始大規模罷工。而此時Compute Node的記憶體也快要耗盡，因此結束測試。分析認為，可以通過增加Cephmonitor或者給在專屬的主機上執行Ceph來解決Ceph的問題。
  

值得注意的是，儘管OpenStack service和agent最後大規模的罷工，但是虛機仍然具有網路連通性。這正是SDN將控制層和資料層分離的好處。

Shaker tests（網路效能測試）

Shaker是一個針對OpenStack設計的網路效能測試工具。Shaker基於iperf3和netperf，可以呼叫OpenStack API生成測試場景，並且有視覺化的測試報告。

網路效能測試同樣是基於L2domain通訊，L3 domain東西向通訊，L3 南北向通訊，但是目前Mirantis只公開了L3 東西向測試的結果。L3東西向的網路拓撲如下：

在測試過程中，有幾點影響了測試結果：

MTU

當使用預設的MTU 1500時，虛機的上行／下載的速率極限約為561/528 （Mbit／S）。之後，將MTU更新到9000，虛機的上行／下載速率極限變成3615/3844（Mbit／S）。也就是說MTU由1500改到9000，網路頻寬提升了7倍。MTU越大，網路資料報文被分片的可能性越小，相應地效率更高，但是每一個數據包的延時也變大，且資料包bit出錯率也相應增加。所以實際環境資料中心的MTU，應該除錯到一個適當值，而不是盲目的改變。

Hardware offload

測試中的資料網路用的是VxLAN網路，在網路傳輸過程中，VxLAN協議會在資料包之外增加50 bytes長度。這就涉及了資料包出／入主機時，VxLAN協議的封包／解包。舊的網絡卡不具備硬體封包／解包的能力，這部分工作由CPU運算完成，而一些新型號的網絡卡(IntelX540 or X710)，具備硬體封包／解包能力。配合這些新的網絡卡，網路效能勢必會有提升。

在Mirantis的測試中，總共有三個環境：

• Lab A：主機網絡卡不具備hardware offload，但是沒有給出具體網絡卡型號。
  
• Lab B：主機配備具備hardware offload 能力的X710 NIC網絡卡。
  
• Lab C：主機配備了4 塊 10G X710 網絡卡，並且bond在一起。
  

Lab A

Lab A的情況，在MTU部分已經講過。

Lab B

Mirantis測試了X710關閉／開啟hardware offload時，對應的MTU=1500 和MTU=9000時的頻寬：

從上面的圖中，可以得出以下結論：

• VxLAN hardware offload，在低MTU（1500）時提升比較大。在雙向頻寬測試時，提升了3.5倍，在單向測試時提升了2.5倍。這個比較好理解，MTU越低，意味著網路資料包分片越嚴重，實際的資料包越多，對應的VxLANoffload壓力也越大。這個時候的硬體加速，能帶來顯著的效果。
  
• 打開了hardware offload，MTU由1500升至9000，網路頻寬仍然有明顯的提升。在雙向頻寬測試時，提升了75%，單向頻寬測試時，提升了41%。根據前面（Lab A的結果）MTU的分析可以知道，MTU變化帶來的提升，與hardware offload是兩個概念，因此即使開啟和hardwareoffload，MTU的提升效果還在。
  
• 測試報告沒有指出，同樣情況下（hardware offload off），Lab B效能要明顯好於Lab A，前者是後者的5倍。Lab B明顯是一個更新的機房。因此，物理網路裝置，例如網絡卡，交換機，對虛擬網路的頻寬影響也是明顯的。
  

Lab B的測試可以看出，開啟硬體VxLAN offload，並使用較大的MTU，能明顯提升虛擬網路頻寬。

Lab C

硬體上Lab C與Lab B同規格，只是Lab C將4塊網絡卡bond在一起，這帶來的好處是網路頻寬非常穩定，幾乎線性。多塊網絡卡bond之後，能實現多塊網絡卡之間的負載均衡，因此得到這樣的測試結果也是意料之中。

Lab B：

Lab C：

綜合比較

從這個圖中，可以得出結論：高MTU，VxLAN hardware offload，以及bond 網絡卡，可以在高網路吞吐量時，保證虛擬網路頻寬的穩定和更高的頻寬。

結論

• 在大規模部署中，Mitaka版本的OpenStack Neutron的沒有大問題。一些小問題也已經在社群fix，並backport到Mitaka。
  
• 資料層的效能令人滿意，通過配置合適的MTU，使用新型號的網絡卡和對網絡卡做bond能大幅提升虛擬網路頻寬。
  
• 使用OpenStack Neutron在控制層崩潰的情況下，資料層還是能正常工作。虛機的網路連通性仍然保持著。
  
• Mitaka版本的OpenStack，管理虛機的能力比之前版本有明顯提升，OpenStack處於正向進化的發展中。
  
• Neutron的控制層可以管理至少24500個虛機（配合3個控制節點，也就是3個neutron-server）。實際測試中，24500並非Neutron的極限，而是其他元件的極限。
  
• Neutron可以在超過350個計算節點的大規模環境中部署。
  
• Neutron L3的南北向效能目前仍然存在問題，在南北向流量較大的環境中，使用仍需謹慎。