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

Troubleshooting Congestion in Lossless Ethernet Networks

解決無損以太網網絡擁塞問題的方法與光纖通道結構相同。兩者都使用逐跳流量控制機制，只是實現方式不同而已。當交換端口顯示出口擁塞時，擁塞的根源在于下游流量路徑。當交換端口顯示入口擁塞時，一定是因為該交換機上的一個或多個端口在出口方向擁塞。

Goals

正如第4 章詳細介紹的那樣，故障排除的目標有兩個：

1. 確定擁塞的來源（元兇）和原因：調查和故障排除的主要目標是確定是否存在擁塞、擁塞源和擁塞原因，擁塞原因可能是慢耗盡（通過高TxWait（如果可用）或快速遞增的暫停計數檢測到）或過度利用（通過高出口利用率或微爆發事件檢測到）。一旦知道了擁塞的來源和原因，就可以對造成擁塞的終端設備進行詳細調查。

2. 確定受影響的設備（受害者）：次要目標是識別受到罪魁禍首設備不利影響的設備。這些就是受害者。在調查完成之前，您可能不知道設備是罪魁禍首還是受害者。請記住，有時識別不同的受害者類型（直接受害者、間接受害者和同路徑受害者）會有所幫助。有關詳細信息，請參閱第4 章"識別受影響設備（受害者）"一節。

重要的是要明白，受害設備可能會將性能下降報告為罪魁禍首設備。但問題只能通過調查罪魁禍首而不是受害者來解決。

Congestion Severities and Levels

第4 章定義了光纖通道結構的擁塞嚴重程度和級別。但它們不能直接用于無損以太網網絡，因為與光纖通道不同，無損以太網沒有鏈路（信用）重置的概念，而鏈路（信用）重置是光纖通道中嚴重（3 級）擁塞的癥狀。另一個原因是，如果環境中的設備沒有檢測這些情況的度量標準，將它們分為不同等級的實際意義就很有限。值得注意的例子是TxWait 和RxWait 指標，在撰寫本文時，大多數以太網端口都沒有這些指標。因此，與光纖通道不同，使用TxWait 無法檢測到1 級擁塞。

總之，對于無損以太網，不同嚴重程度的擁塞癥狀可略作如下調整：

1. 輕度擁塞（1 級）：延遲增加，但不丟幀。

a. 檢測暫停幀數或TxWait/RxWait （如果有）是否過多以及鏈路利用率是否過高。

2. 中度擁塞（2 級）：延遲和丟幀增加。

a. 檢測無損級中的丟包情況

3. 嚴重擁塞（3 級）：延遲增加、丟幀和流量持續停頓。

a. 使用暫停超時或PFC 看門狗進行檢測，稍后解釋

Methodology

我們建議按嚴重程度遞減的方式排除擁塞故障。請注意，這些擁塞嚴重程度并不是標準化的。它們的唯一目的是幫助用戶制定實用的工作流程，從而有助于快速準確地檢測和排除擁塞故障。您可以根據自己的環境進行定制。例如，如果沒有檢測3 級擁塞的簡便方法，可先調查2 級擁塞（數據包丟棄），然后再調查1 級擁塞（暫停幀計數或TxWait（如果有））。

有關詳細信息，請參閱第4 章"故障排除方法- 降低電平"部分。在將第4 章中的信息應用于無損以太網時，請記住Rx 信用不可用與光纖通道中的入口擁塞相同，后者在以太網網絡中由Tx Pause 檢測到。同樣，Tx 信用不可用等同于光纖通道中的出口擁塞，而以太網網絡中的Rx 暫停可檢測到出口擁塞。

建議同時學習第4 章的案例研究。雖然這些案例是針對光纖通道描述的，但從中可以了解到無損以太網網絡的故障排除方法是如何類似的。

Troubleshooting Congestion in Spine-Leaf Topology

請參閱圖7-14，它是圖7-8 脊葉網絡網絡的一個子集。正如前面"無損脊葉網絡中的擁塞"一節所解釋的，一個罪魁禍首可能會使許多設備受害，而這些受害設備的用戶也可能會報告性能下降。因此，自然要從最先報告問題的地方開始排除故障，即受害設備或其連接的交換端口。無論從哪里開始，重要的是要追蹤擁塞的源頭，同時尋找嚴重性較高的事件，然后是嚴重性較低的事件（3 級2 級1 級）。

