A ilusão da redundância no NVMe-oF: por que o native multipath pode trair você

Você comprou aquele storage All-Flash brilhante. O vendedor jurou que o NVMe over Fabrics (NVMe-oF) traria latências de microssegundos e que a redundância seria "transparente". Você conectou os cabos de fibra ou Ethernet, configurou os IPs, viu os discos aparecerem e foi para casa feliz.

Doce inocência.

Se você tratou seus volumes NVMe-oF exatamente como tratava seus LUNs iSCSI ou Fibre Channel de 2015, você não configurou redundância. Você configurou uma bomba-relógio de race conditions. O ecossistema de storage no Linux mudou, e a guerra silenciosa entre o Device Mapper (DM) e o NVMe Native Multipathing está acontecendo agora mesmo dentro do seu kernel. E adivinhe quem vai perder? Seus dados.

Resumo em 30 segundos

Conflito de Soberania: O Linux possui dois gerenciadores de caminhos distintos (Device Mapper e Native NVMe) que, por padrão, tentam controlar os mesmos dispositivos, causando bloqueios e kernel panics.

Latência Fantasma: Usar o multipath-tools (DM) legado em cima do NVMe adiciona overhead de CPU e latência, anulando o propósito de comprar hardware de alto desempenho.

ANA é o novo ALUA: O driver nativo entende o protocolo ANA (Asymmetric Namespace Access) para roteamento inteligente; o DM-Multipath frequentemente luta para interpretar isso corretamente sem configurações manuais complexas.

O conflito: dois capitães, um navio afundando

Historicamente, o multipathing no Linux era território exclusivo do Device Mapper Multipath (DM-MPIO). Era ele quem lidava com o failover de SCSI, SAS e Fibre Channel. Funcionava, era robusto e todos nós decoramos o multipath.conf.

Quando o NVMe chegou, os desenvolvedores do kernel olharam para a pilha de software existente e perceberam que o DM-Multipath era pesado demais. O NVMe foi desenhado para eliminar a pilha SCSI, não para emulá-la. Assim nasceu o NVMe Native Multipathing (introduzido no kernel 4.15+), que vive diretamente no subsistema NVMe.

O problema surge quando você usa uma distribuição Linux "user-friendly" (leia-se: inchada) que traz o pacote multipath-tools instalado e ativado por padrão.

O kernel tenta agrupar os caminhos via driver nativo. O udev dispara. O multipathd acorda e tenta sequestrar esses dispositivos /dev/nvme* para criar dispositivos /dev/dm-*. O resultado é uma briga por bloqueio de recursos.

Figura: O conflito arquitetural: a camada extra do Device Mapper adiciona latência e complexidade onde o driver nativo busca acesso direto.

Por que o `multipath-tools` é um convite ao desastre

Se você está rodando NVMe-oF (seja TCP, FC ou RoCE), o driver nativo do kernel já sabe como lidar com múltiplos caminhos para o mesmo Subsystem NQN. Ele cria um dispositivo único (ex: /dev/nvme0n1) e virtualiza os caminhos por baixo dele.

Quando você joga o dm-multipath na mistura sem a devida configuração de blacklist, você introduz:

Dupla Personalidade: O sistema operacional vê o dispositivo nativo E o dispositivo mapeado. Se você montar o errado (ou se o fstab for ambíguo), boa sorte no próximo reboot.
Overhead de Context Switch: O DM roda em user space para muitas de suas decisões de controle (via daemon multipathd). O NVMe nativo decide o roteamento de I/O inteiramente no kernel. Em 100GbE, essa viagem ao user space custa IOPS caros.
Sintomas de Race Condition: Durante uma falha de link, o driver nativo tenta re-rotear o I/O instantaneamente. O multipathd detecta a falha segundos depois e tenta remover o caminho. Frequentemente, isso resulta em I/O pendurado indefinidamente ou erros de "path checker" que inundam o dmesg até o disco encher.

⚠️ Perigo: Em kernels mais antigos (pré-5.x) ou mal configurados, ter ambos ativos pode causar corrupção de dados silenciosa se o DM tentar enviar comandos de gerenciamento SCSI para um dispositivo que espera comandos NVMe puros.

ANA: A inteligência que você está ignorando

No mundo SCSI/FC, tínhamos o ALUA para dizer qual controladora do storage era a "dona" do LUN. No NVMe, temos o ANA (Asymmetric Namespace Access).

O ANA informa ao host o estado de cada caminho e grupo de caminhos:

Optimized: O caminho preferencial.
Non-Optimized: Funciona, mas é mais lento (talvez passe por um link inter-controladora).
Inaccessible: O caminho existe, mas não pode processar I/O agora (ex: controladora bootando).
Change: O estado está mudando, segure o I/O.

O driver nativo do NVMe consome essas informações de estado ANA diretamente do firmware do storage e ajusta a fila de envio de comandos instantaneamente. O DM-Multipath precisa de handlers específicos para traduzir isso, e frequentemente falha em reagir tão rápido quanto o protocolo exige.

Comparativo: Velha Guarda vs. Eficiência

