Em 15 de dezembro de 2025, a Microsoft anunciou que o Windows Server 2025 finalmente adotaria o padrão NVMe nativamente em sua arquitetura de armazenamento. No entanto, o armazenamento NVMe já é um formato popular em servidores, estações de trabalho corporativas e PCs de consumo há muitos anos, com compatibilidade com sistemas operacionais integrada desde o Windows Server 2012 R2 e o Windows 8.1. Com isso em mente, um anúncio sobre suporte "nativo" ao NVMe pode não parecer importante ou sequer relevante, mas garantimos que há mais por trás disso do que aparenta.
O que significa exatamente "NVMe nativo"?
Nas versões anteriores das pilhas de armazenamento do Windows para consumidores e servidores, os comandos usados para ler e gravar dados, independentemente dos protocolos do hardware subjacente, eram sempre traduzidos em comandos SCSI. O padrão Small Computer System Interface (SCSI) remonta ao início da década de 1980 e foi projetado para conectar periféricos e unidades de armazenamento a computadores (Storage Networking Industry Association, s.d.). Ele é a base de diversos protocolos de armazenamento modernos usados para várias cargas de trabalho, incluindo protocolos conectados à rede, como iSCSI (Internet Small Computer System Interface) e FCP (Fibre Channel Protocol), e interfaces de armazenamento local, como SAS (Serial Attached SCSI) e UASP (USB Attached SCSI).
O Caminho Antigo
Ao converter diferentes protocolos em comandos SCSI, a Microsoft unificou os comandos de armazenamento em níveis mais altos do sistema operacional. No entanto, isso sacrificou muitas das melhorias de escalabilidade e desempenho das arquiteturas de armazenamento modernas. O caminho antigo para operações de E/S era o seguinte:
- As operações de leitura e gravação ocorrem na camada superior de armazenamento, no nível do sistema de arquivos.
- Os comandos são passados para o driver Disk.sys.
- O Disk.sys traduz comandos genéricos de armazenamento em comandos SCSI.
- O Storport recebe os comandos SCSI e os envia para o driver Miniport apropriado (por exemplo, StorAHCI.sys para unidades SATA).
- O driver Miniport correspondente comunica-se diretamente com o dispositivo de armazenamento, traduzindo-o novamente para o formato de comando de armazenamento apropriado.
Outras convenções SCSI, como LUNs (Números de Unidade Lógica) usados para identificar partições de dados em um dispositivo de armazenamento, foram mantidas na pilha de armazenamento do Windows, embora conceitos mais recentes, como namespaces NVMe, já existam há algum tempo (Hands, Worley e Lakhveer Kaur, s.d.).
O novo padrão
A mais recente arquitetura de armazenamento da Microsoft para o Windows Server 2025 habilita novos recursos no Storport e substitui o Disk.sys pelo NVMeDisk.sys, fornecendo uma estrutura escalável, preparada para o futuro e de alto desempenho.
- As operações de leitura e gravação ocorrem na camada superior de armazenamento, no nível do sistema de arquivos.
- Os comandos são passados diretamente do NVMeDisk.sys para o novo código StorMQ dentro do Storport.
- O StorMQ gera os comandos NVMe (ou de outro tipo de armazenamento) apropriados para cada operação de leitura e gravação e os envia diretamente para o próprio hardware.
(Imagem da apresentação de Scott Lee na Conferência de Desenvolvedores da SNIA em 16 de setembro de 2025)
Este novo padrão para operações de unidades no Windows Server 2025 elimina uma camada de tradução e se integra totalmente às filas de comandos de armazenamento em dispositivos NVMe, RAID e HBA. A otimização do sistema de armazenamento do Windows também oferece benefícios adicionais, como a redução do uso de recursos da CPU devido à eliminação da tradução desnecessária de comandos de armazenamento e a melhoria da utilização dos processadores lógicos. A nova arquitetura adota outras especificações do NVMe, como namespaces NVMe e suporte plug-and-play. Ela permite que drivers Miniport de armazenamento específicos do fornecedor ou do tipo de dispositivo sejam criados e "conectados" ao Windows para maior compatibilidade e desempenho com novas classes de dispositivos de armazenamento (Lee, SNIA SDC 2025 – Storage Multi-Queue on Windows, 2025).
Pronto para testar?
Em sua apresentação na Conferência de Desenvolvedores SNIA em 16 de setembro de 2025, Scott Lee revelou que a Microsoft já estava trabalhando em estreita colaboração com fornecedores para desenvolver novos drivers para dispositivos como placas RAID e HBAs. Isso sugere que as melhorias no StorMQ chegarão em breve ou podem já estar habilitadas em muitos dispositivos de armazenamento. O recurso foi anunciado como disponível para o público em geral em dezembro passado, mas a nova pilha de armazenamento é habilitada apenas opcionalmente, exigindo a adição de uma chave de registro. Você pode ler as etapas para habilitá-la no artigo de anúncio do NVMe nativo da Microsoft.
Aviso: Modificar o registro incorretamente pode causar problemas sérios, portanto, certifique-se de testar primeiro em um servidor não crítico. Vários usuários que habilitaram esse recurso relataram problemas com unidades NVMe com a deduplicação ativada. Embora uma correção oficial da Microsoft esteja a caminho, prossiga por sua conta e risco!
Testando NVMe nativo no Windows Server 2025
Nossa plataforma de testes para avaliar o NVMe nativo no Windows Server 2025 (Build do SO 26100.32370) apresentava um servidor com dois sockets SP5 equipado com duas CPUs AMD EPYC 9754 de 128 núcleos. Além dos processadores multi-core, havia também impressionantes 768 GB de memória DDR5 rodando a 4800 MT/s.
Nota: De acordo com Yash Shekar, da Microsoft, uma melhoria provisória não relacionada ao NVMe nativo já foi lançada para o Windows Server 2025, o que pode ter proporcionado um aumento adicional no desempenho da pilha de armazenamento não nativa, diminuindo a possível diferença entre os resultados.
Para avaliar o potencial da nova pilha de armazenamento, utilizamos quinze SSDs NVMe Solidigm P5316 de 30.72 TB com PCIe 4.0 em uma configuração JBOD. É importante notar que o Solidigm P5316 possui uma unidade de indireção de 64 kilobytes, o que significa que os resultados de gravação para tamanhos menores (como testes de 4K) são frequentemente piores do que o esperado. Considerando essa unidade de indireção maior, executamos benchmarks FIO com testes de leitura e gravação para blocos aleatórios de 4K, blocos aleatórios e sequenciais de 64K e blocos sequenciais de 128K para comparar a velocidade geral em diferentes tamanhos de bloco. Também monitoramos o uso da CPU durante os testes para avaliar as alegações da Microsoft sobre maior eficiência.
Destaques
- Aumento massivo da largura de banda de leitura aleatória de 4K e 64K e das IOPS.
- Latência de leitura aleatória reduzida em 4K e 64K
- Reduções significativas no uso da CPU para leituras e gravações sequenciais em diversos tamanhos de bloco.
| métrico | 4K aleatórios | 64K aleatórios | Sequencial 64K | Sequencial 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Não nativo | Nativo | Não nativo | Nativo | Não nativo | Nativo | Não nativo | Nativo | |
| Leia | ||||||||
| Largura de banda (GiB/s) | 6.1 | 10.058 | 74.291 | 91.165 | 35.596 | 35.623 | 86.791 | 92.562 |
| IOPS | 1,598,959 | 2,636,516 | 1,217,176 | 1,493,637 | 583,192 | 583,638 | 710,978 | 758,252 |
| Latência média (ms) | 0.169 | 0.104 | 0.239 | 0.207 | 0.809 | 0.812 | 0.613 | 0.608 |
| Utilização total da CPU (%) | 72.67 | 74.22 | 68.44 | 65.11 | 44.89 | 37.11 | 61.56 | 49.56 |
| métrico | 4K aleatórios | 64K aleatórios | Sequencial 64K | Sequencial 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Não nativo | Nativo | Não nativo | Nativo | Não nativo | Nativo | Não nativo | Nativo | |
| Escreva | ||||||||
| Largura de banda (GiB/s) | 1.803 | 1.756 | 7.654 | 7.655 | 44.67 | 50.087 | 50.477 | 50.079 |
| IOPS | 472,725 | 460,383 | 125,391 | 125,406 | 731,859 | 820,603 | 413,495 | 410,232 |
| Latência média (ms) | 0.992 | 1.028 | 3.814 | 3.816 | 0.399 | 0.558 | 1.022 | 1.149 |
| Utilização total da CPU (%) | 26.00 | 20.67 | 12.22 | 9.33 | 70.44 | 57.78 | 58.44 | 47.33 |
Análise de Resultados
Começando com benchmarks de leitura aleatória de 4K e 64K, observamos velocidades de leitura significativamente maiores, com uma diferença de quase 4 GiB/s entre as pilhas de armazenamento nativas e não nativas (respectivamente) no teste de leitura aleatória de 4K, e um aumento de quase 16.9 GiB/s na leitura aleatória de 64K. Também observamos um aumento considerável nas operações de leitura sequencial de 128K, com nossos testes mostrando um aumento de cerca de 5.8 GiB/s na largura de banda.
Curiosamente, não observamos aumentos significativos em nossos testes de largura de banda de gravação aleatória ou sequencial, com a única diferença notável sendo um aumento aproximado de 5.4 GiB/s em gravações sequenciais de 64K. A maioria dos nossos resultados ficou dentro de uma margem de 100 MiB/s, sugerindo que o desempenho da nova pilha de armazenamento é, no mínimo, consistente com o da antiga nos casos em que não houve melhoria.
Como a taxa de transferência geralmente está correlacionada com a latência, também observamos grandes quedas na latência média de leitura aleatória para os testes de 4K e 64K. Observamos uma redução de 38.46% na leitura aleatória não nativa de 4K, de 0.169 milissegundos para 0.104. Os testes de leitura aleatória de 64K apresentaram uma redução menor, em torno de 13.39%. A latência não mudou drasticamente com as operações de leitura sequencial, mas as operações de gravação aleatória e sequencial mostraram aumentos em todos os casos, apesar da taxa de transferência ser semelhante ou maior.
Além do aumento na velocidade de leitura aleatória, outra tendência interessante revelada pelos nossos testes FIO foi uma redução substancial no uso total da CPU para operações de leitura e gravação sequenciais de 64K e 128K. Os testes de gravação sequencial mostraram as diferenças mais drásticas, com uma queda média de 12.66% no uso da CPU para 64K e uma queda quase idêntica de 11.11% para 128K. O teste de leitura sequencial de 128K que realizamos também apresentou uma redução de 12% no uso, mas apenas uma redução de 7.78% para a leitura sequencial de 64K. Um fator a ser considerado é que, com uma CPU suficientemente rápida, pode haver casos em que ambas as pilhas de processamento (stacks) consigam atingir o potencial máximo do dispositivo de armazenamento; portanto, a taxa de transferência pode não aumentar, mas o uso de recursos da CPU diminuiria.
Takeaways
Embora muitos dos nossos resultados tenham apresentado variações dentro da margem de erro entre execuções após a ativação da nova pilha de armazenamento, conseguimos corroborar muitas das afirmações da Microsoft, incluindo maior largura de banda de leitura com menor latência e redução geral do uso da CPU. Como essa é uma mudança bastante radical em relação à pilha de armazenamento do Windows Server, que já existe há décadas, a Microsoft habilitará o NVMe nativo por padrão no Windows Server vNext. Felizmente, o recurso pode ser habilitado no Windows Server 2025 com uma simples edição no registro ou por meio de uma política de grupo, permitindo que administradores de servidores mais ousados aproveitem a nova pilha já hoje (após reconhecerem os riscos da implementação).
Aguardamos ansiosamente a ativação nativa do NVMe por padrão na plataforma Windows Server e esperamos que os fabricantes de SSDs NVMe, placas RAID e HBAs adotem a iniciativa, pois eles poderão levar as melhorias da Microsoft a um novo patamar!
Referências
Hands, J., Worley, D., & Lakhveer Kaur. (s.d.). Namespaces NVMe. Recuperado em 30 de dezembro de 2025, de NVM Express: https://nvmexpress.org/resource/nvme-namespaces/
Lee, S. (15 de setembro de 2025). SNIA SDC 2025 – Storage Multi-Queue no Windows. San Tomas, CA, Estados Unidos da América: Storage Networking Industry Association. Recuperado em 29 de dezembro de 2025, de https://www.youtube.com/watch?v=dR-DWrmCba0&t
Lee, S. (16 de setembro de 2025). Storage Multi-Queue no Windows: Uma nova pilha para hardware de armazenamento de alto desempenho. Recuperado em 29 de dezembro de 2025, da Conferência de Desenvolvedores da SNIA: https://www.snia.org/sites/default/files/2025-10/SNIA-SDC25-Lee-Storage-Multi-Queue-On-Windows.pdf
Shekar, Y. (15 de dezembro de 2025). Anunciando o NVMe nativo no Windows Server 2025: inaugurando uma nova era de desempenho de armazenamento. (Microsoft) Recuperado em 29 de dezembro de 2025, de Notícias e Melhores Práticas do Windows Server: https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/announcing-native-nvme-in-windows-server-2025-ushering-in-a-new-era-of-storage-p/4477353
Associação da Indústria de Redes de Armazenamento. (s.d.). O que é SCSI? Recuperado em 30 de dezembro de 2025, de Associação da Indústria de Redes de Armazenamento: https://www.snia.org/education/what-is-scsi
Amazon