NVMe-oF TCP vs RoCE: qual protocolo domina o data center moderno?

Você gastou uma fortuna em arrays All-Flash com SSDs NVMe de última geração, mas suas aplicações ainda parecem engasgar. O culpado provavelmente não é o disco, mas o "cano" que conecta seus servidores ao storage. Durante décadas, o iSCSI e o Fibre Channel foram os reis do pedaço, mas eles foram desenhados para a era dos discos mecânicos (HDD). Tentar passar tráfego NVMe por protocolos SCSI antigos é como tentar encher uma piscina olímpica usando um canudo.

É aqui que entra o NVMe over Fabrics (NVMe-oF). Ele estende a performance do barramento PCIe do servidor diretamente para o storage através da rede. Mas a indústria se dividiu em duas trincheiras principais para transportar esses dados via Ethernet: RoCEv2 (RDMA over Converged Ethernet) e NVMe/TCP.

Um promete velocidade pura e latência quase zero. O outro promete simplicidade e compatibilidade total. Qual deles você deve implementar na sua infraestrutura? Vamos dissecar essa batalha.

Resumo em 30 segundos

RoCEv2 (RDMA): É a Ferrari. Oferece a menor latência possível e baixo uso de CPU, mas exige switches caros, configuração de rede "sem perdas" (lossless) complexa e placas de rede específicas.

NVMe/TCP: É o SUV confiável. Roda em qualquer switch Ethernet padrão e qualquer placa de rede. Tem latência um pouco maior que o RoCE, mas ainda é drasticamente mais rápido que o iSCSI.

O Veredito: Para 90% dos casos (VMware, bancos de dados gerais), o NVMe/TCP vence pelo custo-benefício e facilidade. O RoCE fica reservado para HPC (Computação de Alto Desempenho) e clusters de IA.

O problema do gargalo legado

Para entender por que essa briga existe, você precisa entender o que estamos tentando substituir. O protocolo iSCSI encapsula comandos SCSI em pacotes TCP/IP. O problema é que o SCSI foi criado para discos que giram e têm tempos de busca mecânica. Ele é serial, tem filas limitadas e exige muita tradução de comandos pela CPU.

O NVMe foi desenhado para memória flash: ele é massivamente paralelo, suporta 64.000 filas de comandos e fala a língua nativa do PCIe. Quando colocamos NVMe sobre uma rede (Fabric), queremos manter essas características.

Figura: Comparação visual entre o afunilamento do protocolo SCSI legado e o paralelismo massivo do NVMe.

RoCEv2: a busca pela velocidade absoluta

O RoCE (pronuncia-se "Rocky") v2 é a implementação mais popular de RDMA (Remote Direct Memory Access) sobre Ethernet.

A mágica do RDMA é o "zero-copy". Em uma transferência de rede normal, os dados são copiados da aplicação para o buffer do sistema operacional, depois para o driver, e só então para a placa de rede. O RDMA permite que a placa de rede de um servidor leia ou escreva diretamente na memória de outro servidor (ou storage), ignorando completamente a CPU e o Sistema Operacional do destino.

Os prós do RoCE

Latência Insana: Estamos falando de latências de rede na casa de 5 a 10 microssegundos.
Offload de CPU: Como a placa de rede (NIC) faz o trabalho pesado, a CPU do servidor fica livre para rodar suas aplicações.

O "imposto" oculto do RoCE

Aqui é onde o sonho vira pesadelo para muitos administradores de rede. O RDMA odeia perda de pacotes. Se um pacote se perde, o protocolo precisa retransmitir e a performance cai de um penhasco.

Para evitar isso, você precisa configurar uma Lossless Ethernet (Ethernet sem perdas). Isso exige:

Switches Específicos: Eles precisam suportar DCB (Data Center Bridging).
PFC (Priority Flow Control): Um mecanismo que "pausa" o tráfego em filas específicas para evitar buffer overflow.
ECN (Explicit Congestion Notification): Para gerenciar o congestionamento antes que ele ocorra.

⚠️ Perigo: Configurar PFC incorretamente pode causar o temido "head-of-line blocking" ou tempestades de pausa, onde um switch manda o outro parar de transmitir, travando a rede inteira do data center. É complexo e frágil.

Figura: O mecanismo de acesso direto à memória do RoCEv2 e a dependência de controle de fluxo no switch.

NVMe/TCP: a revolução da simplicidade

Enquanto os engenheiros de rede arrancavam os cabelos configurando PFC para o RoCE, a indústria (liderada por gigantes como a Dell, NetApp e a própria criadora do NVMe) padronizou o NVMe/TCP em 2018.

A ideia é brilhante: encapsular os comandos NVMe dentro de pacotes TCP padrão.

Por que o TCP mudou o jogo?

O TCP (Transmission Control Protocol) é a linguagem da internet. Ele foi desenhado para ser robusto. Se um pacote se perde, o TCP retransmite e a vida segue. Ele lida com congestionamento nativamente.

