本文節(jié)選自《DetectingTroubleshooting, and PreventingCongestion in Storage Networks 存儲(chǔ)網(wǎng)絡(luò)中擁塞處理》

微突發(fā)檢測(cè)

Cisco Nexus 9000 交換機(jī)可在微秒等較短時(shí)間內(nèi)檢測(cè)流量突發(fā)。這樣就可以捕捉到可能導(dǎo)致較低粒度擁塞，但由于輪詢間隔較長(zhǎng)而未被其他手段發(fā)現(xiàn)的事件。

當(dāng)出口隊(duì)列利用率超過(guò)上升閾值時(shí)，Cisco Nexus 9000 交換機(jī)可檢測(cè)到微突發(fā)。當(dāng)隊(duì)列利用率低于下降閾值時(shí)，微突發(fā)結(jié)束。根據(jù)交換機(jī)型號(hào)的不同，本文撰寫時(shí)的最小微突發(fā)粒度為?0.64 微秒，持續(xù)時(shí)間為?73 微秒。

要了解微突發(fā)檢測(cè)的要點(diǎn)是，它是在?Cisco Nexus 9000 交換機(jī)的出口隊(duì)列上報(bào)告的（圖?7-10）。正如前面在?"入口和出口隊(duì)列?"一節(jié)中所解釋的，暫停幀的發(fā)送取決于入口隊(duì)列的利用率。但只有在出口隊(duì)列達(dá)到一定程度（未滿）后，入口隊(duì)列才會(huì)填滿。因此，微突發(fā)檢測(cè)是出口擁塞的一種指示。由于出口擁塞會(huì)導(dǎo)致入口擁塞，因此微突發(fā)檢測(cè)也是入口擁塞的早期征兆。換句話說(shuō)，它是該交換機(jī)入口端口發(fā)送暫停幀的早期信號(hào)。?

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

有關(guān)其他詳細(xì)信息，請(qǐng)參閱第?8 章隊(duì)列深度監(jiān)控和微突發(fā)檢測(cè)一節(jié)。

PFC Storm

PFC 風(fēng)暴已成為一個(gè)術(shù)語(yǔ)，用來(lái)指?jìng)鬏?RoCE 和?RoCEv2 流量的無(wú)損以太網(wǎng)網(wǎng)絡(luò)（共享或?qū)Ｓ茫┲械膿砣?。這可能是因?yàn)橐粋€(gè)端口發(fā)送了許多暫停幀來(lái)減慢或停止流量，在其鄰居上看起來(lái)就像一場(chǎng)?PFC 暫停幀風(fēng)暴。

但是，使用這個(gè)術(shù)語(yǔ)可能會(huì)產(chǎn)生誤導(dǎo)，因?yàn)?"風(fēng)暴?"表達(dá)了大量的暫停幀，而且可能與擁塞嚴(yán)重程度有不準(zhǔn)確的聯(lián)系。暫停幀的數(shù)量越多，并不一定表示擁塞的嚴(yán)重程度越高。這是因?yàn)闀和瑢?duì)流量的影響取決于鏈路速度、暫停幀的類型（零或非零量子）及其模式。

前面關(guān)于以太網(wǎng)流量控制和暫停時(shí)間的章節(jié)介紹了這些細(xì)節(jié)。在了解了擁塞檢測(cè)指標(biāo)和故障排除后，讓我們?cè)賮?lái)看看它們的實(shí)際效果。

Link Speed and PFC Storm

正如前面有關(guān)暫停時(shí)間的章節(jié)所述，流量暫停的實(shí)際持續(xù)時(shí)間取決于鏈路的速度。例如，如果一個(gè)?10 GbE 端口每秒只收到?3000 個(gè)暫停幀，每個(gè)幀的量子點(diǎn)為?65535（暫停時(shí)間為?3.355 ms），那么它就可以完全停止傳輸。同一網(wǎng)絡(luò)中的另一個(gè)端口每秒接收?6000 個(gè)暫停幀，每個(gè)暫停幀的量子數(shù)為?65535，但仍不能完全停止傳輸，因?yàn)檫@是一個(gè)?100 GbE 端口，至少需要每秒接收?30,000 個(gè)暫停幀才能完全停止傳輸。

