以太網存儲網絡中的擁塞控制與管理策略

本文節選自《DetectingTroubleshooting, and PreventingCongestion in Storage Networks 存儲網絡中擁塞處理》

微突發檢測

Cisco Nexus 9000 交換機可在微秒等較短時間內檢測流量突發。這樣就可以捕捉到可能導致較低粒度擁塞，但由于輪詢間隔較長而未被其他手段發現的事件。

當出口隊列利用率超過上升閾值時，Cisco Nexus 9000 交換機可檢測到微突發。當隊列利用率低于下降閾值時，微突發結束。根據交換機型號的不同，本文撰寫時的最小微突發粒度為?0.64 微秒，持續時間為?73 微秒。

要了解微突發檢測的要點是，它是在?Cisco Nexus 9000 交換機的出口隊列上報告的（圖?7-10）。正如前面在?"入口和出口隊列?"一節中所解釋的，暫停幀的發送取決于入口隊列的利用率。但只有在出口隊列達到一定程度（未滿）后，入口隊列才會填滿。因此，微突發檢測是出口擁塞的一種指示。由于出口擁塞會導致入口擁塞，因此微突發檢測也是入口擁塞的早期征兆。換句話說，它是該交換機入口端口發送暫停幀的早期信號。?

Figure 7-10?Microburst detection on egress queues for lossless traffic

有關其他詳細信息，請參閱第?8 章隊列深度監控和微突發檢測一節。

PFC Storm

PFC 風暴已成為一個術語，用來指傳輸?RoCE 和?RoCEv2 流量的無損以太網網絡（共享或專用）中的擁塞。這可能是因為一個端口發送了許多暫停幀來減慢或停止流量，在其鄰居上看起來就像一場?PFC 暫停幀風暴。

但是，使用這個術語可能會產生誤導，因為?"風暴?"表達了大量的暫停幀，而且可能與擁塞嚴重程度有不準確的聯系。暫停幀的數量越多，并不一定表示擁塞的嚴重程度越高。這是因為暫停幀對流量的影響取決于鏈路速度、暫停幀的類型（零或非零量子）及其模式。

前面關于以太網流量控制和暫停時間的章節介紹了這些細節。在了解了擁塞檢測指標和故障排除后，讓我們再來看看它們的實際效果。

Link Speed and PFC Storm

正如前面有關暫停時間的章節所述，流量暫停的實際持續時間取決于鏈路的速度。例如，如果一個?10 GbE 端口每秒只收到?3000 個暫停幀，每個幀的量子點為?65535（暫停時間為?3.355 ms），那么它就可以完全停止傳輸。同一網絡中的另一個端口每秒接收?6000 個暫停幀，每個暫停幀的量子數為?65535，但仍不能完全停止傳輸，因為這是一個?100 GbE 端口，至少需要每秒接收?30,000 個暫停幀才能完全停止傳輸。

在這種情況下，100 GbE 端口的風暴更嚴重，但實際上?10 GbE 端口的擁塞嚴重程度更高。因此，在根據暫停幀數量檢測擁塞時，只應比較運行速度相同的鏈路。

Pause Time and PFC Storm

與接收到較多較小quanta值暫停幀的端口相比，接收到較少較高quanta值暫停幀的端口受到的影響更大。正如前面的?"何時發送暫停幀?"一節所述，大多數實施可能使用最大量值?65535，因此這一點的實際意義可能較小。但是，您應該驗證在您的環境中使用的產品的實現。

Reason for Pause Frames and PFC Storm

使用?"PFC 風暴?"一詞并不能說明擁塞的原因。正如前面?"無損脊葉網絡中的擁塞?"一節所解釋的，慢排空和過度使用都會導致向上游直接連接的設備發送暫停幀。

The Pattern and Content of Pause Frames and PFC Storm

在所有其他因素中，接收到的暫停幀的模式是對數據傳輸產生實際影響的最重要因素。其次是發送方在接收到暫停幀時的狀態。讓我們來分析一下這兩個因素。

