NVMe over TCP vs iSCSI: Análise de Latência e Overhead em Redes Ethernet

A modernização do datacenter atingiu um ponto de inflexão crítico em 2026. Com a proliferação de mídias NAND de altíssima densidade (QLC) e performance (SLC/XL-Flash), o gargalo de infraestrutura migrou fisicamente. Não estamos mais esperando o braço do disco girar; estamos esperando o protocolo de transporte "desempacotar" os dados. Durante décadas, o iSCSI (Internet Small Computer Systems Interface) foi o cavalo de batalha das SANs baseadas em Ethernet, democratizando o armazenamento em bloco. No entanto, ao colocarmos arrays All-Flash modernos atrás de uma pilha iSCSI, estamos efetivamente colocando um limitador de velocidade em um motor de Fórmula 1.

Resumo em 30 segundos

• Gargalo de Tradução: O iSCSI exige uma tradução custosa de comandos SCSI para TCP, gerando alta latência de CPU (overhead), enquanto o NVMe/TCP fala a linguagem nativa do SSD através da rede.
• Paralelismo Massivo: O iSCSI depende de filas serializadas que bloqueiam núcleos de CPU. O NVMe/TCP suporta até 64.000 filas paralelas, alinhando-se perfeitamente com arquiteturas de CPU multi-core modernas.
• Simplicidade de Rede: Diferente do NVMe-oF via RoCE (RDMA), o NVMe/TCP não exige switches "lossless" ou configurações complexas de PFC/ECN, rodando na infraestrutura Ethernet padrão existente.

A latência fantasma em arrays All-Flash modernos

Quando analisamos a telemetria de um array de armazenamento flash conectado via iSCSI, frequentemente vemos tempos de resposta de disco na casa dos microssegundos (µs), mas a latência percebida pela aplicação (Host-side latency) permanece na casa dos milissegundos. Chamamos isso de "latência de tecido" ou latência de protocolo.

Em um ambiente iSCSI tradicional, o ciclo de vida de uma operação de I/O é traumático para a latência. O sistema operacional gera um comando. Esse comando é traduzido para SCSI. O driver iSCSI encapsula isso em PDUs (Protocol Data Units). O stack TCP/IP do kernel fragmenta isso em pacotes. No destino, o processo inverso ocorre. Cada etapa adiciona latência de serialização e trocas de contexto (context switches) na CPU.

Fig. 1: Comparativo de Pilha de Protocolos. Note a eliminação da camada de tradução SCSI no NVMe-oF.

O NVMe over Fabrics (NVMe-oF), especificamente o transporte TCP, elimina a camada de tradução SCSI. O comando NVMe criado no host é encapsulado diretamente em um frame TCP. Não há "tradução" de linguagem, apenas transporte. Isso reduz drasticamente o path length do código que a CPU precisa executar.

O gargalo da tradução SCSI e a serialização do TCP

O problema fundamental do iSCSI em 2026 não é a velocidade do cabo, mas a arquitetura do protocolo. O SCSI foi desenhado em uma era de processadores single-core e discos mecânicos. Ele é inerentemente serial.

Quando um host envia dados via iSCSI, ele geralmente estabelece uma única sessão TCP (ou poucas sessões se usarmos MC/S - Multiple Connections per Session, que é raramente implementado de forma eficiente). Isso cria um funil: todos os comandos de I/O de múltiplos núcleos da CPU do servidor precisam entrar em uma fila única para serem processados pela sessão TCP.

⚠️ Perigo: O bloqueio de "Head-of-Line" no nível do TCP em iSCSI pode fazer com que um pacote perdido ou atrasado pare todo o fluxo de dados subsequente até que a retransmissão ocorra, causando picos de latência imprevisíveis (Jitter).

No lado do Target (Storage), a situação é pior. O processamento dessa sessão TCP única geralmente é fixado em um único núcleo de CPU (CPU Pinning). Se você tem um Storage Array com 128 núcleos, mas uma sessão iSCSI pesada está atrelada a apenas um, você terá um gargalo de processamento, mesmo com a CPU global do storage em 5% de uso.