Figure 7-14Congestion troubleshooting direction in a lossless spine-leaf network

假設連接到Leaf-1 的受害主機上的應用程序報告性能下降。這些是間接受害者，因為它們接收來自目標-1 的流量，而目標-1 是罪魁禍首主機-1 的直接受害者。但在故障排除結束之前，這一點還不得而知。故障排除工作流程如下：

1. 轉到受害主機直接連接的交換端口。如果發現出口擁塞癥狀（Rx 暫停或出口丟包），那么這臺主機就是罪魁禍首。

2. 如果沒有，請在同一交換機的任何其他邊緣端口上查找入口擁塞癥狀（Tx 暫停）。如果發現這樣的設備（Target-1），它一定在向罪魁禍首（Host-1）發送流量（如果只有一個擁塞事件或罪魁禍首）。

3. 然后，在Leaf-1 的上游端口上查找出口擁塞癥狀。

4. 轉到其中一個上游設備（例如Spine-1）。Spine-1 發送的Tx 暫停應與Leaf-1 上游端口上的Rx 暫停一致。如果它們的值不一致，請調查位錯誤或固件錯誤。

5. 在Spine-1，查找有出口擁塞癥狀（Rx 暫停）的端口。這些端口通常會傳輸從顯示入口擁塞的端口接收到的流量。

6. 轉到流量路徑中的下一個設備（Leaf-6）。Leaf-6 發送的Tx 暫停應與Spine-1 上的Rx 暫停一致。如前所述，如果它們的值不同，則應調查位錯誤或固件錯誤。

7. 在Leaf-6 上，查找有出口擁塞癥狀（Rx 暫?；虺隹趤G包）的邊緣端口。這應該是連接到罪魁禍首主機（Host-1）的交換端口。如果未發現Rx 暫?；虺隹趤G包，則調查端口是否過度使用。

在任何設備上，如果有更多端口出現出口擁塞癥狀，應先處理較嚴重的癥狀。例如，先處理丟包后處理Rx 暫停。同樣，如果TxWait 不可用，應先處理快速增加的暫停計數，再處理緩慢增加的暫停計數。

Reality Check

圖7-14 所示的故障排除工作流程需要進行實際檢查，原因如下。

1.此故障排除工作流程只能在擁塞狀況持續期間使用，因為與Cisco MDS 交換機和Nexus 7000/7700 交換機不同，大多數以太網交換機（包括Cisco Nexus 9000 交換機）不保留帶有時間和日期戳的擁塞事件歷史記錄。

2. 由于大多數以太網交換機不報告TxWait 和RxWait 的百分比，因此即使實時排除故障也很繁瑣。在Cisco Nexus 9000 交換機和Cisco UCS 服務器上，命令輸出中只有累計暫停計數。用戶必須多次執行這些命令并手動計算差值，如例7-7 所示。為數百個端口執行這些步驟既困難又耗時，而且容易出錯。試想一下，在圖7-8 中可能有數百個端口的脊柱交換機上手動計算這一結果。

3. 正如前面有關暫停幀數的章節所述，暫停幀數的名義增長并不一定表示擁塞。

4. 請注意，造成擁塞的原因可能不止一個。如果造成擁塞的原因在不同的交換機上，那么可能會有不止一條路徑。

5. 最后，在手動解釋暫停幀數時，如果擁塞條件停止，由于事件沒有時間和日期標記，因此無法知道其計數何時增加。

由于這些原因，使用命令行界面很難排除無損以太網網絡擁塞的故障。

Troubleshooting Congestion using a Remote Monitoring Platform

通過使用遠程監控平臺，可以改變在無損以太網網絡中排除擁塞故障時令人不快的現實，該平臺可持續輪詢暫停幀的數量，以保存帶有時間和日期戳的歷史記錄。

UCS 流量監控(UTM) 應用程序就是此類應用程序的一個示例。有關詳細信息，請參閱第9 章。UTM 應用程序可以使用比較分析、踩點和季節性等方法近乎實時地檢測擁堵情況并排除故障。

Comparative Analysis

