Ethernet sin pérdidas para almacenamiento: DCB, PFC, ECN

Ethernet descarta frames cuando hay congestión; los protocolos de almacenamiento construidos para Fibre Channel o RDMA asumen que nunca se descarta nada. Data Center Bridging (DCB) cierra esa brecha con control de flujo por prioridad y asignación de ancho de banda, y RoCE añade señalización de congestión encima. El resultado es tan «sin pérdidas» como su peor enlace: una óptica al límite que descarta un frame entre un millón ya es un incidente de almacenamiento. Esta página explica los mecanismos y los traduce en requisitos de capa física.

El conjunto de herramientas de DCB

Estándar	Nombre	Qué hace
IEEE 802.1Qbb	PFC — priority-based flow control	frames de pausa por clase de tráfico (0–7): un receptor congestionado detiene una clase sin detener el puerto
IEEE 802.1Qaz	ETS — enhanced transmission selection	cuotas de ancho de banda garantizadas por clase (por ejemplo, 50 % almacenamiento, 50 % LAN)
IEEE 802.1Qaz	DCBX — DCB exchange	negociación basada en LLDP de los ajustes de PFC/ETS entre switch y NIC
IEEE 802.1Qau	CN — congestion notification	rara vez se despliega
RFC 3168 + DCQCN	marcado ECN + control de tasa	el switch marca los paquetes cuando se acumulan las colas; las NIC RoCE reducen el flujo antes de que haga falta PFC

Cómo se mantiene RoCE sin pérdidas

El tráfico de almacenamiento/RDMA se etiqueta con una prioridad dedicada (a menudo 3 o 4) vía DSCP o 802.1p.
PFC se habilita solo para esa prioridad en cada puerto a lo largo de la ruta, con un headroom de búfer dimensionado según la velocidad de enlace y la longitud del cable (bytes en tránsito).
Los umbrales de ECN marcan los paquetes de forma temprana; las NIC ejecutan DCQCN para reducir su tasa, de modo que PFC solo se activa como último recurso.
ETS garantiza a la clase de almacenamiento su ancho de banda bajo carga de LAN.
DCBX mantiene coherentes los ajustes de la NIC y del switch; los desajustes rompen la ausencia de pérdidas sin dar ningún aviso.

FC e InfiniBand logran lo mismo con créditos en cada enlace por defecto; Ethernet necesita que esto se configure, se verifique y se monitorice (Fundamentos de protocolo de FC, Transporte de InfiniBand).

Qué puede fallar

Problema	Efecto	Detección
PFC no habilitado en un salto / prioridad incorrecta	descartes bajo carga; RDMA retransmite; picos de latencia	contadores de pausa en cero donde no deberían estarlo; descartes en la clase
Tormenta de PFC	un receptor bloqueado pausa aguas arriba indefinidamente; la congestión se propaga por toda la fabric	frames de pausa desbordando; contadores de watchdog
Interbloqueo de PFC	dependencia cíclica de búfer en fabrics Clos; todo el tráfico de la clase se detiene	requiere detección de interbloqueo / watchdog para romperlo
Headroom insuficiente para cables/ópticas largos	descartes pese a PFC	descartes con contadores de pausa activos
Umbrales de ECN incorrectos	demasiado pronto: pérdida de rendimiento; demasiado tarde: inundación de PFC	contadores de marcas ECN, contadores de CNP en las NIC
Errores físicos en un enlace (CRC, FEC no corregible)	frames perdidos que ningún control de flujo puede recuperar	contadores de errores de puerto, contadores de FEC — Métricas de VDM y FEC

iSCSI sin DCB

iSCSI se ejecuta sobre TCP y sobrevive a las pérdidas, pero lo paga en latencia y retransmisión. Buenas prácticas independientemente de DCB:

VLAN/subredes dedicadas por fabric, dos fabrics, MPIO en los hosts;
frames jumbo (MTU 9000) de extremo a extremo;
sin sobresuscripción entre iniciadores y targets; enlaces ascendentes de 25G/100G dimensionados para el array;
FEC activo en cada enlace de 25G o superior; contadores de CRC en cero;
opcionalmente, PFC en la clase de iSCSI para suavizar microrráfagas (muchos arrays lo recomiendan).

Requisitos de capa física

Requisito	Por qué	Práctica
FEC habilitado y coincidente en cada enlace de 25G o superior	RoCE no tolera el BER en crudo de carriles de 25G/50G sin protección	FEC y negociación de enlace
CRC y FEC no corregible = 0	cada frame perdido bloquea una cola	alerta ante cualquier incremento
Potencia Rx dentro de la ventana con margen	la óptica al límite produce ráfagas de errores con la temperatura	Potencia Rx y presupuesto de enlace
Velocidad/dúplex/AN coherentes	el DAC necesita AN + entrenamiento de enlace en ambos extremos	Cobre y DAC
Longitud de cable dentro de las hipótesis de headroom	el headroom se calcula a partir de los bytes en tránsito	preferir DAC dentro del rack, SR/AOC dentro de la fila, DR/LR entre salas
Identidad aceptada por NIC y switch	la óptica rechazada cae a sin enlace o a velocidad reducida	Bloqueo de fabricante

Lista de comprobación de monitorización

Por puerto: frames de pausa enviados/recibidos por prioridad, marcas ECN, descartes por clase, CRC, FEC corregido/no corregible, caídas de enlace.
Por NIC: CNP enviados/recibidos, retransmisiones, fuera de secuencia, timeouts.
Por óptica: tendencias de potencia Rx/Tx y temperatura (Monitorización).
Correlacionar los picos de latencia de cola del almacenamiento con lo anterior — la capa física es culpable más a menudo que el array.

En CodingBox

Una fabric sin pérdidas se construye con óptica ordinaria simplemente sometida a un estándar más exigente. La inspección de entrada en el banco — identidad, sumas de comprobación, DDM en vivo frente a valores típicos, con línea base almacenada — es lo que mantiene los módulos al límite fuera de una fabric donde un enlace defectuoso le cuesta a una aplicación su SLA de latencia (Check transceiver, DDM).

Dónde se sitúan PFC y ECN entre los demás mecanismos de reenvío, y cómo se manifiestan en ellos los errores de capa física: Fundamentos de reenvío.

Si encuentra una inexactitud o un error en este material, seleccione el fragmento correspondiente y pulse Ctrl+Enter para .