Por que aumentar a largura de banda não resolve o bloqueio de I/O

Muitos administradores cometem o erro de migrar de 10GbE para 25GbE ou 100GbE esperando reduzir a latência do iSCSI. Embora a largura de banda (throughput) aumente, a latência de serialização permanece.

Imagine uma rodovia (a rede). Aumentar a largura de banda é como adicionar mais faixas. Se o problema é o volume de carros, isso ajuda. Mas se o problema é que há um pedágio manual (a tradução SCSI/TCP) onde cada carro deve parar e pagar individualmente, ter 10 faixas não fará o carro passar pelo pedágio mais rápido.

O NVMe/TCP não apenas remove o pedágio, ele constrói viadutos expressos. A eficiência do protocolo permite saturar links de 100GbE com tamanhos de bloco menores (4K ou 8K) usando muito menos ciclos de CPU do que o iSCSI exigiria para a mesma tarefa.

Arquitetura de filas paralelas do NVMe/TCP e o fim do lock de CPU

A grande revolução do NVMe não é a velocidade, é o paralelismo. A especificação NVMe suporta até 65.535 filas de I/O, com até 64.000 comandos por fila.

No NVMe/TCP, essa arquitetura é mapeada diretamente para a rede. Cada núcleo de CPU no host pode ter seu próprio par de filas (Submission/Completion Queues) mapeado para uma conexão TCP dedicada. Isso elimina a necessidade de locking (bloqueio) de recursos compartilhados entre núcleos.

Fig. 2: O impacto do paralelismo. Enquanto o iSCSI serializa comandos, o NVMe mapeia filas diretamente para núcleos de CPU.

O conceito de "Binding"

Em implementações otimizadas (como as vistas em drivers modernos do Linux e VMware ESXi 8.0+), ocorre o seguinte:

1. A aplicação no Core 0 gera um I/O.

2. O driver NVMe coloca o comando na fila do Core 0.

3. A conexão TCP associada ao Core 0 envia o pacote.

4. No Storage Target, a NIC recebe o pacote e o direciona (via Flow Steering) para a CPU que gerencia aquele NVMe namespace específico.

Não há gargalo global. Se você adicionar mais núcleos de CPU, você ganha linearmente mais capacidade de I/O. O iSCSI, por sua natureza, não consegue escalar dessa forma sem gambiarras complexas de multipathing que adicionam sua própria sobrecarga administrativa.

Comparativo de latência de cauda e overhead de processamento

Para operadores de storage, a "latência média" é uma métrica de vaidade. O que importa é a latência de cauda (Tail Latency - p99 ou p99.9), pois é ela que define a experiência do usuário em bancos de dados transacionais.

Testes realizados em laboratório com cargas de trabalho sintéticas (FIO) e reais (PostgreSQL) mostram uma disparidade brutal:

• Overhead de CPU (Host): Para empurrar 1 milhão de IOPS, o iSCSI consome cerca de 2x a 3x mais ciclos de CPU do host do que o NVMe/TCP. Isso significa que, ao usar NVMe/TCP, sobram mais ciclos de CPU para suas aplicações (VMs/Containers) rodarem.

• Latência p99: Sob carga pesada (Queue Depth alto), a latência do iSCSI dispara exponencialmente devido ao enfileiramento de comandos. O NVMe/TCP mantém uma curva quase plana até atingir a saturação física do link ou da mídia.

Fig. 3: Validação de Performance. A vantagem do NVMe/TCP se amplia conforme a carga de trabalho (Queue Depth) aumenta.

💡 Dica Pro: Ao implementar NVMe/TCP, ative o Jumbo Frames (MTU 9000) end-to-end. Diferente do iSCSI, onde o ganho é marginal em CPUs modernas, no NVMe/TCP o Jumbo Frames reduz drasticamente a taxa de pacotes por segundo (PPS) para grandes transferências sequenciais, aliviando a carga de interrupções na NIC.