1. The Pattern and content of Pause frames: ?如果認為收到非零quanta的暫停幀后，流量會在quanta所代表的時間內停止，那是不正確的。實際上，一個非零quanta的暫停幀之后可能很快就會出現一個取消暫停/恢復幀（零quanta的暫停幀）。如果一秒鐘內有?3000 個暫停幀，它們是否都有最大quanta？其中是否有一半具有最大quanta，而其余的quanta為零？如果有?3000 個暫停幀都具有最大quanta，那么?10 GbE 鏈路上的傳輸就會完全停止?1 整秒。但是，如果這些暫停幀中有一半的quanta值為零，并且是在具有最大quanta值的初始暫停幀之后?1 微秒才發送的，那么在這?1 秒鐘內暫停傳輸的時間可能只有?1500 微秒。換句話說，僅僅計算暫停幀并不能完全反映實際情況。

2. The State of the Transmitter: 流量?"可能?"暫停的時間是暫停幀和解除暫停幀之間的時間。這是?"可能"，而不是?"將要"，因為在收到暫停幀后可能會有輕微延遲。在收到暫停幀后，停止傳輸會稍有延遲（不要與暫停時間混淆），因為端口不會中斷當時已經在傳輸的幀。這種延遲取決于鏈路速度、幀大小以及何時收到暫停幀。如果一個?10 GbE 端口在傳輸?1500 字節幀的最后一位時因收到暫停幀而決定停止傳輸，則鏈路傳輸會立即停止。但是，如果同一個?10 GbE 端口在開始傳輸?1500 字節幀時因收到?"暫停?"幀而決定停止傳輸，則傳輸在接下來的（(1500 x 8) 位?/ 10 Gbps）1.2 微秒內不會停止。在這段時間內，如果收到一個?Un-Pause 幀，那么端口在收到兩個暫停幀后也不會停止傳輸。如果該序列在?1 秒內每?1.2 微秒重復一次，那么端口在該秒內將報告約（（1 秒/1.2 微秒）x 2）160 萬個暫停幀，同時繼續以滿負荷傳輸。僅僅通過計算暫停幀的數量，這條鏈路就可能被歸類為?PFC 風暴，但它的行為與另一條?10 GbE 鏈路明顯不同，后者僅?3000 個暫停幀就能停止傳輸?1 整秒。請注意以下幾點：

A. ?為簡單起見，本示例使用?1500 字節的幀大小。但是，存儲流量的幀大小可能更大，約為?2300 字節（FCoE）或甚至?4 KB（RoCEv2）。隨著幀大小的增加，接收到的?"暫停?"幀的動作延遲時間可能會更長，例如，在?10 GbE 鏈路上，2300 字節幀的延遲時間為?2.3 微秒，4 KB 幀的延遲時間為?4.2 微秒。

b. 暫停幀大小為?64 字節。在傳輸一個數據幀時，可能會收到許多暫停幀。

c. 從這一解釋中可以看出，純粹根據暫停quanta值，甚至根據接收到的暫停幀和解除暫停幀之間的時間差來計算?TxWait 是不準確的。準確的?TxWait 值必須計算傳輸實際停止了多長時間。

以太網中的?"暫停幀數?"與光纖通道中的?"B2B 信元轉為零?"類似。光纖通道端口在有一個剩余的?Tx-B2B 信元時，會將此計數器遞減為零，然后開始傳輸幀。但是，在傳輸幀的過程中，它可能會收到一個信元，因此下一幀完全不會延遲。這種情況會導致?"B2B 信元轉為零?"計數器遞增，而傳輸實際上并沒有停止。

雖然這種情況很少被報告，而且更難檢測，但需要了解的關鍵一點是，無論是光纖通道中的?"B2B 信元轉換為零?"計數器，還是以太網中的?"暫停幀數"，都不是檢測擁塞的有力機制。因此，應避免使用基于此計數器的?PFC Strom 這樣的術語，因為它可能會誤導某些人，讓他們相信暫停幀數才是擁塞的真正衡量標準。