在這種情況下，100 GbE 端口的風(fēng)暴更嚴(yán)重，但實(shí)際上?10 GbE 端口的擁塞嚴(yán)重程度更高。因此，在根據(jù)暫停幀數(shù)量檢測(cè)擁塞時(shí)，只應(yīng)比較運(yùn)行速度相同的鏈路。

Pause Time and PFC Storm

與接收到較多較小quanta值暫停幀的端口相比，接收到較少較高quanta值暫停幀的端口受到的影響更大。正如前面的?"何時(shí)發(fā)送暫停幀?"一節(jié)所述，大多數(shù)實(shí)施可能使用最大量值?65535，因此這一點(diǎn)的實(shí)際意義可能較小。但是，您應(yīng)該驗(yàn)證在您的環(huán)境中使用的產(chǎn)品的實(shí)現(xiàn)。

Reason for Pause Frames and PFC Storm

使用?"PFC 風(fēng)暴?"一詞并不能說(shuō)明擁塞的原因。正如前面?"無(wú)損脊葉網(wǎng)絡(luò)中的擁塞?"一節(jié)所解釋的，慢排空和過(guò)度使用都會(huì)導(dǎo)致向上游直接連接的設(shè)備發(fā)送暫停幀。

The Pattern and Content of Pause Frames and PFC Storm

在所有其他因素中，接收到的暫停幀的模式是對(duì)數(shù)據(jù)傳輸產(chǎn)生實(shí)際影響的最重要因素。其次是發(fā)送方在接收到暫停幀時(shí)的狀態(tài)。讓我們來(lái)分析一下這兩個(gè)因素。

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

2. The State of the Transmitter: 流量?"可能?"暫停的時(shí)間是暫停幀和解除暫停幀之間的時(shí)間。這是?"可能"，而不是?"將要"，因?yàn)樵谑盏綍和罂赡軙?huì)有輕微延遲。在收到暫停幀后，停止傳輸會(huì)稍有延遲（不要與暫停時(shí)間混淆），因?yàn)槎丝诓粫?huì)中斷當(dāng)時(shí)已經(jīng)在傳輸?shù)膸?。這種延遲取決于鏈路速度、幀大小以及何時(shí)收到暫停幀。如果一個(gè)?10 GbE 端口在傳輸?1500 字節(jié)幀的最后一位時(shí)因收到暫停幀而決定停止傳輸，則鏈路傳輸會(huì)立即停止。但是，如果同一個(gè)?10 GbE 端口在開始傳輸?1500 字節(jié)幀時(shí)因收到?"暫停?"幀而決定停止傳輸，則傳輸在接下來(lái)的（(1500 x 8) 位?/ 10 Gbps）1.2 微秒內(nèi)不會(huì)停止。在這段時(shí)間內(nèi)，如果收到一個(gè)?Un-Pause 幀，那么端口在收到兩個(gè)暫停幀后也不會(huì)停止傳輸。如果該序列在?1 秒內(nèi)每?1.2 微秒重復(fù)一次，那么端口在該秒內(nèi)將報(bào)告約（（1 秒/1.2 微秒）x 2）160 萬(wàn)個(gè)暫停幀，同時(shí)繼續(xù)以滿負(fù)荷傳輸。僅僅通過(guò)計(jì)算暫停幀的數(shù)量，這條鏈路就可能被歸類為?PFC 風(fēng)暴，但它的行為與另一條?10 GbE 鏈路明顯不同，后者僅?3000 個(gè)暫停幀就能停止傳輸?1 整秒。請(qǐng)注意以下幾點(diǎn)：

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

b. 暫停幀大小為?64 字節(jié)。在傳輸一個(gè)數(shù)據(jù)幀時(shí)，可能會(huì)收到許多暫停幀。

c. 從這一解釋中可以看出，純粹根據(jù)暫停quanta值，甚至根據(jù)接收到的暫停幀和解除暫停幀之間的時(shí)間差來(lái)計(jì)算?TxWait 是不準(zhǔn)確的。準(zhǔn)確的?TxWait 值必須計(jì)算傳輸實(shí)際停止了多長(zhǎng)時(shí)間。

以太網(wǎng)中的?"暫停幀數(shù)?"與光纖通道中的?"B2B 信元轉(zhuǎn)為零?"類似。光纖通道端口在有一個(gè)剩余的?Tx-B2B 信元時(shí)，會(huì)將此計(jì)數(shù)器遞減為零，然后開始傳輸幀。但是，在傳輸幀的過(guò)程中，它可能會(huì)收到一個(gè)信元，因此下一幀完全不會(huì)延遲。這種情況會(huì)導(dǎo)致?"B2B 信元轉(zhuǎn)為零?"計(jì)數(shù)器遞增，而傳輸實(shí)際上并沒(méi)有停止。

