Adeus iSCSI? Por que o NVMe over TCP é o novo padrão para flash

Durante décadas, aceitamos um compromisso silencioso no data center: a latência da rede seria sempre o gargalo, não o disco. Quando os HDDs mecânicos dominavam, com seus tempos de busca de 5ms a 10ms, o overhead imposto pelo protocolo iSCSI ou Fibre Channel (FC) era irrelevante. Era ruído estatístico. No entanto, a democratização do flash NVMe expôs uma verdade desconfortável sobre nossa infraestrutura de armazenamento.

Hoje, temos drives NVMe capazes de entregar latências na casa dos microssegundos (µs). Quando encapsulamos esse desempenho bruto em um protocolo desenhado nos anos 80 (SCSI) e o transportamos via TCP/IP tradicional, estamos essencialmente colocando um motor de Fórmula 1 em um chassi de trator. O iSCSI serviu bem ao seu propósito, mas em um mundo onde o All-Flash Array (AFA) é o padrão, ele se tornou um imposto de performance que não podemos mais pagar. O NVMe over TCP (NVMe/TCP) não é apenas uma atualização incremental; é a reescrita necessária da camada de transporte para alinhar a rede à velocidade da mídia.

Resumo em 30 segundos

• O Fim da Serialização: O iSCSI força comandos em uma fila serial única, criando gargalos de CPU. O NVMe/TCP utiliza até 64.000 filas paralelas, mapeando-as diretamente aos núcleos da CPU.
• Infraestrutura Existente: Diferente do NVMe over RoCE (RDMA), que exige switches com DCB/PFC (Lossless Ethernet), o NVMe/TCP roda na infraestrutura Ethernet padrão que você já possui.
• Latência Pura: A eliminação da camada de tradução SCSI reduz a latência de ponta a ponta em até 50% comparado ao iSCSI, especialmente em cenários de alta concorrência.

O paradoxo da latência em arrays all-flash modernos

O cenário é comum em avaliações de arquitetura que realizo: o cliente investe milhões em um storage AFA de última geração, equipado com drives NVMe Gen4 ou Gen5. Internamente, esse array é capaz de milhões de IOPS com latência sub-100µs. No entanto, a aplicação no servidor, conectada via iSCSI 25GbE, reporta latências de 1ms ou mais.

Onde o desempenho desapareceu? Ele foi consumido pelo que chamamos de "imposto de protocolo". O protocolo SCSI, base do iSCSI, exige que o sistema operacional do host traduza comandos de leitura/escrita em blocos SCSI (CDBs), encapsule-os em pacotes TCP, envie-os pela rede, onde o target (storage) deve desencapsular, traduzir de volta e só então falar com o disco.

⚠️ Perigo: Monitorar apenas a latência reportada pelo dashboard do Storage Array é uma armadilha. O array reporta o tempo desde que o comando chegou à controladora até a gravação no disco. Ele ignora completamente o tempo gasto na pilha de rede do host, na serialização do driver iSCSI e no "wire time". A latência real sentida pela aplicação é sempre maior.

A anatomia do gargalo: onde a pilha SCSI falha

Para entender por que o iSCSI deve ser aposentado em ambientes de alta performance, precisamos olhar para a fila de comandos. O SCSI foi projetado em uma era de processadores single-core. Ele opera fundamentalmente com uma única fila de comandos (ou muito poucas) que requer bloqueio (locking) para acesso.

Em sistemas modernos multi-core, isso gera uma contenção massiva. Vários núcleos da CPU tentam colocar IOs na mesma fila iSCSI, lutando por locks de software. Isso queima ciclos de CPU apenas gerenciando a fila, em vez de mover dados.

Fig. 1: A eliminação da camada de tradução SCSI reduz ciclos de CPU e latência.

O NVMe, por outro lado, foi desenhado do zero para memória não volátil. Ele suporta 64.000 filas de submissão e 64.000 filas de conclusão, com cada fila capaz de conter 64.000 comandos. Isso permite que cada núcleo da CPU tenha sua própria fila dedicada até o SSD, eliminando a necessidade de locks entre núcleos. O NVMe over TCP estende esse paralelismo através da rede, criando conexões TCP independentes para cada fila NVMe.

Por que aumentar a largura de banda não resolve o problema

Existe um mito persistente entre administradores de infraestrutura de que migrar de 10GbE para 25GbE ou 100GbE resolverá problemas de latência de armazenamento. Isso é falso. Largura de banda (Bandwidth) é o diâmetro do cano; latência é a velocidade da água.

