NVMe over TCP vs iSCSI: Modernizando a SAN sem Trocar o Switch

A infraestrutura de armazenamento vive um momento de contradição técnica. Temos arrays All-Flash capazes de entregar milhões de IOPS e latências na casa dos microssegundos, conectados a redes de 25GbE ou 100GbE. No entanto, em muitos datacenters, essa potência é estrangulada por um protocolo desenhado nos anos 80 para fitas magnéticas e discos mecânicos: o SCSI.

Durante anos, o iSCSI foi o cavalo de batalha da SAN Ethernet. Ele democratizou o storage compartilhado, permitindo que administradores fugissem dos custos proibitivos e da complexidade do Fibre Channel. Mas a física dos semicondutores mudou. Com a onipresença do NVMe, encapsular comandos SCSI dentro de pacotes TCP tornou-se um imposto de tradução alto demais para pagar.

A resposta da indústria não é necessariamente jogar fora seus switches e cabos para adotar Fibre Channel ou RDMA (RoCE). A solução está na evolução do protocolo de transporte: NVMe over TCP (NVMe/TCP).

Resumo em 30 segundos

O problema: O iSCSI serializa comandos, criando um gargalo de CPU e latência que desperdiça o potencial de SSDs NVMe modernos.

A solução: O NVMe/TCP estende o paralelismo do NVMe através da rede Ethernet padrão, sem exigir hardware proprietário ou configurações complexas de "Lossless Ethernet".

O ganho: Redução drástica na latência de cauda e aumento de IOPS utilizando a infraestrutura de switches e cabos que você já possui.

O gargalo de serialização do protocolo SCSI

Para entender por que o iSCSI está se tornando obsoleto para cargas de trabalho de alta performance, precisamos olhar para a fila de comandos. O protocolo SCSI foi projetado em uma era onde a CPU era infinitamente mais rápida que o disco. O objetivo era gerenciar a escassez de I/O.

O iSCSI opera fundamentalmente com uma única fila de comandos (ou muito poucas) por sessão. Quando você tem um array All-Flash NVMe do outro lado, o host precisa traduzir instruções NVMe nativas para comandos SCSI, encapsulá-los em TCP/IP, enviá-los pela rede, e o storage precisa fazer o processo inverso. Esse ciclo de tradução e a natureza serial do SCSI criam o que chamamos de lock contention. As CPUs modernas, com dezenas de núcleos, acabam brigando para acessar essa fila única.

Figura: Comparação visual: O gargalo da fila única do SCSI versus o paralelismo massivo das filas NVMe.

O NVMe foi desenhado do zero para memória não volátil. Ele suporta até 64.000 filas, com 64.000 comandos por fila. Isso permite que cada núcleo da CPU do seu servidor tenha sua própria fila dedicada de I/O até o disco, eliminando travas e espera.

A barreira do RoCE e a democratização via TCP

Quando o NVMe over Fabrics (NVMe-oF) surgiu, a primeira implementação dominante foi baseada em RDMA (Remote Direct Memory Access), especificamente o RoCE v2 (RDMA over Converged Ethernet).

O RoCE é tecnicamente superior em latência pura porque permite que o storage escreva diretamente na memória do servidor, ignorando a CPU. No entanto, ele cobra um preço alto na infraestrutura: exige uma rede Lossless Ethernet.

⚠️ Perigo: Implementar RoCE v2 exige switches com suporte a DCB (Data Center Bridging), PFC (Priority Flow Control) e ECN (Explicit Congestion Notification). Configurar isso corretamente em uma rede convergente é complexo e propenso a erros humanos que podem derrubar a SAN inteira se o controle de fluxo pausar o tráfego errado.

Muitos administradores de storage não controlam a rede. Pedir ao time de redes para habilitar PFC globalmente ou em VLANs específicas é muitas vezes um obstáculo político e técnico intransponível. É aqui que o NVMe over TCP brilha.

A arquitetura do NVMe over TCP

Padronizado pela NVM Express em 2018/2019, o NVMe/TCP encapsula os comandos NVMe e dados dentro de datagramas TCP padrão. Não há exigência de hardware especial. Se o seu switch passa tráfego TCP/IP, ele suporta NVMe/TCP.

A mágica acontece no software. O protocolo cria filas de I/O mapeadas diretamente para as threads da CPU. Diferente do iSCSI, que depende pesadamente de interrupções, o NVMe/TCP pode utilizar polling (sondagem) de alta eficiência, reduzindo o context switching e a latência percebida pela aplicação.

Figura: A pilha de protocolos simplificada: Note a ausência da camada de tradução SCSI no modelo NVMe/TCP.

Performance: O que esperar no mundo real

Não espere que o NVMe/TCP dobre sua taxa de transferência (throughput) se você já está saturando seus links de 25GbE com iSCSI. A largura de banda é limitada pela física do cabo. O ganho real está na latência e na eficiência de CPU por IOPS.

Em testes de laboratório e implementações de produção, observamos consistentemente:

