Congestion spreading em NVMe-oF: mitigando tempestades PFC e latência fantasma

Você já presenciou o cenário clássico: uma aplicação crítica de banco de dados começa a sofrer com latência de gravação alta. O DBA aponta o dedo para o storage. Você verifica o array All-Flash e ele está dormindo, com latência sub-milissegundo. Você verifica os links de rede e a utilização média está em confortáveis 30%. No entanto, a aplicação continua engasgando.

Bem-vindo ao mundo da "latência fantasma" em redes Ethernet Lossless. O culpado provável não é a falta de banda, mas um fenômeno destrutivo conhecido como Congestion Spreading (propagação de congestionamento), causado pelo comportamento binário do Priority Flow Control (PFC) em implementações RoCEv2 (RDMA over Converged Ethernet).

Para arquitetos de storage modernos, entender a física do tráfego NVMe-oF (NVMe over Fabrics) deixou de ser opcional. Diferente do Fibre Channel, que nasceu com controle de fluxo baseado em créditos (buffer-to-buffer credits) desenhado para evitar perda de pacotes nativamente, o Ethernet precisa de "ajuda" para se comportar de maneira determinística. Quando essa ajuda é mal configurada, o remédio se torna pior que a doença.

Resumo em 30 segundos

O Problema: O PFC (Priority Flow Control) pausa o tráfego de toda uma classe de prioridade quando um buffer enche, afetando até fluxos que não estão congestionados (vítimas inocentes).

A Causa: Microbursts (rajadas de milissegundos) enchem buffers instantaneamente, disparando "tempestades de pausa" que travam o fabric.

A Solução: Implementar ECN (Explicit Congestion Notification) e DCQCN para desacelerar os emissores proativamente antes que o PFC precise parar o tráfego brutalmente.

O mecanismo de backpressure do priority flow control

O protocolo NVMe é extremamente eficiente, desenhado para o paralelismo dos SSDs modernos. Quando transportamos NVMe sobre Ethernet via RoCEv2, exigimos uma rede "Lossless" (sem perdas). Por que? Porque a perda de um único pacote no RoCE obriga a retransmissão de toda uma sequência de dados ou força o fallback para mecanismos de recuperação lentos, destruindo a latência baixa que motivou a compra do All-Flash em primeiro lugar.

Para garantir zero perda, usamos o IEEE 802.1Qbb (PFC). Ele divide o tráfego Ethernet em 8 classes de serviço (CoS). O tráfego de storage geralmente reside na CoS 3 ou 4.

O funcionamento é simples: se a fila de entrada de uma porta de switch (ingress buffer) atinge um limite crítico (Xoff), o switch envia um quadro de pausa PFC para o dispositivo que está enviando os dados. O emissor para de transmitir aquela classe de prioridade específica.

O efeito dominó no fabric

O problema surge quando temos uma topologia "Many-to-One" (Muitos para Um), comum em backups ou analytics. Se o Storage Alvo (Target) não consegue processar os dados rápido o suficiente, ele manda um Pause para o switch. O buffer do switch enche. O switch, agora sem buffer, manda Pause para todos os servidores conectados que estão enviando dados naquela prioridade.

Aqui nasce o Congestion Spreading:

O Servidor A está enviando dados para o Storage Lento. Ele é pausado.
O Servidor B está enviando dados para o Storage Rápido (que está livre).
Como o Servidor B compartilha a mesma porta de uplink ou a mesma classe de prioridade no switch congestionado, ele também recebe o comando de pausa.

O Servidor B é uma "vítima inocente". Sua latência dispara não porque seu destino está lento, mas porque um vizinho barulhento travou a via expressa.

Figura: Diagrama do efeito de Propagação de Congestionamento (Congestion Spreading), onde um fluxo agressor causa o envio de quadros de pausa que bloqueiam fluxos de vítimas inocentes.

Por que aumentar buffers ou desativar flow control falha

Uma reação instintiva de administradores de rede generalistas é: "Vamos aumentar os buffers do switch" ou "Vamos desativar o PFC e deixar o TCP se virar". Ambas as abordagens são catastróficas para NVMe-oF RoCEv2.