Característica	DM-Multipath (Legacy)	NVMe Native Multipath
Localização	Camada de abstração acima do driver	Integrado ao subsistema NVMe
Gerenciamento	Daemon em User Space (`multipathd`)	Kernel Space puro
Detecção de Falha	Polling (Checkers periódicos)	Notificação de Evento (AEN) / ANA
Nomes de Dispositivo	`/dev/mapper/mpatha`, `/dev/dm-0`	`/dev/nvme0n1` (abstrai caminhos)
Complexidade	Alta (arquivos .conf gigantes)	Zero (Plug & Play na maioria dos casos)
Performance	Overhead mensurável em NVMe	Próximo de wire speed

Forçando a disciplina: como configurar corretamente

Se você decidiu (sabiamente) usar o multipath nativo, você precisa garantir que o DM não interfira. Não basta "não usar". Você precisa proibir o sistema de tentar usar.

1. Parâmetros de Boot (A abordagem nuclear)

A maneira mais segura de garantir que o multipath nativo esteja ativo é via parâmetros do kernel no GRUB.

# Verifique se está ativo
cat /sys/module/nvme_core/parameters/multipath
# Deve retornar 'Y'

Se retornar N, adicione nvme_core.multipath=Y à linha GRUB_CMDLINE_LINUX no /etc/default/grub e atualize o bootloader. Isso força o driver NVMe a agrupar namespaces idênticos sob um único dispositivo /dev/nvmeXn1.

2. A Blacklist no `multipath.conf`

Se você ainda precisa do multipath-tools para outros discos (como discos de boot SATA/SAS locais ou LUNs FC legados), você deve explicitamente ignorar os dispositivos NVMe.

Edite /etc/multipath.conf:

blacklist {
    devnode "^nvme"
    device {
        vendor "NVME"
        product ".*"
    }
}

Isso impede que o daemon toque nos seus preciosos volumes NVMe-oF.

💡 Dica Pro: Se você não tem nenhum disco SCSI/SAS que precise de multipath, remova o pacote multipath-tools completamente. Menos daemons, menos vetores de ataque, menos dores de cabeça. apt purge multipath-tools é terapêutico.

Auditoria: Como saber se está funcionando?

Não confie na luzinha verde do switch. Verifique como o kernel está vendo a topologia.

Com o multipath nativo, você não usa multipath -ll. Você usa a CLI do NVMe.

# Instale se não tiver (mas você deveria ter)
# apt/yum install nvme-cli

nvme list-subsys

A saída deve mostrar algo assim:

nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:f8...
\
 +- nvme0 tcp traddr=192.168.10.50 trsvcid=4420 live
 +- nvme1 tcp traddr=192.168.20.50 trsvcid=4420 live

Note que nvme0 e nvme1 são os controladores (caminhos), mas eles pertencem ao mesmo subsistema. O dispositivo de bloco utilizável será /dev/nvme0n1. Se você vir múltiplos subsistemas para o que deveria ser o mesmo volume, sua configuração de NQN no storage ou no host está errada.

Para verificar o estado ANA em tempo real:

cat /sys/class/nvme-subsystem/nvme-subsys0/iopolicy
# Deve retornar 'numa' ou 'round-robin'

cat /sys/class/nvme-subsystem/nvme-subsys0/nvme0/state
# Deve retornar 'live'

O veredito

A inércia é a força mais poderosa em TI. Continuamos usando ferramentas desenhadas para discos giratórios de 15K RPM em memórias flash que operam na velocidade da luz.

O NVMe Native Multipath não é "o futuro", é o requisito básico para operar NVMe-oF sem gargalos artificiais. Se você insistir em envolver seus volumes NVMe em camadas de Device Mapper por puro hábito ou preguiça de ler a documentação, não culpe o protocolo quando sua latência de cauda (tail latency) disparar durante um failover.

Limpe suas configurações, remova o bloatware e deixe o kernel fazer o trabalho para o qual foi pago (ou não, já que é open source).

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Seções sobre Multipathing e Asymmetric Namespace Access (ANA).
Linux Kernel Documentation: Documentation/block/data-integrity.rst e parâmetros do módulo nvme_core.
TP 4004 (Technical Proposal): Detalhes sobre a implementação de ANA e reporte de erros de caminho.

FAQ: Perguntas Frequentes (e Respostas Honestas)

Qual a diferença entre NVMe Native Multipath e Device Mapper (DM-Multipath)?

O Native Multipath é integrado diretamente ao subsistema NVMe do kernel, operando com conhecimento profundo do protocolo (como estados ANA) e zero overhead de user-space. O DM-Multipath é a camada genérica legada (projetada para SCSI/SAS) que adiciona latência, complexidade e pontos de falha desnecessários em ambientes NVMe puros.

O que é ANA (Asymmetric Namespace Access) no contexto de NVMe-oF?

É o equivalente moderno ao ALUA do mundo SCSI. O ANA é um protocolo onde o storage informa ao host quais caminhos são "Otimizados", "Não Otimizados" ou "Inacessíveis". Isso permite que o driver NVMe nativo tome decisões de roteamento de I/O instantâneas e inteligentes sem que você precise configurar prioridades manualmente.

Devo desativar o multipath-tools ao usar NVMe-oF?

Na maioria absoluta dos casos, sim. Se você não tem storage legado (FC/iSCSI) no mesmo host, remova o pacote. Se tiver um ambiente misto, configure a `blacklist` no `multipath.conf` para ignorar dispositivos `nvme*`. Ter ambos tentando gerenciar os mesmos dispositivos causa conflitos de bloqueio, corrupção de dados e kernel panics.