Por que o iSCSI está matando seus SSDs e como o NVMe/TCP salva o dia

Se você gastou o orçamento anual da empresa em arrays All-Flash NVMe de última geração, mas ainda os conecta via iSCSI, tenho más notícias: você acabou de comprar uma Ferrari para andar em uma zona escolar. O gargalo não é mais o disco; é o protocolo que você insiste em usar porque "sempre funcionou assim".

O iSCSI foi um herói na era dos discos rotacionais (HDDs), onde a latência mecânica mascarava qualquer ineficiência do protocolo. Mas no mundo do armazenamento flash, onde a latência é medida em microssegundos, o iSCSI é uma âncora enferrujada arrastando sua infraestrutura para o fundo do oceano. E não, a solução não é comprar switches Fibre Channel proprietários que custam mais que a educação universitária dos seus filhos. A resposta está no protocolo que já domina a internet: TCP.

Resumo em 30 segundos

O problema de tradução: O iSCSI obriga seus SSDs NVMe a "falar" SCSI, um protocolo desenhado para fitas e discos magnéticos dos anos 80, desperdiçando ciclos de CPU em tradução.

A armadilha do RoCE: Embora o NVMe-over-Fabrics (RoCEv2) seja rápido, ele exige uma rede "Lossless" complexa e switches caros, transformando a configuração em um pesadelo operacional.

A salvação do NVMe/TCP: Ele oferece performance próxima ao RDMA usando a infraestrutura Ethernet padrão que você já possui, democratizando a alta performance sem o "imposto de complexidade".

O gargalo oculto na tradução de comandos SCSI

Para entender por que sua latência está alta, precisamos olhar para a pilha de software. O protocolo NVMe (Non-Volatile Memory Express) foi criado do zero para entender a natureza paralela da memória flash. Ele suporta até 64.000 filas de comando, com 64.000 comandos por fila. É uma autoestrada massiva.

O SCSI (Small Computer System Interface), base do iSCSI, foi desenhado quando um disco rígido fazia barulho de cafeteira. Ele é serial. Ele opera, essencialmente, com uma única fila de comandos.

Quando você usa iSCSI com backends NVMe, ocorre um processo brutal de encapsulamento e tradução:

A aplicação envia um comando.
O sistema operacional encapsula isso em SCSI.
O driver iSCSI encapsula o SCSI em TCP/IP.
O pacote viaja pela rede.
O target (storage) desencapsula o TCP.
O target traduz o SCSI de volta para comandos NVMe nativos para falar com o disco.

💡 Dica Pro: Cada ciclo de CPU gasto traduzindo SCSI para NVMe é um ciclo roubado da sua aplicação ou do seu throughput. Em escalas de Petabytes, isso não é apenas ineficiente; é financeiramente irresponsável.

Figura: Comparação visual: O engarrafamento serial do iSCSI versus o paralelismo massivo do NVMe.

A anatomia do encapsulamento em redes de alta velocidade

O problema não é apenas a tradução; é a serialização. O iSCSI bloqueia. Ele espera a confirmação (ACK) de uma forma que mata o paralelismo inerente dos SSDs modernos.

O NVMe over Fabrics (NVMe-oF) resolve isso estendendo o protocolo NVMe nativo através da rede. Sem tradução SCSI. O comando que sai do servidor é o mesmo que chega ao disco. Inicialmente, a indústria apostou tudo no RDMA (Remote Direct Memory Access) via RoCEv2 (RDMA over Converged Ethernet).

E aqui começaram os problemas.

Por que o RoCEv2 transforma a rede em um pesadelo

O RoCEv2 promete latência quase zero e bypass de CPU. Soa incrível no papel ou em benchmarks de laboratório patrocinados por fabricantes de NICs. Na vida real, o RoCEv2 exige uma rede Lossless Ethernet.

Isso significa que você precisa configurar PFC (Priority Flow Control) e DCB (Data Center Bridging) em todos os switches do caminho. Se um pacote for dropado, a performance despenca. Configurar PFC em uma rede de produção mista é uma das maneiras mais rápidas de causar um "head-of-line blocking" e derrubar não só o storage, mas todo o tráfego do cluster.

Você quer ser o arquiteto que explica ao CTO que o banco de dados parou porque a configuração de QoS do switch 3 estava errada? Eu não.

A arquitetura do NVMe over TCP em hardware commodity

É aqui que o NVMe/TCP brilha. Ratificado pela NVM Express org em 2018/2019, ele pega a semântica do NVMe e a coloca dentro de datagramas TCP padrão.

Por que isso é genial?

TCP é resiliente: A internet inteira roda sobre ele. Ele lida com perda de pacotes, retransmissão e congestionamento nativamente. Você não precisa de redes Lossless.
Hardware Commodity: Funciona no switch Top-of-Rack que você comprou há 3 anos. Funciona através de roteadores. Funciona na nuvem.
Custo: Zero investimento em hardware de rede exótico (Infiniband ou FC switches).