雖然這種情況很少被報(bào)告，而且更難檢測(cè)，但需要了解的關(guān)鍵一點(diǎn)是，無(wú)論是光纖通道中的?"B2B 信元轉(zhuǎn)換為零?"計(jì)數(shù)器，還是以太網(wǎng)中的?"暫停幀數(shù)"，都不是檢測(cè)擁塞的有力機(jī)制。因此，應(yīng)避免使用基于此計(jì)數(shù)器的?PFC Strom 這樣的術(shù)語(yǔ)，因?yàn)樗赡軙?huì)誤導(dǎo)某些人，讓他們相信暫停幀數(shù)才是擁塞的真正衡量標(biāo)準(zhǔn)。

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

我們希望通過(guò)本書傳達(dá)的一個(gè)觀點(diǎn)是，將在一種傳輸類型（如光纖通道）中學(xué)到的知識(shí)用于另一種傳輸類型（如無(wú)損以太網(wǎng)）。在以太網(wǎng)中使用?"PFC Storm "就像在光纖通道中使用?"Credit Transition Storm "來(lái)表示擁塞一樣。許多年前，也就是現(xiàn)在看來(lái)，當(dāng)光纖通道交換機(jī)不提供?TxWait 時(shí)，"B2B 信元過(guò)渡到零?"是擁塞檢測(cè)的唯一指標(biāo)。然而，自從有了?TxWait，它就成了檢測(cè)擁塞的主要指標(biāo)，而?"B2B 信元轉(zhuǎn)換為零?"只是在萬(wàn)不得已的情況下才使用。如今，將擁塞稱為?"信元過(guò)渡風(fēng)暴?"是不合適的，將其稱為?"PFC 風(fēng)暴?"也是不合適的。由于?PFC Strom 反映的是暫停幀的數(shù)量，因此現(xiàn)在使用它意味著無(wú)損以太網(wǎng)并沒(méi)有真正從光纖通道中學(xué)習(xí)。

當(dāng)然，切勿在光纖通道結(jié)構(gòu)中使用?"信元轉(zhuǎn)換風(fēng)暴?"一詞。對(duì)于無(wú)損以太網(wǎng)網(wǎng)絡(luò)，盡管本節(jié)反對(duì)使用?PFC Storm 一詞，但包括?Cisco 在內(nèi)的一些供應(yīng)商還是使用了該詞。我們將讓讀者自己決定是否以及何時(shí)使用?PFC Storm 這個(gè)術(shù)語(yǔ)會(huì)產(chǎn)生誤導(dǎo)，然后再?zèng)Q定要做什么。

Storage I/O Performance Monitoring

存儲(chǔ)網(wǎng)絡(luò)中的流量是應(yīng)用程序啟動(dòng)讀取或?qū)懭?I/O 操作的直接結(jié)果。因此，通過(guò)分析應(yīng)用程序?I/O 配置文件，如?I/O 操作的時(shí)間、大小、類型和速率，可以更好地了解網(wǎng)絡(luò)流量模式。從本質(zhì)上講，應(yīng)用程序?I/O 配置文件有助于理解網(wǎng)絡(luò)出現(xiàn)流量或擁塞的原因。

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

第?5 章?"為什么要監(jiān)控存儲(chǔ)?I/O 性能？"一節(jié)介紹了監(jiān)控存儲(chǔ)?I/O 性能的基本價(jià)值。

第?5 章?"如何以及在何處監(jiān)控存儲(chǔ)?I/O 性能?"一節(jié)介紹了監(jiān)控存儲(chǔ)?I/O 性能的三個(gè)位置--主機(jī)、存儲(chǔ)陣列或網(wǎng)絡(luò)。

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

第?5 章?"了解存儲(chǔ)網(wǎng)絡(luò)中的?I/O 流量?"一節(jié)有助于了解光纖通道結(jié)構(gòu)中的?I/O 流量與無(wú)損以太網(wǎng)網(wǎng)絡(luò)中的?I/O 流量之間的區(qū)別。請(qǐng)?zhí)貏e注意?"I/O 流量與?I/O 操作?"小節(jié)。

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