Redução de Latência: Uma queda de 20% a 50% na latência média comparada ao iSCSI no mesmo hardware.
Consistência: A latência de cauda (o 99º percentil) é muito mais estável. Isso significa que bancos de dados transacionais sofrem menos "engasgos" aleatórios.
Custo de CPU: O NVMe/TCP consome mais ciclos de CPU do host para calcular o CRC (verificação de integridade) do que o RoCE (que faz isso no hardware). No entanto, com CPUs modernas (AMD EPYC/Intel Xeon Scalable), esse overhead é negligenciável para a maioria das aplicações, exceto as mais extremas.

💡 Dica Pro: Para mitigar o uso de CPU no host, verifique se suas placas de rede (NICs) suportam TCP Offload ou se são adaptadores modernos que já possuem otimizações para o fluxo de dados do NVMe/TCP. Mesmo sem SmartNICs completas, o offload básico ajuda muito.

Comparativo: Padrões de Conectividade SAN

Para situar onde o NVMe/TCP se encaixa no seu datacenter, veja a comparação direta:

Característica	iSCSI	NVMe over TCP	NVMe over RoCE (v2)	Fibre Channel (FC-NVMe)
Protocolo Base	SCSI	NVMe	NVMe	NVMe
Transporte	TCP/IP	TCP/IP	UDP/RDMA	Protocolo FC
Requisito de Rede	Ethernet Padrão	Ethernet Padrão	Lossless Ethernet (PFC/ECN)	Fabric FC Dedicado
Complexidade	Baixa	Baixa	Alta	Média (mas exige hardware dedicado)
Custo	Baixo	Baixo	Médio (Switches/NICs específicos)	Alto
Latência	Alta (Tradução SCSI)	Baixa	Muito Baixa (Bypass de Kernel)	Baixa
Roteável?	Sim	Sim	Sim (mas complexo na L3)	Não (geralmente L2 flat)

Implementação e Multipath: O salto do ALUA para o ANA

Uma das mudanças mais significativas ao migrar de iSCSI para NVMe-oF é a gestão de caminhos (multipathing). No mundo SCSI, dependemos do ALUA (Asymmetric Logical Unit Access) para que o storage diga ao host qual caminho é o "dono" do LUN.

No NVMe, utilizamos o ANA (Asymmetric Namespace Access). O ANA é muito mais dinâmico e granular. O subsistema de storage pode informar ao host, em tempo real, o estado de cada caminho para cada Namespace (o equivalente ao LUN no NVMe).

Se um controlador de storage estiver sobrecarregado ou em manutenção, ele notifica o host via ANA para redirecionar o I/O instantaneamente, sem os timeouts e pausas dramáticas que às vezes ocorrem no failover do iSCSI.

Figura: Topologia Leaf-Spine padrão suportando NVMe/TCP: Roteamento L3 completo sem hardware proprietário.

O veredito do arquiteto

O iSCSI cumpriu seu papel honrosamente por duas décadas. Ele não vai desaparecer da noite para o dia; para backups, arquivamento e cargas de trabalho secundárias em discos rotacionais (HDD), ele continua sendo uma opção robusta e barata.

Entretanto, para qualquer nova implantação envolvendo armazenamento All-Flash ou NVMe, insistir no iSCSI é subutilizar o investimento feito nos drives. O NVMe over TCP oferece o equilíbrio perfeito: entrega 80-90% da performance do RDMA/Fibre Channel com 100% da simplicidade e compatibilidade da Ethernet padrão.

Se você tem switches de 10GbE ou 25GbE modernos e arrays que suportam NVMe-oF, a migração é, na maioria das vezes, uma atualização de software e configuração, não um projeto de renovação de hardware (forklift upgrade). O futuro da SAN é Ethernet, e o idioma que ela fala é TCP.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Detalhes técnicos sobre a arquitetura de filas e transporte NVMe.
SNIA (Storage Networking Industry Association): "NVMe over TCP Transport Specification" – Documentação oficial sobre a implementação do transporte.
RFC 793 (TCP): A base do protocolo de transporte que viabiliza a compatibilidade universal.
RFC 9669: Especificações recentes sobre encapsulamento e otimizações de NVMe sobre tecidos IP.

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

Não. Diferente do NVMe/RoCE que exige suporte a RDMA, o NVMe/TCP roda em qualquer NIC Ethernet padrão, embora placas com offload de TCP (TOE) ajudem a reduzir o uso de CPU.

O NVMe over TCP é roteável entre subnets?

Sim. Como é baseado no protocolo TCP/IP padrão, ele é totalmente roteável, permitindo arquiteturas de storage que atravessam racks ou até datacenters (respeitando a latência).

Qual a diferença entre ALUA e ANA no multipath?

O ALUA é o padrão de multipath do SCSI/iSCSI. O ANA (Asymmetric Namespace Access) é o equivalente otimizado para NVMe, permitindo que o storage informe ao host quais caminhos são otimizados para performance em tempo real.