Comparando latência e overhead de CPU

Os puristas dirão: "Mas o TCP tem overhead de CPU!". Sim, tem. O processamento da pilha TCP/IP consome ciclos do processador host. No entanto, a Lei de Moore (ou o que restou dela) e a engenharia de software mitigaram isso drasticamente.

Tecnologias como ADQ (Application Device Queues) da Intel permitem que filas de tráfego NVMe/TCP sejam isoladas e tratadas por threads específicas da CPU, melhorando a previsibilidade da latência.

Em testes reais, a diferença de latência entre NVMe/RoCE e NVMe/TCP é frequentemente menor que 10-20 microssegundos. Para 99% das cargas de trabalho corporativas, essa diferença é irrelevante, mas a complexidade operacional do RoCE é um fardo diário.

Figura: A complexidade operacional do RoCEv2 versus a simplicidade "plug-and-play" do NVMe/TCP em infraestrutura padrão.

Tabela comparativa: O estado da arte do storage em rede

Para os gerentes que precisam de slides para justificar a migração, aqui está a realidade nua e crua:

Característica	iSCSI (Legacy)	NVMe over RoCEv2	NVMe over TCP
Protocolo Base	SCSI sobre TCP	NVMe sobre RDMA (UDP)	NVMe sobre TCP
Paralelismo	Baixo (Serial)	Altíssimo (64k filas)	Altíssimo (64k filas)
Requisito de Rede	Ethernet Padrão	Ethernet Lossless (PFC/DCB)	Ethernet Padrão
Complexidade de Config	Baixa	Alta (Pesadelo)	Baixa
Uso de CPU (Host)	Médio/Alto (Tradução)	Baixo (Offload)	Médio (Otimizável c/ ADQ)
Custo de Hardware	Baixo	Alto (Switches/NICs Específicos)	Baixo
Caso de Uso Ideal	HDDs, Legado, Boot	HPC, Supercomputadores	Enterprise Storage, Cloud, Containers

⚠️ Perigo: Não tente implementar RoCEv2 sem uma equipe de engenharia de rede dedicada. A "economia" de CPU será rapidamente consumida pelo custo de troubleshooting de rede.

O futuro é chato (e isso é bom)

Estamos vendo uma mudança tectônica. Grandes players de armazenamento e provedores de nuvem estão adotando o NVMe/TCP como o padrão de facto para armazenamento em bloco de alta performance. O VMware vSphere 7.0 U3 adicionou suporte nativo. A AWS e a Azure utilizam variantes dessa tecnologia para seus discos EBS e Managed Disks.

O iSCSI não vai desaparecer amanhã — protocolos de armazenamento têm uma meia-vida maior que resíduos nucleares. Mas para qualquer nova implementação envolvendo Flash, ele é tecnicamente obsoleto.

Minha recomendação? Pare de lutar contra a maré. O NVMe/TCP oferece 80-90% da performance do RDMA com 10% da dor de cabeça. Em um mundo onde a complexidade é o inimigo da disponibilidade, escolher a opção que roda na infraestrutura que você já domina não é apenas inteligente; é a única arquitetura sustentável.

Referências & Leitura Complementar

Para os céticos que querem ver os bits e bytes:

NVM Express Base Specification 2.0: Detalha a arquitetura de filas e comandos que tornam o iSCSI obsoleto.
NVM Express over Fabrics (NVMe-oF) Specification: A "bíblia" de como o NVMe trafega na rede.
SNIA (Storage Networking Industry Association): Whitepapers sobre a performance comparativa de transportes NVMe-oF.
Intel Ethernet 800 Series com ADQ: Documentação técnica sobre como mitigar o overhead de TCP em NICs modernas.

Perguntas Frequentes (FAQ)

O NVMe over TCP exige switches especiais?

Não. Diferente do RoCEv2, que exige switches com suporte a DCB/PFC (Lossless Ethernet) para evitar a perda de pacotes que destruiria a performance, o NVMe/TCP funciona em qualquer switch Ethernet padrão. Isso reduz drasticamente o custo (CapEx) e a complexidade operacional (OpEx), permitindo usar a infraestrutura de rede existente.

Qual a diferença de performance entre iSCSI e NVMe/TCP?

Benchmarks indicam que o NVMe/TCP pode oferecer até 50% mais IOPS e reduzir a latência em 30-40% comparado ao iSCSI no mesmo hardware. A mágica acontece devido ao paralelismo de filas (multi-queue) e à eliminação da camada de tradução SCSI, permitindo que o protocolo escale linearmente com o número de núcleos da CPU.

Preciso de placas de rede (NICs) específicas?

Não estritamente. Qualquer NIC Ethernet moderna funciona, pois o protocolo é apenas TCP/IP padrão. No entanto, para ambientes de altíssima densidade, placas com suporte a offload de TCP e tecnologias como ADQ (Application Device Queues) são recomendadas, pois reduzem significativamente o uso de CPU do host e garantem latência mais consistente.