面向NVMeoF存儲網絡的負載感知傳輸機制研究

齊勇軍，湯海林

(廣東白云學院大數據與計算機學院，510450，廣州)

1 問題提出

NVMe(NVM Express)主機控制器接口協議專為SSD和PCIe物理接口而設計，大大提高了主機到SSD訪問的并行性，突破了傳統SCSI協議和SATA/SAS硬盤接口的性能瓶頸[1]。NVMeoF(NVMe over Fabrics)協議進一步將NVMe的優勢擴展到了存儲網絡結構，如高并發、低延遲、低協議開銷等。為了實現NVMe SSD通過以太網構建高性能存儲網絡，廣泛應用于數據中心，Lightbits、Facebook、Intel、Cisco、Dell EMC、Micron[2-5]等公司聯合開發了NVMe over TCP標準，被 NVM Express[6]組織批準為新的 NVMeoF 傳輸層標準。然而，基于TCP的NVMeoF存儲網絡的NVMe需要計算節點和存儲節點在每次I/O請求完成時響應多個中斷請求。在高并發I/O場景下，會向CPU發出海量的中斷請求。并且隨著超高速以太網在未來數據中心的部署和應用，NVMe over TCP存儲網絡的性能瓶頸逐漸轉移到CPU對各類NVMeoF報文的處理效率上。

本文設計并實現了Load-Aware NVMeoF消息處理機制LANoT(Load-Aware NVMe over TCP)。 使用interupt合并技術緩解中斷風暴問題，通過感知不同CPU核心和目標NVMe SSD的專用隊列中的I/O負載，匹配相應的NVMeOF存儲網絡消息處理機制，實現不同特性應用的關鍵指標表現。

2 問題研究

2.1 中斷風暴問題

與只有單個請求隊列的傳統 SCSI 存儲設備不同，NVMe SSD 可以同時并發處理大量 I/O 請求。驅動完成NVMe請求的初始化后，立即通過Doorbell寄存器通知NVMe SSD開始處理NVMe指令。此外，通過單個磁頭串行執行讀寫請求的磁盤相比，NVMe SSD具有通道間、芯片間、晶圓間和組間4個級別的并行性，可以并發執行同時多條數據讀寫指令，并在指令執行后并發向CPU發起中斷請求。

數據密集型應用需要主機CPU和NVMe軟件協議棧每秒處理數百萬個數據中斷請求，這會導致主機CPU計算能力被中斷請求產生的上下文切換開銷消耗。本文將大量CPU資源用于處理NVMe SSD中斷請求而導致應用執行效率急劇下降的問題稱為NVMe中斷風暴。

2.2 多應用I/O干擾問題

隨著人工智能技術、云計算、大數據和物聯網技術的發展，以及多通道CPU服務器和多核CPU技術在數據中心的普及，數據中心的數據流量呈指數級增長。數據中心計算節點通常同時運行多個應用程序，每個應用程序具有不同的I/O特性和需求。CPU Core A上運行著數據密集型應用和延遲敏感型應用。對于這2種應用，服務質量保證對不同的性能指標敏感。

在計算節點和I/O節點的NVMeoF存儲網絡I/O關鍵路徑中，如果只用一套機制來管理不同CPU核對應的NVeoF隊列中指令的處理和發送，是無法針對性地在不同應用程序的 I/O 中實現。 I/O特性和需求準確實現應用負載感知指令處理和發送策略，更好地實現不同應用的服務質量保證。例如，針對數據密集型應用優化的NVeoF存儲網絡指令處理策略無法滿足延遲敏感應用的I/O需求，甚至可能對延遲敏感應用的I/O造成延遲放大問題，導致計算結果錯誤。點應用之間的I/O干擾問題，針對延遲敏感應用的NVeoF存儲網絡指令處理策略，由于追求極低的延遲，也無法充分發揮網絡性能及滿足數據密集型應用的高吞吐要求。因此，如何為NVMe over TCP存儲網絡的主機和目標I/O關鍵路徑中的每個CPU核設置專用的消息處理策略，并根據I/O負載動態調整，是有效避免多核CPU的關鍵。同時，正在運行的應用程序之間的I/O干擾問題，是為了充分發揮ULL-SSD高并發、低延遲所面臨的關鍵問題。

3 系統設計

3.1 應用I/O特性分析

