NVMe over TCP no Kubernetes: O Fim do Gargalo de Storage para Bancos de Dados

Você já viu esse filme: o cluster Kubernetes está saudável, a CPU dos nós está em 30%, mas o banco de dados está engasgando. O DBA aponta para o tempo de resposta do disco, o DevOps aponta para a rede, e o gráfico de I/O Wait sobe silenciosamente.

Se você está tentando rodar cargas de trabalho estaduais (stateful workloads) intensivas, como PostgreSQL, MongoDB ou ElasticSearch no Kubernetes, provavelmente já esbarrou no limite físico dos protocolos legados. Tratar um banco de dados como se fosse um microsserviço stateless é a receita para o desastre, e a camada de armazenamento é quase sempre a culpada.

A promessa do armazenamento nativo em nuvem sempre esbarrou em um dilema: ou você usa Local PVs (discos locais) e perde a mobilidade do pod (se o nó cai, o dado fica preso lá), ou usa armazenamento em rede (NAS/SAN) e sofre com a latência do protocolo. O NVMe over TCP (NVMe/TCP) surgiu para eliminar essa escolha binária, entregando performance de barramento local através de cabos Ethernet padrão.

Resumo em 30 segundos

O Fim do iSCSI: Protocolos baseados em SCSI foram desenhados para discos rotacionais e não conseguem lidar com o paralelismo massivo dos SSDs NVMe modernos, criando gargalos de CPU e latência.

Infraestrutura Padrão: Ao contrário do NVMe-oF via RDMA (RoCE), o NVMe/TCP não exige switches caros ou configurações de rede complexas (Flow Control/PFC). Ele roda na sua infraestrutura Ethernet existente.

Desacoplamento Real: Permite separar computação de armazenamento sem penalidade de performance, garantindo que o Kubernetes possa reagendar pods de banco de dados em qualquer nó instantaneamente.

O gargalo de I/O wait e a armadilha do armazenamento local

No ecossistema Kubernetes, existe uma tendência perigosa de resolver problemas de I/O jogando hardware no problema. A solução "padrão ouro" tem sido o uso de Local Persistent Volumes (Local PVs) com SSDs NVMe diretamente acoplados aos nós de computação.

Tecnicamente, isso oferece a menor latência possível. O caminho do dado é curto: CPU -> Barramento PCIe -> SSD. Porém, arquiteturalmente, isso é um pesadelo para a resiliência.

Quando você amarra um Pod de banco de dados a um disco local específico, você quebra a promessa fundamental do Kubernetes: a orquestração dinâmica. Se o nó falhar, o Pod não pode ser subido em outro lugar até que o nó original volte ou que você inicie uma recuperação de desastre (restore de backup ou resync de réplica), o que pode levar horas.

Além disso, o armazenamento local sofre do problema de "capacidade ilhada". Você pode ter um nó com 10TB de NVMe ocioso e outro nó gritando por espaço, sem ter como compartilhar esses recursos.

Figura: Comparativo visual: A rigidez dos Volumes Locais vs. a mobilidade da arquitetura Desagregada com NVMe/TCP.

A física do protocolo: por que o iSCSI não acompanha o flash

Muitos administradores tentam resolver a questão da mobilidade usando iSCSI sobre arrays All-Flash. O problema aqui não é a mídia (o SSD é rápido), é o protocolo de transporte.

O iSCSI encapsula comandos SCSI. O conjunto de comandos SCSI foi projetado nos anos 80 para discos rígidos mecânicos (HDD). Ele opera fundamentalmente com uma única fila de comandos (ou pouquíssimas filas) e requer um handshake excessivo para cada operação de leitura e escrita.

Para entender a disparidade:

Discos SAS/SATA (Legado): Uma única fila de comandos com profundidade de 32 ou 256 comandos.
NVMe (Moderno): Suporta até 65.535 filas, com 65.535 comandos por fila.

Quando você coloca um SSD NVMe atrás de um protocolo iSCSI, você está forçando um carro de Fórmula 1 a andar no trânsito de uma estrada vicinal. O kernel do Linux precisa gastar ciclos preciosos de CPU serializando comandos paralelos do NVMe para caberem no funil estreito do SCSI/TCP. Isso gera latência de cauda (tail latency) e eleva o load average dos seus nós, roubando CPU que deveria estar processando transações do banco de dados.

💡 Dica Pro: Verifique o arquivo /proc/interrupts nos seus nós de banco de dados. Se você vir uma única CPU saturada lidando com interrupções de rede ou armazenamento enquanto as outras estão ociosas, você provavelmente está sofrendo com gargalos de serialização de protocolos legados.

Implementando NVMe over TCP para desacoplar computação

O NVMe over Fabrics (NVMe-oF) estende o protocolo NVMe nativo através da rede. Inicialmente, isso exigia redes especializadas como Fibre Channel ou RDMA (InfiniBand/RoCE). Embora performático, o RDMA é complexo, caro e difícil de configurar em escala (exige switches com Priority Flow Control e NICs específicas).

O NVMe over TCP mudou o jogo. Padronizado em 2018 e incluído no Kernel Linux 5.0 (2019), ele encapsula comandos NVMe dentro de datagramas TCP padrão.

A mágica acontece na eficiência. O protocolo foi desenhado para ser processado de forma eficiente pelas CPUs modernas, utilizando polling em vez de interrupções constantes, e mapeando filas de I/O diretamente para threads de CPU. Isso elimina trocas de contexto (context switches) desnecessárias.