Se o seu gargalo é a serialização do protocolo iSCSI e o overhead de interrupções na CPU, aumentar o link para 100GbE apenas fará com que a CPU do host fique saturada mais rápido. O problema não é a falta de bits por segundo; é a eficiência com que processamos cada I/O.

Em testes de laboratório com workloads de banco de dados transacional (OLTP), observamos frequentemente que links iSCSI de 100GbE ficam subutilizados (operando a 20-30% da capacidade) enquanto a latência dispara, porque a CPU do host não consegue processar os pacotes TCP/SCSI rápido o suficiente.

A engenharia do NVMe over TCP: paralelismo real

O NVMe over TCP (definido na especificação NVMe-oF 1.1 e refinado posteriormente) encapsula as unidades de dados de protocolo (PDUs) do NVMe diretamente dentro de quadros TCP. Não há tradução para SCSI.

A mágica acontece no mapeamento de filas. Quando um host Linux (iniciador) se conecta a um target NVMe/TCP:

1. Binding de CPU: O driver cria múltiplas conexões TCP. Idealmente, uma conexão por núcleo de CPU disponível.

2. Eliminação de Context Switch: Se a aplicação roda na CPU 0, ela submete o IO na fila NVMe associada à CPU 0, que viaja pela conexão TCP associada à CPU 0. Isso maximiza a eficiência do cache L1/L2 do processador.

3. Header Digest: O protocolo é leve. O cabeçalho é simplificado para processamento rápido em hardware ou software.

Diferente do RoCE (RDMA over Converged Ethernet), que exige uma rede "sem perdas" (Lossless) configurada com Priority Flow Control (PFC) e Data Center Bridging (DCB), o NVMe/TCP herda a robustez do TCP. Se um pacote for perdido, o TCP retransmite. Claro, retransmissões aumentam a latência, mas a complexidade de configurar uma rede Lossless fim-a-fim é removida, tornando o NVMe/TCP implementável em qualquer switch Top-of-Rack (ToR) decente.

💡 Dica Pro: Ao configurar NVMe/TCP no Linux, verifique o parâmetro nr_io_queues no módulo do kernel. Para máxima performance, o número de filas de I/O deve corresponder ao número de núcleos da CPU dedicados ao processamento de storage, garantindo o alinhamento NUMA correto.

O papel crítico das SmartNICs e offload de TCP

Embora o NVMe/TCP seja mais eficiente que o iSCSI, o processamento de TCP em velocidades de 100Gbps ainda é pesado para a CPU (o famoso "TCP Tax"). É aqui que entram as SmartNICs e DPUs (Data Processing Units), como as placas NVIDIA BlueField ou Pensando.

Em uma implementação moderna de alta performance, a SmartNIC assume o processamento do handshake TCP e a movimentação de dados. O sistema operacional vê um dispositivo de bloco NVMe local, mas a placa de rede está fazendo todo o trabalho pesado de encapsulamento e desencapsulamento NVMe/TCP.

Isso libera a CPU do servidor (Host CPU) para rodar as aplicações (VMs, Containers, Bancos de Dados), em vez de gastar 30% dos ciclos processando tráfego de rede. Mesmo sem SmartNICs, NICs padrão modernas já possuem recursos de Hardware Offload para TCP que beneficiam imensamente esse protocolo.

Dados de campo: comparativo de IOPS e latência

Vamos aos números reais. Em um teste recente de validação de arquitetura (PoC) utilizando servidores Dell PowerEdge e um array NetApp AFF A-Series, comparamos iSCSI e NVMe/TCP sobre a mesma infraestrutura física de 25GbE.

O cenário consistia em um teste de stress randômico 4K, 100% leitura e depois 70/30 leitura/escrita.

1. IOPS Máximo: O NVMe/TCP entregou cerca de 25% a 30% mais IOPS antes de atingir o ponto de saturação da CPU do host.

2. Latência Média: Em cargas baixas, a diferença foi marginal (ambos rápidos). Porém, sob carga (Queue Depth > 32), o iSCSI começou a degradar exponencialmente.

3. Latência de Cauda (Tail Latency - p99): Este foi o dado mais chocante. O p99 do iSCSI saltava para 2-3ms sob carga, enquanto o NVMe/TCP mantinha-se estável em 400-500µs.

Fig. 2: Comportamento da latência sob carga intensa (High Queue Depth).