本書使用?TxWait 和?RxWait 來表示無損網絡（光纖通道或無損以太網）中各方向傳輸停止的實際時間。PFC Storm 作為一個術語，似乎非常適合累計暫停時間（TxWait 和?RxWait）不可用的環境，而且暫停幀的數量是檢測擁塞的主要指標。但是，將來當設備改進了暫停時間檢測（TxWait 和?RxWait）后，使用?"PFC 風暴?"這一術語將更具誤導性。例如，一個?10 GbE 端口可能在每秒只有?3000 個暫停幀的情況下顯示?100% 的?TxWait，而一個?100 GbE 端口可能在每秒有?6000 個暫停幀的情況下顯示?10% 的?TxWait。100 GbE 端口的?"風暴?"嚴重性可能看起來更高，但?10 GbE 端口的擁塞嚴重性更高。

我們希望通過本書傳達的一個觀點是，將在一種傳輸類型（如光纖通道）中學到的知識用于另一種傳輸類型（如無損以太網）。在以太網中使用?"PFC Storm "就像在光纖通道中使用?"Credit Transition Storm "來表示擁塞一樣。許多年前，也就是現在看來，當光纖通道交換機不提供?TxWait 時，"B2B 信元過渡到零?"是擁塞檢測的唯一指標。然而，自從有了?TxWait，它就成了檢測擁塞的主要指標，而?"B2B 信元轉換為零?"只是在萬不得已的情況下才使用。如今，將擁塞稱為?"信元過渡風暴?"是不合適的，將其稱為?"PFC 風暴?"也是不合適的。由于?PFC Strom 反映的是暫停幀的數量，因此現在使用它意味著無損以太網并沒有真正從光纖通道中學習。

當然，切勿在光纖通道結構中使用?"信元轉換風暴?"一詞。對于無損以太網網絡，盡管本節反對使用?PFC Storm 一詞，但包括?Cisco 在內的一些供應商還是使用了該詞。我們將讓讀者自己決定是否以及何時使用?PFC Storm 這個術語會產生誤導，然后再決定要做什么。

Storage I/O Performance Monitoring

存儲網絡中的流量是應用程序啟動讀取或寫入?I/O 操作的直接結果。因此，通過分析應用程序?I/O 配置文件，如?I/O 操作的時間、大小、類型和速率，可以更好地了解網絡流量模式。從本質上講，應用程序?I/O 配置文件有助于理解網絡出現流量或擁塞的原因。

第?5 章介紹了如何通過存儲?I/O 性能監控解決擁塞問題。由于上層（SCSI 和?NVMe）相同，因此相同的細節（至少在概念上）也適用于?FCoE 和?RoCE（傳輸協議不同除外）。在繼續閱讀之前，請參考第?5 章中的以下章節，為簡潔起見，此處不再贅述。

第?5 章?"為什么要監控存儲?I/O 性能？"一節介紹了監控存儲?I/O 性能的基本價值。

第?5 章?"如何以及在何處監控存儲?I/O 性能?"一節介紹了監控存儲?I/O 性能的三個位置--主機、存儲陣列或網絡。

第?5 章?"Cisco SAN Analytics "一節介紹了?Cisco MDS 交換機如何在交換機內部監控存儲?I/O 性能。這種功能稱為?SAN Analytics，僅在光纖通道端口上可用。本節還有助于理解為什么以太網交換機不具備類似功能。

第?5 章?"了解存儲網絡中的?I/O 流量?"一節有助于了解光纖通道結構中的?I/O 流量與無損以太網網絡中的?I/O 流量之間的區別。請特別注意?"I/O 流量與?I/O 操作?"小節。

第?5 章?"I/O 流量指標?"一節有助于了解如何使用各種指標監控?I/O 流量的性能，如?I/O 完成時間（光纖通道中稱為交換完成時間）、IOPS、吞吐量和?I/O 大小。

了解第?5 章的這些內容后，請注意可以在以下層面監控無損以太網網絡的性能：

