Gerenciamento avançado de NVMe-oF com nvme-cli: do discovery ao multipath

O gerenciamento de armazenamento remoto evoluiu. Se você ainda pensa em SAN apenas como Fibre Channel ou iSCSI, é hora de atualizar o firmware mental. O NVMe over Fabrics (NVMe-oF) removeu o gargalo do protocolo SCSI, permitindo que a latência do flash remoto rivalize com o armazenamento local.

Mas essa performance tem um preço: complexidade na linha de comando. O nvme-cli não é apenas um acessório; é o painel de controle principal para orquestrar iniciadores, targets e caminhos. Vamos dissecar como manipular essa ferramenta para garantir que seus dados fluam do target ao host sem engasgos.

Resumo em 30 segundos

O padrão de ouro: O nvme-cli é a ferramenta user-space definitiva para gerenciar NVMe, seja PCIe local ou Fabrics (TCP, RDMA, FC).

Multipath nativo: O Linux agora prefere seu próprio multipath nativo para NVMe em vez do dm-multipath (device mapper), oferecendo melhor performance e failover mais inteligente.

Identidade é tudo: O Host NQN (/etc/nvme/hostnqn) funciona como o IQN do iSCSI; sem ele configurado corretamente, as ACLs no storage array vão rejeitar sua conexão silenciosamente.

O ecossistema NVMe over Fabrics e o iniciador Linux

Diferente do iSCSI, que encapsula comandos SCSI em TCP, o NVMe-oF estende o conjunto de comandos NVMe nativos através da rede. Isso elimina ciclos de CPU gastos em tradução de protocolos. No Linux, o suporte a "Fabrics" é modular.

Antes de digitar qualquer comando, você precisa garantir que o kernel fala a língua do transporte escolhido.

modprobe nvme-tcp

# Para redes RDMA (InfiniBand ou RoCE)
modprobe nvme-rdma

Se o módulo não estiver carregado, o nvme-cli retornará erros genéricos que farão você perder horas debugando firewall.

Figura: Comparação da pilha de I/O: A simplicidade do NVMe-oF versus a profundidade da pilha SCSI tradicional.

Identidade do host: o Host NQN

No mundo NVMe, tudo gira em torno do NQN (NVMe Qualified Name). Seu servidor (o iniciador) precisa de um nome único para se apresentar ao storage (o target).

O driver busca essa identidade em /etc/nvme/hostnqn. Se o arquivo não existir, o driver gera um UUID volátil ou aleatório, o que é um pesadelo para persistência de regras de acesso (ACLs) no storage.

💡 Dica Pro: Nunca deixe o sistema gerar o NQN a cada boot. Fixe a identidade do seu servidor.

Para gerar e salvar um NQN persistente:

nvme gen-hostnqn > /etc/nvme/hostnqn
cat /etc/nvme/hostnqn
# Saída esperada: nqn.2014-08.org.nvmexpress:uuid:f8d9c0a1-2b3c-4d5e-6f7g-8h9i0j1k2l3m

Mapeando targets com nvme discover

O comando discover é o equivalente ao "SendTargets" do iSCSI. Ele interroga um Discovery Controller (uma porta de escuta no storage) para saber quais subsistemas estão disponíveis para o seu Host NQN.

A sintaxe exige precisão nos transportes:

nvme discover -t tcp -a 192.168.10.50 -s 4420

Dissecando as flags:

-t tcp: Define o transporte (pode ser rdma, fc, loop).
-a 192.168.10.50: O endereço IP do target (traddr).
-s 4420: A porta de serviço (trsvcid). A porta padrão do NVMe/TCP é 4420, mas sempre especifique para evitar dúvidas.

A saída listará os subsistemas (subnqn) disponíveis. Se a lista estiver vazia, verifique se o Host NQN do seu servidor foi adicionado à "Allow List" no storage array.

Estabelecendo sessões com nvme connect

Uma vez descoberto o subnqn, é hora de criar o vínculo de I/O. O comando connect cria a estrutura de controle no kernel e apresenta o dispositivo de bloco (ex: /dev/nvme0n1).

nvme connect -t tcp -n nqn.2022-01.com.storage:array1:flash-pool -a 192.168.10.50 -s 4420

Aqui introduzimos a flag -n, que especifica o NQN do target (obtido no passo de discovery).

⚠️ Perigo: O comando connect não é persistente após o reboot por padrão. Para persistência, a maioria das distros modernas usa o serviço nvme-tcp.service ou scripts que leem arquivos JSON em /etc/nvme/discovery.conf gerados pelo comando connect-all.

Multipath nativo: o novo padrão

Aqui é onde muitos administradores experientes em SAN tropeçam. Por décadas, usamos o device-mapper-multipath (dm-multipath) e o arquivo multipath.conf.