Implementação: O fim da complexidade do DCB?

Uma das maiores vitórias do NVMe/TCP sobre seu irmão, o NVMe-oF via RoCE (RDMA over Converged Ethernet), é a simplicidade da camada física.

O RoCEv2 exige uma rede "Lossless". Isso obriga o administrador de rede a configurar Priority Flow Control (PFC) e Explicit Congestion Notification (ECN) nos switches. Um erro na configuração do PFC pode causar um "Head-of-Line Blocking" em todo o switch, parando o tráfego de outras portas. É complexo, frágil e difícil de escalar em redes roteadas L3.

O NVMe/TCP roda em cima do TCP padrão. Ele aceita perda de pacotes e retransmissão (embora não seja desejável). Ele atravessa roteadores e firewalls sem configurações exóticas. Para 95% dos casos de uso Enterprise, a latência adicional do TCP (vs RDMA) é imperceptível (na casa de 10-20µs), mas a facilidade de operação é imensa. Você pode rodar NVMe/TCP na sua infraestrutura de switches ToR existente hoje.

Considerações Finais

A transição do iSCSI para o NVMe/TCP não é uma questão de "se", mas de "quando". Para novos deployments All-Flash, insistir no iSCSI é subutilizar o investimento feito em hardware. O protocolo legado simplesmente não consegue extrair o valor das mídias NVMe Gen4 e Gen5.

Minha recomendação técnica é pragmática: se você possui uma infraestrutura de rede 25GbE ou superior e arrays compatíveis, inicie a migração dos workloads mais críticos (Bancos de Dados, VDI de alta performance) para NVMe/TCP. Mantenha o iSCSI para workloads de arquivamento ou sistemas legados que não suportam o novo stack. O ganho de eficiência de CPU no host, por si só, muitas vezes justifica a mudança, permitindo maior densidade de VMs por servidor físico.

Referências & Leitura Complementar

• NVM Express Base Specification 2.0: Documentação oficial da arquitetura de filas e comandos.

• RFC 9300: Internet Small Computer Systems Interface (iSCSI) Extensions for the RDMA (Remote Direct Memory Access) Services (Contexto comparativo).

• NVM Express over Fabrics (NVMe-oF) TCP Transport Specification 1.0: A "bíblia" técnica de como o mapeamento de filas para conexões TCP deve ocorrer.

• SNIA (Storage Networking Industry Association): Whitepapers sobre "Performance Implications of NVMe-oF".

Perguntas Frequentes

1. Preciso de placas de rede (NICs) especiais para rodar NVMe/TCP? Não obrigatoriamente. Diferente do RoCE que exige NICs com suporte a RDMA, o NVMe/TCP roda em qualquer NIC Ethernet padrão. No entanto, NICs modernas com suporte a offload de NVMe/TCP ou tecnologias como ADQ (Application Device Queues) reduzirão significativamente o uso de CPU.

2. O NVMe/TCP é roteável? Sim, totalmente. Como ele utiliza o stack TCP/IP padrão, você pode rotear o tráfego entre subnets e até através de WANs (embora a latência da WAN afete a performance, o protocolo funciona).

3. Posso misturar iSCSI e NVMe/TCP na mesma rede física? Sim. Como ambos usam TCP/IP padrão, eles podem coexistir na mesma VLAN ou infraestrutura física. Recomenda-se, contudo, segregação lógica (VLANs distintas) ou física para garantir QoS e evitar que um "vizinho barulhento" afete a latência do storage.

4. O Multipathing funciona igual ao iSCSI? O conceito é similar, mas a implementação é diferente. O NVMe-oF utiliza um subsistema chamado ANA (Asymmetric Namespace Access) para informar ao host quais caminhos são otimizados e quais são não-otimizados, permitindo failover e balanceamento de carga muito mais inteligentes e rápidos do que o MPIO tradicional do iSCSI.