隨著計算能力的不斷提升和存儲技術的進步，大型數據中心可以支持應用程序進行更復雜地分析和處理更大的數據集。例如，數據密集型分析應用需要讀入大量原始數據才能獲得深入分析結果，而超大規模模擬應用每次保存一個檢查點都會持續寫入TB級數據。數據密集型應用程序需要大量 I/O 帶寬來訪問呈指數增長的數據。由于數據中心計算節點通常同時運行多個應用程序，并且它們可能具有不同的I/O特性，因此不可能使用固定的機制來管理所有CPU核對應的NVeoF隊列。因此，需要應用程序 I/O。I/O需要分析確定如何為每個CPU以及 NVMe over TCP 存儲網絡的主機側和目標側之間設置專用的消息處理策略。根據對美國橡樹嶺國家實驗室管理的2個大型存儲集群的運行記錄的研究，small I/O已成為存儲系統必須處理的重要I/O模式，其中60% Spider 2 集群上的寫入請求為4 kB 或更少。根據應用程序的 I/O 特性，大致可以分為數據密集型應用和時間敏感型應用。

如果按照這個值設置聚合度，會導致聚合過大，在正常的定時器限制內無法達到聚合度，對于PDU大小較大的情況，聚合度會導致發送到網卡的數據包需要再次拆分，給網卡帶來額外的工作量。

NVMe over TCP存儲網絡的Target端向Host端發送C2HData PDU和Resp PDU(消息結構)。其中，Resp PDU的典型大小為24 B，C2HData PDU根據攜帶的數據部分的大小而變化。根據聚合度的計算公式，合適的聚合度與CapsuleCmd PDU有較大差異。

1)對于寫入密集型應用程序。NVMe over TCP存儲網絡的Host端向Target端密集發送CapsuleCmd PDU和H2CData PDU。此時的情況對應于讀取密集型應用程序。Host發送高頻大包，Target端發送高頻小包。

2)對于時間敏感的應用程序。時間敏感的應用程序通常沒有很高的吞吐率，消息大小也低于KB級別，例如實時控制流信息。雖然這種類型的應用程序不需要高帶寬，但它需要足夠低的延遲來確保應用程序的正常運行和良好的用戶體驗。對于這類應用，如果聚合度和定時器超時時間設置過高，則應用的消息延遲會過高，影響用戶體驗，甚至影響應用的正常運行。因此，應該采用低聚合、低定時器超時的策略，并犧牲一定的帶寬/吞吐量和CPU使用率，以換取時間敏感的應用消息的低延遲。

3.2 基于聚合PDU的中斷合并

LANoT有效地聚合了Host端的每個隊列中PDU，以減少Target端的中斷請求數量。LANoT引入了PG(PDU Group)數據結構來記錄需要發送的多個PDU的內存起始地址和長度。在PG聚合度達到閾值或等待時間結束后，通過調用kernel_sendmsg()接口一次將包含多個PDU的PG發送給Target。這樣，存儲節點網卡收到PG后，只需要向CPU發起中斷請求，CPU就可以在中斷處理的下半部分連續解析處理多個PDU，從而避免CPU響應到多個中斷請求和上下文切換開銷。基于CPU核的負載檢測。

在基于聚合PDU的中斷合并策略中，如果要保證消息傳輸的延遲，必須設置一個較低的計時器超時時間，以確保在時限內及時發送消息。但是，減少定時器時間后，等待時間會發生變化。總之，相應的PG聚合度更難達到閾值，相當于降低PG聚合度。為了保證消息傳輸的高吞吐量，必須盡量提高PG的聚合度。PG的聚合度越大，中斷合并的效率就越高，同時也會獲得計算節點和存儲節點的有效CPU算力，保護得更好。但是，隨著PG聚合度的增加，如果想要PG聚合度達到閾值，就需要為定時器設置更長的超時時間，防止定時器超時超時。

這2個指標所需的消息發送機制似乎相互矛盾，需要進行一定的權衡。然而，根據華中科技大學楊穎等人的研究，通過觀察大量以往的實驗結果，多個應用的并發運行時負載呈現出規律的分布。在一定時間內，單個CPU核的負載特性表現出一定的一致性。雖然不可能同時達到2個最高的目標NVMe over TCP存儲網絡中的吞吐率和最低延遲，可以為CPU內核設置專用的消息處理隊列，并根據實時I/O負載狀態動態調整消息處理策略。最大程度滿足應用對高吞吐量、低延遲的性能要求。