Para NVMe, a recomendação da indústria mudou. O NVMe Native Multipath é gerenciado diretamente pelo driver NVMe, sem a camada extra do device mapper. Ele entende melhor os estados do protocolo NVMe, como ANA (Asymmetric Namespace Access).

Como verificar se o multipath nativo está ativo:

cat /sys/module/nvme_core/parameters/multipath
# Y = Nativo (Recomendado)
# N = Desativado (O sistema usará dm-multipath se configurado)

Tabela comparativa: Multipath Nativo vs. DM-Multipath

Característica	NVMe Native Multipath	DM-Multipath (Legacy)
Localização	Driver NVMe (Kernel)	Device Mapper (Userspace/Kernel)
Device Node	`/dev/nvme0n1`	`/dev/dm-0` ou `/dev/mapper/mpatha`
Awareness	Suporte total a ANA (Optimized/Non-Optimized)	Suporte genérico, depende de configuração
Performance	Menor overhead (bypass da camada DM)	Overhead adicional de roteamento de I/O
Complexidade	Zero conf (geralmente)	Requer `multipath.conf` complexo

Se você conectar duas interfaces de rede ao mesmo target NVMe usando multipath nativo, você não verá dois dispositivos /dev/nvme0n1 e /dev/nvme0n2. Você verá apenas um dispositivo /dev/nvme0n1, e o driver gerencia os caminhos por baixo do capô.

Figura: Topologia do Multipath Nativo: Múltiplos controladores agregados em um único namespace pelo driver.

Validação da topologia com nvme list-subsys

O comando nvme list mostra os dispositivos de bloco, mas esconde a complexidade dos caminhos se o multipath nativo estiver ativo. Para ver a "verdade" sobre sua redundância, use:

nvme list-subsys

Exemplo de saída interpretada:

nvme-subsys0 - NQN=nqn.2022-01.com.storage:array1
 \
  +- nvme0 tcp traddr=192.168.10.50 trsvcid=4420 live
  +- nvme1 tcp traddr=192.168.20.50 trsvcid=4420 live

Neste exemplo, temos um subsistema (nvme-subsys0) acessível por dois controladores (nvme0 e nvme1) através de caminhos de rede diferentes. Ambos estão live. Se um cabo for desconectado, o estado mudará para connecting ou dead, mas o dispositivo /dev/nvme0n1 permanecerá acessível via o caminho restante.

Ajuste fino e timeouts

Em redes TCP congestionadas, os valores padrão podem ser agressivos demais, causando desconexões prematuras. Duas flags no nvme connect são vitais para estabilidade em produção:

-k (keep-alive-tmo): Define a frequência dos "heartbeats". O padrão costuma ser baixo. Aumentar para 30 ou 60 segundos pode evitar flaps em redes instáveis.
-c (ctrl-loss-tmo): Quanto tempo o driver espera um controlador voltar antes de declarar I/O error. Se o multipath estiver ativo, você quer que o failover seja rápido, mas não instantâneo a ponto de qualquer soluço na rede matar a aplicação.

# Exemplo robusto para produção
nvme connect -t tcp -a 192.168.10.50 -n <nqn> -k 30 -c 1800

Isso diz ao driver: "Mande keep-alives a cada 30s, e se a conexão cair, tente reconectar por 30 minutos (1800s) antes de desistir dos dados".

O futuro é agora

O nvme-cli é a ponte entre o hardware de ponta e a confiabilidade operacional. Dominar suas flags de descoberta, conexão e multipath não é opcional para quem gerencia infraestrutura moderna. O NVMe-oF já saiu da fase de "early adopter". Se você está subindo clusters Kubernetes on-premise ou bancos de dados de alta performance, o gargalo agora é o seu conhecimento sobre a ferramenta, não mais o protocolo.

Perguntas Frequentes (FAQ)

Qual a diferença entre nvme connect e nvme connect-all?

O 'nvme connect' é cirúrgico: estabelece uma conexão única com um subsistema específico que você define manualmente. Já o 'nvme connect-all' é abrangente: ele consulta o Discovery Controller, lê o log de descoberta e conecta automaticamente a todos os subsistemas que o target apresentar para o seu host. É ideal para scripts de inicialização.

Como habilitar o multipath nativo do NVMe no Linux?

Na maioria das distribuições modernas, ele já vem ativo. É controlado pelo parâmetro de kernel 'nvme_core.multipath=Y'. Você pode verificar o estado atual com 'cat /sys/module/nvme_core/parameters/multipath'. Se a saída for 'Y', o driver NVMe gerencia o failover e balanceamento de carga internamente, dispensando o DM-Multipath.

O que é o Host NQN e onde ele fica configurado?

O Host NQN (NVMe Qualified Name) é o "RG" do seu servidor no mundo NVMe. Ele reside em '/etc/nvme/hostnqn'. Se esse arquivo não existir, o driver gera um ID aleatório a cada boot, o que quebra suas permissões de acesso no storage. Use 'nvme gen-hostnqn' para criar um identificador fixo e persistente.