1. 端口或流量類別：?大多數終端設備和交換機都會報告網絡端口或接口上發送/接收的數據包和發送/接收的字節等計數器。與其他類別相比，可以單獨監控無損類別的流量。

2. UDP 流量：?OSI 模型第?4 層的流量由?5 個元組標識：源?IP、目標?IP、源端口、目標端口和第?4 層協議（TCP、UDP 等）。換句話說，RoCEv2 流量可按?UDP 流量分類。每個?UDP 流量的發送/接收的數據包、發送/接收的字節數和丟棄的數據包等計數器可根據網絡設備的能力分別進行監控。

3. ?I/O 流：I/O 流是對存儲卷（SCSI 為邏輯單元，NVMe 為命名空間）的?SCSI 或?NVMe I/O 操作的感知。通過監控?I/O 流級別的性能，可以計算?I/O 操作完成所需的時間、吞吐量、IOPS、類型（讀或寫）、I/O 大小等。

UDP Flow Monitoring versus I/O Flow Monitoring

UDP 流量監控不應與?I/O 流量監控混淆，原因如下：

1. ?UDP 屬于?OSI 模型的傳輸層（第?4 層）。它不了解?RDMA、SCSI 和?NVMe 等上層協議的功能。

2. 許多?I/O 操作可能在一個?UDP 數據流中傳輸。這些?I/O 操作可能屬于不同的?I/O 流。請參閱第?5 章?"I/O 流與?I/O 操作?"一節。

3. 如前所述，UDP 流量有自己的性能監控指標，如每秒傳輸的數據包、吞吐量等。這與?I/O 流量的性能監控指標（如?IOPS、I/O 吞吐量、完成?I/O 操作所需的時間、I/O 大小等）不同。

Unavailability of I/O Flow Monitoring in Lossless Ethernet Networks

在撰寫本文時，無損以太網網絡中還沒有對?I/O 流量進行性能監控。以太網交換機可能會報告網絡延遲，這通常是指數據包在網絡中花費的時間。這不是?I/O 完成時間。同樣，以太網交換機可能會報告?UDP 流量的吞吐量，但這不是讀或寫?I/O 吞吐量或?IOPS。

雖然啟動程序和目標程序的?IP 地址可被視為?IT 流量，但如果不了解?I/O 流量指標，這種流量定義就沒有什么價值。

即使在將來，以太網交換機也不可能監控?I/O 性能，類似于?Cisco MDS 交換機光纖通道端口上的?SAN Analytics。這是因為以太網網絡攜帶數千個上層協議，每個協議都有不同的?TCP 和?UDP 端口號。增強以太網交換機以解碼存儲協議（FCoE、RoCE 等）并測量其性能，可能無法彌補進行這些增強所需的額外成本。這對?Cisco MDS 交換機來說并不是一個挑戰，因為光纖通道是專門為存儲流量而構建的。相比之下，以太網網絡則可傳輸各種流量，如第?1 章圖?1-11 所示。

Alternative Approaches

另一種方法是監控主機或存儲陣列內的存儲?I/O 性能。第?5 章將解釋這些細節以及如何使用?I/O 性能指標來解決擁塞問題。雖然第?5 章重點介紹光纖通道，但其概念也適用于無損以太網網絡。

一些以太網交換機（如?Cisco Nexus 9000 交換機）會監控?UDP 流的性能。但如前所述，這并不是對?I/O 流量的性能監控，這些?UDP 流量中包含了?I/O 流量。因此，在對主機和存儲陣列進行?I/O 性能監控的同時，應使用以太網交換機進行?UDP 流量監控。RoCEv2 目標/控制器使用?UDP 端口?4791，這意味著發往目標/控制器的數據包具有目標端口?4791，而發往主機的數據包具有源端口?4791。UDP 端口?4420 分配給?NVMe/RoCE。可以將各種來源的信息關聯起來，構建自己的解決方案。

FCoE I/O Operations