為解決應用之間的I/O干擾問題，根據不同應用的I/O特性，通過動態機制調整，首先要通過獲取相關維度的I/O傳輸特性數據來確定當前的負載特性。在NVMeoF消息處理方法中，以每個CPU核的特殊消息處理隊列為粒度進行I/O傳輸特征數據感知。對應中斷合并機制中聚合、數據長度、等待時間3個維度的特點，考察每個聚合PG在CPU核心專用隊列中的聚合度、聚合數據的長度、是否定時器超時，獲取的數據感知當前運行的應用I/O負載特性，對每個CPU使用Qos算法內核的專用消息處理隊列匹配當前I/O負載特性對應的專用消息處理策略正在運行的應用程序。

3.3 Load-aware動態NVMeoF消息處理機制

針對NVMe SSD在多核CPU中多個并發運行應用之間I/O干擾情況下面臨的高并發、低延遲特性的關鍵問題，本文采用機制與策略分離。設計思路是針對數據中心的多核CPU負載多樣性問題，在NVMe over TCP存儲網絡中設計Load-aware NVMe over TCP動態消息處理機制LANoT(Load Aware NVMe over TCP)，并設置專門的消息處理機制針對每個CPU核根據I/O負載動態調整策略，有效避免了多核CPU中多個并發運行的應用程序之間的I/O干擾問題，充分發揮了CPU的高并發、低延遲特性NVMe固態硬盤。

如圖1所示，對應聚合度、數據長度和等待時間3個維度，可實現對應用負載情況的感知，主動調整響應策略。例如，當一個PDU Group對應一個NVMeoF隊列時，如果因為數據長度達到閾值而連續N次觸發PDU Group的發送，則預測在NVMeoF隊列中要發送的NVMe指令主要來自來密集的I/O請求。CPU中運行的程序歸類為高吞吐量應用程序，針對CPU利用率進行了優化，提高了PDU Group的數據長度閾值，減少了中斷次數。如果因為等待時間達到閾值，連續N次觸發PDU Group的發送，預測NVMeoF隊列中要發送的NVMe指令主要來自非密集I/O請求，并且這些請求對應的PDU在PDU Group中較長。時間等待會導致I/O延遲顯著增加。因此，對CPU中運行的程序進行了延時優化，降低了PDU Group的數據長度閾值，適當減少了等待時間。具體的策略調度由Qos算法控制。

圖1 Load-aware動態NVMeoF消息處理機制

不同I/O特性的應用程序具有不同的性能目標。對于數據密集型應用，其追求的性能指標是吞吐率，對延遲時間指標要求不高。為了實現更高的吞吐量，NVMeoF存儲網絡應在通信網絡允許的情況下，采用盡可能增加PDU聚合度的策略，以減少中斷次數，提高CPU和數據的處理效率。對于延遲敏感的應用，它追求的性能指標是延遲時間，對吞吐量的要求相對較低。為了實現更低的時延，NVMeoF存儲網絡應該在不浪費CPU算力的情況下，盡量減少PDU傳輸等待時間，從而減少網絡開銷以外的不必要的延遲，提高NVeoF存儲網絡的延遲性能。

感知具有不同I/O特性的應用程序。當應用為數據密集型應用時，特點是頻繁發送PG，定時器基本不超時。為了實現針對數據密集型應用優化的性能目標，此時的策略應該是：逐漸增加聚合度，達到合適的值。當應用對時間敏感且數據不密集時，其特點是頻繁的定時器超時和NVeoF網絡中發送的PG的低聚合。為了達到針對數據密集型應用優化的性能目標，此時的策略應該是：逐漸降低聚合度到合適的值。為了實現對不同應用程序使用不同的策略，首先要解決如何確定的問題。LANoT為每個CPU核和目標存儲節點設計了專用的處理隊列，設置了SmallPG-send、PG-send和doorbell-ring 3個統計每個隊列中的變量來收集每個隊列的工作狀態，并實時傳遞給Qos算法，以達到根據不同的非通過工作狀態實時調整NVMeoF存儲網絡消息處理策略的設計目標。隊列充分適應不同特性應用的性能需求。其中small PG-sned統計隊列發送的聚合度低的PG個數，PG-send統計隊列發送的正常PG個數，doorbell-ring統計定時器超時的次數，當一個變量到達a setthreshold 時，調整聚合度，重置2個變量的值。如果2個變量相差很小，說明當前隊列應用特征不明顯，直接重置2個變量，不調整策略。

4 系統評估

4.1 系統環境測試

