Windows Server 2025 e NVMe Nativo: A Revolução na Pilha de I/O e o Fim da Tradução SCSI
Análise profunda do novo driver NVMe no Windows Server 2025. Entenda a arquitetura sem tradução SCSI, ganhos de IOPS e como validar sua infraestrutura de armazenamento.
Como engenheiros de sistemas e arquitetos de dados, passamos as últimas duas décadas obcecados com a integridade do dado em repouso. Discutimos checksums, árvores de Merkle e a elegância do Copy-on-Write (CoW) no ZFS e Btrfs. No entanto, existe um "elefante na sala" que, por muito tempo, toleramos com um suspiro resignado: a pilha de I/O (Input/Output).
Durante anos, conectamos dispositivos de memória não volátil expressa (NVMe) — verdadeiros puros-sangues de silício — a uma carroça chamada SCSI. O Windows, assim como outros sistemas operacionais, utilizava uma camada de tradução para fazer com que esses SSDs ultrarrápidos "falassem" a língua dos discos rotativos antigos. Era uma ineficiência arquitetural, um "impedance mismatch" clássico.
Com o Windows Server 2025, a Microsoft finalmente realizou a cirurgia de peito aberto necessária: a introdução de uma pilha NVMe nativa otimizada, eliminando a tradução SCSI. Vamos dissecar essa mudança não como administradores que clicam em "Next", mas como engenheiros que entendem o custo de cada ciclo de CPU e a beleza de uma fila de comandos otimizada.
Conceito Arquitetural: O Fim da Era SCSI na Camada NVMe
Para entender a gravidade dessa mudança, precisamos revisitar o passado recente. Até o Windows Server 2022, quando você gravava um bloco de dados em um drive NVMe, o sistema operacional realizava um malabarismo desnecessário. O comando de escrita passava pelo driver Storport, que, por design, fala SCSI.
O problema? O NVMe não é SCSI. O NVMe é um protocolo projetado do zero para barramentos PCIe, focado em paralelismo massivo e baixa latência. O Windows, portanto, tinha que pegar o comando NVMe, encapsulá-lo ou traduzi-lo para um comando SCSI, passá-lo pela pilha de armazenamento, apenas para que, no final, um driver de miniporta traduzisse tudo de volta para NVMe para o hardware entender.
Isso é o equivalente computacional a traduzir Shakespeare para o Latim e depois de volta para o Inglês Moderno antes de recitá-lo. Você perde nuances, gasta energia cognitiva (ciclos de CPU) e, crucialmente, perde tempo.
Figura: Fig. 1: A eliminação da camada de tradução SCSI representa a maior mudança arquitetural no subsistema de armazenamento da Microsoft em uma década.
No Windows Server 2025, essa camada de tradução foi efetivamente contornada para dispositivos NVMe. A nova arquitetura permite que o sistema de arquivos (seja ReFS ou NTFS) envie comandos que fluem diretamente para o subsistema NVMe sem a sobrecarga da tradução SCSI.
Por que a Tradução SCSI era o Gargalo?
Serialização: O SCSI foi nascido na era dos discos rígidos mecânicos, onde uma cabeça de leitura/escrita física só podia estar em um lugar por vez. As filas eram, por natureza, limitadas e frequentemente serializadas.
Overhead de CPU: Cada tradução de comando consome ciclos. Em um HDD de 150 IOPS, isso é irrelevante. Em um SSD NVMe Gen5 capaz de 2 milhões de IOPS, o custo da tradução consome uma porcentagem significativa da CPU do servidor, roubando recursos que deveriam estar processando suas aplicações ou máquinas virtuais.
Latência de Cauda: A complexidade da pilha antiga introduzia variabilidade na latência (jitter), o inimigo mortal de bancos de dados transacionais.
A nova abordagem nativa abraça a natureza do NVMe: paralelismo. Não estamos mais tentando forçar um fluxo de dados paralelo através de um funil serial.
Mecânica de I/O: Como o Windows Server 2025 Acessa o Disco NVMe
Se abrirmos o capô do kernel, a mudança é fascinante do ponto de vista das estruturas de dados. O protocolo NVMe baseia-se em pares de filas de submissão e conclusão (Submission/Completion Queues).
Na arquitetura antiga, o driver stornvme.sys fazia um trabalho heroico, mas estava algemado pelas regras do Storport. Com o Windows Server 2025, a Microsoft implementou otimizações que permitem um mapeamento muito mais direto entre as threads da CPU e as filas do hardware NVMe.
Otimização de Filas e Afinidade de CPU
O segredo da performance em sistemas de arquivos modernos não é apenas a velocidade da mídia, mas a localidade do cache e a afinidade da CPU.
O novo driver nativo explora o conceito de filas múltiplas do NVMe (que suporta até 64.000 filas, cada uma com 64.000 comandos). O Windows Server 2025 tenta alinhar as filas de I/O com os núcleos do processador.
Figura: Fig. 2: O novo driver nativo explora o paralelismo massivo do protocolo NVMe, permitindo que cada núcleo da CPU tenha suas próprias filas de I/O.
O Fluxo Otimizado:
Submissão: Quando uma aplicação solicita uma leitura, o comando é colocado diretamente na Submission Queue mapeada para aquele núcleo de CPU específico. Não há necessidade de bloqueios (locks) globais complexos que eram comuns na pilha SCSI.
Doorbell: O sistema "toca a campainha" (escreve em um registrador do controlador NVMe) para avisar que há trabalho.
DMA e Execução: O dispositivo NVMe usa DMA (Direct Memory Access) para pegar o comando e transferir os dados, sem incomodar a CPU durante a transferência.
Conclusão: Ao finalizar, o dispositivo coloca o resultado na Completion Queue e gera uma interrupção (MSI-X) que é roteada preferencialmente para o mesmo núcleo que iniciou o pedido.
Isso elimina o context switching excessivo e o cache thrashing da CPU. Para quem estuda ZFS, isso soa familiar: é a busca incessante por eficiência no caminho do dado (data path). O resultado é uma redução drástica na latência, especialmente sob carga pesada.
Validação Prática: Comandos PowerShell para Diagnóstico de Armazenamento
Como engenheiros, não confiamos em marketing; confiamos em terminais. Para verificar se seus drives estão operando com a eficiência esperada e identificar a topologia do armazenamento no Windows Server 2025, o PowerShell continua sendo nossa ferramenta de dissecção.
Abaixo, apresento comandos essenciais para validar a camada física e a configuração do NVMe.
1. Identificando Dispositivos NVMe e o Tipo de Barramento
O primeiro passo é garantir que o sistema operacional reconhece os drives explicitamente como NVMe, e não como um dispositivo genérico atrás de uma controladora RAID legada.
# Listar discos físicos com foco no tipo de barramento e saúde
Get-PhysicalDisk | Select-Object FriendlyName, SerialNumber, MediaType, BusType, HealthStatus, OperationalStatus | Format-Table -AutoSize
# O output esperado para 'BusType' deve ser 'NVMe'.
# Se você ver 'RAID' ou 'SAS', sua controladora de hardware está mascarando o dispositivo,
# anulando os benefícios da pilha nativa do Windows.
2. Inspecionando a Camada de Adaptadores e Drivers
Para confirmar qual driver está controlando o dispositivo, precisamos ir um pouco mais fundo.
# Obter detalhes dos adaptadores de armazenamento
Get-StorageAdapter | Where-Object { $_.BusType -eq 'NVMe' } | Select-Object FriendlyName, DriverName, FirmwareVersion, PhysicalLocation | Format-List
# Dica de Guru: Verifique a versão do Firmware.
# NVMe nativo expõe bugs de firmware de SSDs que a camada SCSI antiga escondia.
# Mantenha seus firmwares atualizados.
3. Teste de Performance Sintética (Rápido)
Embora eu prefira ferramentas como diskspd para benchmarks sérios, podemos usar o winsat para uma validação rápida de que não estamos limitados por drivers antigos.
# Teste rápido de leitura randômica (o teste de fogo para latência)
winsat disk -drive c -ran -read -count 10
# Observe a latência média. Em um sistema Server 2025 bem configurado com NVMe Gen4/5,
# esperamos latências na casa dos microssegundos baixos (<50us), não milissegundos.
Mitos Comuns sobre Performance NVMe e Drivers Microsoft
No mundo do armazenamento, o folclore técnico muitas vezes supera a documentação técnica. Vamos desmantelar alguns mitos persistentes que podem impedir você de adotar a nova arquitetura do Windows Server 2025.
Tabela de Realidade vs. Ficção
| Mito | Realidade Técnica |
|---|---|
| "Controladoras RAID de Hardware são sempre mais rápidas." | Falso. Controladoras RAID adicionam latência. Elas são um "homem no meio". Com NVMe, a CPU do servidor é geralmente mais capaz de gerenciar I/O (via Storage Spaces Direct) do que o processador limitado de uma placa RAID. O NVMe Nativo brilha no acesso direto (Pass-through). |
| "O driver padrão da Microsoft é genérico e lento." | Obsoleto. No passado, drivers de fabricantes (Samsung, Intel) eram obrigatórios para performance. No Server 2025, a pilha nativa foi otimizada em colaboração com consórcios de hardware. Frequentemente, o driver nativo agora supera drivers proprietários em estabilidade e integração com o ReFS. |
| "IOPS é a única métrica que importa." | Perigoso. IOPS é vaidade; Latência é sanidade. Você pode ter 1 milhão de IOPS, mas se a latência de cauda (p99) for alta devido à tradução SCSI, seu banco de dados SQL travará. A pilha nativa foca na consistência da latência. |
O Mito da "Compatibilidade Legada"
Muitos administradores configuram seus servidores na BIOS para usar modos de emulação SATA ou RAID para "garantir compatibilidade". Não faça isso. Isso força o Windows a carregar a pilha legada. Para usar a revolução do I/O do 2025, o hardware deve ser exposto como NVMe nativo para o OS.
Cenário de Desastre: Falha de Drive em Storage Spaces Direct com NVMe
A verdadeira prova de qualquer sistema de arquivos ou subsistema de armazenamento não é quando tudo vai bem, mas quando o caos se instala. Como evangelista de sistemas robustos, meu cenário favorito é a falha de disco.
Imagine um cluster de Storage Spaces Direct (S2D) rodando no Windows Server 2025. Temos um pool de armazenamento com 12 drives NVMe por nó. Um drive morre subitamente.
O Processo de Reconstrução (Resilvering)
No mundo ZFS, chamamos isso de "resilvering". No S2D, é a reparação do storage pool.
Na arquitetura antiga (Server 2019/2022), a latência induzida pela pilha de software limitava a velocidade com que os dados podiam ser lidos dos drives sobreviventes e gravados nos novos alvos. O gargalo não era o fio (rede 100GbE) nem o disco (NVMe), mas a pilha de processamento de I/O da CPU.
Figura: Fig. 3: Em um cenário de desastre, a baixa latência do NVMe combinada com o novo driver permite tempos de reconstrução (resilvering) drasticamente menores.
Com a pilha NVMe nativa do Server 2025, observamos três melhorias críticas durante um desastre:
Bypass de Interrupções: A eficiência da nova pilha libera ciclos de CPU. Durante uma reconstrução, a CPU é o recurso mais precioso, pois precisa calcular checksums (se estiver usando ReFS com integridade) e mover dados. Menos overhead de driver significa reconstrução mais rápida.
Leituras Prioritárias: A arquitetura NVMe permite priorizar filas. O tráfego de reconstrução pode ser gerenciado de forma mais granular, garantindo que suas VMs de produção não congelem enquanto o servidor se cura.
Redução da Janela de Vulnerabilidade: O tempo é inimigo da integridade. Quanto mais rápido o resilvering termina, menor a chance de uma segunda falha catastrófica. A baixa latência do NVMe nativo permite saturar a largura de banda de rede RDMA (Remote Direct Memory Access) de forma muito mais eficaz.
A Importância do ReFS e Integridade
Neste cenário, a combinação do NVMe Nativo com o ReFS (Resilient File System) é onde a mágica acontece. O ReFS utiliza checksums para detectar bit rot (podridão de bits). Com a pilha antiga, ativar checksums de integridade tinha um custo de performance perceptível. Com a pilha NVMe do 2025, o overhead de I/O é tão baixo que o custo computacional da integridade se torna negligenciável. Nunca desative a integridade de dados por medo de performance no Server 2025.
Veredito Técnico: O Veredito de um Engenheiro de Sistemas de Arquivos
O Windows Server 2025 não trouxe apenas "mais velocidade". Ele trouxe correção arquitetural.
Para nós, puristas de dados, a eliminação da tradução SCSI para dispositivos NVMe é comparável a remover uma engrenagem enferrujada de um relógio suíço. A Microsoft finalmente alinhou o software (OS) com a realidade física do hardware (Memória Não Volátil).
Ao adotar essa nova pilha, você não está apenas ganhando IOPS em um gráfico de benchmark. Você está ganhando:
Eficiência Termodinâmica: Menos ciclos de CPU por byte transferido.
Consistência: Latências previsíveis que deixam bancos de dados felizes.
Resiliência: Tempos de recuperação de desastres que acompanham a velocidade do flash moderno.
O disco rotativo serviu bem ao seu propósito, e o protocolo SCSI foi seu fiel escudeiro. Mas no datacenter moderno, o silício fala diretamente com o silício. A tradução acabou. Longa vida ao NVMe Nativo.
Referências Bibliográficas
NVM Express Organization. "NVM Express Base Specification 2.0". Technical Spec, 2024.
Microsoft Learn. "Storage Innovations in Windows Server 2025". Microsoft Docs, 2024.
Bonwick, Jeff. "ZFS: The Last Word in File Systems". Sun Microsystems, 2008. (Para conceitos fundamentais de integridade e CoW).
Lucas, Michael W. "FreeBSD Master of Storage". (Conceitos agnósticos de I/O Stack).
Smith, A.J. "Input/Output Optimization in Operating Systems". Computer Science Technical Reports, University of California.
Ricardo Vilela
Especialista em Compras/Procurement
"Especialista em dissecar contratos e destruir argumentos de vendas. Meu foco é TCO, SLAs blindados e evitar armadilhas de lock-in. Se não está no papel, não existe."