FCoE 網絡中的?SCSI 和?NVMe I/O 操作與光纖通道?Fabric 相同。有關詳細信息，請參閱第?5 章。

但?SAN 分析功能僅適用于?Cisco MDS 交換機上的光纖通道端口。如果流量在端到端數據路徑中至少經過一次具有分析功能的光纖通道端口，則仍可對其進行檢查，以收集?I/O 流量指標。即使流量通過網絡中其他位置的?FCoE 端口，這種方法也能發揮作用。一個典型的例子是思科?UCS 服務器，它在內部使用?FCoE。當相同的流量到達?MDS 上的光纖通道端口時，可以使用?SAN Analytics 對其進行檢查，以收集?I/O 流量指標。

RoCE I/O Operations

圖?7-11 顯示了?NVMe over RoCE 讀?I/O 操作。主機通過向目標機發送命令包中的?RDMA_SEND 來啟動讀?I/O 操作。目標機根據?I/O 操作請求的數據量和網絡的最大傳輸單元?(MTU)，通過?RDMA_WRITE 以一個或多個數據包的形式向主機發送數據（更多詳情請參見第?8 章?IP MTU 和?TCP MSS 考慮因素部分）。最后，當目標發送響應包時，I/O 操作完成。

Figure 7-11?NVMe over RoCE read I/O operation

圖?7-12 顯示了?NVMe over RoCE 寫?I/O 操作。主機通過向目標機發送命令包中的?RDMA_SEND，啟動寫?I/O 操作。然后，目標機向主機發送?RDMA_READ 請求。接下來，主機根據?I/O 操作請求的數據量和網絡的?MTU，通過?RDMA_READ 響應以一個或多個數據包的形式向目標發送數據。最后，當目標機發送響應包時，I/O 操作完成。

Figure 7-12?NVMe over RoCE write I/O operation

Table 7-2?shows the Ethernet frame sizes and directions based on the type of RDMA operation.

Table 7-2?Typical size of Ethernet frames for NVMe/RoCE I/O operations?

Correlating I/O Operations, Traffic Patterns, and Network Congestion

請參閱第?5 章的以下章節，為簡潔起見，此處不再贅述。

將第?5 章中的?I/O 操作和網絡流量模式一節與前一節進行比較，可以發現流量模式之間有驚人的相似之處。因此，與網絡擁塞的相關性也很相似。對于讀取數據，SCSI 和?NVMe 使用讀?CMD，而?RDMA 則反向使用?RDMA_WRITE verb。同樣，在寫數據時，SCSI 和?NVMe 使用寫?CMD，而?RDMA 則反向使用?RDMA_READ verb。

第?5 章?"網絡流量方向?"一節介紹了各種端口類型因讀寫?I/O 操作而產生的流量。

第?5 章?"I/O 操作、流量模式和網絡擁塞的相關性?"一節解釋說，主機鏈路擁塞的主要原因是來自該主機的多個并發大容量讀取?I/O 操作。同樣，存儲鏈路擁塞的主要原因是存儲陣列請求的數據總量。

Detecting Congestion on a Remote Monitoring Platform

遠程監控平臺可同時監控網絡中的所有端口，以提供全網單一窗口可視性。

請參閱第?3 章?"在遠程監控平臺上檢測擁塞?"一節，其中介紹了如何使用以下類型的監控應用程序：

設備制造商/供應商開發的應用程序，如?Cisco Nexus Dashboard Fabric Controller (NDFC) 和?Nexus Dashboard Insights。

第三方或定制開發的應用程序，如?MDS 流量監控?(MTM) 應用程序。

本節簡要介紹用于檢測以太網擁塞的?Cisco Nexus Dashboard Insights。

要進一步了解定制開發的用于檢測和排除無損以太網網絡擁塞故障的應用程序，請參閱第?9 章，其中介紹了如何使用?UCS 流量監控應用程序?(UTM)。

第?3 章還介紹了?"監控網絡流量的陷阱"。其中關于平均利用率和峰值利用率的小節也適用于無損以太網網絡。