A falácia dos buffers profundos (Deep Buffers)

Aumentar o buffer apenas adia o problema e introduz bufferbloat. Em storage, latência é inimiga. Se um pacote fica 50ms parado em um buffer gigante antes de ser processado, para a aplicação, isso é tão ruim quanto uma perda. Além disso, quando esse buffer gigante finalmente enche, a tempestade de PFC será ainda mais longa e difícil de drenar.

O perigo de desativar o PFC

Se você desativar o PFC em uma rede RoCEv2, ela se torna "Lossy" (com perdas). Quando ocorre um microburst e o buffer estoura, pacotes são descartados silenciosamente. O protocolo RoCE (v1 ou v2) não lida bem com perdas. O impacto na performance não é linear; é exponencial. Uma taxa de perda de pacotes de 0,1% pode reduzir o throughput do NVMe-oF em mais de 50% devido aos timeouts e retransmissões do protocolo RDMA.

⚠️ Perigo: Nunca misture tráfego Lossless (RoCE) e Lossy (LAN geral) na mesma fila de prioridade (CoS). O tráfego geral pode consumir o buffer compartilhado e disparar pausas no tráfego de storage, ou o tráfego de storage pode pausar o tráfego de gerenciamento. O isolamento via QoS é obrigatório.

Implementando ECN e DCQCN: desaceleração controlada

A solução para evitar o travamento binário do PFC é agir antes que o buffer encha. Para isso, utilizamos o ECN (Explicit Congestion Notification) na camada 3 (IP) em conjunto com o algoritmo DCQCN (Data Center Quantized Congestion Notification) nos adaptadores de rede (NICs/HBAs).

Diferente do PFC, que grita "PARE!", o ECN sussurra "Vá mais devagar".

Como funciona o fluxo ECN:

Detecção: O switch monitora a profundidade da fila. Definimos um limiar (threshold) Kmin e Kmax.
Marcação: Quando a fila ultrapassa Kmin, o switch não pausa ninguém. Ele apenas altera dois bits no cabeçalho IP do pacote (bits ECN) para marcar "Congestion Experienced" (CE).
Notificação: O Storage (Target) recebe o pacote marcado. Ele percebe o congestionamento, mas não descarta o dado. Ele envia de volta ao servidor (Initiator) um pacote especial chamado CNP (Congestion Notification Packet).
Ação (DCQCN): A placa de rede do servidor recebe o CNP e reduz imediatamente a taxa de transmissão daquele fluxo específico (Rate Limiting).

O resultado é que o servidor agressor diminui a velocidade, permitindo que o buffer do switch esvazie, sem nunca precisar disparar um quadro de pausa PFC. As vítimas inocentes continuam operando em velocidade máxima.

Figura: Comparativo visual: PFC atua como um sinal vermelho de parada total quando o buffer enche, enquanto ECN atua como um aviso amarelo para redução de velocidade antes da saturação.

Monitoramento de microbursts e validação

O maior desafio em diagnosticar esses problemas é que as ferramentas de monitoramento padrão (SNMP, Zabbix, SolarWinds) geralmente coletam dados a cada 1 ou 5 minutos.

Um microburst pode saturar um link de 100Gbps em questão de microssegundos, causar uma tempestade de PFC, e desaparecer. Na média de 5 minutos, o link parecerá ter 5% de uso.

O que monitorar (Telemetry):

Para validar se sua rede SAN Ethernet está saudável, você deve monitorar contadores específicos via CLI do switch ou ferramentas de telemetria de streaming (gRPC/sFlow):

Priority Pause Frames (Rx/Tx): Se este contador está incrementando rapidamente, você tem um problema de congestionamento severo. Em uma rede perfeitamente tunada com ECN, os contadores de PFC devem ser próximos de zero.
CNP Sent/Received: Verifique nas placas de rede (NICs) dos servidores. Se houver contadores de CNP subindo, significa que o ECN está funcionando e mitigando o congestionamento.
Buffer Usage / Queue Depth: Switches modernos (Mellanox Spectrum, Cisco Nexus, Dell PowerSwitch) conseguem reportar picos de uso de buffer (watermarks) que ocorreram entre os intervalos de coleta.

