電子發(fā)燒友App
本文節(jié)選自《DetectingTroubleshooting, and PreventingCongestion in Storage Networks 存儲網(wǎng)絡(luò)中擁塞處理》
微突發(fā)檢測
Cisco Nexus 9000 交換機可在微秒等較短時間內(nèi)檢測流量突發(fā)。這樣就可以捕捉到可能導(dǎo)致較低粒度擁塞，但由于輪詢間隔較長而未被其他手段發(fā)現(xiàn)的事件。
當(dāng)出口隊列利用率超過上升閾值時，Cisco Nexus 9000 交換機可檢測到微突發(fā)。當(dāng)隊列利用率低于下降閾值時，微突發(fā)結(jié)束。根據(jù)交換機型號的不同，本文撰寫時的最小微突發(fā)粒度為?0.64 微秒，持續(xù)時間為?73 微秒。
要了解微突發(fā)檢測的要點是，它是在?Cisco Nexus 9000 交換機的出口隊列上報告的（圖?7-10）。正如前面在?"入口和出口隊列?"一節(jié)中所解釋的，暫停幀的發(fā)送取決于入口隊列的利用率。但只有在出口隊列達(dá)到一定程度（未滿）后，入口隊列才會填滿。因此，微突發(fā)檢測是出口擁塞的一種指示。由于出口擁塞會導(dǎo)致入口擁塞，因此微突發(fā)檢測也是入口擁塞的早期征兆。換句話說，它是該交換機入口端口發(fā)送暫停幀的早期信號。?
Figure 7-10?Microburst detection on egress queues for lossless traffic
有關(guān)其他詳細(xì)信息，請參閱第?8 章隊列深度監(jiān)控和微突發(fā)檢測一節(jié)。
PFC Storm
PFC 風(fēng)暴已成為一個術(shù)語，用來指傳輸?RoCE 和?RoCEv2 流量的無損以太網(wǎng)網(wǎng)絡(luò)（共享或?qū)Ｓ茫┲械膿砣?。這可能是因為一個端口發(fā)送了許多暫停幀來減慢或停止流量，在其鄰居上看起來就像一場?PFC 暫停幀風(fēng)暴。
但是，使用這個術(shù)語可能會產(chǎn)生誤導(dǎo)，因為?"風(fēng)暴?"表達(dá)了大量的暫停幀，而且可能與擁塞嚴(yán)重程度有不準(zhǔn)確的聯(lián)系。暫停幀的數(shù)量越多，并不一定表示擁塞的嚴(yán)重程度越高。這是因為暫停幀對流量的影響取決于鏈路速度、暫停幀的類型（零或非零量子）及其模式。
前面關(guān)于以太網(wǎng)流量控制和暫停時間的章節(jié)介紹了這些細(xì)節(jié)。在了解了擁塞檢測指標(biāo)和故障排除后，讓我們再來看看它們的實際效果。
Link Speed and PFC Storm
正如前面有關(guān)暫停時間的章節(jié)所述，流量暫停的實際持續(xù)時間取決于鏈路的速度。例如，如果一個?10 GbE 端口每秒只收到?3000 個暫停幀，每個幀的量子點為?65535（暫停時間為?3.355 ms），那么它就可以完全停止傳輸。同一網(wǎng)絡(luò)中的另一個端口每秒接收?6000 個暫停幀，每個暫停幀的量子數(shù)為?65535，但仍不能完全停止傳輸，因為這是一個?100 GbE 端口，至少需要每秒接收?30,000 個暫停幀才能完全停止傳輸。
在這種情況下，100 GbE 端口的風(fēng)暴更嚴(yán)重，但實際上?10 GbE 端口的擁塞嚴(yán)重程度更高。因此，在根據(jù)暫停幀數(shù)量檢測擁塞時，只應(yīng)比較運行速度相同的鏈路。
Pause Time and PFC Storm
與接收到較多較小quanta值暫停幀的端口相比，接收到較少較高quanta值暫停幀的端口受到的影響更大。正如前面的?"何時發(fā)送暫停幀?"一節(jié)所述，大多數(shù)實施可能使用最大量值?65535，因此這一點的實際意義可能較小。但是，您應(yīng)該驗證在您的環(huán)境中使用的產(chǎn)品的實現(xiàn)。
Reason for Pause Frames and PFC Storm
使用?"PFC 風(fēng)暴?"一詞并不能說明擁塞的原因。正如前面?"無損脊葉網(wǎng)絡(luò)中的擁塞?"一節(jié)所解釋的，慢排空和過度使用都會導(dǎo)致向上游直接連接的設(shè)備發(fā)送暫停幀。
The Pattern and Content of Pause Frames and PFC Storm
在所有其他因素中，接收到的暫停幀的模式是對數(shù)據(jù)傳輸產(chǎn)生實際影響的最重要因素。其次是發(fā)送方在接收到暫停幀時的狀態(tài)。讓我們來分析一下這兩個因素。
1. The Pattern and content of Pause frames: ?如果認(rèn)為收到非零quanta的暫停幀后，流量會在quanta所代表的時間內(nèi)停止，那是不正確的。實際上，一個非零quanta的暫停幀之后可能很快就會出現(xiàn)一個取消暫停/恢復(fù)幀（零quanta的暫停幀）。如果一秒鐘內(nèi)有?3000 個暫停幀，它們是否都有最大quanta？其中是否有一半具有最大quanta，而其余的quanta為零？如果有?3000 個暫停幀都具有最大quanta，那么?10 GbE 鏈路上的傳輸就會完全停止?1 整秒。但是，如果這些暫停幀中有一半的quanta值為零，并且是在具有最大quanta值的初始暫停幀之后?1 微秒才發(fā)送的，那么在這?1 秒鐘內(nèi)暫停傳輸?shù)臅r間可能只有?1500 微秒。換句話說，僅僅計算暫停幀并不能完全反映實際情況。
2. The State of the Transmitter: 流量?"可能?"暫停的時間是暫停幀和解除暫停幀之間的時間。這是?"可能"，而不是?"將要"，因為在收到暫停幀后可能會有輕微延遲。在收到暫停幀后，停止傳輸會稍有延遲（不要與暫停時間混淆），因為端口不會中斷當(dāng)時已經(jīng)在傳輸?shù)膸?。這種延遲取決于鏈路速度、幀大小以及何時收到暫停幀。如果一個?10 GbE 端口在傳輸?1500 字節(jié)幀的最后一位時因收到暫停幀而決定停止傳輸，則鏈路傳輸會立即停止。但是，如果同一個?10 GbE 端口在開始傳輸?1500 字節(jié)幀時因收到?"暫停?"幀而決定停止傳輸，則傳輸在接下來的（(1500 x 8) 位?/ 10 Gbps）1.2 微秒內(nèi)不會停止。在這段時間內(nèi)，如果收到一個?Un-Pause 幀，那么端口在收到兩個暫停幀后也不會停止傳輸。如果該序列在?1 秒內(nèi)每?1.2 微秒重復(fù)一次，那么端口在該秒內(nèi)將報告約（（1 秒/1.2 微秒）x 2）160 萬個暫停幀，同時繼續(xù)以滿負(fù)荷傳輸。僅僅通過計算暫停幀的數(shù)量，這條鏈路就可能被歸類為?PFC 風(fēng)暴，但它的行為與另一條?10 GbE 鏈路明顯不同，后者僅?3000 個暫停幀就能停止傳輸?1 整秒。請注意以下幾點：
A. ?為簡單起見，本示例使用?1500 字節(jié)的幀大小。但是，存儲流量的幀大小可能更大，約為?2300 字節(jié)（FCoE）或甚至?4 KB（RoCEv2）。隨著幀大小的增加，接收到的?"暫停?"幀的動作延遲時間可能會更長，例如，在?10 GbE 鏈路上，2300 字節(jié)幀的延遲時間為?2.3 微秒，4 KB 幀的延遲時間為?4.2 微秒。
b. 暫停幀大小為?64 字節(jié)。在傳輸一個數(shù)據(jù)幀時，可能會收到許多暫停幀。
c. 從這一解釋中可以看出，純粹根據(jù)暫停quanta值，甚至根據(jù)接收到的暫停幀和解除暫停幀之間的時間差來計算?TxWait 是不準(zhǔn)確的。準(zhǔn)確的?TxWait 值必須計算傳輸實際停止了多長時間。
以太網(wǎng)中的?"暫停幀數(shù)?"與光纖通道中的?"B2B 信元轉(zhuǎn)為零?"類似。光纖通道端口在有一個剩余的?Tx-B2B 信元時，會將此計數(shù)器遞減為零，然后開始傳輸幀。但是，在傳輸幀的過程中，它可能會收到一個信元，因此下一幀完全不會延遲。這種情況會導(dǎo)致?"B2B 信元轉(zhuǎn)為零?"計數(shù)器遞增，而傳輸實際上并沒有停止。
雖然這種情況很少被報告，而且更難檢測，但需要了解的關(guān)鍵一點是，無論是光纖通道中的?"B2B 信元轉(zhuǎn)換為零?"計數(shù)器，還是以太網(wǎng)中的?"暫停幀數(shù)"，都不是檢測擁塞的有力機制。因此，應(yīng)避免使用基于此計數(shù)器的?PFC Strom 這樣的術(shù)語，因為它可能會誤導(dǎo)某些人，讓他們相信暫停幀數(shù)才是擁塞的真正衡量標(biāo)準(zhǔn)。
本書使用?TxWait 和?RxWait 來表示無損網(wǎng)絡(luò)（光纖通道或無損以太網(wǎng)）中各方向傳輸停止的實際時間。PFC Storm 作為一個術(shù)語，似乎非常適合累計暫停時間（TxWait 和?RxWait）不可用的環(huán)境，而且暫停幀的數(shù)量是檢測擁塞的主要指標(biāo)。但是，將來當(dāng)設(shè)備改進(jìn)了暫停時間檢測（TxWait 和?RxWait）后，使用?"PFC 風(fēng)暴?"這一術(shù)語將更具誤導(dǎo)性。例如，一個?10 GbE 端口可能在每秒只有?3000 個暫停幀的情況下顯示?100% 的?TxWait，而一個?100 GbE 端口可能在每秒有?6000 個暫停幀的情況下顯示?10% 的?TxWait。100 GbE 端口的?"風(fēng)暴?"嚴(yán)重性可能看起來更高，但?10 GbE 端口的擁塞嚴(yán)重性更高。
我們希望通過本書傳達(dá)的一個觀點是，將在一種傳輸類型（如光纖通道）中學(xué)到的知識用于另一種傳輸類型（如無損以太網(wǎng)）。在以太網(wǎng)中使用?"PFC Storm "就像在光纖通道中使用?"Credit Transition Storm "來表示擁塞一樣。許多年前，也就是現(xiàn)在看來，當(dāng)光纖通道交換機不提供?TxWait 時，"B2B 信元過渡到零?"是擁塞檢測的唯一指標(biāo)。然而，自從有了?TxWait，它就成了檢測擁塞的主要指標(biāo)，而?"B2B 信元轉(zhuǎn)換為零?"只是在萬不得已的情況下才使用。如今，將擁塞稱為?"信元過渡風(fēng)暴?"是不合適的，將其稱為?"PFC 風(fēng)暴?"也是不合適的。由于?PFC Strom 反映的是暫停幀的數(shù)量，因此現(xiàn)在使用它意味著無損以太網(wǎng)并沒有真正從光纖通道中學(xué)習(xí)。
當(dāng)然，切勿在光纖通道結(jié)構(gòu)中使用?"信元轉(zhuǎn)換風(fēng)暴?"一詞。對于無損以太網(wǎng)網(wǎng)絡(luò)，盡管本節(jié)反對使用?PFC Storm 一詞，但包括?Cisco 在內(nèi)的一些供應(yīng)商還是使用了該詞。我們將讓讀者自己決定是否以及何時使用?PFC Storm 這個術(shù)語會產(chǎn)生誤導(dǎo)，然后再決定要做什么。
Storage I/O Performance Monitoring
存儲網(wǎng)絡(luò)中的流量是應(yīng)用程序啟動讀取或?qū)懭?I/O 操作的直接結(jié)果。因此，通過分析應(yīng)用程序?I/O 配置文件，如?I/O 操作的時間、大小、類型和速率，可以更好地了解網(wǎng)絡(luò)流量模式。從本質(zhì)上講，應(yīng)用程序?I/O 配置文件有助于理解網(wǎng)絡(luò)出現(xiàn)流量或擁塞的原因。
第?5 章介紹了如何通過存儲?I/O 性能監(jiān)控解決擁塞問題。由于上層（SCSI 和?NVMe）相同，因此相同的細(xì)節(jié)（至少在概念上）也適用于?FCoE 和?RoCE（傳輸協(xié)議不同除外）。在繼續(xù)閱讀之前，請參考第?5 章中的以下章節(jié)，為簡潔起見，此處不再贅述。
第?5 章?"為什么要監(jiān)控存儲?I/O 性能？"一節(jié)介紹了監(jiān)控存儲?I/O 性能的基本價值。
第?5 章?"如何以及在何處監(jiān)控存儲?I/O 性能?"一節(jié)介紹了監(jiān)控存儲?I/O 性能的三個位置--主機、存儲陣列或網(wǎng)絡(luò)。
第?5 章?"Cisco SAN Analytics "一節(jié)介紹了?Cisco MDS 交換機如何在交換機內(nèi)部監(jiān)控存儲?I/O 性能。這種功能稱為?SAN Analytics，僅在光纖通道端口上可用。本節(jié)還有助于理解為什么以太網(wǎng)交換機不具備類似功能。
第?5 章?"了解存儲網(wǎng)絡(luò)中的?I/O 流量?"一節(jié)有助于了解光纖通道結(jié)構(gòu)中的?I/O 流量與無損以太網(wǎng)網(wǎng)絡(luò)中的?I/O 流量之間的區(qū)別。請?zhí)貏e注意?"I/O 流量與?I/O 操作?"小節(jié)。
第?5 章?"I/O 流量指標(biāo)?"一節(jié)有助于了解如何使用各種指標(biāo)監(jiān)控?I/O 流量的性能，如?I/O 完成時間（光纖通道中稱為交換完成時間）、IOPS、吞吐量和?I/O 大小。
了解第?5 章的這些內(nèi)容后，請注意可以在以下層面監(jiān)控?zé)o損以太網(wǎng)網(wǎng)絡(luò)的性能：
1. 端口或流量類別：?大多數(shù)終端設(shè)備和交換機都會報告網(wǎng)絡(luò)端口或接口上發(fā)送/接收的數(shù)據(jù)包和發(fā)送/接收的字節(jié)等計數(shù)器。與其他類別相比，可以單獨監(jiān)控?zé)o損類別的流量。
2. UDP 流量：?OSI 模型第?4 層的流量由?5 個元組標(biāo)識：源?IP、目標(biāo)?IP、源端口、目標(biāo)端口和第?4 層協(xié)議（TCP、UDP 等）。換句話說，RoCEv2 流量可按?UDP 流量分類。每個?UDP 流量的發(fā)送/接收的數(shù)據(jù)包、發(fā)送/接收的字節(jié)數(shù)和丟棄的數(shù)據(jù)包等計數(shù)器可根據(jù)網(wǎng)絡(luò)設(shè)備的能力分別進(jìn)行監(jiān)控。
3. ?I/O 流：I/O 流是對存儲卷（SCSI 為邏輯單元，NVMe 為命名空間）的?SCSI 或?NVMe I/O 操作的感知。通過監(jiān)控?I/O 流級別的性能，可以計算?I/O 操作完成所需的時間、吞吐量、IOPS、類型（讀或?qū)懀?、I/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 操作可能在一個?UDP 數(shù)據(jù)流中傳輸。這些?I/O 操作可能屬于不同的?I/O 流。請參閱第?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 操作所需的時間、I/O 大小等）不同。
Unavailability of I/O Flow Monitoring in Lossless Ethernet Networks
在撰寫本文時，無損以太網(wǎng)網(wǎng)絡(luò)中還沒有對?I/O 流量進(jìn)行性能監(jiān)控。以太網(wǎng)交換機可能會報告網(wǎng)絡(luò)延遲，這通常是指數(shù)據(jù)包在網(wǎng)絡(luò)中花費的時間。這不是?I/O 完成時間。同樣，以太網(wǎng)交換機可能會報告?UDP 流量的吞吐量，但這不是讀或?qū)?I/O 吞吐量或?IOPS。
雖然啟動程序和目標(biāo)程序的?IP 地址可被視為?IT 流量，但如果不了解?I/O 流量指標(biāo)，這種流量定義就沒有什么價值。
即使在將來，以太網(wǎng)交換機也不可能監(jiān)控?I/O 性能，類似于?Cisco MDS 交換機光纖通道端口上的?SAN Analytics。這是因為以太網(wǎng)網(wǎng)絡(luò)攜帶數(shù)千個上層協(xié)議，每個協(xié)議都有不同的?TCP 和?UDP 端口號。增強以太網(wǎng)交換機以解碼存儲協(xié)議（FCoE、RoCE 等）并測量其性能，可能無法彌補進(jìn)行這些增強所需的額外成本。這對?Cisco MDS 交換機來說并不是一個挑戰(zhàn)，因為光纖通道是專門為存儲流量而構(gòu)建的。相比之下，以太網(wǎng)網(wǎng)絡(luò)則可傳輸各種流量，如第?1 章圖?1-11 所示。
Alternative Approaches
另一種方法是監(jiān)控主機或存儲陣列內(nèi)的存儲?I/O 性能。第?5 章將解釋這些細(xì)節(jié)以及如何使用?I/O 性能指標(biāo)來解決擁塞問題。雖然第?5 章重點介紹光纖通道，但其概念也適用于無損以太網(wǎng)網(wǎng)絡(luò)。
一些以太網(wǎng)交換機（如?Cisco Nexus 9000 交換機）會監(jiān)控?UDP 流的性能。但如前所述，這并不是對?I/O 流量的性能監(jiān)控，這些?UDP 流量中包含了?I/O 流量。因此，在對主機和存儲陣列進(jìn)行?I/O 性能監(jiān)控的同時，應(yīng)使用以太網(wǎng)交換機進(jìn)行?UDP 流量監(jiān)控。RoCEv2 目標(biāo)/控制器使用?UDP 端口?4791，這意味著發(fā)往目標(biāo)/控制器的數(shù)據(jù)包具有目標(biāo)端口?4791，而發(fā)往主機的數(shù)據(jù)包具有源端口?4791。UDP 端口?4420 分配給?NVMe/RoCE?？梢詫⒏鞣N來源的信息關(guān)聯(lián)起來，構(gòu)建自己的解決方案。
FCoE I/O Operations
FCoE 網(wǎng)絡(luò)中的?SCSI 和?NVMe I/O 操作與光纖通道?Fabric 相同。有關(guān)詳細(xì)信息，請參閱第?5 章。
但?SAN 分析功能僅適用于?Cisco MDS 交換機上的光纖通道端口。如果流量在端到端數(shù)據(jù)路徑中至少經(jīng)過一次具有分析功能的光纖通道端口，則仍可對其進(jìn)行檢查，以收集?I/O 流量指標(biāo)。即使流量通過網(wǎng)絡(luò)中其他位置的?FCoE 端口，這種方法也能發(fā)揮作用。一個典型的例子是思科?UCS 服務(wù)器，它在內(nèi)部使用?FCoE。當(dāng)相同的流量到達(dá)?MDS 上的光纖通道端口時，可以使用?SAN Analytics 對其進(jìn)行檢查，以收集?I/O 流量指標(biāo)。
RoCE I/O Operations
圖?7-11 顯示了?NVMe over RoCE 讀?I/O 操作。主機通過向目標(biāo)機發(fā)送命令包中的?RDMA_SEND 來啟動讀?I/O 操作。目標(biāo)機根據(jù)?I/O 操作請求的數(shù)據(jù)量和網(wǎng)絡(luò)的最大傳輸單元?(MTU)，通過?RDMA_WRITE 以一個或多個數(shù)據(jù)包的形式向主機發(fā)送數(shù)據(jù)（更多詳情請參見第?8 章?IP MTU 和?TCP MSS 考慮因素部分）。最后，當(dāng)目標(biāo)發(fā)送響應(yīng)包時，I/O 操作完成。
Figure 7-11?NVMe over RoCE read I/O operation
圖?7-12 顯示了?NVMe over RoCE 寫?I/O 操作。主機通過向目標(biāo)機發(fā)送命令包中的?RDMA_SEND，啟動寫?I/O 操作。然后，目標(biāo)機向主機發(fā)送?RDMA_READ 請求。接下來，主機根據(jù)?I/O 操作請求的數(shù)據(jù)量和網(wǎng)絡(luò)的?MTU，通過?RDMA_READ 響應(yīng)以一個或多個數(shù)據(jù)包的形式向目標(biāo)發(fā)送數(shù)據(jù)。最后，當(dāng)目標(biāo)機發(fā)送響應(yīng)包時，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 章的以下章節(jié)，為簡潔起見，此處不再贅述。
將第?5 章中的?I/O 操作和網(wǎng)絡(luò)流量模式一節(jié)與前一節(jié)進(jìn)行比較，可以發(fā)現(xiàn)流量模式之間有驚人的相似之處。因此，與網(wǎng)絡(luò)擁塞的相關(guān)性也很相似。對于讀取數(shù)據(jù)，SCSI 和?NVMe 使用讀?CMD，而?RDMA 則反向使用?RDMA_WRITE verb。同樣，在寫數(shù)據(jù)時，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é)解釋說，主機鏈路擁塞的主要原因是來自該主機的多個并發(fā)大容量讀取?I/O 操作。同樣，存儲鏈路擁塞的主要原因是存儲陣列請求的數(shù)據(jù)總量。
Detecting Congestion on a Remote Monitoring Platform
遠(yuǎn)程監(jiān)控平臺可同時監(jiān)控網(wǎng)絡(luò)中的所有端口，以提供全網(wǎng)單一窗口可視性。
請參閱第?3 章?"在遠(yuǎn)程監(jiān)控平臺上檢測擁塞?"一節(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é)簡要介紹用于檢測以太網(wǎng)擁塞的?Cisco Nexus Dashboard Insights。
要進(jìn)一步了解定制開發(fā)的用于檢測和排除無損以太網(wǎng)網(wǎng)絡(luò)擁塞故障的應(yīng)用程序，請參閱第?9 章，其中介紹了如何使用?UCS 流量監(jiān)控應(yīng)用程序?(UTM)。
第?3 章還介紹了?"監(jiān)控網(wǎng)絡(luò)流量的陷阱"。其中關(guān)于平均利用率和峰值利用率的小節(jié)也適用于無損以太網(wǎng)網(wǎng)絡(luò)。
Congestion Detection using Cisco Nexus Dashboard Insights
Cisco Nexus Dashboard Insights 以?1 秒的低粒度接收來自交換機和計算節(jié)點的指標(biāo)。然后，它使用基線、相關(guān)性和預(yù)測算法分析原始指標(biāo)，深入洞察流量模式。在擁塞檢測方面，Nexus Dashboard Insights 可檢測數(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
對于定制開發(fā)的應(yīng)用程序或腳本而言，指標(biāo)導(dǎo)出機制是一個重要的考慮因素。第?3 章?"指標(biāo)導(dǎo)出機制?"一節(jié)中解釋的大部分細(xì)節(jié)也適用于無損以太網(wǎng)網(wǎng)絡(luò)。
請?zhí)貏e注意第?3 章介紹的指標(biāo)輸出建議。使用命令行輸出和?SNMP 在歷史上很常見，但現(xiàn)在使用?API 已成為常態(tài)。對于大規(guī)模的低粒度度量導(dǎo)出，流式遙測是最佳選擇，而且正在被迅速采用。
Cisco Nexus Dashboard Fabric Controller 和?Nexus Dashboard Insights 默認(rèn)選擇最佳導(dǎo)出機制。
以下小節(jié)簡要介紹了?Cisco Nexus 9000 交換機上的指標(biāo)導(dǎo)出機制，不再重復(fù)第?3 章中的說明。
SNMP
表?7-3 提供了可檢測啟用?LLFC 和?PFC 的端口擁塞情況的指標(biāo)的?SNMP MIB。?
Note the following points:?請注意以下幾點：
1. Cisco Nexus 9000 交換機上的?PFC 計數(shù)器可由?CISCO-PFC-EXT-MIB 監(jiān)控，該?MIB 包含更多計數(shù)器，如?TxWait 和?RxWait，但表?7-3 沒有列出所有計數(shù)器，因為?Nexus 交換機在本文撰寫時不支持?TxWait 和?RxWait。雖然交換機可能會響應(yīng)?MIB 請求，但它們的值不會隨時間而改變。如果交換機類型支持?CISCO-PFC-EXT-MIB，它還可用于監(jiān)控?PFC 看門狗。
2. 需要注意的是，多年來，Cisco 設(shè)備上的?LLFC 和?PFC MIB 計數(shù)器一直受到某些固件版本和交換機型號執(zhí)行不力的影響。在依賴返回值之前，請驗證它們是否與交換機上的命令行輸出相匹配。根據(jù)返回值?0 進(jìn)行初步驗證是不夠的，因為盡管?0 是一個有效值，但它可能不會遞增。這將造成沒有擁塞的錯誤提示。
3. ?IF-MIB 包含接口速度、字節(jié)輸入和字節(jié)輸出，可用于計算利用率百分比。
4. 由于?PFC 是通過以太網(wǎng)交換機上的?QoS 實現(xiàn)的，因此監(jiān)控?CISCO-SWITCH-QOS-MIB 可提供每個隊列的指標(biāo)。
Streaming Telemetry
有關(guān)流遙測的詳細(xì)信息，請參閱第?3 章?"流遙測?"一節(jié)。Cisco Nexus 9000 交換機有以下額外注意事項：
1. Nexus 交換機可以從前面板數(shù)據(jù)端口導(dǎo)出指標(biāo)，從而實現(xiàn)低粒度指標(biāo)導(dǎo)出。在撰寫本文時，MDS 交換機只能從交換機的管理端口導(dǎo)出指標(biāo)。
2. Nexus 交換機支持?NetFlow 和?sFlow。不過，流式遙測可導(dǎo)出粒度更小的指標(biāo)。
3. Cisco Nexus 交換機上的軟件遙測功能可導(dǎo)出控制平面信息和接口指標(biāo)。
4. 此外，Nexus 交換機還支持硬件遙測，可導(dǎo)出粒度（根據(jù)交換機類型可低至?1 秒）的指標(biāo)：
a. 流統(tǒng)計數(shù)據(jù)導(dǎo)出?(SSX)，用于導(dǎo)出原始?ASIC 統(tǒng)計數(shù)據(jù)。
b. 流量表?(FT)，用于導(dǎo)出流量級別信息。
c. 流量表事件?(FTE)，用于在滿足配置條件時觸發(fā)通知。
5. Nexus 交換機支持帶內(nèi)網(wǎng)絡(luò)遙測?(INT)，用于監(jiān)控丟棄的數(shù)據(jù)包和擁塞的隊列。
網(wǎng)絡(luò)遙測和分析領(lǐng)域發(fā)展迅速。我們建議您參考文檔和發(fā)行說明，了解產(chǎn)品在您的環(huán)境中的功能以及如何使用它們。
審核編輯：黃飛
?
工商網(wǎng)監(jiān)
評論