Congestion Detection using Cisco Nexus Dashboard Insights

Cisco Nexus Dashboard Insights 以?1 秒的低粒度接收來自交換機和計算節點的指標。然后，它使用基線、相關性和預測算法分析原始指標，深入洞察流量模式。在擁塞檢測方面，Nexus Dashboard Insights 可檢測數據平面異常，如丟包、延遲、微爆發等。它使用直觀的圖形用戶界面顯示流量的端到端數據包路徑，以及丟包和丟包的原因。

圖?7-13 顯示了?RoCEv2 流量的端到端路徑、平均網絡延遲和?Nexus Dashboard Insights 上的突發。?

Figure 7-13?Monitoring RoCEv2 in Cisco Nexus Dashboard Insights

Metric Export Mechanisms

對于定制開發的應用程序或腳本而言，指標導出機制是一個重要的考慮因素。第?3 章?"指標導出機制?"一節中解釋的大部分細節也適用于無損以太網網絡。

請特別注意第?3 章介紹的指標輸出建議。使用命令行輸出和?SNMP 在歷史上很常見，但現在使用?API 已成為常態。對于大規模的低粒度度量導出，流式遙測是最佳選擇，而且正在被迅速采用。

Cisco Nexus Dashboard Fabric Controller 和?Nexus Dashboard Insights 默認選擇最佳導出機制。

以下小節簡要介紹了?Cisco Nexus 9000 交換機上的指標導出機制，不再重復第?3 章中的說明。

SNMP

表?7-3 提供了可檢測啟用?LLFC 和?PFC 的端口擁塞情況的指標的?SNMP MIB。?

Note the following points:?請注意以下幾點：

1. Cisco Nexus 9000 交換機上的?PFC 計數器可由?CISCO-PFC-EXT-MIB 監控，該?MIB 包含更多計數器，如?TxWait 和?RxWait，但表?7-3 沒有列出所有計數器，因為?Nexus 交換機在本文撰寫時不支持?TxWait 和?RxWait。雖然交換機可能會響應?MIB 請求，但它們的值不會隨時間而改變。如果交換機類型支持?CISCO-PFC-EXT-MIB，它還可用于監控?PFC 看門狗。

2. 需要注意的是，多年來，Cisco 設備上的?LLFC 和?PFC MIB 計數器一直受到某些固件版本和交換機型號執行不力的影響。在依賴返回值之前，請驗證它們是否與交換機上的命令行輸出相匹配。根據返回值?0 進行初步驗證是不夠的，因為盡管?0 是一個有效值，但它可能不會遞增。這將造成沒有擁塞的錯誤提示。

3. ?IF-MIB 包含接口速度、字節輸入和字節輸出，可用于計算利用率百分比。

4. 由于?PFC 是通過以太網交換機上的?QoS 實現的，因此監控?CISCO-SWITCH-QOS-MIB 可提供每個隊列的指標。

Streaming Telemetry

有關流遙測的詳細信息，請參閱第?3 章?"流遙測?"一節。Cisco Nexus 9000 交換機有以下額外注意事項：

1. Nexus 交換機可以從前面板數據端口導出指標，從而實現低粒度指標導出。在撰寫本文時，MDS 交換機只能從交換機的管理端口導出指標。

2. Nexus 交換機支持?NetFlow 和?sFlow。不過，流式遙測可導出粒度更小的指標。

3. Cisco Nexus 交換機上的軟件遙測功能可導出控制平面信息和接口指標。

4. 此外，Nexus 交換機還支持硬件遙測，可導出粒度（根據交換機類型可低至?1 秒）的指標：

a. 流統計數據導出?(SSX)，用于導出原始?ASIC 統計數據。

b. 流量表?(FT)，用于導出流量級別信息。

c. 流量表事件?(FTE)，用于在滿足配置條件時觸發通知。

5. Nexus 交換機支持帶內網絡遙測?(INT)，用于監控丟棄的數據包和擁塞的隊列。