解讀Mirantis最新的Neutron性能測試

01-26

最近，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地址。也就是說如果虛機的網路正常，外部伺服器可以收到虛機的彙報。

測試基於Heat，測試中的Heat stack有一個network，裡面包含一個subnet，一個DVR，以及每個Compute node上的一個虛機，也就是196台虛機。一次創建5個Heat stack。

最終，成功創建了125個Heat Stack，對應的也就是125*196= 24500個虛機。這個數字比他們的7.0版本（對應的應該是Kilo版本）要多2倍，從這可以看出，隨著OpenStack的進化，使得其性能越變越好。

測試中，相關的性能數據如下表：

得出的結論就是，隨著虛機數量的增加，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 網卡，可以在高網路吞吐量時，保證虛擬網路帶寬的穩定和更高的帶寬。

這張圖就不那麼好看了，當並發數增加時（可以理解多個虛機同時請求北向最大帶寬），虛擬網路的帶寬急劇下降。即使Lab C也是如此。DVR的SNAT還是集中式處理，當並發數增加時，網路節點的負擔將大大增加，並成為瓶頸。北向訪問的外網，其MTU，物理網路也變得更加不可控，這也是影響測試結果的因素。總之，OpenStack Neutron L3的南北向帶寬，不盡如人意。

結論

在大規模部署中，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的南北向性能目前仍然存在問題，在南北向流量較大的環境中，使用仍需謹慎。