為了評估LANoT的實際性能，在Linux內核中實現了基于NVMe的TCP設計的LANoT原型系統，在每個隊列中引入struct kvec類型的數組PDU組，記錄聚合PDU的內存開始地址和數據長度，并為PG維護PG聚合度和PG定時器。每次發送PG時，更新SmallPG-send、PG-send和門鈴這3個統計變量的值，達到設定的閾值后調用Qos算法進行判斷處理。

通過在真實系統上安裝并部署了LANoT，并測試了其性能。LANoT測試的硬件平臺包括2臺寶德(PowerLeader)PR2124G雙向服務器，CPU型號為Intel Xeon E5-2660 v3，主頻2.60 GHz，內存256 GB。每臺服務器包含1塊邁絡思網卡(Mellanox CX555A)，2塊服務器網卡的鏈路類型設置為以太網模式，通過EDR光纖直接連接。另外，在Target服務器上安裝了一塊2TB 的U.2規格DERA NVMe SSD，并通過PCIx8 NVMe擴展卡連接CPU，保證了NVMe SSD的鏈路帶寬。LANoT軟件測試環境是基于CentOS 7.7.1908 (Core)操作系統，內核版本為Linux 4.20.0-rc3，網卡驅動版本為ofd -5.0-2.1.8。用于與NVMe內核驅動交互的NVMe -cli軟件版本為1.8.1，用于測試存儲設備性能的FIO版本為FIO -3.7。

4.2 系統性能評估

為了綜合評價LANoT的性能優勢，引入了NVMe-Local、NVMe-TCP和PGIC(基于PG的中斷合并)3個比較對象。其中，NVMe-Local用于測試相同負載下Target端NVMe SSD的本地讀寫。NVMe-TCP用于測試Linux內核中原生NVMe over TCP存儲網絡的性能，PGIC用于測試LANoT僅采用基于固定聚合PDU的中斷合并策略時的性能。此外，還對通過NVMe-TCP、PGIC和LANoT遠程訪問的RAMDisk和NVMe SSD的性能進行了測試對比，避免了NVMe SSD性能瓶頸對存儲網絡遠程訪問性能的限制。在PGIC固定參數設置方面，根據實驗數據兼顧延遲和性能的平衡，將PG定時長度設置為50 μs，PG聚合度閾值設置為16。

圖2(a)和圖2(b)分別是4 K隨機寫入和4 K隨機讀取的IOPS性能測試結果。對比本地NVMe SSD的4 K讀寫IOPS，3個線程發出請求時可以達到最高性能。

圖2 基于SSD的讀寫IOPS對比

與本地NVMe SSD的性能不同，NVMe-TCP，PGIC和LANoT 3個NVMe通過TCP存儲網絡實現方法需要更多的CPU內核參與到NVMe SSD的IOPS完全傳遞到計算節點的應用程序。對于NVMe-TCP在Linux內核中，10個CPU內核都需要充分利用NVMe SSD的4 K下的隨機寫入負載的性能，而在4 K隨機讀取負載，20threads仍不能充分利用NVMe SSD的最高性能。這也間接驗證了 NVMe over TCP 存儲網絡比本地 NVMe SSD 消耗更多的 CPU 資源。在相同的I/O負載下，使用基于聚合PDU的中斷合并的PGIC和LANoT，可以通過5線程的存儲網絡充分發揮NVMe SSD的4K寫入性能。8個線程，充分發揮4K讀取性能，CPU資源消耗降低50%以上。

在NVMe over TCP存儲網絡中，4 K隨機寫入請求采用In-Capsule數據傳輸方式，寫入NVMe SSD的數據與CapsuleCmd PDU一起從Host發送到Target。4 K讀寫IOPS測試因為每個PDU比較小，在飽和測試的情況下CPU占用率較高。它是模擬數據密集型應用程序的典型測試。

在基于NVMe SSD的性能評測中，LANoT在4 K隨機寫入負載下可比PGIC提升約25.30%的IOPS，在4 K隨機讀取負載下可比PGIC提升約36.06%的IOPS。但是由于PGIC和LANoT的性能在2個線程中接近NVMe SSD的最高性能，為了避免NVMe SSD的性能瓶頸掩蓋了LANoT的性能優勢，進行了性能評測。下圖3為計算節點通過NVMeTCP、PGIC和 LANoT遠程訪問存儲節點中的RAMDisk時的性能評估結果。 RAMDisk的讀寫性能比NVMe SSD更高，可以更好地評估存儲網絡的邊界性能。如下圖3(a)和(b)所示，在4 K隨機讀寫負載下，當存儲網絡性能不受NVMe SSD最大性能限制時，PGIC和LANoT基于聚合PDU中斷合并的優勢大大提升。隨著fiothread數量的增加，PGIC和LANoT逐漸達到了網卡的極致性能，而NVMe-TCP由于海量PDU收發操作引入的中斷風暴，嚴重限制了存儲網絡性能，無法與NVMe SSD相比，更高性能的ULLSSD的性能優勢被傳遞到計算節點應用程序。