A arquitetura no Kubernetes

No Kubernetes, a implementação ocorre via drivers CSI (Container Storage Interface). O fluxo é o seguinte:

O Pod solicita um PVC (Persistent Volume Claim).
O driver CSI comunica-se com o Storage Array (ou software-defined storage como OpenEBS/Lightbits).
O Storage cria o volume e retorna as informações de conexão.
O Kubelet no nó do worker utiliza o módulo do kernel nvme-tcp para conectar-se ao alvo.
O dispositivo aparece no host como /dev/nvme0n1, indistinguível de um disco local para a aplicação.

Figura: A pilha de protocolos: A complexidade e serialização do iSCSI (esquerda) versus o paralelismo direto do NVMe over TCP (direita).

A ilusão da replicação via software e o custo oculto da CPU

Uma alternativa comum ao armazenamento externo é o uso de Hyperconverged Infrastructure (HCI) ou soluções de armazenamento definidas por software que rodam dentro do próprio cluster (como Ceph, Longhorn ou Rook).

Embora funcionais, essas soluções cobram um imposto alto: CPU.

Para garantir a durabilidade dos dados, essas ferramentas realizam replicação síncrona via rede (geralmente 3 réplicas). Cada operação de escrita (Write) do seu banco de dados gera:

Serialização do dado.
Envio pela rede para outros nós.
Confirmação de escrita (ACK) dos outros nós.
Cálculo de checksums.

Em testes de estresse com bancos transacionais (OLTP), é comum ver 30% a 40% da CPU dos nós do cluster sendo consumida apenas pelo processo de armazenamento (ex: processos ceph-osd), competindo diretamente com o banco de dados.

O NVMe over TCP permite descarregar (offload) essa responsabilidade para um tier de armazenamento dedicado ou arrays otimizados, liberando a CPU dos nós de computação exclusivamente para processar queries SQL e lógica de negócio.

Comparativo de latência de cauda: Local vs NVMe/TCP

Para um DBA, a latência média é uma métrica de vaidade. O que importa é a latência de cauda (p99 ou p99.9) — ou seja, quão lento é o sistema nos piores momentos. É isso que causa timeouts na aplicação.

Em cenários de alta concorrência, o NVMe/TCP brilha.

Característica	Local NVMe (PCIe)	iSCSI (All-Flash)	NVMe over TCP
Latência Média (4K Read)	~80 µs	~500 µs - 1ms	~150 µs - 200 µs
Latência p99 (Carga Alta)	~150 µs	> 5 ms (Spikes)	~300 µs
Uso de CPU (Host)	Baixo	Alto (iSCSI Initiator)	Médio/Baixo (Otimizado)
Complexidade de Rede	N/A	Baixa (TCP padrão)	Baixa (TCP padrão)
Mobilidade do Pod	Nenhuma	Alta	Alta

⚠️ Perigo: Não subestime a rede. Para usar NVMe over TCP em produção, interfaces de 10GbE são o mínimo absoluto, mas 25GbE ou 100GbE são fortemente recomendados. A latência da rede física torna-se o novo gargalo se você saturar o link.

Figura: Gráfico de Latência de Cauda (p99): A estabilidade do NVMe/TCP próxima ao disco local, contrastando com a instabilidade do iSCSI sob carga.

O futuro é desagregado

A era de tratar bancos de dados no Kubernetes como cidadãos de segunda classe acabou. O NVMe over TCP remove a última barreira técnica que justificava manter grandes monolitos de banco de dados fora dos clusters de contêineres.

Ao adotar esse padrão, você ganha a elasticidade da nuvem com a performance do bare metal. Não é apenas sobre velocidade bruta, é sobre previsibilidade. Um banco de dados precisa de tempos de resposta determinísticos, e o protocolo NVMe foi desenhado exatamente para isso.

Se você está desenhando a próxima geração da sua infraestrutura de dados on-premise ou em colocation, pare de lutar contra configurações de iSCSI legado ou tentar gerenciar a complexidade do Fibre Channel. O futuro é Ethernet, TCP e NVMe.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Documentação oficial do padrão NVMe e transportes (incluindo TCP).
SNIA (Storage Networking Industry Association): "Performance of NVMe-oF™: TCP vs. RDMA" (Whitepapers técnicos sobre overhead de protocolo).
Linux Kernel Archives: Detalhes do módulo nvme-tcp introduzido na versão 5.0 e melhorias de Zero-Copy nas versões 5.10+.

Perguntas Frequentes (FAQ)

Qual a diferença prática de latência entre iSCSI e NVMe/TCP?

Enquanto o iSCSI adiciona milissegundos devido à serialização e overhead do protocolo SCSI legado, o NVMe/TCP opera na casa dos microssegundos (<200µs), aproveitando o paralelismo nativo do NVMe (64k filas) sobre redes Ethernet padrão.

O NVMe over TCP exige hardware de rede proprietário como o RDMA?

Não. Diferente do RoCE (RDMA over Converged Ethernet) que exige switches com suporte a DCB/PFC e NICs especiais, o NVMe/TCP funciona em qualquer infraestrutura Ethernet padrão (recomenda-se 25GbE+), reduzindo drasticamente o custo e a complexidade.

Como o Kubernetes gerencia volumes NVMe/TCP?

Através do CSI (Container Storage Interface). O driver CSI monta o volume NVMe/TCP diretamente no nó do worker via kernel Linux (módulos nvme-tcp disponíveis desde o Kernel 5.0), apresentando-o ao pod como um dispositivo de bloco local.