NVMe-oF vs iSCSI em 2025: O Fim da Era SCSI e a Realidade do Storage Desagregado
NVMe over Fabrics (NVMe-oF) não é apenas mais rápido que iSCSI, é arquiteturalmente diferente. Analisamos NVMe/TCP, RDMA e o suporte nativo no Windows Server para decidir o futuro do seu storage.
Durante as últimas duas décadas, o armazenamento em rede viveu sob a hegemonia do protocolo SCSI. Mesmo quando migramos de HDDs rotacionais para SSDs SATA, e depois para NVMe local, o transporte dos dados pela rede continuou encapsulado em um protocolo desenhado nos anos 80 para fitas magnéticas e discos mecânicos.
Em 2025, a infraestrutura de armazenamento atingiu um ponto de inflexão. Com redes de 100GbE se tornando commodity e o armazenamento All-Flash sendo o padrão, o gargalo deixou de ser a mídia ou o link físico. O gargalo é o protocolo. Continuar usando iSCSI em arrays All-NVMe é como comprar uma Ferrari e trocar o motor por um de fusca para economizar na gasolina: funciona, mas você está desperdiçando a engenharia do chassi.
O que é NVMe-oF? NVMe over Fabrics (NVMe-oF) é uma especificação de protocolo que estende o conjunto de comandos NVMe através da rede (Ethernet, Fibre Channel ou InfiniBand), eliminando a camada de tradução SCSI. Diferente do iSCSI, que serializa comandos, o NVMe-oF suporta paralelismo massivo e múltiplas filas, reduzindo drasticamente a latência e o overhead de CPU no host e no storage.
A Morte da Tradução SCSI e a Superioridade do NVMe-oF
Para entender por que o iSCSI está se tornando obsoleto para cargas de alta performance, precisamos olhar para a pilha de software (stack). O iSCSI opera sob a premissa de que o sistema operacional fala SCSI. Quando uma aplicação solicita um dado, o SO gera um comando SCSI. O driver iSCSI encapsula isso em TCP/IP, envia pela rede, o storage recebe, desencapsula o TCP, lê o comando SCSI e — aqui está o problema — precisa traduzi-lo para NVMe para falar com o SSD moderno.
Essa tradução bidirecional consome ciclos de CPU preciosos e adiciona latência intrínseca.
Figura: A Taxa de Tradução: O iSCSI obriga o sistema a converter comandos modernos em linguagem de 1980. O NVMe-oF fala a língua nativa do Flash.
O NVMe-oF remove o intermediário. O SO fala NVMe nativamente. O comando é encapsulado de forma leve e enviado. O storage recebe e executa diretamente na mídia. Não há "dicionário" SCSI no meio do caminho. Em testes controlados, apenas a remoção dessa camada de tradução pode reduzir a latência de acesso em 30% a 50%, mesmo mantendo a mesma velocidade de rede.
Paralelismo e Filas: Comparando a Arquitetura de I/O
A maior diferença arquitetural, no entanto, não é a tradução, mas o gerenciamento de filas. O protocolo SCSI (e consequentemente o iSCSI) foi desenhado em uma era de processadores single-core. Ele opera fundamentalmente com uma fila de comando única (ou muito poucas).
Isso cria um gargalo de bloqueio (locking). Em um servidor moderno com 64 cores tentando acessar o storage via iSCSI, esses cores precisam competir pelo acesso à fila do driver iSCSI. O resultado é contenção de CPU e latência de cauda (tail latency).
Figura: O Gargalo da Fila Única: Enquanto o iSCSI serializa o tráfego, o NVMe-oF permite até 64k filas, alinhando o I/O com a arquitetura multi-core das CPUs modernas.
O NVMe foi desenhado na era multi-core. O NVMe-oF suporta até 64.000 filas de I/O, com profundidade de 64.000 comandos por fila. Isso permite que cada core da CPU tenha sua própria fila dedicada para falar com o storage, sem necessidade de locking com outros cores.
O Impacto no Throughput Real
Em um teste de carga sintética (fio) com 4K random read:
iSCSI: O throughput escala até saturar o core da CPU responsável pelo driver iSCSI. O link de rede muitas vezes sobra.
NVMe-oF: O throughput escala linearmente com o número de cores disponíveis até saturar o link de rede ou a mídia.
A Guerra dos Transportes em 2025: Por que NVMe/TCP Venceu
Quando o NVMe-oF surgiu, a indústria apostou pesado no RDMA (Remote Direct Memory Access) através de RoCEv2 (RDMA over Converged Ethernet). O RDMA permite que os dados passem da memória do storage para a memória do servidor sem tocar na CPU. É tecnicamente superior e oferece a menor latência absoluta.
Porém, o RoCEv2 exige uma rede "Lossless" (sem perda de pacotes), configurada com Priority Flow Control (PFC) e Data Center Bridging (DCB). Configurar isso em escala é um pesadelo operacional. Um erro de configuração no switch pode paralisar a rede de storage.
Em 2025, o NVMe/TCP emergiu como o vencedor pragmático para 90% dos data centers corporativos.
Por que NVMe/TCP?
Infraestrutura Existente: Roda em switches Ethernet padrão, sem necessidade de configurações exóticas de DCB/PFC.
Roteamento: O TCP é o protocolo mais robusto da internet. Ele lida com retransmissões e congestionamento nativamente.
Performance "Good Enough": A sobrecarga do TCP moderno (com offload em NICs) é mínima comparada ao ganho de remover o SCSI. A diferença de latência entre NVMe/TCP e NVMe/RoCE é frequentemente medida em microssegundos de um dígito, irrelevante para a maioria das aplicações que não sejam High Frequency Trading.
O Ecossistema Windows Server e Linux
Até recentemente, o suporte a NVMe-oF no Windows era limitado ou dependia de drivers de terceiros. Em 2025, o cenário amadureceu.
Linux
O Linux continua sendo a referência. O suporte no kernel é maduro tanto para Target quanto para Initiator. Conectar a um target NVMe/TCP é trivial e não exige daemons complexos como o iscsid.
# Exemplo de descoberta e conexão em Linux (nvme-cli)
# Descobrir targets no IP 192.168.10.50
nvme discover -t tcp -a 192.168.10.50 -s 8009
# Conectar ao subsistema
nvme connect -t tcp -n nqn.2014-08.org.nvmexpress:uuid:f8a... -a 192.168.10.50 -s 8009
Windows Server
A Microsoft integrou iniciadores NVMe/TCP nativos nas versões mais recentes do Windows Server. Isso eliminou a necessidade de "workarounds" ou gateways iSCSI na frente de arrays NVMe. O suporte a Direct Drive Access (DDA) no Hyper-V para passar funções NVMe virtuais também melhorou, permitindo que VMs falem NVMe-oF quase nativamente.
Benchmark Teórico vs Realidade: O que medir?
Como engenheiro de performance, você deve ser cético com números de folha de dados ("1 Milhão de IOPS"). No mundo real, duas métricas importam mais na comparação NVMe-oF vs iSCSI:
Latência de Cauda (p99 e p99.9): O iSCSI sofre com variações de latência sob carga pesada devido ao enfileiramento serial. O NVMe-oF mantém a latência consistente. Em bancos de dados transacionais, o p99 do NVMe-oF costuma ser 3x a 5x menor que o do iSCSI.
CPU Wait / System Time: Meça quanto de CPU o host gasta para processar I/O. Com iSCSI em 100GbE, é comum ver um core a 100% em SoftIRQ. Com NVMe/TCP, a carga é distribuída. Isso significa que você libera CPU do servidor para rodar a aplicação, não o storage.
Callout: Cuidado com o MTU O overhead do cabeçalho TCP/IP é significativo em pacotes pequenos. Para NVMe/TCP, o uso de Jumbo Frames (MTU 9000) é praticamente obrigatório para atingir throughput de linha em 25GbE ou superior, reduzindo a taxa de pacotes por segundo (PPS) que a CPU precisa processar.
Tabela Comparativa: iSCSI vs NVMe/TCP vs NVMe/RoCE
| Característica | iSCSI | NVMe/TCP | NVMe/RoCE (RDMA) |
|---|---|---|---|
| Protocolo Base | SCSI sobre TCP | NVMe sobre TCP | NVMe sobre RDMA |
| Complexidade de Rede | Baixa (TCP Padrão) | Baixa (TCP Padrão) | Alta (Exige DCB/PFC/Lossless) |
| Paralelismo (Filas) | Baixo (Gargalo Serial) | Massivo (64k filas) | Massivo (64k filas) |
| Overhead de CPU | Alto (Tradução + TCP) | Médio (Sem tradução + TCP) | Mínimo (Offload total) |
| Custo de Hardware | NICs padrão | NICs padrão | NICs e Switches compatíveis com RDMA |
| Caso de Uso Ideal | HDDs, Legado, 1Gb/10Gb | All-Flash Genérico, Cloud | HPC, AI/ML, Supercomputação |
Checklist de Migração: O que muda na rede
Se você decidiu migrar de iSCSI para NVMe/TCP, não basta mudar o protocolo no storage. Sua rede precisa estar preparada:
MTU 9000 (Jumbo Frames): Configure end-to-end (Switch, NIC do Host, Porta do Storage). Teste com
ping -M do -s 8972 <ip-destino>.Flow Control: Diferente do RoCE, o NVMe/TCP se beneficia do controle de fluxo padrão do TCP, mas verifique se o Global Pause nas portas do switch não está causando head-of-line blocking.
Isolamento de Tráfego: NVMe-oF pode saturar links rapidamente. O uso de VLANs dedicadas ou switches fisicamente separados para o tráfego de storage (Air-gapped) é ainda mais crítico do que no iSCSI.
Drivers de NIC: Use drivers do fabricante (Mellanox, Intel, Broadcom) em vez dos genéricos do SO. O suporte a Hardware Offload para TCP checksum e segmentação (TSO/LRO) é vital.
Veredito: Quando manter o iSCSI e quando migrar
O iSCSI não morreu, mas foi relegado.
Mantenha o iSCSI se:
Sua rede é 1GbE ou 10GbE baseada em cobre (10GBASE-T) onde a latência da rede já é alta.
Seu backend de storage é composto por discos mecânicos (HDDs) ou SSDs SATA antigos.
Você não tem controle sobre a infraestrutura de switches (ex: ambientes compartilhados restritivos).
Migre para NVMe-oF (Preferencialmente TCP) se:
Você possui arrays All-Flash NVMe.
Sua rede é 25GbE, 100GbE ou superior.
Você roda bancos de dados de alta performance, virtualização densa ou containers (Kubernetes).
Você observa alta latência de CPU (iowait) nos seus servidores atuais.
A era do SCSI cumpriu seu papel. Mas em 2025, insistir na tradução de comandos é um imposto de performance que sua infraestrutura não precisa mais pagar.
Referências & Leitura Complementar
NVM Express Base Specification 2.0 – Seção sobre NVMe over Fabrics e Transport Bindings.
RFC 3720 – Internet Small Computer Systems Interface (iSCSI).
RFC 9302 – NVMe over TCP.
Intel Ethernet 800 Series: NVMe over TCP Performance Guide (Whitepaper técnico sobre tuning de NICs).
Otávio Henriques
Arquiteto de Soluções Enterprise
"Com duas décadas desenhando infraestruturas críticas, olho além do hype. Foco em TCO, resiliência e trade-offs, pois na arquitetura corporativa a resposta correta quase sempre é 'depende'."