x86服務器中網絡性能分析與調優 轉

x86服務器中網絡性能分析與調優

2017-04-05 巨楓 英特爾精英匯

 

【OpenStack 易經】是 EasyStack 官微在2017年新推出的技術品牌，將原創技術乾貨分享給您，本期咱們討論

【x86服務器中網絡性能分析與調優】

那些事！

 

＞＞ 網絡性能理論極限

網絡數據包處理的性能指標，通常包括吞吐、延時、丟包率、抖動等。

數據包有大有小，數據包的大小對這些性能指標有很大的影響。

通常認爲服務器處理能力很強，不是數據包處理的瓶頸，而經過物理線路可以傳送數據包的最大速率，即線速（Wire Speed）纔是網絡性能的瓶頸點。

隨着物理線路和網卡的不斷髮展，這個線速不斷增大，帶寬從100Mpbs、1Gbpbs、10Gbpbs、25Gbpbs、40Gbpbs，甚至到100Gpbs。此時服務器數據包處理能力越顯重要。原有的服務器數據包處理方式已不能知足要求，一方面服務器硬件須要更新，另外一個方面軟件處理方式也須要變化。

物理線路上傳送的這些0、1電或光信號，當有了格式規定就有了意義，咱們知道以太網中有OSI七層模型和簡化的TCP/IP四層模型，這些模型規定了一個數據包的格式，下面是一個以太幀（Ethernet frame，俗稱二層）格式。

因爲物理線路的信號衝突問題（https://en.wikipedia.org/wiki/Ethernet_frame#cite_note-7），一個以太幀（不帶vlan）最小爲7+1+6+6+2+46+4+12=84B，即咱們常說的最小數據包64B，指的是6+6+2+46+4=64B。

根據以太幀的大小，咱們就能夠算出來，不一樣的以太幀大小在不一樣的物理線路上傳輸的速率，好比10Gbps的物理線路，一個10Gbps的網卡1秒內能夠接收的64B的數據包的個數（packet per seconds，即pps）爲

14.88Mpps（10^10/84/8），每一個以太幀到達網卡的時間爲67.20（10^9/14.88/10^6）納秒，下圖能夠看出以太幀越大，pps越低，到達時間越長。

因爲物理服務器處理數據包是一個一個處理，包括數據包的校驗，數據包每一層包頭的處理，因此數據包越小，到達時間就越短，服務器處理數據包要求就越高。好比64B的小包，若是處理數據包要達到線速，那麼就要求服務器67.20納秒就要處理完一個包，隨着物理線路速率越大，處理時間就要求越短，這也就要求服務器硬件和軟件都要相應的發展和升級來應對愈來愈多的數據包處理需求。

＞＞ 服務器硬件發展

這裏所說的硬件指以Intel Architecture CPU爲核心的硬件服務器。

IA處理器如何能更快的處理數據包，須要看看硬件的發展歷史。

經典計算機硬件系統架構，如圖所示。

網卡能夠集成在主板經過南橋鏈接，或者網卡插在PCI插槽上，或者好一些網卡插在PCI-E插槽上，數據包進入網卡後，須要通過南橋（主要管理IO設備），PCI/PCI-E，北橋（主要管理內存），內存和CPU的處理。網卡須要頻繁訪問內存存取數據包，CPU處理數據包須要頻繁訪問內存，此時北橋是瓶頸，當CPU個數增長時，單個內存控制器也是瓶頸。

爲了解決這些瓶頸，就出現了NUMA（Non-Uniform Memory Architecture）架構，以下圖所示，每一個CPU都有本身的內存（將北橋功能集成到了CPU），每一個CPU也有直接管理的PCI-E插槽，低速設備好比SATA/SAS，USB等被PCH, Platform Controller Hub（替換了南橋）管理。

多核CPU以及NUMA架構使得數據包處理能夠以幾乎相同處理性能橫向擴展，加上網卡的多隊列機制，能夠實現網絡數據包的併發處理。

＞＞ 網卡發展

首先看一下網卡的功能，網卡實現數據包的發送和接受，上圖A是網卡發送數據包的流程，圖B是網卡接收數據包的流程。

發送流程以下：

1. CPU通知網卡控制器發送內存中的數據

2. 網卡控制器使用DMA將內存中的數據拷貝到網卡本地內存的發送隊列

3. 網卡的MAC單元等待數據拷貝完成，準備發送

4. 網卡MAC單元經過PHY（PortPhysical Layer）單元將數據的數字信號轉換爲對應的電信號或光信號從線纜發送出去

5. 網卡控制器通知CPU數據發送完成

接收流程以下：

1. 網卡的PHY單元接收到數據包信號，將其轉換爲數字信號

2. 網卡的MAC單元將數據包存儲在本地內存的接收隊列上

3. 網卡控制器使用DMA將數據拷貝到系統內存上

4. 網卡控制器以中斷方式告訴CPU數據包已放在了指定的內存空間

網卡鏈接主板接口的發展

1. 主板內置網卡(LAN OnMotherboard, LOM)，通常爲100Mbps或1Gbps，速度慢

2. PCI：也叫傳統PCI，速度比較慢

