NVMe/TCP vs. RoCEv2: o dilema entre latência pura e sanidade operacional

A evolução do armazenamento corporativo atingiu um ponto de inflexão curioso. Durante anos, lutamos contra a latência mecânica dos discos rígidos. Com a onipresença do flash NAND e a interface NVMe, o gargalo saiu da mídia de armazenamento e se instalou firmemente na rede.

Quando desacoplamos o armazenamento do servidor (NVMe-oF), surgem duas filosofias distintas de transporte. De um lado, temos o RoCEv2 (RDMA over Converged Ethernet), que promete desempenho de "metal nu" trazendo a herança do Infiniband para o Ethernet. Do outro, o NVMe/TCP, que aposta na onipresença e robustez do protocolo que construiu a internet.

A escolha entre eles raramente é sobre qual é "mais rápido" em um benchmark de laboratório. É uma decisão sobre quanto "imposto operacional" sua equipe está disposta a pagar por alguns microssegundos de ganho.

Resumo em 30 segundos

RoCEv2: Oferece a menor latência possível e menor uso de CPU via offload de hardware, mas exige uma rede "lossless" (sem perdas) complexa e propensa a falhas em cascata se mal configurada.

NVMe/TCP: Utiliza a infraestrutura Ethernet padrão (L2/L3) existente. Embora tenha um overhead de CPU ligeiramente maior, escala de forma previsível e é muito mais simples de depurar e manter.

O Veredito: Para 90% das cargas de trabalho corporativas e nuvens privadas, a simplicidade e o TCO do NVMe/TCP superam os ganhos marginais de latência do RoCEv2.

O fascínio perigoso da latência zero

Arquitetos de sistemas são frequentemente seduzidos por números de folha de dados. O RoCEv2 (RDMA over Converged Ethernet version 2) é tecnicamente impressionante. Ele permite que uma aplicação em um servidor leia a memória de outro servidor (neste caso, um array de storage) sem envolver o sistema operacional da máquina remota. Isso é o famoso kernel bypass e zero-copy.

O resultado é uma latência de transporte incrivelmente baixa, muitas vezes na casa de um dígito de microssegundos. Em cenários de HPC (High Performance Computing) ou treinamento de grandes modelos de IA, onde cada ciclo de CPU conta e a rede é uma malha dedicada e controlada, o RoCEv2 é o rei indiscutível.

No entanto, trazer essa tecnologia para um data center corporativo ou uma nuvem privada de propósito geral introduz uma fragilidade arquitetural que muitos ignoram até que a primeira interrupção ocorra.

Figura: Comparativo das pilhas de protocolo: O caminho direto do RoCEv2 versus a integração via Kernel do NVMe/TCP.

A armadilha da rede "Lossless"

O "calcanhar de Aquiles" do RoCEv2 é sua intolerância à perda de pacotes. O protocolo RDMA foi desenhado para redes Infiniband, que garantem entrega. O Ethernet, por natureza, é "best effort" e descarta pacotes quando congestionado.

Para fazer o RoCE funcionar em Ethernet, precisamos transformar a rede em Lossless Ethernet. Isso é feito através do PFC (Priority Flow Control). O PFC permite que um switch ou NIC envie um sinal de "PAUSE" para o remetente quando seu buffer está enchendo.

⚠️ Perigo: O PFC é um mecanismo de força bruta. Se um nó de storage fica lento, ele pausa o switch. O switch, ficando sem buffer, pausa os servidores que estão enviando dados. Isso cria uma "propagação de congestionamento" (congestion spreading) que pode paralisar partes da rede que nem sequer estão envolvidas no fluxo original.

Já presenciei incidentes onde uma configuração errada de PFC em um único rack causou um head-of-line blocking que derrubou a performance de clusters inteiros. Depurar isso exige uma visibilidade de telemetria que poucas equipes de operações possuem.

Figura: O efeito dominó do PFC: Como um único nó congestionado pode paralisar servidores saudáveis através da propagação de quadros de pausa.

NVMe/TCP: A vitória do pragmatismo

O NVMe/TCP adota uma abordagem diametralmente oposta. Ele assume que a rede é hostil, que pacotes serão perdidos e que o congestionamento é inevitável. E o TCP é excelente em lidar com isso.

Quando há congestionamento no NVMe/TCP, o protocolo simplesmente reduz a janela de transmissão e retransmite os pacotes perdidos. Não há quadros de pausa parando a rede inteira. O impacto é isolado ao fluxo específico que está sofrendo o problema.

O mito do custo de CPU

O argumento histórico contra o TCP era o overhead de processamento. Encapsular e desencapsular pacotes TCP consome ciclos de CPU que poderiam ser usados pela aplicação.

Isso era verdade em 2015. Hoje, o cenário mudou por dois fatores:

Lei de Moore (ainda viva em cores): CPUs modernas com dezenas de núcleos lidam com o processamento TCP sem suar para a maioria das cargas de trabalho de armazenamento (IOPS típicos de Enterprise).
Ascensão das SmartNICs e DPUs: Placas de rede modernas (como NVIDIA BlueField, Pensando ou Marvell Octeon) agora fazem offload completo ou parcial do NVMe/TCP. Isso nivela o campo de jogo, permitindo latências muito próximas ao RDMA sem a complexidade da rede lossless.