比較網絡端口（主機端口和交換機端口）的暫停幀速率，檢測是否有幾個端口的暫停幀數比其他端口高得多。

在圖7-8 中，有數千臺主機、

1. 每60 秒從邊緣交換端口或主機輪詢一次Tx 和Rx 暫停。

2. 計算累計暫停幀數的delta 值，了解60 秒內的變化情況。

3. 按"Tx 暫停"降序排列主機，或按"Rx 暫停"降序排列邊緣交換端口。

4. 調查該列表中排名前10 位的主機。通常情況下，這些主機的慢排空嚴重程度較高。

應在所有類似實體中使用相同的比較分析。例如，將所有骨干端口相互比較，檢測是否有幾個端口報告了過多的暫停幀。

Trends and Seasonality

暫停幀對無損以太網網絡的運行非常重要，因此其正?；顒邮菦]有問題的。但要仔細分析任何峰值和谷值。此外，還要查找暫停幀計數在過去幾天或幾周內是否一直在上升，盡管可能不會出現任何突然的峰值。此外，還要查找是否存在季節性，即暫停幀數的峰值是否出現在一天中的特定時段或一周中的特定日子，甚至一年中的特定月份。

從圖表上看，低計數的直線就可以了。注意峰值，尤其是持續時間較長的大峰值。

Monitoring a Slow-drain Suspect

可疑設備是發送暫停幀的終端設備。但它不一定是罪魁禍首。可以肯定的是，我們需要更多的信息，因為如前所述，僅僅計算暫停幀的數量并不能說明傳輸到底停止了多長時間。

根據我們的經驗，以下幾種方法有助于判斷嫌疑人是否也是罪魁禍首。

1. 不發送暫停幀的終端設備不是慢排空的來源。可以將這些設備排除在可疑設備列表之外，從而只關注那些發送暫停幀的設備。

2. 終端設備每秒最多只有幾百個暫停幀（如少于300 個）并不會使其成為可疑設備。但是，當暫停幀速率增加到每秒數百或數千的大倍數時，終端設備就會成為可疑設備。每秒數百萬個暫停幀無疑會使終端設備非常接近于罪魁禍首，因此應積極監控。

3. 檢查上游端口的擁塞擴散癥狀。例如，在脊葉拓撲結構中，主機暫停幀速率的峰值是否與位于主機流量路徑上的骨干交換機端口的暫停幀速率峰值一致？如果是，則表明擁塞正在蔓延，因此主機是罪魁禍首。如果不是，則表明主機只是瞬間暫停了流量，因此不會成為罪魁禍首。

4. 比較終端設備在兩個（或多個）端口上發送暫停幀的速率。通常情況下，它們的速率應該是一致的。但如果一個端口每秒發送數百個暫停幀，而另一個端口每秒發送數百萬個暫停幀，或出現類似的非均勻暫停幀速率，則需要進行調查。

5. 高暫停幀速率或暫停幀速率的增加必須與終端設備上層的事件相關聯。例如，終端設備上的I/O 錯誤、應用性能下降、I/O 完成時間增加和IOPS 減少。這種關聯必須在網絡中的可疑終端設備（發送暫停幀）和其他終端設備（不發送暫停幀）上進行。這是因為，如果可疑設備真的是罪魁禍首，那么由其造成的擁塞就會擴散，使許多其他終端設備受害。

6.網絡端口的過多Tx 暫停幀應導致該鏈路的Rx 流量降低。如果結果與此不同，則可能表明暫停幀沒有到達流量發送方，或者沒有被正確處理，或者是在沒有TxWait/RxWait 的情況下，僅使用暫停幀數量檢測擁塞的局限性，這在前面有關PFC 風暴的章節中已有解釋。需要記住的要點是比較暫停幀和相反方向的流量。

Monitoring an Over-utilization Suspect

正如第1 章"定義完全使用率vs 高使用率vs 過度使用率"和"監控完全使用率vs 高使用率vs 過度使用率"兩節所述，我們建議將任何高使用率（如超過80%）情況與過度使用率同等對待。這是因為，根據我們的經驗，大多數高使用率情況也有一定的過度使用時間。要確定高使用率是否導致擁塞，可監控上游端口的暫停幀。但在開始調查時，除非另有證明，否則應將高使用率情況與過度使用情況同等對待。這種方法節省了檢測擁塞和尋找解決方案的時間。