Isso significa que o NVMe/TCP:

Não exige switches especiais: Funciona no switch Top-of-Rack que você comprou há 3 anos.
Não exige Lossless Ethernet: Adeus, pesadelo do PFC.
É roteável em qualquer lugar: Pode atravessar sub-redes e até WANs (embora a latência aumente).

O custo da simplicidade

O NVMe/TCP não tem a mágica do RDMA (por padrão). O processamento do encapsulamento TCP consome ciclos da CPU do servidor (Host CPU).

💡 Dica Pro: Para mitigar o uso de CPU no NVMe/TCP, o mercado está adotando SmartNICs ou DPUs (Data Processing Units). Essas placas fazem o offload do processamento TCP, entregando uma performance muito próxima ao RoCE, mas mantendo a compatibilidade da rede padrão.

Figura: Comparativo de latência e custo entre os protocolos, destacando o equilíbrio do NVMe/TCP.

Batalha de Performance: O que dizem os números?

Em testes de laboratório controlados, o cenário geralmente é este:

Métrica	iSCSI (Legado)	NVMe/TCP	RoCEv2 (RDMA)
Latência de Rede	100-200 µs	30-50 µs	5-10 µs
Uso de CPU (Host)	Alto	Médio/Alto (sem DPU)	Muito Baixo
Complexidade de Rede	Baixa	Baixa (Plug & Play)	Altíssima (Lossless)
Custo de Hardware	Baixo	Baixo	Alto (Switches/NICs)

Embora o RoCE seja tecnicamente mais rápido, a diferença entre 10µs e 40µs é irrelevante para a maioria das aplicações de negócios, como SQL Server, VDI ou servidores web. O gargalo real geralmente está na aplicação ou no próprio SSD, não nesses microssegundos de rede.

O fator ecossistema: VMware e o mercado

A virada de chave aconteceu quando a VMware anunciou suporte nativo total ao NVMe/TCP no vSphere 7.0 Update 3. Isso validou a tecnologia para o mercado corporativo.

Hoje, grandes players de storage como Pure Storage, Dell PowerStore e NetApp estão empurrando o NVMe/TCP como o padrão de fato para implementações novas. Eles sabem que o custo de suporte para ajudar clientes a depurar configurações de PFC no RoCE é alto demais. O NVMe/TCP "simplesmente funciona".

Figura: A integração nativa do NVMe/TCP em ambientes virtualizados modernos como VMware.

Qual escolher para o seu Data Center?

Escolha RoCEv2 se:

Você está construindo um cluster de HPC (High Performance Computing) ou treinamento de IA/Machine Learning.
Você tem uma equipe de engenharia de rede dedicada e capaz de manter uma fabric Lossless.
Cada microssegundo impacta diretamente sua receita (ex: High Frequency Trading).

Escolha NVMe/TCP se:

Você roda virtualização geral (VMware, Hyper-V, KVM).
Você quer aproveitar a infraestrutura de switches Ethernet existente (10GbE, 25GbE, 100GbE).
Você quer a performance do NVMe sem a complexidade de configuração do RDMA.
Você quer reduzir o TCO (Custo Total de Propriedade).

O futuro é TCP (com uma pitada de silício)

A guerra dos protocolos parece estar chegando ao fim com uma vitória pragmática. O NVMe/TCP está se tornando o padrão para armazenamento primário em data centers devido à sua flexibilidade e custo. A desvantagem do uso de CPU está sendo resolvida rapidamente com a commoditização das placas de rede com offload (mesmo NICs padrão da Intel e Broadcom já fazem muito disso hoje).

O RoCE não vai morrer, mas ficará confinado ao seu nicho de ultra-performance, onde a complexidade se justifica. Para todo o resto, o TCP provou mais uma vez que a compatibilidade universal vence a velocidade bruta. Se você vai atualizar seu storage este ano, aposte suas fichas no TCP.

Perguntas Frequentes (FAQ)

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

Em termos brutos, sim. O RoCE adiciona cerca de 5-10 microssegundos de latência, enquanto o NVMe/TCP adiciona entre 30-80 microssegundos. Porém, para 90% das cargas de trabalho virtualizadas (como VMware vSphere), essa diferença é imperceptível, e o TCP ainda é drasticamente mais rápido que o iSCSI.

Posso usar switches comuns para RoCEv2?

Tecnicamente o RoCEv2 é roteável, mas para performance estável ele exige switches com suporte a DCB (Data Center Bridging), PFC (Priority Flow Control) e ECN. Sem isso, a perda de pacotes destrói a performance do RDMA. Já o NVMe/TCP funciona em qualquer switch Ethernet padrão.

Preciso de placas de rede especiais (SmartNICs) para NVMe/TCP?

Não obrigatoriamente. O NVMe/TCP roda em qualquer NIC padrão. No entanto, o uso de SmartNICs ou DPUs pode ajudar a reduzir o uso de CPU do servidor (offload), aproximando a eficiência do TCP à do RoCE.