Ethernet lossless per lo storage: DCB, PFC, ECN

Ethernet scarta i frame quando è congestionata; i protocolli di storage costruiti per Fibre Channel o RDMA presumono che non venga mai scartato nulla. Data Center Bridging (DCB) colma il divario con controllo di flusso per priorità e allocazione della larghezza di banda, e RoCE aggiunge sopra una segnalazione di congestione. Il risultato è lossless solo quanto il suo collegamento peggiore: un’ottica al limite che scarta un frame su un milione è un incidente di storage. Questa pagina spiega i meccanismi e li traduce in requisiti del livello fisico.

Gli strumenti DCB

Standard	Nome	Cosa fa
IEEE 802.1Qbb	PFC — controllo di flusso basato su priorità	frame di pausa per classe di traffico (0–7): un ricevitore congestionato ferma una classe senza fermare la porta
IEEE 802.1Qaz	ETS — selezione avanzata della trasmissione	quote di larghezza di banda garantite per classe (per esempio 50 % storage, 50 % LAN)
IEEE 802.1Qaz	DCBX — scambio DCB	negoziazione basata su LLDP delle impostazioni PFC/ETS tra switch e NIC
IEEE 802.1Qau	CN — notifica di congestione	raramente implementato
RFC 3168 + DCQCN	marcatura ECN + controllo della velocità	lo switch marca i pacchetti quando le code crescono; le NIC RoCE rallentano il flusso prima che serva il PFC

Come RoCE resta lossless

Il traffico storage/RDMA è marcato con una priorità dedicata (spesso 3 o 4) tramite DSCP o 802.1p.
Il PFC è abilitato solo per quella priorità su ogni porta lungo il percorso, con l’headroom del buffer dimensionato per la velocità del collegamento e la lunghezza del cavo (byte in transito).
Le soglie ECN marcano i pacchetti in anticipo; le NIC eseguono DCQCN per ridurre la propria velocità, così il PFC scatta solo come ultima risorsa.
ETS garantisce alla classe storage la propria larghezza di banda sotto carico LAN.
DCBX mantiene coerenti le impostazioni di NIC e switch; le discrepanze compromettono silenziosamente il funzionamento lossless.

FC e InfiniBand ottengono lo stesso risultato con i crediti su ogni collegamento per impostazione predefinita; su Ethernet va configurato, verificato e monitorato (Nozioni di base del protocollo FC, Trasporto InfiniBand).

Cosa può andare storto

Problema	Effetto	Rilevamento
PFC non abilitato su un hop / priorità sbagliata	drop sotto carico; RDMA ritrasmette; picchi di latenza	contatori di pausa a zero dove non dovrebbero esserlo; drop sulla classe
Tempesta PFC	un ricevitore bloccato mette in pausa a monte indefinitamente; la congestione si propaga in tutta la fabric	flooding di frame di pausa; contatori watchdog
Deadlock PFC	dipendenza ciclica del buffer nelle fabric Clos; tutto il traffico della classe si ferma	serve il rilevamento del deadlock o un watchdog per interromperlo
Headroom insufficiente per cavi/ottiche lunghi	drop nonostante il PFC	drop con contatori di pausa attivi
Soglie ECN sbagliate	troppo presto: perdita di throughput; troppo tardi: flooding di PFC	contatori dei marchi ECN, contatori CNP sulle NIC
Errori fisici su un collegamento (CRC, FEC non correggibile)	frame persi che nessun controllo di flusso può recuperare	contatori di errore della porta, contatori FEC — Metriche VDM e FEC

iSCSI senza DCB

iSCSI funziona su TCP e sopravvive alla perdita, ma la paga in latenza e ritrasmissioni. Buona pratica indipendentemente dal DCB:

VLAN/subnet dedicate per fabric, due fabric, MPIO sugli host;
frame jumbo (MTU 9000) end-to-end;
nessuna oversubscription tra initiator e target; uplink 25G/100G dimensionati per l’array;
FEC attivo su ogni collegamento 25G+; contatori CRC a zero;
facoltativamente PFC sulla classe iSCSI per smorzare i micro-burst (molti array lo raccomandano).

Requisiti del livello fisico

Requisito	Perché	Pratica
FEC abilitato e corrispondente su ogni collegamento 25G+	RoCE non tollera il BER grezzo di lane 25G/50G non protette	FEC e link training
CRC e FEC non correggibile = 0	ogni frame perso blocca una coda	avviso su qualsiasi incremento
Potenza Rx dentro la finestra con margine	le ottiche al limite producono raffiche di errori al variare della temperatura	Potenza Rx e bilancio del collegamento
Velocità/duplex/AN coerenti	il DAC richiede AN + link training su entrambe le estremità	Rame e DAC
Lunghezza del cavo entro le ipotesi di headroom	l’headroom si calcola dai byte in transito	preferisci DAC in rack, SR/AOC in fila, DR/LR tra sale
Identità accettata da NIC e switch	le ottiche rifiutate ripiegano su nessun collegamento o velocità ridotta	Blocco del produttore

Checklist di monitoraggio

Per porta: frame di pausa inviati/ricevuti per priorità, marchi ECN, drop per classe, CRC, FEC corretti/non correggibili, flap del collegamento.
Per NIC: CNP inviati/ricevuti, ritrasmissioni, fuori sequenza, timeout.
Per ottica: andamento di potenza Rx/Tx e temperatura (Monitoraggio).
Correla i picchi di latenza di coda dello storage con quanto sopra — il livello fisico è colpevole più spesso dell’array.

In CodingBox

Una fabric lossless è costruita con ottiche ordinarie che vengono semplicemente tenute a uno standard più alto. L’ispezione in ingresso sul banco — identità, checksum, DDM in tempo reale confrontato con i valori tipici, baseline memorizzata — è il modo in cui i moduli al limite vengono tenuti fuori da una fabric dove un collegamento difettoso costa a un’applicazione il suo SLA di latenza (Check transceiver, DDM).

Dove si collocano PFC ed ECN tra gli altri meccanismi di forwarding, e come gli errori del livello fisico vi emergono: Nozioni di forwarding.

Se trovi un’imprecisione o un errore in questo articolo, seleziona il passaggio corrispondente e premi Ctrl+Enter per .