本節將從學術角度解釋如何計算無損以太網鏈路的headroom大小。該解釋基于IEEE 802.1Qbb 優先級流量控制標準。這對好奇的讀者來說是很好的信息,但實際上,由于兩個關鍵原因,在您的環境中應始終遵循設備供應商的建議。首先,多個組件取決于實施情況,而供應商不會公開分享這些細節。其次,實際解決方案必須通過認證,并得到供應商的支持。
長途鏈路的暫停閾值
本節使用以下基本概念:
它是傳輸一個比特所需的時間。它是比特率的倒數。例如,10 GbE 端口的BT為1/10,000,000,000 秒或0.1 納秒,100 GbE 端口的BT 為0.01 納秒。
它是傳輸512 比特所需的時間。換句話說,就是512 BT。
以太網的幀間間隔為12 個字節。傳輸需要96 個字節。
以太網幀以7 個字節的preamble和1 個字節的SFD 開始。這8 個字節通常不計入1522 字節的以太網幀大小中。前言和SFD 的總傳輸時間為64 BT。
如圖7-2 所示,流量接收器的headroom應足夠大,以容納下列延遲因素下的幀。
Figure 7-2Worst-case delay for calculating the headroom for PFC.
1.傳輸最大長度幀時產生的延遲(D-Max-Frame-Len): 流量接收器上的隊列達到了暫停閾值。但在流量接收器上,一個幀剛剛開始傳輸。暫停幀不會搶先傳輸另一個幀。因此,暫停幀的傳輸會延遲到其他幀傳輸完畢。這一延遲占所有流量類別的最大幀長。考慮到最大幀長為9216 字節,這一延遲可達73728 BT(9216 x 8)。再加上IFG 的96 BT 以及preamble和SFD 的64 BT,總延遲可達73888 BT。
2.傳輸暫停幀(D-暫停)導致的延遲:暫停幀的大小為64 字節,因此傳輸需要512 BT。加上IFG 的96 BT 和preamble及SFD 的64 BT,總延遲為672 BT。
3. 這是低層在傳輸和接收幀時造成的延遲。以太網標準規定了該接口延遲的上限。例如,10 GbE 的最大延遲為8192 BT,25 GbE 為6144 BT,40 GbE 為24576 BT,100 GbE 為122880 BT。這些值包括發送和接收延遲。在相同的以太網速度下有不同的實現方式,每種實現方式的接口延遲可能不同。有關詳細信息,請參閱IEEE 標準以太網802.3 并搜索延遲約束。
4.這是暫停幀的比特從流量接收器傳播到流量發送器所造成的延遲。它由傳輸介質中的光速決定。在光纜中,光速約為200,000 千米/秒。因此,1 米長的光纜會造成5 納秒的延遲。它可以通過乘以端口速度轉換為比特時間。例如,對于10 GbE 端口,1 米長的光纜會造成50 BT 的延遲,100 米長的光纜會造成5000 BT 的延遲。
5.接收暫停幀的接口延遲(D-Intf): This is the same as explained in (3) on the receiver of the Pause frame (traffic-sender).這與(3) 中對暫停幀接收方(流量發送方)的解釋相同
6.流量發送方(暫停接收方)需要一些時間來處理暫停幀,并在收到暫停幀后實際暫停無損類中的流量。這一響應延遲取決于實施情況,但以太網標準對其設置了上限。對于10 GbE,這一延遲可達60 個暫停quanta(30720 BT)。對于25 GbE,則為80 個暫停quanta(40960 BT)。對于40 GbE,則為118 個暫停quanta(60416 BT)。100 GbE 為394 個暫停quanta(201728 BT)。對于400 GbE,是905 個暫停quanta(463360 BT)。更多詳情,請參閱IEEE 以太網標準802.3,MAC 控制PAUSE 操作部分(附件31B),以及PAUSE 操作的定時注意事項小節。
7.在無損幀類中傳輸最大長度幀引起的延遲(D-Max-No-Drop-Frame-Len): 就在流量發送方暫停無損類流量之前,可能會開始傳輸幀。該幀的傳輸不會中斷,因此會導致額外的延遲。流量接收器上的D-Max-Frame-Len 與(1) 中解釋的D-Max-Frame-Len 不同,D-Max-Frame-Len 考慮了任何流量類別中的最大幀長,而流量發送器上的這一延遲只需考慮不丟棄類別中的最大幀長。這是因為流量接收器只需為其已發送暫停幀的無丟包類別中的幀預留headroom。對于FCoE 流量,無損類的最大幀長約為2300 字節。對于RoCE,可為約2 KB 或4 KB。根據應用的定義,這些值甚至可以更小。在此,我們使用2300 字節,這將導致18400 BT 的延遲。加上IFG 的96 BT 以及前導碼和SFD 的64 BT,總延遲可達18560 BT。
8.在無損類中傳輸幀的接口延遲(D-Intf): This is the same as explained in (3)這與(3) 中的解釋相同.
9.Cable delay (D-Cable):這與(4) 中的解釋相同。
10.Interface delay to receive the frame in the no-drop class (D-Intf): 這與(3) 中的解釋相同。
除了圖7-2 所示的延遲外,由于MACsec(IEEE 802.1AE)和其他實施延遲,可能會出現更多延遲。這些延遲統稱為高層延遲,在本節中忽略不計。但這也解釋了為什么在使用MACsec 時需要額外的考慮,以及為什么Cisco Nexus 交換機在撰寫本文時沒有聲稱支持帶有MACsec 的PFC。這并不意味著當啟用MACsec 時,PFC 在Cisco Nexus 交換機上不起作用。這只是意味著思科尚未正式認證它。
總延遲(D-Total)是圖7-2 所示所有延遲值的總和
D-Total = D-Max-Frame-Len + D-Pause + D-Intf + D-Cable + D-Intf + D-Resp + D-Max-No-Drop-Frame-Len + D-Cable
在這里,接口延遲(D-Intf) 只計算兩次,而不是四次,因為它們的值包含發送和接收延遲。
考慮到任何流量類別中的最大幀長度為9216 字節,無丟棄流量類別中的最大幀長度為2300 字節,電纜長度為100 米,以及10 GbE 端口,總延遲如下:
D-Total = 73888 + 672 + 8192 + 5000 + 8192 + 30720 + 18560 + 5000 = 150224 BT
這意味著流量接收器應具有吸收多達150224 BT 的幀的headroom。在10 GbE 的情況下,這相當于18.778 KB 的headroom。
但這一計算還沒有結束,因為流量接收器上的緩沖區是按單元排列的。
Buffers and Cells
Cisco Nexus 交換機將緩沖區組織成單元。每個單元最多可存儲固定數量的字節。最常見的單元大小為208 字節、416 字節和624 字節。具體數值取決于交換機的類型,用戶無法更改。可以使用show hardware internal buffer info pkt-stats input 命令來驗證Cisco Nexus 交換機的單元大小。Cisco Nexus 93180YC-FX 上該命令的輸出請參見例7-3。
Example 7-3Finding the cell size on Cisco Nexus switches.在Cisco Nexus 交換機上查找單元大小。
switch# show hardware internal buffer info pkt-stats input
Instance 0
=======================================================================
Ingress Queue Info: 1 cell = 416 bytes, Total cells: 25976,
Instant cell usage: 0, Remaining cell: 25976
一個單元只供一個幀使用。如果幀較大,則需要多個單元。但單元中的任何剩余空間都不會被使用,而是成為開銷。例如,一個64 字節的幀消耗一個單元格。假設單元大小為416 字節,則剩余的352 字節將成為開銷。同樣,一個2300 字節的幀會完全占用5 個416 字節的單元,而第六個單元只占用220 字節。第六個單元中剩余的196 字節成為開銷。
這意味著前面計算的18.778 KB headroomk必須考慮單元大小和開銷。假設最小幀大小為64 字節,單元大小為416 字節,由于每個幀需要消耗416 字節的緩沖區,因此需要消耗6.5 (416 ÷64) 倍的緩沖區空間。因此,18.778 KB 相當于122 KB(18.778 x 6.5)的流量接收器headroom。
隨著幀大小的增加,這一乘法系數也會降低。例如,512 字節的幀大小消耗兩個416 字節的單元格,乘法系數為1.62((2 x 416)÷512)。同樣,1024 字節的幀大小消耗三個416 字節的單元格,乘法系數為1.21((3 x 416)÷1024),以此類推。
請注意以下幾點:
1. 本節的計算考慮了最壞情況下的數值,只是為了從理論上解釋這一概念。實際上,并非所有幀的大小都很大。此外,本節中考慮的接口延遲(D-Intf) 和響應時間(D-Resp) 值是標準規定的上限,但實際值要低得多。
2. 從另一個角度看,這些計算的責任由制造商和用戶分擔。制造商更了解接口延遲(D-Intf) 和響應延遲(D-Resp),而用戶則更了解電纜長度和最大幀長度(根據流量情況而定)。
因此,在未咨詢設備制造商的情況下,本節中的學術解釋不應直接用于生產環境。
下一節提供了一種更簡單實用的PFC headroom計算方法。
實用的方法
如前所述,Cisco Nexus 9000 默認為100 米電纜長度配置"暫停閾值"和"恢復閾值"。無論電纜長度如何,首先要啟用PFC,找到100 米電纜的默認值。接下來,要更改長距離鏈路的閾值,唯一的因素是考慮電纜延遲(D -cable)。圖7-2 中解釋的所有其他因素與計算100 米電纜的"暫停閾值"和"恢復閾值"默認值時所考慮的因素相同。
以Cisco Nexus 93180YC-FX 上的FCoE 端口為例進行說明。10 GbE 端口的默認FCoE 策略配置了以下值:
Buffer-size — 104000 bytes.
Pause-threshold — 20800 bytes.
Resume-threshold — 19136 bytes.
因此,headroom為83200 字節(104000 - 20800)。這適用于短距離鏈路。
根據Cisco 文檔,對于10 千米鏈路,10 GbE 端口的FCoE 策略應修改為使用以下值:
Buffer-size — 166400 bytes.
Pause-threshold — 20800 bytes.
Resume-threshold — 19136 bytes.
因此,headroom為145600 字節(166400 - 20800)。與100 米電纜的headroom(145600 - 83200)相比,增加了62400 字節。從100 米鏈路到10 千米鏈路的headroom增加不能僅僅用電纜延遲來解釋,主要原因有兩個。首先,100 米的默認閾值是超額預留的,因為它們可用于更長的鏈路。其次,交換機架構的內部細節不為人知。
如果思科決定在更遠距離的鏈路(如15 公里)上支持FCoE,那么緩沖區大小的值就可以推算出來。如前所述,1 米電纜會增加5 毫微秒的延遲。因此,5 千米電纜會增加25000 毫微秒的延遲。在這段時間內,10 GbE 端口可傳輸250000 比特或31250 字節。考慮到電纜的往返延遲,該值必須加倍,從而產生62500 字節的額外headroom。因此,對于15 千米FCoE 鏈路,緩沖區大小可配置為166400 + 62500 = 228900 字節。需要注意的是,思科在撰寫本文時并不支持這種配置,而且也不考慮單元大小。這里只是解釋概念以及如何以更實用的方式調整這些閾值。
另一個考慮因素是,隨著端口速度的增加,對headroom和footroom的要求也會增加。此外,如果在交換機上配置了許多長距離無損以太網鏈路,為所有鏈路預留緩沖區可能會超出交換機有限的緩沖區容量。如果沒有足夠的緩沖區來啟動長途鏈路,Cisco Nexus 交換機會生成緩沖區分配失敗信息,如例7-4 所示。
Example 7-4思科Nexus 交換機上的入口緩沖區分配失敗
switch(config-if)# interface ethernet1/8
switch(config-if)# service-policy type queuing input ld_10G_fcoe_in_que_policy
switch(config-if)# no shutdown
2022 Oct 31 0721 HW1 %$ VDC-1 %$ %ACLQOS-SLOT1-2-ACLQOS_FAILED: ACLQOS
failure: Ingress buffer allocation failed for interface Ethernet1/8
要解決這個問題,可以減少該交換機上配置為PFC 的端口數量、減小其緩沖區大小,或兩者結合使用,這樣基本上就減少了預留緩沖區。
查找端口是否有足夠的headroom和footroom:
1. headroom不足的端口會在無損流量的入口處丟棄幀并發送暫停幀。換句話說,Tx 暫停和Rx 數據包丟棄同時增加就是headroom不足的癥狀。
2. footroom不足的端口可能會成為擁塞源,報告較低的入口利用率,并發送暫停幀。所有這些情況同時都是footroom不足的癥狀。
如果緩沖區大小和閾值配置正確,PFC 機制應能防止數據包丟棄,并達到預期的鏈路利用率。
以太網暫停與光纖通道B2B 信元的比較
雖然以太網暫停幀和光纖通道B2B 信元的操作方式不同,但它們都是通過通知直接連接的發送方放慢速度,以避免接收方的緩沖區耗盡,從而實現逐跳流量控制。
以下幾點對以太網暫停和光纖通道B2B 信元進行了比較:
1. Initial exchange:光纖通道B2B 信元號在鏈路初始化期間與直接連接的鄰居進行通信。相比之下,以太網流量控制不會與直接連接的鄰居交換緩沖區數量,盡管DCBX 可能會交換其他信息,如需要無損行為的流量類型。
2. Link utilization: 光纖通道R_RDY 不影響鏈路利用率,因為它們是基元,在兩個幀之間使用填充字。相反,暫停是一個正式的以太網幀,帶有報頭、填充和CRC。暫停幀的大小為64 字節。因此,當大量發送暫停幀時,會增加鏈路利用率。在后面有關PFC 風暴的章節中,將解釋每秒在鏈路上發送一百萬個暫停幀的情況。這將導致512 Mbps 的吞吐量(64 字節x 8 x 1000,000)。雖然這種情況并不常見,但當許多暫停幀在鏈路上流動時,還是要注意這方面的問題。
3. Duration exchange: 以太網暫停幀傳達發送器必須停止傳輸的持續時間,盡管該持續時間很少傳達流量暫停的實際時間。光纖通道R_RDY 不傳遞持續時間。
4. When they are sent:光纖通道R_RDY 表示流量接收器準備好接收一個幀。而以太網暫停幀則表示發送器應停止傳輸或立即開始傳輸的持續時間。
5. How many: 光纖通道R_RDY 對于鏈路的健康運行非常重要。換句話說,FC 鏈路上出現大量R_RDY 是一個好兆頭。相比之下,發送以太網暫停幀是為了停止流量。雖然(未)暫停幀也會恢復流量,但它只是在暫停幀之后。換句話說,鏈路上的暫停幀越少,鏈路就越健康。
6. Direction: 光纖通道端口上的Tx B2B 信元數不足表示出口擁塞。相反,以太網端口上的Tx 暫停表示入口擁塞。同樣,光纖通道端口上的Rx B2B 點數不足表示入口擁塞,而以太網鏈路上的Rx 暫停表示出口擁塞。
7. Configuration: 光纖通道B2B 信元是以數字為單位配置的,無論幀大小如何,每個信元都用于一個幀。相反,以太網暫停閾值和恢復閾值是以字節為單位配置的,因此在更改配置時應考慮幀的大小。大多數短距離的數據中心內鏈路無需更改配置。但對于長距離鏈路,必須正確配置B2B 信元或暫停閾值。這里,暫停閾值和恢復閾值不應與暫停量相混淆,大多數實施方案不允許更改暫停量。
8. Troubleshooting: 當光纖通道端口發送R_RDY 時,這是一個好兆頭,而當以太網端口發送暫停幀時,則表示擁塞。這兩種機制的基本區別是無損以太網網絡擁塞檢測和故障排除的基礎。
9. Scope: 兩者都是逐跳流量控制機制,即都在直接連接的設備之間運行。
10. Distance:在光纖通道中,如果距離、速度和平均幀大小的B2B 信元不足,那么鏈路只會在低于最大容量的情況下運行,而不會出現任何錯誤。在無損以太網中,如果距離、速度和平均幀大小的余量不足,連接端口上就會出現丟幀,從而導致終端設備出現I/O 錯誤。如果余量不足,那么在出現擁塞時,鏈路可能會表現不佳。重要的一點是,光纖通道和無損以太網都必須考慮到距離問題。
Priority Flow Control
根據IEEE 802.3x 標準,最初的暫停幀可在整個鏈路上進行流量控制(LLFC),但這并不能滿足在同一鏈路上傳輸無損和有損流量的要求。
PFC 通過增強暫停幀格式,為八個流量類別提供量值,從而解決了這一問題。如圖7-3 所示,PFC 暫停幀還包含一個類別啟用矢量(Class Enable Vector),該矢量通過打開特定流量類別的位來表示量值是否對該類別有效。類啟用向量未啟用的其他類將忽略暫停幀。因此,PFC 也被稱為基于類別的流量控制(CBFC) 或每優先級暫停(PPP)。
Figure 7-3PFC Pause frame format.
Mapping Traffic Classes to Pause Frame Class Enable Vector
如果不將"類別啟用矢量"映射到流量類別,暫停幀接收器就無法知道要停止哪些流量。試想一下,當流量接收方發送PFC 暫停幀以停止A 類流量時,流量發送方卻不知道入口PFC 暫停幀中的"類啟用矢量"與A 類流量之間的映射關系,或者映射關系有誤。這將導致丟棄無損流量。
PFC 要想成功運行,以下因素很重要:
1. 定義將流量類別映射到PFC 暫停幀中類別啟用向量的方案。
2. 在終端設備和交換機上統一應用這一方案。通常情況下,DCBX 或軟件定義網絡解決方案可以簡化這一步驟。
本節重點討論定義映射方案的第一個因素。應用配置不在本文討論范圍之內。請參考環境中的產品文檔和參考資料部分的資源。
從概念上講,無損流量類別可以包含任何類型的流量,只要發送方和接收方同意相同的分類,并有辦法將其與其他流量進行分類。但實際上,在撰寫本文時,有兩種類型的映射很常見。
1. Layer 2 PFC: PFC 的最初用例是允許無損FCoE 流量與有損流量在同一鏈路上匯聚。但必須對流量進行虛擬分離以進行分類。為了實現虛擬分離,FCoE 流量被分配到一個專用VLAN,即FCoE VLAN。VLAN 標頭包含用于對流量進行分類的三個比特(優先級代碼點),這些比特被唯一映射到PFC 暫停幀中的類啟用向量。當RoCE 流量需要無損第2 層網絡時,這種第2 層PFC 也可用于RoCE 流量。
2. Layer 3 PFC: 隨著數據中心架構的發展,路由IP 網絡變得越來越普遍,這主要是因為其規模得到了改善。但要在IP 路由網絡中使用PFC,基于以太網VLAN 標頭的流量映射是不夠的,因為VLAN 標頭在每個第3 層跳變,在某些情況下,VLAN 標頭甚至可能不存在。解決方案是將類啟用向量(在PFC 暫停幀中)映射到在OSI 模型第3 層工作的流量分類方案。IPv4 和IPv6 報頭包含DSCP 字段,該字段廣泛用于服務質量(QoS),也可用于PFC。在撰寫本文時,RoCEv2 是第3 層PFC 的主要用例,但同樣的實現也可用于需要無損第3 層網絡的其他協議。
第2 層PFC 可在OSI 第2 層域內實現無損流量傳輸,而第3 層PFC 則可通過IP 路由網絡實現無損流量傳輸。下文將詳細介紹這些映射方案。
Layer 2 Priority Flow Control
如圖7-4 所示,在OSI 模型的第2 層,通過添加IEEE 802.1Q VLAN 標頭將流量分配到不同的VLAN。該VLAN 標頭包含一個3 位優先級碼點(PCP)字段,允許8 個獨特的流量類別。PCP 通常稱為服務等級(CoS)。
Figure 7-4數據幀的以太網VLAN CoS 與暫停幀中的類啟用向量之間的關系
PFC 暫停幀包含以下值:
Class Enable Vector: 這是一個8 位字段,表示暫停幀適用于哪個(些)類別。
Quanta values: 這8 個16 位值與每個可能的流量類別相對應。當"類別啟用向量"中的位被打開時,相應的quanta在該暫停幀中有效。
以太網VLAN CoS 字段與PFC 暫停幀的類啟用向量之間的映射可啟用第2 層PFC。
注意以下幾點
1. VLAN 由IEEE 802.1Q 報頭中的12 位VLAN ID 字段唯一標識。這就允許多達4096 個VLAN。但只能有8 個流量類別(CoS)。因此,在技術上可以為多個VLAN 分配相同的CoS,但這種方法會增加復雜性,在存儲網絡中應避免使用。換句話說,將所有FCoE 或RoCE 流量分配到一個VLAN(比方說VLAN 100),將該VLAN 中的所有流量標記為一個唯一的CoS(比方說3),將其他流量保留在其他VLAN 中,不要將CoS 3 分配給任何其他VLAN。此外,避免為FCoE 或RoCE 流量使用多個VLAN,以保持簡單。
2. PFC 暫停幀中的類啟用矢量有8 位。為了表示量子對CoS N 有效,類啟用矢量會啟用右起第N 位(最小有效位)。例如,00001000 的類啟用矢量表示該暫停幀適用于CoS 3,00011000 的類啟用矢量表示該暫停幀適用于CoS 3 和CoS 4。
3. 成功的第2 層PFC 需要兩個映射。
a. VLAN ID 和CoS:這些值包含在數據幀的以太網頭中。雖然這不是真正的技術要求,但正如所解釋的那樣,這種映射簡化了部署,并有助于保持終端設備和交換機配置的一致性。
b. CoS 和Class Enable Vector:CoS 包含在數據幀的以太網VLAN 標頭中,而Class Enable Vector 則包含在PFC 暫停幀中。數據幀和暫停幀的流動方向相反。這就解釋了為什么發送方和接收方之間的配置必須同步,而且應避免更改供應商提供的默認CoS 值(如FCoE 的CoS 3),以實現一致的實施。
-
以太網
+關注
關注
40文章
5460瀏覽量
172724 -
接收器
+關注
關注
14文章
2479瀏覽量
72212 -
PFC
+關注
關注
47文章
977瀏覽量
106394 -
存儲網絡
+關注
關注
0文章
31瀏覽量
8139
原文標題:以太網存儲網絡的擁塞管理連載(二)
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
以太網存儲網絡的擁塞管理連載方案(三)
![<b class='flag-5'>以太網</b><b class='flag-5'>存儲</b><b class='flag-5'>網絡</b>的<b class='flag-5'>擁塞</b><b class='flag-5'>管理</b><b class='flag-5'>連載</b><b class='flag-5'>方案</b>(三)](https://file1.elecfans.com/web2/M00/C2/A2/wKgaomXeif2AawuhAABO1n1_j0I501.png)
以太網和工業以太網的不同
工業以太網的實現方案和現場實際應用情況
基于BOOTP的工業以太網IP儀表的智能化管理策略
![基于BOOTP的工業<b class='flag-5'>以太網</b>IP儀表的智能化<b class='flag-5'>管理</b>策略](https://file.elecfans.com/web2/M00/48/D9/pYYBAGKhtCiALDMVAAASbQwvyVQ020.jpg)
以太網的分類及靜態以太網交換和動態以太網交換、介紹
以太網光模你了解多少
TOSUN 車載以太網仿真測試解決方案
![TOSUN 車載<b class='flag-5'>以太網</b>仿真測試解決<b class='flag-5'>方案</b>](https://file.elecfans.com/web2/M00/40/07/pYYBAGJrUk2AaMaTAAAQONQtdzo461.jpg)
評論