FC and FCoE in the Same Network

有些交換機，如Cisco Nexus 9000 交換機、Nexus 5000/6000 交換機和Cisco UCS Fabric Interconnect 可以有FC、FCoE（無損）和以太網（有損）端口。這些交換機以類似于前面解釋的方式將擁塞從流量控制出口端口擴散到流量控制入口端口。唯一不同的是流量控制機制，因此檢測擁塞的指標也不同。

請注意，FC 端口使用Rx B2B 信用不可用檢測入口擁塞，使用Tx B2B 信用不可用檢測出口擁塞。有關光纖通道指標的詳細解釋，請參閱第3 章。

FCoE 端口（無損以太網）使用"Tx 暫停"檢測入口擁塞，使用"Rx 暫停"檢測出口擁塞。前面關于擁塞檢測指標的章節解釋了這些指標。

ConsiderFigure 7-15with the following components.

有損以太網：沒有逐跳流量控制（如PFC 或LLFC）的骨干網絡。這部分網絡的流量依靠其他機制（如OSI 模型第4 層的TCP）進行擁塞控制。

無損光纖通道：具有B2B 流量控制功能的邊緣核心光纖通道Fabric。MDS-1 連接存儲陣列（Target-1 和Target-2）。

融合（有損+無損）以太網：有損以太網網絡和光纖通道結構共享葉子交換機（L-4 和L-6）。它們有專用的以太網上行鏈路（無流量控制）連接到骨干交換機，光纖通道上行鏈路連接到MDS-1。下行鏈路連接到一個或多個FEX（FEX-4 和FEX-6），最終連接到主機。葉子到FEX 鏈路和FEX 到主機鏈路使用PFC。無損FC/FCoE 流量保持在無丟包類別中，而有損以太網流量保持在不受流控制的其他類別中。

FEX 代表思科Fabric Extender。從外形上看，它像一個交換機，但實際上像一個遠程模塊。它需要一個父交換機來實現控制功能（如路由協議）和管理功能（如配置端口）。父交換機和FEX 之間的鏈接使用SFP 和電纜，并運行逐跳流量控制（如PFC）。這與ISL 類似。因此，在處理擁塞時，可將FEX 視為交換機，盡管從一般意義上講，FEX 本身可能并不符合交換機的條件。

圖7-15 是思科UCS 架構的近似表示。葉子交換機代表Fabric Interconnects，FEX 代表I/O 模塊(IOM)，主機代表服務器。有關Cisco UCS 服務器的詳細信息，請參閱第9 章。

讓我們分析Host-1 和Host-2 造成的擁塞事件，并遵循故障排除方法。

Congestion Spreading due to Slow-Drain

在圖7-15 中，Host-1 是一個慢速排空設備，因為它的無損流量處理速率低于向其傳送幀的速率。因此，它會向FEX-4 發送PFC 暫停幀，以降低無損類別的流量速率。無損類之外的流量不受流量控制，因此在隊列滿時可能會被丟棄。

當超過FEX-4 的暫停閾值時，它會向L-4 發送PFC 暫停幀，以降低不丟棄類的流量速率。但L-4 的上行鏈路（入口端口）運行光纖通道。當其緩沖區耗盡時，它會降低向上游鄰居（MDS-1）發送R_RDY 的速率。最后，MDS-1 降低向目標發送R_RDY 的速率，以減少來自目標的流量。

Congestion Spreading due to Over-Utilization

請看圖7-15 中的主機-2。它沒有造成慢排空，但在其交換端口的出口方向上造成了100% 的使用率，這可能會因過度使用而導致擁塞。用前面解釋過的類似方法從MDS-1 追逐擁塞源時，在到達FEX-6 后，可能找不到任何有Rx 暫停增量的出口端口。在這種情況下，請查找正在以高出口利用率運行的端口，這是過度利用導致擁塞的跡象。這樣就能找到罪魁禍首Host-2。

Figure 7-15Congestion troubleshooting workflow with FC and FCoE in the same network

請注意以下幾點：

1. FC 和FCoE 混合網絡中擁塞的蔓延情況與僅有FC 或僅有FCoE 的網絡類似。