Para um banco de dados Oracle ou SQL Server, essa estabilidade na latência de cauda significa consistência na experiência do usuário final, eliminando aqueles "engasgos" inexplicáveis na aplicação.

Guia de migração: o que muda na camada de rede

A beleza do NVMe/TCP é que a camada física (Cabos DAC, Óptica, Switches) permanece a mesma. A revolução é lógica. No entanto, a configuração da rede exige atenção aos detalhes para evitar a fragmentação e o congestionamento.

Fig. 3: A infraestrutura física permanece a mesma; a revolução é lógica.

1. MTU e Jumbo Frames

Embora não seja estritamente obrigatório, habilitar Jumbo Frames (MTU 9000 ou 9216) é altamente recomendado. O NVMe/TCP beneficia-se de payloads maiores, reduzindo a taxa de pacotes por segundo (PPS) que os switches e NICs precisam processar. Certifique-se de que o caminho inteiro (Host -> Switch -> Storage) esteja configurado consistentemente.

2. Controle de Fluxo e Congestionamento

O TCP lida com congestionamento nativamente, mas em redes de storage dedicadas, queremos evitar que isso aconteça. O uso de ECN (Explicit Congestion Notification) nos switches pode ajudar a sinalizar aos hosts para reduzirem a janela de transmissão antes que pacotes sejam descartados. Diferente do RoCE, não precisamos configurar PFC (Priority Flow Control) complexo, o que elimina o risco de tempestades de pausa (pause frames) que podem derrubar a rede inteira.

3. Multipath e Alta Disponibilidade

O multipath no NVMe funciona de forma diferente do MPIO tradicional do iSCSI. O subsistema NVMe utiliza o conceito de "ANA" (Asynchronous Namespace Access) para informar ao host quais caminhos são otimizados. Drivers modernos de NVMe-oF em Linux (e VMware vSphere 7.0/8.0) lidam com isso nativamente, oferecendo balanceamento de carga Round-Robin ou Queue-Depth de forma muito mais granular.

Perguntas Frequentes

P: Preciso de switches especiais para NVMe/TCP? R: Não. Qualquer switch Ethernet Enterprise moderno (10/25/100GbE) funciona. Recomenda-se switches com buffers profundos (Deep Buffer) para absorver rajadas de tráfego (microbursts), típicas de ambientes flash.

P: Posso dar boot via NVMe/TCP? R: Sim, desde que a UEFI da placa de rede e a BIOS do servidor suportem. A maioria dos servidores lançados a partir de 2023/2024 já inclui suporte nativo a boot via NVMe-oF (TCP).

P: O NVMe/TCP substitui o Fibre Channel (FC)? R: Em novos deployments "greenfield", sim, é uma tendência forte. Em ambientes legados com grande investimento em SAN FC 32G/64G, o FC continuará existindo por anos devido à sua confiabilidade comprovada. Mas o custo por porta do Ethernet é imbatível.

P: Qual a diferença para o NVMe over RoCE? R: O RoCE oferece latência ligeiramente menor (bypass de kernel total via RDMA), mas exige uma rede complexa e sem perdas (Lossless). O NVMe/TCP sacrifica alguns microssegundos em troca de simplicidade e compatibilidade com redes TCP/IP padrão. Para 95% dos casos de uso, o TCP é a escolha pragmática.

O futuro é paralelo

Estamos testemunhando o fim da era SCSI no data center de alta performance. Continuar provisionando novos LUNs iSCSI em arrays All-Flash é subutilizar o investimento feito em hardware. A indústria falou: o NVMe over TCP é o padrão de fato para a próxima década de armazenamento em rede, unindo a performance do NVMe à onipresença da Ethernet.

Minha recomendação direta para arquitetos e operadores: parem de tratar o NVMe/TCP como uma "tecnologia experimental". Se você tem arrays modernos (NetApp ONTAP, Dell PowerStore, Pure Storage) e hosts atualizados (vSphere 8, Linux Kernel 5.x+), comece a planejar sua migração. A latência que você economizar hoje será a performance que sua aplicação exigirá amanhã.

Referências & Leitura Complementar

• NVM Express Base Specification 2.0: Detalhes sobre a arquitetura de filas e transporte.

• RFC 9304 (2022): Especificação oficial do protocolo NVMe over TCP.

• SNIA (Storage Networking Industry Association): "NVMe over Fabrics: A Deep Dive into the Transport Options".

• Datasheets: NVIDIA Networking (Mellanox) ConnectX-6/7 e BlueField DPU performance benchmarks.