了解第?5 章的這些內(nèi)容后，請(qǐng)注意可以在以下層面監(jiān)控?zé)o損以太網(wǎng)網(wǎng)絡(luò)的性能：

1. 端口或流量類別：?大多數(shù)終端設(shè)備和交換機(jī)都會(huì)報(bào)告網(wǎng)絡(luò)端口或接口上發(fā)送/接收的數(shù)據(jù)包和發(fā)送/接收的字節(jié)等計(jì)數(shù)器。與其他類別相比，可以單獨(dú)監(jiān)控?zé)o損類別的流量。

2. UDP 流量：?OSI 模型第?4 層的流量由?5 個(gè)元組標(biāo)識(shí)：源?IP、目標(biāo)?IP、源端口、目標(biāo)端口和第?4 層協(xié)議（TCP、UDP 等）。換句話說(shuō)，RoCEv2 流量可按?UDP 流量分類。每個(gè)?UDP 流量的發(fā)送/接收的數(shù)據(jù)包、發(fā)送/接收的字節(jié)數(shù)和丟棄的數(shù)據(jù)包等計(jì)數(shù)器可根據(jù)網(wǎng)絡(luò)設(shè)備的能力分別進(jìn)行監(jiān)控。

3. ?I/O 流：I/O 流是對(duì)存儲(chǔ)卷（SCSI 為邏輯單元，NVMe 為命名空間）的?SCSI 或?NVMe I/O 操作的感知。通過(guò)監(jiān)控?I/O 流級(jí)別的性能，可以計(jì)算?I/O 操作完成所需的時(shí)間、吞吐量、IOPS、類型（讀或?qū)懀/O 大小等。

UDP Flow Monitoring versus I/O Flow Monitoring

UDP 流量監(jiān)控不應(yīng)與?I/O 流量監(jiān)控混淆，原因如下：

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

2. 許多?I/O 操作可能在一個(gè)?UDP 數(shù)據(jù)流中傳輸。這些?I/O 操作可能屬于不同的?I/O 流。請(qǐng)參閱第?5 章?"I/O 流與?I/O 操作?"一節(jié)。

3. 如前所述，UDP 流量有自己的性能監(jiān)控指標(biāo)，如每秒傳輸?shù)臄?shù)據(jù)包、吞吐量等。這與?I/O 流量的性能監(jiān)控指標(biāo)（如?IOPS、I/O 吞吐量、完成?I/O 操作所需的時(shí)間、I/O 大小等）不同。

Unavailability of I/O Flow Monitoring in Lossless Ethernet Networks

在撰寫本文時(shí)，無(wú)損以太網(wǎng)網(wǎng)絡(luò)中還沒(méi)有對(duì)?I/O 流量進(jìn)行性能監(jiān)控。以太網(wǎng)交換機(jī)可能會(huì)報(bào)告網(wǎng)絡(luò)延遲，這通常是指數(shù)據(jù)包在網(wǎng)絡(luò)中花費(fèi)的時(shí)間。這不是?I/O 完成時(shí)間。同樣，以太網(wǎng)交換機(jī)可能會(huì)報(bào)告?UDP 流量的吞吐量，但這不是讀或?qū)?I/O 吞吐量或?IOPS。

雖然啟動(dòng)程序和目標(biāo)程序的?IP 地址可被視為?IT 流量，但如果不了解?I/O 流量指標(biāo)，這種流量定義就沒(méi)有什么價(jià)值。

即使在將來(lái)，以太網(wǎng)交換機(jī)也不可能監(jiān)控?I/O 性能，類似于?Cisco MDS 交換機(jī)光纖通道端口上的?SAN Analytics。這是因?yàn)橐蕴W(wǎng)網(wǎng)絡(luò)攜帶數(shù)千個(gè)上層協(xié)議，每個(gè)協(xié)議都有不同的?TCP 和?UDP 端口號(hào)。增強(qiáng)以太網(wǎng)交換機(jī)以解碼存儲(chǔ)協(xié)議（FCoE、RoCE 等）并測(cè)量其性能，可能無(wú)法彌補(bǔ)進(jìn)行這些增強(qiáng)所需的額外成本。這對(duì)?Cisco MDS 交換機(jī)來(lái)說(shuō)并不是一個(gè)挑戰(zhàn)，因?yàn)楣饫w通道是專門為存儲(chǔ)流量而構(gòu)建的。相比之下，以太網(wǎng)網(wǎng)絡(luò)則可傳輸各種流量，如第?1 章圖?1-11 所示。