2. 在FEX-4 和FEX-6 的上行鏈路上，排空緩慢和過度使用也會導致類似的癥狀。即使在L-4、L-6 和MDS-1 上也無法找到擁塞原因。只有FEX-4 和FEX-6 上的邊緣鏈路能明確區分擁塞原因，因為它們直接連接到擁塞源（罪魁禍首終端設備）。

3.無損以太網鏈路（L-4 和L-6 下行鏈路）和光纖通道鏈路（L-4 和L-6 上行鏈路）的擁塞故障排除方法與前面解釋的相同。不同之處在于，L-4 和L-6 交換機本身需要追尋擁塞源。在這些交換機上，入口（FC）端口使用光纖通道指標，出口（以太網）端口使用PFC 指標。它們的命令不同。執行這兩種命令，檢查交換機上FC 和FCoE 流量的出口擁塞情況。

4. 在圖7-15 中，如果L-4 不在上行FC 端口（例如Cisco UCS Fabric Interconnects）上提供入口擁塞檢測指標，則可以使用MDS-1 上的出口擁塞檢測指標。同樣，如果Host-1 不監控Tx 暫停幀（或監控起來不夠方便），則可選擇監控FEX-4 上的Rx 暫停。

Bit Rate Differences between FC and FCoE

交換機在FC 和FCoE 端口之間傳輸流量時，必須仔細考慮比特率的差異。如第2 章"光纖通道比特率"、"光纖通道速度與比特率之間的差異"和表2-4 所述，某些光纖通道比特率與宣傳的速度有很大差異。例如，8GFC 端口的比特率為8.5 Gbps，但考慮到8b/10b 編碼，只能以6.8 Gbps 的速度傳輸數據。這使得10 GbE 的"速度"幾乎比8GFC 快50%。因此，當FCoE 流量從10 Gbps 以太網端口切換到8GFC 端口時，可能會出現速度不匹配導致的擁塞。當流量從16GFC 端口（比特率為14.025 Gbps）切換到工作速率為10 Gbps 的FCoE 端口時，會出現另一種常見的擁塞情況。正如本章所述，速度或容量不匹配程度越高，擁塞就越容易發生和蔓延。

雖然無法完全消除以太網和光纖通道在比特率上的差異，但必須盡可能地縮小它們之間的差距，例如32GFC 和25 GbE。除了端口速度外，還應考慮共享FCoE 鏈路的最低帶寬保證，因為FC/FCoE 流量可能不允許占用鏈路的全部容量。

對于帶有FC 和FCoE 端口的交換機，如Cisco UCS Fabric Interconnect（參見第9 章），這應該是一個設計層面的決策。初步設計完成后，應持續監控流量模式，并根據需要增加額外容量。

Multiple no-drop Classes on the Same Link

當無損以太網網絡中啟用了多個無損類時，請按照每次一個類（CoS）的擁塞故障排除方法進行操作。

圖7-15 中的融合拓撲只為FCoE 流量設置了一個無損類。在同一拓撲中，可為RoCEv2 流量啟用另一個無損類。

請參閱圖7-16。存儲陣列連接到葉子交換機(L-1)，并為RoCEv2 進行了配置。主機-1 和主機-2 通過FEX-4 連接到葉子L-4。這些主機以分配給CoS 5 流量的無損類訪問RoCEv2 存儲。脊葉拓撲現在可為CoS 5 流量提供PFC。RoCEv2 流量使用IP 標頭中的DSCP 字段進行分類，從而實現前面所述的第3 層PFC。不過，為簡單起見，本節假定RoCEv2 是表7-1 中CoS 到DSCP 映射的CoS 5 流量。

Figure 7-16Congestion troubleshooting with multiple no-drop classes

FCoE 主機（Host-3）連接到FEX-4，并將FCoE 流量分配到CoS 3。FEX-4 和L-4 將CoS 3 流量分配到專用的無損類。在L-4 上，CoS 3 流量通過光纖通道上行鏈路發送。

總之，在此拓撲中，L-4 和FEX-4 之間的鏈路為兩個無損類配置了PFC，分別分配給CoS 5 和CoS 3。因此，交換端口創建了兩個獨立的無損隊列，分別有自己的暫停閾值和恢復閾值。

