iSER vs. NVMe-oF: Quando o iSCSI RDMA ainda vence (e quando migrar)
Análise forense de storage: compare a latência, overhead e trade-offs reais entre iSER (iSCSI over RDMA) e NVMe-oF. Saiba quando manter a infraestrutura atual ou investir na migração.
Você entra no data center, o ar condicionado zumbindo aquele ruído branco familiar. O cliente reclama de lentidão no banco de dados. "Mas nós acabamos de comprar switches de 100GbE e storage flash", dizem eles. Você olha para os gráficos de latência e vê picos erráticos. A rede sobra banda, os discos sobram IOPS, mas a aplicação engasga.
Aqui começa a nossa autópsia. O suspeito usual é a rede, mas em arquiteturas modernas, o verdadeiro culpado muitas vezes é a linguagem que o storage e o servidor usam para conversar. É aqui que entra a batalha entre iSER (iSCSI Extensions for RDMA) e o NVMe-oF (NVMe over Fabrics).
Muitos arquitetos migram cegamente para NVMe-oF seguindo o hype do mercado, enquanto outros se agarram ao iSCSI TCP legado por medo de complexidade. A verdade forense está no meio: o protocolo de transporte deve casar com a mídia física subjacente. Vamos dissecar essa pilha para entender onde os ciclos de CPU estão morrendo.
O que é iSER e NVMe-oF?
iSER (iSCSI Extensions for RDMA) é um protocolo que mapeia comandos iSCSI diretamente na memória via RDMA, eliminando a cópia de dados do TCP/IP, mas mantendo a estrutura de comandos SCSI. NVMe-oF (NVMe over Fabrics) é uma especificação que estende a eficiência do protocolo NVMe local através da rede, eliminando totalmente a camada SCSI e permitindo paralelismo massivo de filas (queues) inatingível por tecnologias legadas.
O Problema da Pilha TCP: Onde a latência se esconde
Quando você usa iSCSI padrão (sobre TCP), você está pedindo ao seu servidor para empacotar dados de armazenamento em pacotes de rede, passar pelo kernel, gerar interrupções de CPU, fazer handshakes de TCP, e só então enviar o dado. É burocracia computacional.
Em links de 10GbE, o TCP era aceitável. Em 25GbE ou 100GbE, o protocolo TCP consome tanto tempo de CPU apenas para processar o tráfego de rede que sobra pouco para a aplicação real (o banco de dados ou a VM). Chamamos isso de "overhead de protocolo".
É aqui que o RDMA (Remote Direct Memory Access) entra. Ele permite que o storage escreva diretamente na memória do servidor (e vice-versa) sem acordar a CPU do host para cada pacote. Tanto o iSER quanto o NVMe-oF usam RDMA (seja via RoCE ou InfiniBand).
Figura: Comparação da Pilha de Protocolos: Note como o NVMe-oF elimina tanto o overhead do TCP quanto a tradução SCSI.
Como a imagem acima ilustra, a diferença fundamental não é apenas a velocidade do fio, mas quantas camadas de software temos que atravessar. O iSER remove o TCP, mas mantém o SCSI. O NVMe-oF remove tudo.
Anatomia do Protocolo: A Taxa de Tradução SCSI no iSER
Se o iSER usa RDMA e remove o gargalo do TCP, por que ele perderia para o NVMe-oF? A resposta está na tradução.
O iSER é, essencialmente, um "turbo" no motor de um fusca. O transporte é rapidíssimo (RDMA), mas a linguagem ainda é SCSI. O protocolo SCSI foi desenhado décadas atrás para discos mecânicos que giravam pratos magnéticos. Ele espera confirmações sequenciais.
Quando o comando chega no storage via iSER, o controlador ainda precisa traduzir esse comando SCSI para algo que o disco entenda. Se o disco for um SSD moderno, essa camada de tradução (SCSI-to-Flash) adiciona microssegundos preciosos de latência. Para cargas de trabalho moderadas, é imperceptível. Para High-Performance Computing (HPC) ou bancos de dados transacionais pesados, é uma eternidade.
NVMe-oF e o Paralelismo: Eliminando o gargalo da fila única
A grande revolução do NVMe (local ou over Fabrics) não é a largura de banda, é a profundidade de fila (Queue Depth).
O Mundo SCSI (iSER/iSCSI): Imagine um guichê único de pedágio. Não importa o quão rápido o atendente seja, os carros (IOPS) precisam formar uma fila única (ou poucas filas) por LUN. O bloqueio de cabeça de fila (Head-of-Line Blocking) é real.
O Mundo NVMe: O NVMe suporta 64.000 filas, cada uma com 64.000 comandos de profundidade. É como um pedágio com 64 mil guichês.
Figura: Escalabilidade de Filas: O impacto do paralelismo do NVMe-oF em altas profundidades de fila (Queue Depth).
Ao analisar a evidência na imagem acima, note que em baixas profundidades de fila (QD), a diferença é pequena. Mas conforme a carga sobe (o cenário real de um cluster de virtualização em horário de pico), o iSER começa a sofrer com a serialização do SCSI, enquanto o NVMe-oF escala linearmente.
O Fator Mídia: Quando o SSD SATA torna a migração para NVMe-oF irrelevante
Aqui entra o ceticismo necessário do investigador. Você não pode consertar um problema físico com um protocolo lógico.
Já vi empresas implementarem redes de 100GbE com NVMe-oF (RoCEv2) caríssimas, conectadas a um storage array cheio de... SSDs SATA ou SAS.
Se a mídia backend (o disco) é SATA/SAS, ela fala SCSI nativamente.
O servidor envia NVMe-oF (rápido).
O controlador do storage recebe NVMe.
O controlador precisa traduzir NVMe de volta para SCSI para falar com o SSD SATA.
Nesse cenário, você apenas moveu o gargalo de lugar e pagou caro por isso. Se o seu backend não é NVMe nativo (end-to-end), o ganho do NVMe-oF sobre o iSER é marginal ou inexistente.
Comparativo Técnico: iSCSI vs iSER vs NVMe-oF
Para tomar a decisão correta, precisamos alinhar as evidências lado a lado.
| Característica | iSCSI (TCP Standard) | iSER (Block over RDMA) | NVMe-oF (NVMe over Fabrics) |
|---|---|---|---|
| Transporte | TCP/IP (CPU Heavy) | RDMA (Zero Copy) | RDMA ou FC ou TCP (Otimizado) |
| Protocolo de Comando | SCSI | SCSI | NVMe |
| Uso de CPU (Host) | Alto | Baixo | Muito Baixo |
| Paralelismo (Queues) | Baixo (1 fila/LUN tipicamente) | Limitado pelo SCSI | Massivo (64k filas) |
| Requisito de Rede | Ethernet Padrão | Ethernet com suporte a Flow Control (PFC/ECN) ou InfiniBand | Ethernet Lossless (PFC/ECN), FC ou TCP |
| Complexidade | Baixa (Plug & Play) | Média (Requer config de switch) | Alta (Drivers, Multipath específico) |
| Custo/Benefício Ideal | Backups, Arquivos, VMs leves | Banco de Dados em Flash SAS/SATA | AI/ML, HPC, Banco de Dados em All-NVMe |
Ecossistema e Compatibilidade: Onde o iSCSI ainda reina
Antes de declarar o iSER morto, vamos olhar para a compatibilidade. O iSER tem uma vantagem tática enorme: para o sistema operacional (VMware ESXi, Linux, Windows), ele ainda parece um disco SCSI.
Isso significa que suas ferramentas de backup (Veeam, Commvault), seus scripts de snapshot e seus mecanismos de multipathing antigos continuam funcionando quase sem alterações.
O NVMe-oF muda a forma como o dispositivo é apresentado (/dev/nvme0n1 vs /dev/sda). Isso pode quebrar:
Boot from SAN: Nem todas as placas de rede/BIOS suportam boot via NVMe-oF facilmente.
VMware VAAI: Alguns offloads específicos do SCSI não têm equivalentes diretos ou maduros em todas as implementações NVMe.
Hardware Legado: Switches antigos que não suportam Priority Flow Control (PFC) ou ECN vão destruir a performance do NVMe-oF (e do iSER) ao dropar pacotes. O RDMA odeia perda de pacotes.
Medindo a Verdade: Comandos e métricas para validar a troca
Como investigador, não confie no datasheet. Meça. Se você já tem o hardware ou está fazendo uma PoC (Prova de Conceito), use estas ferramentas para verificar se o protocolo está entregando o prometido.
1. Verificando se o RDMA está ativo
No Linux, verifique se você está realmente usando as interfaces RDMA ou se caiu para o TCP.
ibstat
# Verifique contadores de tráfego RDMA (procure por erros de transmissão)
perfquery
2. Latência de Dispositivo e Filas
Use o iostat estendido para ver se há gargalo na fila do dispositivo local.
# -x para estendido, -d para disco, -k para KB, 1 segundo de intervalo
iostat -xdk 1
Olhe para a coluna avgqu-sz (tamanho médio da fila) e await (latência total). Se await é alto mas o svctm (tempo de serviço do disco) é baixo, o gargalo é o protocolo/fila.
3. NVMe Nativo
Se estiver testando NVMe-oF, use a CLI nativa para ver como o controlador está sendo enxergado.
# Listar subsistemas NVMe conectados
nvme list-subsys
# Testar latência bruta do dispositivo (bypassando filesystem)
# CUIDADO: Isso é destrutivo em testes de escrita
fio --name=random-write --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=4G --iodepth=64 --filename=/dev/nvme0n1
Veredito: Matriz de Decisão para Arquitetos de Storage
A decisão final não é sobre qual protocolo é "melhor", mas qual resolve o problema sem introduzir complexidade desnecessária.
Figura: Fluxo de Decisão: Quando manter iSER vs Migrar para NVMe-oF baseado em hardware e requisitos.
Use iSER se:
Você tem um Storage All-Flash baseado em SAS/SATA.
Sua infraestrutura de rede suporta RDMA (RoCE/iWARP) mas você precisa de compatibilidade total com ferramentas baseadas em SCSI.
Você quer reduzir o uso de CPU do host sem reconfigurar toda a camada de aplicação.
Migre para NVMe-oF se:
Seu Storage é "End-to-End NVMe" (Discos NVMe + Controlador NVMe).
Você precisa de mais de 500k IOPS por host ou latência sub-100µs.
Suas aplicações são altamente paralisáveis (HPC, AI Training, Sharded Databases).
Fique no iSCSI TCP se:
Sua rede é 1GbE ou 10GbE "suja" (sem suporte a Flow Control/Lossless).
O custo de complexidade de configurar switches para RDMA supera o benefício de performance.
O gargalo atual são os discos mecânicos (HDD).
A regra de ouro da forense de sistemas se aplica aqui: Não otimize o que não é o gargalo. Se seus discos são lentos, o NVMe-oF é apenas um cano mais largo para uma torneira que pinga.
Referências & Leitura Complementar
NVM Express Base Specification 2.0 - Detalhes sobre a arquitetura de filas e comandos NVMe.
RFC 7145 (iSCSI Extensions for RDMA) - A especificação técnica de como o iSCSI mapeia para RDMA.
SNIA (Storage Networking Industry Association) - Whitepapers sobre "Performance Implications of NVMe-oF vs iSER".
Mellanox/NVIDIA Networking Community - Tutoriais práticos sobre configuração de RoCEv2 e PFC em switches.
Alexei Volkov
Ceph Cluster Administrator
Escala clusters Ceph para o infinito. Mestre em CRUSH maps e recuperação de placement groups.