3. PCI Express：支持熱插拔，提供更高的總線傳輸率和帶寬

網口的發展

常見接口：電口（RJ-45），光口，InfiniBand

速度發展從100Mbps到100Gbps快速發展

網卡控制器的發展

目前經常使用的網卡控制器都是ASIC（專用集成電路）芯片，該芯片固化了網絡的功能，速度快，設計完成後，成本低。但不可編程。

如今FPGA的可編程控制器也愈來愈流行，原來FPGA是做爲實驗和研究的平臺，好比設計和實驗新的網絡功能，以後使用ASIC實現。隨着虛擬化，雲計算的發展，FPGA成本的下降，FPGA的使用也愈來愈多。

還有一種是ASIC和FPGA混合方案，力圖作到兼顧二者的優勢。

ASIC芯片控制器的發展使得網卡的功能愈來愈強大，以前不少數據包處理的功能都是CPU來完成，佔用大量CPU時間，不少重複簡單的工做被網卡芯片來處理大大減輕了CPU的負擔，這就是網卡offload功能。

咱們使用ethtool -k eth0命令能夠看到網卡支持的offload功能。

Checksumming：TCP，UDP數據包都有checksum字段，這些checksum的計算和校驗交由網卡處理。

segmentation-offload：因爲MTU的限制，從網卡發出去的包中PDU（ProtocolData Unit）須要小於等於MTU，因此網卡發出去的數據包的大小都有限制。用戶態應用程序發送數據時，不會關心MTU，一個IP數據包最大能夠是65535B，即MTU最大能夠是65535，可是這個數據包要從網卡發出必需要切分爲1500的小包。這個切分過程若是CPU來作會佔用大量CPU時間，segmentation-offload就是網卡來作這件事。固然若是你將MTU設置爲9000（jumbo frame），CPU和網卡都會少處理一些。MTU理論上雖然能夠設置更大，可是9000是一個標準，交換機、網卡等都支持，爲何不能設置更大，一個緣由是設備不支持，另外一個緣由是太大的話數據包傳輸過程當中出錯概率就變大，數據包處理慢，延時也變高。

receive-offload：這個和segmentation-offload恰好相反，網卡收到小包以後，根據包的字段知道能夠合成爲一個大包，就會將這些小包合成爲大包以後給到應用程序，這樣既減小了CPU的中斷，也減小了CPU處理大量包頭的負擔。

scatter-gather：DMA將主存中的數據包拷貝到網卡內存時，因爲主存中的數據包內容在物理內存上是分散存儲的，若是沒有scatter-gather，DMA無法直接拷貝，須要kernel拷貝一次數據讓地址連續，有了scatter-gather，就能夠少一次內存拷貝。

tx-fcoe-segmentation，tx-gre-segmentation，tx-ipip-segmentation，tx-sit-segmentation，tx-udp_tnl-segmentation，tx-mpls-segmentation:

這些基本是overlay或其餘類型的數據包網卡是否支持的offload，好比udp_tnl就是指vxlan是否支持offload。

ntuple-filters，receive-hashing：若是網卡支持多隊列，ntuple-filters使得用戶能夠設置不一樣的數據包到不一樣的隊列，receive-hashing根據從網卡進來的數據包hash到不一樣的隊列處理，實現併發接收數據包。

還有不少offload，都對性能有或多或少的影響。

隨着網卡的不斷髮展，智能網卡會承載愈來愈多的功能，以減輕CPU的負擔。

好比

將安全相關的處理（SSL/IPsec，防火牆，入侵檢測，防病毒）集成在網卡中

將協議棧實如今網卡中

將虛擬交換機功能實如今網卡中（ASAP2）

使用FPGA的網卡實現用戶對網卡的自定義。

對於雲計算中虛擬機的網絡，首先充分利用網卡的Offload功能，性能會有很大提高，其次從虛擬機網卡到物理網卡的這段路徑如何實現也會對性能產生很大影響，目前有四種方式。

1. Passthrough方式：直接把物理網卡映射給虛機，雖然這種性能是最好的，可是喪失了虛擬化的本質，一個物理網卡只能被一個虛機使用。

2. SR-IOV方式：物理網卡支持虛擬化功能，能將物理網卡虛擬成多個網卡，讓多個虛機直接使用，至關於虛擬機直接使用物理網卡功能，性能很好。可是對於虛擬機的防火牆，動態遷移等很差實現。

3. Virtio半虛擬化方式：Vritio是Hypervisor中IO設備的抽象層，虛擬機的網卡是Virtio的前端驅動實現，然後端驅動實現能夠是Linux kernel中的vhost-net，也能夠用戶態的vhost-user。後端驅動實現的方式對Virtio性能影響很大。

4. 全虛擬化方式：徹底由QEMU純軟件模擬的設備，性能最差。

＞＞ 網卡調優

硬件調優儘可能使用網卡的offload，offload的成本是低的，效果是明顯的。

Offload的一些參數調優

1. 查看設置網卡隊列個數

ethtool -l eth0

2.查看設置ring buffer大小

ethtool -g eth0