Alternative Approaches

另一種方法是監(jiān)控主機(jī)或存儲(chǔ)陣列內(nèi)的存儲(chǔ)?I/O 性能。第?5 章將解釋這些細(xì)節(jié)以及如何使用?I/O 性能指標(biāo)來(lái)解決擁塞問(wèn)題。雖然第?5 章重點(diǎn)介紹光纖通道，但其概念也適用于無(wú)損以太網(wǎng)網(wǎng)絡(luò)。

一些以太網(wǎng)交換機(jī)（如?Cisco Nexus 9000 交換機(jī)）會(huì)監(jiān)控?UDP 流的性能。但如前所述，這并不是對(duì)?I/O 流量的性能監(jiān)控，這些?UDP 流量中包含了?I/O 流量。因此，在對(duì)主機(jī)和存儲(chǔ)陣列進(jìn)行?I/O 性能監(jiān)控的同時(shí)，應(yīng)使用以太網(wǎng)交換機(jī)進(jìn)行?UDP 流量監(jiān)控。RoCEv2 目標(biāo)/控制器使用?UDP 端口?4791，這意味著發(fā)往目標(biāo)/控制器的數(shù)據(jù)包具有目標(biāo)端口?4791，而發(fā)往主機(jī)的數(shù)據(jù)包具有源端口?4791。UDP 端口?4420 分配給?NVMe/RoCE?？梢詫⒏鞣N來(lái)源的信息關(guān)聯(lián)起來(lái)，構(gòu)建自己的解決方案。

FCoE I/O Operations

FCoE 網(wǎng)絡(luò)中的?SCSI 和?NVMe I/O 操作與光纖通道?Fabric 相同。有關(guān)詳細(xì)信息，請(qǐng)參閱第?5 章。

但?SAN 分析功能僅適用于?Cisco MDS 交換機(jī)上的光纖通道端口。如果流量在端到端數(shù)據(jù)路徑中至少經(jīng)過(guò)一次具有分析功能的光纖通道端口，則仍可對(duì)其進(jìn)行檢查，以收集?I/O 流量指標(biāo)。即使流量通過(guò)網(wǎng)絡(luò)中其他位置的?FCoE 端口，這種方法也能發(fā)揮作用。一個(gè)典型的例子是思科?UCS 服務(wù)器，它在內(nèi)部使用?FCoE。當(dāng)相同的流量到達(dá)?MDS 上的光纖通道端口時(shí)，可以使用?SAN Analytics 對(duì)其進(jìn)行檢查，以收集?I/O 流量指標(biāo)。

RoCE I/O Operations

圖?7-11 顯示了?NVMe over RoCE 讀?I/O 操作。主機(jī)通過(guò)向目標(biāo)機(jī)發(fā)送命令包中的?RDMA_SEND 來(lái)啟動(dòng)讀?I/O 操作。目標(biāo)機(jī)根據(jù)?I/O 操作請(qǐng)求的數(shù)據(jù)量和網(wǎng)絡(luò)的最大傳輸單元?(MTU)，通過(guò)?RDMA_WRITE 以一個(gè)或多個(gè)數(shù)據(jù)包的形式向主機(jī)發(fā)送數(shù)據(jù)（更多詳情請(qǐng)參見第?8 章?IP MTU 和?TCP MSS 考慮因素部分）。最后，當(dāng)目標(biāo)發(fā)送響應(yīng)包時(shí)，I/O 操作完成。

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

圖?7-12 顯示了?NVMe over RoCE 寫?I/O 操作。主機(jī)通過(guò)向目標(biāo)機(jī)發(fā)送命令包中的?RDMA_SEND，啟動(dòng)寫?I/O 操作。然后，目標(biāo)機(jī)向主機(jī)發(fā)送?RDMA_READ 請(qǐng)求。接下來(lái)，主機(jī)根據(jù)?I/O 操作請(qǐng)求的數(shù)據(jù)量和網(wǎng)絡(luò)的?MTU，通過(guò)?RDMA_READ 響應(yīng)以一個(gè)或多個(gè)數(shù)據(jù)包的形式向目標(biāo)發(fā)送數(shù)據(jù)。最后，當(dāng)目標(biāo)機(jī)發(fā)送響應(yīng)包時(shí)，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

