Ethernet sans perte pour le stockage : DCB, PFC, ECN

Ethernet perd des trames en cas de congestion ; les protocoles de stockage conçus pour Fibre Channel ou RDMA supposent que rien n’est jamais perdu. Le Data Center Bridging (DCB) comble cet écart avec un contrôle de flux et une allocation de bande passante par priorité, et RoCE ajoute par-dessus une signalisation de congestion. Le résultat n’est sans perte qu’à hauteur de sa pire liaison : une optique limite qui perd une trame sur un million est un incident de stockage. Cette page explique les mécanismes et les traduit en exigences de couche physique.

La boîte à outils DCB

Norme	Nom	Rôle
IEEE 802.1Qbb	PFC — priority-based flow control	trames de pause par classe de trafic (0–7) : un récepteur congestionné arrête une classe sans arrêter le port
IEEE 802.1Qaz	ETS — enhanced transmission selection	parts de bande passante garanties par classe (par ex. 50 % stockage, 50 % LAN)
IEEE 802.1Qaz	DCBX — DCB exchange	négociation des réglages PFC/ETS entre commutateur et NIC, basée sur LLDP
IEEE 802.1Qau	CN — congestion notification	rarement déployé
RFC 3168 + DCQCN	marquage ECN + contrôle de débit	le commutateur marque les paquets quand les files se remplissent ; les NIC RoCE ralentissent le flux avant que le PFC soit nécessaire

Comment RoCE reste sans perte

Le trafic stockage/RDMA est marqué avec une priorité dédiée (souvent 3 ou 4) via DSCP ou 802.1p.
Le PFC n’est activé que pour cette priorité sur chaque port le long du chemin, avec un headroom de tampon dimensionné pour le débit de la liaison et la longueur du câble (octets en transit).
Les seuils ECN marquent les paquets tôt ; les NIC exécutent DCQCN pour réduire leur débit, si bien que le PFC ne se déclenche qu’en dernier recours.
ETS garantit sa bande passante à la classe stockage sous charge LAN.
DCBX maintient la cohérence des réglages entre NIC et commutateur ; une incohérence casse silencieusement le caractère sans perte.

FC et InfiniBand obtiennent le même résultat par défaut grâce aux crédits sur chaque liaison ; Ethernet doit le configurer, le vérifier et le surveiller (bases du protocole FC, transport InfiniBand).

Ce qui peut mal tourner

Problème	Effet	Détection
PFC non activé sur un saut / mauvaise priorité	pertes sous charge ; retransmissions RDMA ; pics de latence	compteurs de pause à zéro là où ils ne devraient pas l’être ; pertes sur la classe
Tempête de PFC	un récepteur bloqué met en pause l’amont indéfiniment ; la congestion se propage à tout le fabric	inondation de trames de pause ; compteurs de watchdog
Interblocage PFC	dépendance cyclique de tampons dans les fabrics Clos ; tout le trafic de la classe s’arrête	nécessite une détection d’interblocage / un watchdog pour le rompre
Headroom trop faible pour des câbles/optiques longs	pertes malgré le PFC	pertes avec compteurs de pause actifs
Seuils ECN incorrects	trop tôt : perte de débit ; trop tard : le PFC déborde	compteurs de marques ECN, compteurs de CNP sur les NIC
Erreurs physiques sur une liaison (CRC, FEC non corrigible)	trames perdues qu’aucun contrôle de flux ne peut récupérer	compteurs d’erreurs de port, compteurs FEC — métriques VDM et FEC

iSCSI sans DCB

iSCSI fonctionne sur TCP et survit à la perte, mais le paie en latence et en retransmissions. Bonnes pratiques indépendamment du DCB :

des VLAN/sous-réseaux dédiés par fabric, deux fabrics, MPIO sur les hôtes ;
des trames jumbo (MTU 9000) de bout en bout ;
pas de sursouscription entre initiateurs et cibles ; liaisons montantes 25G/100G dimensionnées pour la baie ;
FEC activé sur chaque liaison 25G et plus ; compteurs CRC à zéro ;
éventuellement le PFC sur la classe iSCSI pour lisser les micro-rafales (de nombreuses baies le recommandent).

Exigences de couche physique

Exigence	Pourquoi	Pratique
FEC activé et assorti sur chaque liaison 25G et plus	RoCE ne tolère pas le BER brut de voies 25G/50G non protégées	FEC et link training
CRC et FEC non corrigible = 0	chaque trame perdue bloque une file	alerte sur tout incrément
Puissance Rx dans la fenêtre avec marge	une optique limite produit des rafales d’erreurs sous l’effet de la température	puissance Rx et bilan de liaison
Débit/duplex/AN cohérents	le DAC nécessite AN + link training aux deux extrémités	cuivre et DAC
Longueur de câble compatible avec les hypothèses de headroom	le headroom est calculé à partir des octets en transit	préférer le DAC en baie, SR/AOC dans la rangée, DR/LR entre salles
Identité acceptée par le NIC et le commutateur	une optique rejetée retombe sur pas de liaison ou un débit réduit	verrouillage constructeur

Liste de contrôle pour la surveillance

Par port : trames de pause envoyées/reçues par priorité, marques ECN, pertes par classe, CRC, FEC corrigé/non corrigible, battements de liaison.
Par NIC : CNP envoyés/reçus, retransmissions, paquets hors séquence, timeouts.
Par optique : tendances de puissance Rx/Tx et de température (surveillance).
Corrélez les pics de latence de queue du stockage avec ce qui précède — la couche physique est coupable plus souvent que la baie.

Dans CodingBox

Un fabric sans perte est construit à partir d’une optique ordinaire, simplement tenue à un niveau d’exigence plus élevé. L’inspection à l’entrée sur le banc — identité, sommes de contrôle, DDM en direct comparé aux valeurs typiques, référence enregistrée — permet d’écarter les modules limites d’un fabric où une seule mauvaise liaison coûte à une application son SLA de latence (Check transceiver, DDM).

Où se situent le PFC et l’ECN parmi les autres mécanismes de forwarding, et comment les erreurs de couche physique s’y manifestent : bases du forwarding.

Si vous trouvez une inexactitude ou une erreur dans cet article, sélectionnez le passage concerné et appuyez sur Ctrl+Enter pour .