圖3 基于RAMDisk的讀寫IOPS對比

比較2種基于中斷合并的NVMeoF消息處理機制，因為在使用fio進行飽和測試的情況下，LANoT會根據負載逐步將NVMeoF存儲網絡的消息處理策略切換到對應的一種情況。數據密集型應用處理策略，增加PG定時器的超時時間，保證每次發送的PG有更高的聚合度，降低NVMeoF存儲網絡的計算開銷。與PGIC相比，LANoT在基于RAMDisk的4 K隨機寫飽和測試中IOPS性能指標平均提升14.16%。當fio線程數為20時，最高增幅為 20.9%。在基于RAMDisk的4 K隨機讀飽和測試中，LANoT的IOPS性能指標平均可提升18.39%，最高提升28.24%。在基于RAMDisk的16 K隨機寫飽和測試中，LANoT將IOPS性能指標平均提升了14.3%，最高提升了37.14%。在基于RAMDisk的16 K隨機讀飽和測試中，LANoT平均提升了22.64%的IOPS性能指標，最高提升了29.24%。

但相應地，這是通過犧牲PDU延遲時間性能指標來實現的。如圖4所示，在基于RAMDisk的4 K隨機讀寫飽和測試中，與PGIC和NVMe-TCP不同的最低延遲基本維持在200 μs。下面，LANoT的最低延遲達到了300 μs的范圍，而且由于LANoT采用動態NVeoF消息發送機制，其延遲穩定性更差。在16 K隨機讀寫飽和測試中，LANoT的延遲不穩定性進一步加劇。但對于數據密集型應用來說，其更關注的性能指標是吞吐量，LANoT可以在滿足數據密集型應用對延遲的性能需求的同時，大幅提升吞吐量。

圖4 基于RAMDisk的最低讀寫延遲對比

為了測試CPU內核上運行時間敏感應用程序時LANoT的性能，使用fio在固定IOPS指標上進行了基于RAMDisk的4 K隨機讀寫和16 K隨機讀寫延遲測試，結果比較直觀，介紹了之前飽和讀寫測試中延遲性能最好的NVMe-TCP機制進行對比。

如圖5所示，在不手動修改任何參數的情況下，使用fio來測試當IOPS指標從50變為500時LANoT和NVMe-TCP的延遲。在基于RAMDisk的測試中，LANoT方法是最低的。延遲和平均延遲與NVMe-TCP方法基本相同。在基于SSD的測試中，LANoT的整體延遲性能略高于NVMe-TCP，但差距控制在100 μs以下。

圖5 小數據隨機讀寫延遲測試

5 結論

本文設計并實現了Load-aware NVMeoF消息處理機制LANoT[7-8]。首先，針對NVMe over TCP存儲網絡在高并發I/O環境下引入的中斷風暴問題，在每個NVeoF隊列中實現了一種基于聚合PDU的中斷合并方法的設計與實現。引入PDU Group數據結構，高效聚合Host端的CapsuleCmd PDU和H2CData PDU，減少Target端的

CPU中斷請求次數，高效聚合Target端的C2HData PDU和CapsuleResp PDU，減少CPU中斷次數主機端的請求。其次，在PDU Group數據結構中引入并維護3個統計變量SmallPG-send、PG-send和doorbell-ring，表征不同CPU內核-目標內存專用隊列的負載情況，進而感知各節點的運行狀態。它們的應用和基于不同類型的負載情況匹配不同的NVMeoF存儲網絡消息處理機制，實現不同I/O特性的應用對應的關鍵性能指標的優化。解決了多應用I/O干擾問題，無法同時滿足數據密集型應用和延遲敏感型應用的需求，所有團隊采用單一機制。LANoT原型系統的性能測試結果表明：與標準Linux內核中的標準NVMe over TCP實現相比，LANoT 可以將數據密集型應用程序的 IOPS 指數提高約2倍，并且可以保證延遲敏感應用的延遲性能；與PGIC方法相比，LANoT可以將IOPS指標提升高達37.14%。