請(qǐng)參閱第?5 章的以下章節(jié)，為簡(jiǎn)潔起見，此處不再贅述。

將第?5 章中的?I/O 操作和網(wǎng)絡(luò)流量模式一節(jié)與前一節(jié)進(jìn)行比較，可以發(fā)現(xiàn)流量模式之間有驚人的相似之處。因此，與網(wǎng)絡(luò)擁塞的相關(guān)性也很相似。對(duì)于讀取數(shù)據(jù)，SCSI 和?NVMe 使用讀?CMD，而?RDMA 則反向使用?RDMA_WRITE verb。同樣，在寫數(shù)據(jù)時(shí)，SCSI 和?NVMe 使用寫?CMD，而?RDMA 則反向使用?RDMA_READ verb。

第?5 章?"網(wǎng)絡(luò)流量方向?"一節(jié)介紹了各種端口類型因讀寫?I/O 操作而產(chǎn)生的流量。

第?5 章?"I/O 操作、流量模式和網(wǎng)絡(luò)擁塞的相關(guān)性?"一節(jié)解釋說(shuō)，主機(jī)鏈路擁塞的主要原因是來(lái)自該主機(jī)的多個(gè)并發(fā)大容量讀取?I/O 操作。同樣，存儲(chǔ)鏈路擁塞的主要原因是存儲(chǔ)陣列請(qǐng)求的數(shù)據(jù)總量。

Detecting Congestion on a Remote Monitoring Platform

遠(yuǎn)程監(jiān)控平臺(tái)可同時(shí)監(jiān)控網(wǎng)絡(luò)中的所有端口，以提供全網(wǎng)單一窗口可視性。

請(qǐng)參閱第?3 章?"在遠(yuǎn)程監(jiān)控平臺(tái)上檢測(cè)擁塞?"一節(jié)，其中介紹了如何使用以下類型的監(jiān)控應(yīng)用程序：

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

第三方或定制開發(fā)的應(yīng)用程序，如?MDS 流量監(jiān)控?(MTM) 應(yīng)用程序。

本節(jié)簡(jiǎn)要介紹用于檢測(cè)以太網(wǎng)擁塞的?Cisco Nexus Dashboard Insights。

要進(jìn)一步了解定制開發(fā)的用于檢測(cè)和排除無(wú)損以太網(wǎng)網(wǎng)絡(luò)擁塞故障的應(yīng)用程序，請(qǐng)參閱第?9 章，其中介紹了如何使用?UCS 流量監(jiān)控應(yīng)用程序?(UTM)。

第?3 章還介紹了?"監(jiān)控網(wǎng)絡(luò)流量的陷阱"。其中關(guān)于平均利用率和峰值利用率的小節(jié)也適用于無(wú)損以太網(wǎng)網(wǎng)絡(luò)。

Congestion Detection using Cisco Nexus Dashboard Insights

Cisco Nexus Dashboard Insights 以?1 秒的低粒度接收來(lái)自交換機(jī)和計(jì)算節(jié)點(diǎn)的指標(biāo)。然后，它使用基線、相關(guān)性和預(yù)測(cè)算法分析原始指標(biāo)，深入洞察流量模式。在擁塞檢測(cè)方面，Nexus Dashboard Insights 可檢測(cè)數(shù)據(jù)平面異常，如丟包、延遲、微爆發(fā)等。它使用直觀的圖形用戶界面顯示流量的端到端數(shù)據(jù)包路徑，以及丟包和丟包的原因。

圖?7-13 顯示了?RoCEv2 流量的端到端路徑、平均網(wǎng)絡(luò)延遲和?Nexus Dashboard Insights 上的突發(fā)。?

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

Metric Export Mechanisms

對(duì)于定制開發(fā)的應(yīng)用程序或腳本而言，指標(biāo)導(dǎo)出機(jī)制是一個(gè)重要的考慮因素。第?3 章?"指標(biāo)導(dǎo)出機(jī)制?"一節(jié)中解釋的大部分細(xì)節(jié)也適用于無(wú)損以太網(wǎng)網(wǎng)絡(luò)。