當Host-1（RoCEv2 主機）成為慢排空設備時，它會發送CoS 5 的PFC 暫停幀。當FEX-4 的暫停閾值超過CoS 5 隊列時，它只向L-4 發送CoS 5 的PFC 暫停幀。結果，Host-2（另一臺使用CoS 5 的RoCEv2 主機）因L-4 和FEX-4 之間的共享鏈路擁塞而受害。

L-4 不會接收CoS 3 的PFC 暫停幀，因此不會減慢CoS 3 流量。因此，FCoE 主機（Host-3）不會受到影響。

在L-4 上，擁塞只擴散到CoS 5 上行鏈路（骨干交換機），而不擴散到光纖通道上行鏈路。

總之，啟用多個不丟包類別時，應分別注意每個類別的擁塞癥狀。分析L-4 上每個端口的暫停計數器可能會導致錯誤的方向。只在CoS 5 中排除故障可以找到擁塞源（Host-1）。

Bandwidth Allocation Between Lossless and Lossy Traffic

回想一下，增強傳輸選擇（ETS，除PFC 外）是使融合（有損+無損）以太網取得成功的重要功能，因為它為無損類提供帶寬保證，同時與其他類別的流量共享鏈路。

請注意以下有關使用ETS 分配帶寬的要點：

1. 每個無損類別都預留了最少數量的緩沖區。

2. 無損類別會被分配一個最小帶寬，例如鏈路容量的50%。但這并不是"無損"類所能達到的最大帶寬。當其他類沒有流量時，流量類最多可占用100% 的鏈路容量。

3. 但是，當其他類別有流量時，無損類別的帶寬分配就會受到限制（假設為50%）。這可能會因過度使用而造成擁塞。

4. 端口在無損等級中的傳輸容量為50%，在其他等級中的傳輸容量為50%。

5.當端口已按各流量等級的帶寬分配滿負荷傳輸時，例如無損等級的流量為50%，其他等級的流量為50%、

a. 如果交換機上的其他端口接收到的有損類流量超過了該端口的發送量，多余的流量就會像有損網絡一樣被丟棄。

b. 如果交換機上的其他端口接收到更多要從該端口發送出去的無損類流量，則接收到多余流量的端口會在暫停閾值處發送一個暫停幀。每個入口端口都維護有自己的暫停閾值、恢復閾值和凈空的無損隊列。這種情況就像過度使用造成的擁塞，并導致擁塞擴散。

Effect of Lossy Traffic on no-drop Class

一個常見的誤解是，有損類中的流量不會影響無損類。這取決于處理問題的方式。

無損類的流量可以消耗100% 的容量。但是，當其他類有流量時，它就會被限制在保證帶寬內。換句話說，以前不會造成擁塞的鏈路，在其他（有損耗）類別的流量增加后，可能會開始造成擁塞（由于過度使用）。例如，考慮一條10 GbE 鏈路，其中5 Gbps 分配給無損類，5 Gbps 分配給其他類。如果不存在其他流量，無損類中的無損流量可以消耗掉鏈路的全部容量。但是，如果其他流量需要2 Gbps，無損流量將被限制在8 Gbps。這臺交換機現在必須將其他端口的入口速率均衡為8 Gbps，而之前的速率為10 Gbps。為實現速率均衡，交換機會調用PFC，導致擁塞擴散。

如果只監控I/O 吞吐量，這種情況就不容易理解了。早期，10 Gbps 的I/O 吞吐量不會造成擁塞。后來，僅8 Gbps 就會造成擁塞。

由于這些原因，在融合存儲網絡甚至共享存儲網絡中確定過度使用情況要比專用存儲網絡困難得多。再也不能通過出口百分比利用率來確定過度利用。在鏈路級別上分別監控每類流量和每類擁塞情況，以及將兩者結合起來，有助于更好地理解和檢測此類問題。

Case Study 1 — An Online Gaming Company

一家在線游戲公司將融合以太網網絡用于無損存儲I/O 流量和有損TCP/IP 流量。他們的服務器以10 GbE 連接網絡，50% 的帶寬分配給無損類。他們的鏈路利用率很少超過90%。

他們報告了以下觀察結果：

許多應用程序都報告了性能下降。