Comparativo técnico: Onde a teoria encontra a prática

Para tomar uma decisão baseada em dados, precisamos olhar além da latência média e considerar o ecossistema completo.

Característica	NVMe over RoCEv2	NVMe over TCP
Dependência de Rede	Crítica (Exige DCB/PFC/ECN)	Nenhuma (Roda em Ethernet padrão)
Complexidade de Configuração	Alta (Hop-by-hop no fabric)	Baixa (Configuração de Host/Target)
Latência (Média)	Excelente (< 5µs adicionais)	Muito Boa (10-20µs adicionais)
Latência de Cauda (P99)	Imprevisível sob congestionamento severo	Consistente e degradável suavemente
Roteamento (L3)	Possível, mas complexo (RoCEv2)	Nativo e trivial
Custo de Hardware	Switches e NICs específicos recomendados	Hardware commodity existente
Depuração (Troubleshooting)	Difícil (Requer ferramentas especializadas)	Trivial (Tcpdump, Wireshark padrão)

Métricas de latência de cauda e o impacto no TCO

Ao projetar arquiteturas de grande escala, a métrica "média" é mentirosa. O que mata a experiência do usuário e viola SLAs é a latência de cauda (P99 ou P99.9) — o 1% das requisições mais lentas.

Em uma rede RoCEv2 mal otimizada, quando o PFC entra em ação, a latência de cauda pode disparar de 100µs para 500ms (milissegundos!) devido ao bloqueio de tráfego. O NVMe/TCP, sob carga, aumenta a latência de forma linear, não exponencial.

💡 Dica Pro: Se sua aplicação não é sensível a variações de 10 a 20 microssegundos (ex: bancos de dados transacionais padrão, VDI, servidores de arquivos), o custo de engenharia para manter uma rede RoCEv2 não se justifica. O TCO do NVMe/TCP é drasticamente menor porque utiliza os switches Top-of-Rack que você já possui e a expertise que sua equipe de redes já domina.

Figura: Previsibilidade sob estresse: Enquanto o RoCEv2 sofre picos violentos durante o congestionamento, o NVMe/TCP degrada de forma linear e previsível.

O futuro é híbrido, mas o TCP vencerá no volume

Estamos vendo uma bifurcação clara no mercado de armazenamento.

Para o nicho de IA/ML e HPC, onde clusters de GPUs precisam ser alimentados com dados na velocidade da luz e a rede é desenhada especificamente para isso, o RoCEv2 (e o Infiniband) continuará reinando.

Para o Enterprise Data Center, Cloud Privada e VMware vSphere (que suporta NVMe/TCP nativamente desde a versão 7.0 Update 3), o NVMe/TCP está se tornando o padrão de facto. A simplicidade de implantar armazenamento de alto desempenho em qualquer lugar onde haja uma porta Ethernet e uma rota IP é uma vantagem logística insuperável.

Recomendação Arquitetural

Não construa uma infraestrutura baseada em "se tudo der certo". Construa para quando as coisas derem errado.

Se você não possui uma equipe dedicada de engenharia de rede capaz de ajustar buffers de switch, configurar ECN (Explicit Congestion Notification) e monitorar tempestades de PFC, adote o NVMe/TCP. A diferença de desempenho é imperceptível para a aplicação, mas a diferença na sua qualidade de vida operacional será imensa. A sanidade operacional é uma feature que não aparece no datasheet, mas é a mais valiosa de todas.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Detalhes oficiais sobre os transportes NVMe-oF.
SNIA (Storage Networking Industry Association): "Performance Analysis of NVMe/TCP vs. RoCEv2" (Whitepapers técnicos variados).
RFC 793 (TCP) & RFC 5046 (iWARP/RDMA context): Para entender as fundações dos protocolos de transporte.
VMware vSphere Storage Guide: Documentação sobre a implementação e melhores práticas de NVMe/TCP em ambientes virtualizados.

Perguntas Frequentes (FAQ)

O NVMe/TCP é muito mais lento que o RoCEv2?

Em termos de latência bruta de transporte, o NVMe/TCP adiciona cerca de 10 a 20 microssegundos a mais que o RoCEv2. No entanto, para a maioria das aplicações corporativas (bancos de dados, virtualização), essa diferença é imperceptível no nível da aplicação, enquanto a complexidade de manter uma rede RoCEv2 é significativamente maior.

Preciso de switches especiais para rodar NVMe/TCP?

Não. Essa é a principal vantagem do NVMe/TCP. Ele roda na infraestrutura Ethernet padrão existente (L2/L3) sem necessidade de configurações complexas de DCB (Data Center Bridging) ou PFC (Priority Flow Control), ao contrário do RoCEv2 que exige switches com suporte a Lossless Ethernet.

O NVMe/TCP consome muita CPU do servidor?

Historicamente, o processamento TCP consumia mais ciclos de CPU do que o offload de hardware do RDMA. Contudo, com CPUs modernas e a introdução de SmartNICs e DPUs que fazem offload de NVMe/TCP, esse impacto foi drasticamente reduzido, tornando-o viável para alta performance.