2017 OpenStack Summit | 網路性能篇

02-04

今天是OpenStack Boston峰會的最後一天，聽了很多，也想了很多，網路方面的內容更多一點，筆者著重以性能和擴展性為切入點，為大家總結一下相關的內容。

首先，說下Neutron性能的問題背景，OpenStack受限於默認的軟體架構設計，本身擴展性會受到限制，默認情況下，在單Region下，建議部署的節點數不要超過200個計算節點，否則隨著節點數的增加，整個OpenStack集群會出現不穩定的情況。在我們研發團隊分享的Topic《The Challenge of OpenStack Performance Optimization for 800 Nodes in Singe Region》中，對這些受限的性能瓶頸點以及解決方案提供了一些參考，大家可以參考：

單數據中心的800台伺服器性能優化的挑戰_騰訊視頻

對網路而言，為了給虛擬計算資源建立統一的大二層，通常以下幾種選型方案：Vlan、Vxlan、Gre，我們知道Vlan有2^12的規模限制，也就是說，在Vlan的大二層下，最多只能有4096個租戶隔離網路，而Vxlan可以支持2^16個租戶網路，可以滿足絕大多數的雲化場景。

以Vxlan為例，如果使用Vxlan的Type Driver，計算節點間都會兩兩建立Vxlan隧道 - 全網狀，默認情況下，對於BUM (Broadcast, Un-known unicast and multicast)類型的數據包，會泛洪給所有的計算節點，這給物理層面的交換機造成很大的負載，因此社區引進了L2pop的機制，簡單點說明，Neutron Server會將任何埠的更新，以Fanout消息的形式告知Agent，Agent會將Fdb以及Arp信息靜化在計算節點上，這樣當網路內的其它埠訪問次埠，就會由計算節點本地告知，而不會泛洪，這大大降低了物理交換機的負載；但是，這卻給消息隊列帶了更大的負載，在我們內部測試（創建/刪除虛機）中發現，約90%的消息都是Fanout類消息，這給Rabbitmq造成了很大的壓力，在規模較大的情況下，經常會發現很多Rpc超時的錯誤。

因此針對這個場景，總結下來，一共會有2個問題：1. Fanout類消息，會給消息隊列造成很大的壓力，使消息隊列成為規模擴展的瓶頸2. Agent側，頻繁的Fdb規則更新，都會以Command的形式應用規則，這給本地的操作系統造成了很大的壓力。

那麼針對這兩個問題，我們從峰會上能學到什麼新的思路呢？

在《Hybrid Messaging Solutions for Large Scale OpenStack Deployments》的Topic中，Ken向我們展示了可以使用Hybrid Messaging解決方案來應對大規模OpenStack部署，使Oslo.Messaging支持特定於服務的Transport，這就允許RPC和Notification使用不同的消息驅動，我們都知道默認的RPC都是基於Broker的消息隊列（Rabbitmq），這會引入複雜性、可擴展性的問題，對於這種短暫的RPC消息，我們完全可以基於非Broker的消息驅動，比如Zeromq，利用Direct Messaging的快速、低延遲的能力來提升RPC的性能和可擴展性；而針對Notification類的消息，會有持久化和高可用的業務要求，比如雲環境中經常利用此類消息用於計量，我們可以針對這類業務，單獨使用基於broker的消息驅動：

在這個Topic中，Ken還像我們講述了其它類型的消息驅動，闡述了它們之間的異同：

而Mark向我們介紹了利用Ombt Controller進行消息隊列的壓測方法，並展示了他們在不同場景下的測試結果：

這種依據不同業務場景，使用不同消息驅動的方法，可以給我們在性能優化上提供一些指導，這和我們在《The Challenge of OpenStack Performance Optimization for 800 Nodes in Singe Region》演講中所提到的做法有相似處，我們將L2pop類的消息單獨使用ZeroMQ類承載，從而減少對Rabbitmq的性能壓力。

在Saving up to 98% Time Updating Firewall Using Netlink的topic中，speaker向我們展示了在大規模的系統環境下，由於FWaaS使用Conntrack來控制網路的連接，它需要頻繁的更新、添加、刪除上千條防火牆規則，而規則的變更，都需要通過子進程調用命令的方式來執行，這給系統內核造成了很大的壓力：

而改造的方法，就用封裝Netlink介面給上層業務調用，而不是直接的命令調用：

通過引入Netlink，在他們的性能測試場景中，足足節省了98%的性能損耗時間，這不僅降低了規則的生效時間，也大大降低了高峰期CPU的負載，避免不可預知的情況發生：

確實，在Neutron中，好多地方都是通過命令的調用的方式來進行相關規則的更新，比如，路由CRUD、PORT的CRUD、IP的CRUD等等，不得不吐槽下，這種低級的操作方式，OpenStack發展這麼多年了，這種機制早就應該被替換掉，在上面我提及的Neutron場景問題中，對於Fdb的更新，也存在這種性能問題，通過Netlink介面，相信可以大大降低相應的性能損耗。

再說說Vxlan的網路傳輸性能，在使用社區原生的實現中，兩台VM之間的傳輸性能僅僅能達到2Gps左右，現在，越來越多的大數據分析、資料庫等業務場景，對網路傳輸的帶寬和延遲都有越來越高的要求，為了能夠達到線速轉發，目前業界也有很多做法，比如，利用硬體網卡Offload，利用DPDK用戶態轉發，SRIOV技術等，每種方案都相應的優缺點，比如DPDK需要獨立綁定CPU核，而且隨著對轉發性能的更高要求，需要綁定更多的CPU核；SRIOV技術不夠靈活，靜態的VF分配，尤其不支持安全組等虛擬網路服務。

在Serverless Network Services in OpenStack and Data Centers的topic中，Cloudigo的CEO Eran向我們展示並比較了幾種高性能轉發方案，為了支持可擴展的虛擬網路服務，提出了Serverless Network Services方案，該方案基於Mellox的Smart NIC，將更多的智能（即network service）置於Smart NIC中：

對於Smart NIC，除了要滿足更高性能的要求，同時還是一個微型的基於流的交換機，通過軟體編程，可以在Smart NIC植入更多的虛擬網路服務：

從下圖的性能比較，可以看出基於硬體的Offload，和軟體DPDK的方案比起來，利用網卡嵌入的晶元，零佔用伺服器的CPU，釋放出來的CPU可以提供給計算資源使用，同時性能是軟體方案的近4.5倍，性能上的優勢不言而喻：

當然這是，CLOUDIGO公司的商業解決方案，不過都是基於Mellox ConnectX家族的網卡做的，對於有實力的公司，也可以做出一樣的商業解決方案，相信可以給客戶帶來很多的價值：

關於性能測試，還有一個Topic比較實用，在常規的環境下，我們很難擁有一個大規模的測試環境，在《Maximizing Hardware - Server Simulator》的Topic中，Kevin向我展示了，如何最大化利用硬體資源來模擬大規模的測試環境，比如，你擁有10台物理伺服器，可以將其分成100台虛擬伺服器來充當計算節點，在這個Topic中，Kevin還提供一個模擬工具，這大大降低了我們的測試成本：

除了以上提及的Topic，本次峰會還有很多關於性能的討論，這些都可以通過本次峰會獲得相應的指導，更多的信息可以參考OpenStack的官方網站，Speaker的演講視頻目前已經在Youtube網站上了，從本次峰會的議題來看，對於性能和可擴展性的問題，已經越來越受到社區的重視，相信在未來的OpenStack的發展中，這些問題都可以得到很好的解決.