問題只在工作時間出現。

在同一時間段內，他們發現了一臺CPU 高的服務器，但這臺服務器的鏈接利用率從未超過70%。在這臺服務器上運行的應用程序的所有者懷疑存在存儲訪問問題。

CPU 高并不是有力的證據，但應用程序所有者懷疑是存儲問題。他們沒有在主機上看到任何I/O 錯誤。為了驗證網絡擁塞情況，他們檢查了該服務器鏈接上的暫停幀計數。他們發現，在問題持續期間，服務器發送了很多暫停幀。此外，連接該服務器的交換機也在其上行鏈路上進一步發送暫停幀。這是擁塞的擴散，可能會使許多其他服務器受害。

接下來，他們想找到在鏈路利用率保持在70% 以下的情況下，該服務器出現高Tx Pause 的原因。他們開始監控每個類的流量利用率，并在問題持續期間發現了以下情況：

1. 服務器入口鏈路利用率從5 Gbps 提高到7 Gbps。

2.每級流量監測顯示

a. 無損類的流量從2 Gbps 降至1.5 Gbps。

b. 其他（有損）類別的流量從3 Gbps 增加到5.5 Gbps。

根據這些觀察結果，我們懷疑其他（有損）流量的增加可能會導致CPU 使用率過高，從而沒有足夠的資源來處理存儲I/O。因此，服務器試圖減慢入口I/O 流量，這一點從暫停幀的數量和整個I/O 的減少可以看出。

為了驗證這一理論，他們將該應用程序移到了一臺CPU 數量更多的強大服務器上。這一改變之后，應用程序不再遇到性能問題。有損類流量保持在3 Gbps 至5.5 Gbps 之間。無損類的平均流量為2 Gbps。暫停幀數保持在最低水平，沒有出現任何峰值或驟降。服務器的CPU 使用率也不高。

除了說明監控每個端口和每個類流量利用率的重要性外，本案例研究還展示了全棧可觀測性如何幫助更快、更準確地檢測擁塞問題。但全?？捎^察性并不是本案例研究的目的。真正的教訓是，當有損類的流量增加時，可能也會導致無損類的擁塞。在本案例中，真正的問題出在網絡之外，也就是服務器的CPU 容量，但其影響卻體現在網絡上，使許多其他服務器也深受其害。

不能一概而論地認為CPU 高會導致I/O 性能問題。只有在本案例研究中，CPU 高才會導致問題。影響I/O 性能的原因還有很多。本案例研究的關鍵是了解有損耗類流量對無丟包類的影響。

Case Study 2 — Converged Versus Dedicated Storage Network

本案例研究與案例研究1 相似。不同之處在于服務器的CPU 利用率不再很高。此外，無損類的平均流量為6 Gbps（60%），有損類的平均流量為2 Gbps（20%）。當報告應用性能下降時，持續時間也與會聚鏈路的100% 利用率相吻合。對每類流量利用率進行調查后發現，有損類的流量從2 Gbps 激增到5 Gbps。同時，無損類的流量從6 Gbps 下降到5 Gbps。這是因為在這條10 GbE 鏈路上，無損類被分配了5 Gbps（50%）的帶寬保證。但該交換機其他端口上無損流量的總入口速率仍為6 Gbps。為了將這些流量均衡到5 Gbps，該交換機調用了PFC，從而導致擁塞擴散。交換機上接收邊緣端口發送流量的其他端口上的Tx 暫停幀峰值證實了這一點。

在本案例研究中，明顯的問題是融合鏈路的容量不足，以及無損和有損類之間的流量爭用。通過增加另一條10 GbE 鏈路，這一問題得以解決。

在本案例研究中，兩種類型的流量（有損和無損）都使用兩條鏈路，這是共享存儲網絡的方法。另一種有效的方法是將一條鏈路專用于有損（普通級）流量，另一條鏈路專用于無損（無丟包級）流量，這就是專用存儲網絡的方法。

正確答案在于鏈路的容量和這些鏈路的預期吞吐量。專用存儲網絡是一種不同的架構，需要以不同的方式進行操作。其優點在于結構的獨立性、可擴展性、故障隔離和更易于故障排除。相反，專用存儲網絡的部署成本更高，需要更多資源來管理和運行。