3. 查看設置RSS的hash策略，好比vxlan的數據包，兩個物理節點的mac和ip是不變的，咱們在進行hash時能夠算上port，這樣兩個物理節點之間vxlan也能使用網卡多隊列。

ethtool -N eth0 rx-flow-hash udp4 sdfn

＞＞ 軟件優化

軟件數據包處理方案

a. 標準Linux數據包處理

標準Linux網絡棧設計複雜，但也是最通用的。下面是一些優化點.

1. 軟中斷的優化處理

網卡的每一個隊列會對應一個CPU來處理數據包到達的軟中斷，合理的將網卡隊列綁定到指定的CPU能更好的併發處理數據包，好比將網卡隊列綁定到離網卡近的CPU上。

2. 減小沒必要要的網絡棧處理，好比若是不使用ipv6，能夠disable掉，若是不使用iptables，清空規則。

3. 網絡參數的優化，好比調整socketbuffer，txqueuelen的大小等等。

b. OvS+DPDK

DPDK是Intel實現的一個用戶態高速數據包處理框架，相比於Linux內核實現的數據包處理方式，有如下優點。

1. 用戶態驅動程序，避免沒必要要的內存拷貝和系統調用。

2. 使用輪詢方式從網卡獲取數據包，避免中斷方式的上下文切換開銷。

3. 獨佔CPU處理數據包，雖然在網絡流量低的時候浪費CPU資源，可是網絡流量高的時候處理數據包性能很好，能夠避免CPU切換致使的cache miss和上下文切換。最新DPDK能夠實現流量小的時候使用中斷方式，流量大的時候使用輪詢方式。

4. 內存訪問優化，充分利用NUMA架構，大頁內存，無鎖隊列實現數據包的併發高效處理。

5. 軟件的優化，好比cache line對齊，CPU預取數據，充分利用IntelCPU的網絡相關新指令來提高性能。

6. 充分利用網卡的Offload功能實現硬件加速。

雖然DPDK對於數據包處理性能很好，可是它只是將數據包高效的送給用戶態，而沒有網絡棧去處理數據包，社區版DPDK也沒法與Linux網絡棧很好結合，因此基於Linux網絡棧實現的網絡應用程序沒法直接使用DPDK，若是要使用DPDK，應用程序須要重寫。固然若是是全新的網絡程序，基於DPDK開發是個不錯的選擇。

OvS是目前主流的虛擬交換機，支持主流的交換機功能，好比二層交換、網絡隔離、QoS、流量監控等，而其最大的特色就是支持openflow，openflow定義了靈活的數據包處理規範，經過openflow流表能夠實現各類網絡功能，而且經過openflow protocol能夠方便的實現控制+轉發分離的SDN方案。

OvS豐富的功能和穩定性使得其被部署在各類生產環境中，加上雲計算的快速發展，OvS成爲了雲網絡裏的關鍵組件。隨着OvS的普遍使用，對OvS的性能也提出了更高的要求。

標準OvS的數據包處理是在kernel中有個datapath，緩存流表，實現快速數據包轉發。Kernel中數據包的處理複雜，效率相比DPDK慢很多，所以使用DPDK加速能有效的提高OvS數據包處理的能力。

雖然DPDK沒有用戶態網絡棧支撐，可是OvS提供的基於流表的交換機，負責連通虛機和網卡，不須要網絡棧的更多功能，經過DPDK加速，雲環境中虛機到網卡的性能獲得了很大提高。

 

參考連接

https://en.wikipedia.org/wiki/Ethernet_frame

https://en.wikipedia.org/wiki/Internet_Protocol

https://en.wikipedia.org/wiki/Transmission_Control_Protocol

https://en.wikipedia.org/wiki/User_Datagram_Protocol

https://en.wikipedia.org/wiki/TCP_offload_engine

http://fmad.io/blog-what-is-10g-line-rate.html

http://wiki.networksecuritytoolkit.org/index.php/LAN_Ethernet_Maximum_Rates,_Generation,_Capturing_%26_Monitoring

https://zh.wikipedia.org/wiki/%E5%8D%97%E6%A1%A5

http://stackoverflow.com/questions/9770125/zero-copy-with-and-without-scatter-gather-operations

https://raghavclv.wordpress.com/article/network-packet-processing-in-linux-8m286fvf764g-5/

http://pluto.ksi.edu/~cyh/cis370/ebook/ch02c.htm

http://www.jeffshafer.com/publications/presentations/shafer-tam-talk08.pdf

https://pdfs.semanticscholar.org/8bfe/8988c14703302ebd2d567924b27a5cb10c57.pdf

http://www.cnblogs.com/TheGrandDesign/archive/2011/08/06/2129235.html

 

做者簡介：

巨楓，14年以前在IBM作OpenStack開發，涉及nova、neutron、heat。14年做爲創始工程師加入EasyStack，作過部署工具，解決OpenStack相關問題，以後專一網絡。目前做爲網絡組組長，負責網絡相關社區與產品的開發與管理，涉及neutron，二三層網絡調優，四到七層網絡功能驗證與開發，sdn/nfv，商業網絡產品的調研與對接等。