💡 Dica Pro: Configure o limiar do ECN (Kmin) baixo o suficiente para disparar antes do PFC. Uma regra prática comum é configurar o início da marcação ECN em 20-30% do buffer e o disparo do PFC apenas em 90-95% (Headroom). Se o ECN começar muito tarde, ele não terá tempo de frear o tráfego antes que o PFC entre em ação.

Figura: Visualização de telemetria: A média de banda esconde os microbursts reais. O gráfico destaca picos invisíveis de uso de fila que causam latência, contrastando com a média plana.

Tabela Comparativa: RoCEv2 vs. NVMe/TCP

Embora o foco deste artigo seja mitigar problemas em RoCEv2, é vital entender onde o NVMe/TCP se encaixa. O NVMe/TCP utiliza a pilha TCP/IP padrão, que possui controle de congestionamento nativo (CUBIC, BBR), dispensando a complexidade do PFC/ECN no switch, ao custo de maior latência e overhead de CPU.

Característica	NVMe over RoCEv2 (UDP)	NVMe over TCP
Dependência da Rede	Crítica (Lossless L2 obrigatório)	Baixa (Lossy L2 aceitável)
Mecanismo de Controle	PFC (L2) + ECN/DCQCN (L3)	TCP Congestion Control (L4)
Risco de Congestion Spreading	Alto (se mal configurado)	Baixo (isolado por fluxo TCP)
Latência Típica	Ultra-baixa (<10µs adicionais)	Baixa (10-30µs adicionais)
Complexidade de Configuração	Alta (QoS, DCB, PFC, ECN)	Baixa (Plug & Play padrão)
Caso de Uso Ideal	AI/ML, HPC, Tier-0 Storage	Virtualização Geral, Tier-1, Cloud

O fim da inocência da rede

A migração para NVMe-oF exige que o operador de storage abandone a visão de que a rede é apenas um "tubo". Em velocidades de 100GbE, 200GbE e 400GbE, a física dos buffers e a interação entre protocolos de controle de fluxo definem a performance final do disco.

Não espere que o congestionamento desapareça apenas adicionando banda. Tempestades de PFC podem derrubar clusters inteiros mesmo em backbones de alta velocidade se houver descasamento de velocidade (speed mismatch) entre emissores e receptores. A implementação rigorosa de ECN e DCQCN não é apenas uma "melhoria", é um requisito de sobrevivência para SANs Ethernet de alta performance.

Referências & Leitura Complementar

IETF RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP.
IEEE 802.1Qbb: Priority-based Flow Control (PFC).
Mellanox/NVIDIA: "RoCEv2 Congestion Management (ECN/DCQCN) Deployment Guide" (2023/2024).
SNIA: "NVMe over Fabrics: Configuration and Troubleshooting Guide".
Cisco: "Intelligent Buffer Management on Nexus Switches for RoCE".

O que é uma tempestade PFC em redes de storage?

É um evento crítico onde um dispositivo ou porta de switch envia incessantemente quadros de pausa (Priority Flow Control) devido a um buffer cheio. Isso trava o tráfego de toda uma classe de prioridade na rede, criando um efeito cascata que afeta até fluxos de dados que não passam pelo link congestionado (vítimas inocentes).

O NVMe/TCP sofre dos mesmos problemas de PFC que o RoCEv2?

Não. O NVMe/TCP utiliza o controle de congestionamento nativo e robusto do protocolo TCP (camada 4) e não exige uma rede lossless (sem perdas) na camada 2. Isso elimina a necessidade estrita de PFC e o risco de suas tempestades, embora introduza uma latência ligeiramente maior devido ao overhead de processamento do TCP.

Qual a diferença entre PFC e ECN no contexto de NVMe-oF?

A diferença é a sutileza e a camada de atuação. O PFC (Camada 2) é reativo e "bruto", pausando totalmente o tráfego para evitar perda de pacotes. O ECN (Camada 3), usado com DCQCN, é proativo: ele marca pacotes quando o buffer começa a encher, instruindo o emissor a reduzir a velocidade suavemente antes que o buffer sature e o PFC precise ser acionado.