請(qǐng)?zhí)貏e注意第?3 章介紹的指標(biāo)輸出建議。使用命令行輸出和?SNMP 在歷史上很常見，但現(xiàn)在使用?API 已成為常態(tài)。對(duì)于大規(guī)模的低粒度度量導(dǎo)出，流式遙測(cè)是最佳選擇，而且正在被迅速采用。

Cisco Nexus Dashboard Fabric Controller 和?Nexus Dashboard Insights 默認(rèn)選擇最佳導(dǎo)出機(jī)制。

以下小節(jié)簡(jiǎn)要介紹了?Cisco Nexus 9000 交換機(jī)上的指標(biāo)導(dǎo)出機(jī)制，不再重復(fù)第?3 章中的說(shuō)明。

SNMP

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

Note the following points:?請(qǐng)注意以下幾點(diǎn)：

1. Cisco Nexus 9000 交換機(jī)上的?PFC 計(jì)數(shù)器可由?CISCO-PFC-EXT-MIB 監(jiān)控，該?MIB 包含更多計(jì)數(shù)器，如?TxWait 和?RxWait，但表?7-3 沒(méi)有列出所有計(jì)數(shù)器，因?yàn)?Nexus 交換機(jī)在本文撰寫時(shí)不支持?TxWait 和?RxWait。雖然交換機(jī)可能會(huì)響應(yīng)?MIB 請(qǐng)求，但它們的值不會(huì)隨時(shí)間而改變。如果交換機(jī)類型支持?CISCO-PFC-EXT-MIB，它還可用于監(jiān)控?PFC 看門狗。

2. 需要注意的是，多年來(lái)，Cisco 設(shè)備上的?LLFC 和?PFC MIB 計(jì)數(shù)器一直受到某些固件版本和交換機(jī)型號(hào)執(zhí)行不力的影響。在依賴返回值之前，請(qǐng)驗(yàn)證它們是否與交換機(jī)上的命令行輸出相匹配。根據(jù)返回值?0 進(jìn)行初步驗(yàn)證是不夠的，因?yàn)楸M管?0 是一個(gè)有效值，但它可能不會(huì)遞增。這將造成沒(méi)有擁塞的錯(cuò)誤提示。

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

4. 由于?PFC 是通過(guò)以太網(wǎng)交換機(jī)上的?QoS 實(shí)現(xiàn)的，因此監(jiān)控?CISCO-SWITCH-QOS-MIB 可提供每個(gè)隊(duì)列的指標(biāo)。

Streaming Telemetry

有關(guān)流遙測(cè)的詳細(xì)信息，請(qǐng)參閱第?3 章?"流遙測(cè)?"一節(jié)。Cisco Nexus 9000 交換機(jī)有以下額外注意事項(xiàng)：

1. Nexus 交換機(jī)可以從前面板數(shù)據(jù)端口導(dǎo)出指標(biāo)，從而實(shí)現(xiàn)低粒度指標(biāo)導(dǎo)出。在撰寫本文時(shí)，MDS 交換機(jī)只能從交換機(jī)的管理端口導(dǎo)出指標(biāo)。

2. Nexus 交換機(jī)支持?NetFlow 和?sFlow。不過(guò)，流式遙測(cè)可導(dǎo)出粒度更小的指標(biāo)。

3. Cisco Nexus 交換機(jī)上的軟件遙測(cè)功能可導(dǎo)出控制平面信息和接口指標(biāo)。

4. 此外，Nexus 交換機(jī)還支持硬件遙測(cè)，可導(dǎo)出粒度（根據(jù)交換機(jī)類型可低至?1 秒）的指標(biāo)：

a. 流統(tǒng)計(jì)數(shù)據(jù)導(dǎo)出?(SSX)，用于導(dǎo)出原始?ASIC 統(tǒng)計(jì)數(shù)據(jù)。

b. 流量表?(FT)，用于導(dǎo)出流量級(jí)別信息。

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

5. Nexus 交換機(jī)支持帶內(nèi)網(wǎng)絡(luò)遙測(cè)?(INT)，用于監(jiān)控丟棄的數(shù)據(jù)包和擁塞的隊(duì)列。

網(wǎng)絡(luò)遙測(cè)和分析領(lǐng)域發(fā)展迅速。我們建議您參考文檔和發(fā)行說(shuō)明，了解產(chǎn)品在您的環(huán)境中的功能以及如何使用它們。

審核編輯：黃飛

?