Windows Server 2025 Native NVMe: Tải cấu trúc lại ngăn xếp lưu trữ và kết quả thử nghiệm hiệu năng
Vào ngày 15 tháng 12 năm 2025, Microsoft đã thông báo rằng Windows Server 2025 cuối cùng sẽ áp dụng tiêu chuẩn NVMe một cách gốc (natively) trong kiến trúc lưu trữ của mình. Tuy nhiên, lưu trữ NVMe đã là một định dạng lưu trữ phổ biến trên các máy chủ, máy trạm doanh nghiệp và PC tiêu dùng trong nhiều năm qua, với khả năng tương thích của hệ điều hành được tích hợp sẵn kể từ Windows Server 2012 R2 và Windows 8.1. Với ý nghĩ đó, một thông báo về hỗ trợ NVMe “gốc” có vẻ như không quan trọng hoặc thậm chí không phải là tin tức sốt dẻo, nhưng chúng tôi hứa rằng điều này có nhiều ý nghĩa hơn những gì mắt bạn nhìn thấy.
“Native NVMe” thực sự có nghĩa là gì?
Trong các phiên bản trước đây của ngăn xếp lưu trữ trên các phiên bản Windows dành cho người dùng cá nhân và máy chủ, các lệnh được sử dụng để đọc và ghi dữ liệu, bất kể giao thức của phần cứng bên dưới là gì, đều luôn được dịch sang các lệnh SCSI. Tiêu chuẩn Giao tiếp Hệ thống Máy tính Nhỏ (SCSI) có từ đầu những năm 1980 và được thiết kế để kết nối các thiết bị ngoại vi và ổ đĩa lưu trữ với máy tính (Storage Networking Industry Association, n.d.). Nó là nền tảng của một vài giao thức lưu trữ hiện đại được sử dụng cho các khối lượng công việc khác nhau, bao gồm các giao thức kết nối qua mạng như iSCSI (Internet Small Computer System Interface) và FCP (Fibre Channel Protocol), và các giao diện lưu trữ cục bộ như SAS (Serial Attached SCSI) và UASP (USB Attached SCSI).
Cách tiếp cận cũ
Bằng cách chuyển đổi các giao thức khác nhau thành các lệnh SCSI, Microsoft đã thống nhất các lệnh lưu trữ ở các cấp cao hơn của hệ điều hành. Tuy nhiên, nó đã hy sinh nhiều cải tiến về khả năng mở rộng và hiệu năng của các kiến trúc lưu trữ hiện đại. Đường truyền cũ cho các hoạt động I/O diễn ra như sau:
- Các hoạt động đọc và ghi diễn ra ở ngăn xếp lưu trữ phía trên tại cấp độ hệ thống tệp.
- Các lệnh được chuyển xuống trình điều khiển Disk.sys.
- Disk.sys dịch các lệnh lưu trữ chung thành các lệnh SCSI.
- Storport nhận các lệnh SCSI và gửi chúng đến trình điều khiển Miniport thích hợp (Ví dụ: StorAHCI.sys cho các ổ đĩa SATA).
- Trình điều khiển Miniport tương ứng giao tiếp trực tiếp với thiết bị lưu trữ, dịch nó một lần nữa sang định dạng lệnh lưu trữ thích hợp.
Các quy ước SCSI khác, chẳng hạn như LUN (Số Đơn vị Logic) được sử dụng để xác định các phân vùng dữ liệu trên một thiết bị lưu trữ, đã được chuyển tiếp vào ngăn xếp lưu trữ Windows, mặc dù các khái niệm mới hơn như không gian tên (namespaces) NVMe đã tồn tại được một thời gian khá lâu (Hands, Worley, & Lakhveer Kaur, n.d.).
Tiêu chuẩn mới
Kiến trúc lưu trữ mới nhất của Microsoft dành cho Windows Server 2025 kích hoạt các tính năng mới trong Storport và thay thế Disk.sys bằng NVMeDisk.sys, cung cấp một khung cấu trúc có khả năng mở rộng, sẵn sàng cho tương lai và có hiệu năng cao.
- Các hoạt động đọc và ghi diễn ra ở ngăn xếp lưu trữ phía trên tại cấp độ hệ thống tệp.
- Các lệnh được chuyển trực tiếp từ NVMeDisk.sys đến mã StorMQ mới bên trong Storport.
- StorMQ tạo ra các lệnh NVMe (hoặc loại lưu trữ khác) thích hợp cho mỗi hoạt động đọc và ghi rồi gửi chúng trực tiếp đến chính phần cứng.
(Hình ảnh từ bài thuyết trình của Scott Lee tại Hội nghị Nhà phát triển SNIA vào ngày 16 tháng 9 năm 2025)
Tiêu chuẩn mới này cho các hoạt động của ổ đĩa trên Windows Server 2025 loại bỏ một lớp dịch mã và tích hợp hoàn toàn chính nó với các hàng đợi lệnh lưu trữ trên các thiết bị NVMe, RAID và HBA. Việc tinh giản hệ thống lưu trữ Windows cũng mang lại các lợi ích bổ sung, chẳng hạn như giảm sử dụng tài nguyên CPU nhờ loại bỏ việc dịch lệnh lưu trữ không cần thiết và cải thiện việc khai thác các bộ xử lý logic. Kiến trúc mới áp dụng các thông số kỹ thuật NVMe khác, chẳng hạn như không gian tên (namespaces) NVMe và hỗ trợ cắm-và-chạy (plug-and-play). Nó cho phép các trình điều khiển Miniport lưu trữ dành riêng cho từng nhà cung cấp hoặc loại thiết bị được tạo ra và “cắm vào” Windows để đạt được khả năng tương thích và hiệu năng cao hơn với các lớp thiết bị lưu trữ mới (Lee, SNIA SDC 2025 – Storage Multi-Queue on Windows, 2025).
Sẵn sàng để thử nghiệm?
Trong bài thuyết trình của mình tại Hội nghị Nhà phát triển SNIA vào ngày 16 tháng 9 năm 2025, Scott Lee đã tiết lộ rằng Microsoft đang hợp tác chặt chẽ với các nhà cung cấp để phát triển các trình điều khiển mới cho các thiết bị như card RAID và HBA. Điều này cho thấy những cải tiến đối với StorMQ sắp ra mắt hoặc có thể đã được kích hoạt trên nhiều thiết bị lưu trữ. Tính năng này đã được công bố là khả dụng rộng rãi (generally available) vào tháng 12 năm ngoái, nhưng ngăn xếp lưu trữ mới chỉ được kích hoạt dưới dạng tùy chọn tham gia (opt-in), yêu cầu thêm một khóa registry. Bạn có thể đọc các bước để kích hoạt nó trong bài viết thông báo về NVMe gốc của Microsoft.
Cảnh báo: Việc sửa đổi registry không chính xác có thể gây ra các vấn đề nghiêm trọng, vì vậy hãy đảm bảo thử nghiệm điều này trên một máy chủ không quan trọng trước. Một số người dùng kích hoạt tính năng này đã báo cáo các sự cố với ổ đĩa NVMe khi bật tính năng chống trùng lặp dữ liệu (deduplication). Mặc dù một bản vá chính thức từ Microsoft sắp sửa ra mắt, bạn phải tự chịu rủi ro khi tiến hành!
Thử nghiệm native NVMe trên Windows Server 2025
Nền tảng thử nghiệm của chúng tôi để đánh giá NVMe gốc trên Windows Server 2025 (OS Build 26100.32370) có một máy chủ socket SP5 kép được trang bị hai CPU AMD EPYC 9754 128 lõi. Bên cạnh các bộ xử lý đa lõi là bộ nhớ DDR5 768GB chạy ở tốc độ 4800 MT/s cũng ấn tượng không kém.
Lưu ý: Theo Yash Shekar của Microsoft, một cải tiến tạm thời không liên quan đến NVMe gốc đã được phát hành cho Windows Server 2025, điều này có thể đã cung cấp thêm sự nâng cao cho ngăn xếp lưu trữ không phải gốc, làm giảm mức chênh lệch tiềm năng giữa các kết quả.
Để đánh giá tiềm năng của ngăn xếp lưu trữ mới, chúng tôi đã sử dụng mười lăm ổ cứng SSD NVMe Solidigm P5316 dung lượng 30,72 TB với PCIe 4.0 trong cấu hình JBOD. Một lưu ý quan trọng là Solidigm P5316 có kích thước đơn vị gián tiếp (indirection unit size) là 64 kilobyte, điều này có nghĩa là kết quả ghi đối với các kích thước nhỏ hơn (chẳng hạn như các bài thử nghiệm 4K) thường tệ hơn mong đợi. Xem xét đơn vị gián tiếp lớn hơn này, chúng tôi đã chạy các thử nghiệm hiệu năng FIO với các bài kiểm tra đọc và ghi cho các mức 4K ngẫu nhiên, 64K ngẫu nhiên và tuần tự, và 128K tuần tự để so sánh tốc độ tổng thể giữa các kích thước khối khác nhau. Chúng tôi cũng giám sát việc sử dụng CPU trong quá trình thử nghiệm để đánh giá các tuyên bố của Microsoft về hiệu suất cao hơn.
Các Điểm Nhấn Bản Tin
- Băng thông và IOPS đọc ngẫu nhiên 4K và 64K tăng mạnh mẽ
- Độ trễ đọc ngẫu nhiên 4K và 64K thấp hơn
- Giảm đáng kể mức sử dụng CPU đối với các tác vụ đọc và ghi tuần tự trên nhiều kích thước khối khác nhau
|
Random 4K | Random 64K | Sequential 64K | Sequential 128K | ||||
| Non-Native | Native | Non-Native | Native | Non-Native | Native | Non-Native | Native | |
| Read | ||||||||
| Bandwidth (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 |
| Average Latency (ms) | 0.169 | 0.104 | 0.239 | 0.207 | 0.809 | 0.812 | 0.613 | 0.608 |
| Total CPU Usage (%) | 72.67 | 74.22 | 68.44 | 65.11 | 44.89 | 37.11 | 61.56 | 49.56 |
| Metric | Random 4K | Random 64K | Sequential 64K | Sequential 128K | ||||
| Non-Native | Native | Non-Native | Native | Non-Native | Native | Non-Native | Native | |
| Write | ||||||||
| Bandwidth (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 |
| Average Latency (ms) | 0.992 | 1.028 | 3.814 | 3.816 | 0.399 | 0.558 | 1.022 | 1.149 |
| Total CPU Usage (%) | 26.00 | 20.67 | 12.22 | 9.33 | 70.44 | 57.78 | 58.44 | 47.33 |
Phân tích kết quả
Bắt đầu với các thử nghiệm hiệu năng đọc 4K và 64K ngẫu nhiên, chúng tôi đã quan sát thấy tốc độ đọc cao hơn đáng kể, với mức chênh lệch gần 4 GiB/s giữa các ngăn xếp lưu trữ gốc và không phải gốc (tương ứng) trong bài kiểm tra đọc 4K ngẫu nhiên, và mức tăng gần 16,9 GiB/s đối với bài kiểm tra đọc 64K ngẫu nhiên. Chúng tôi cũng nhận thấy mức tăng khá tốt trong các hoạt động đọc 128K tuần tự, với các thử nghiệm của chúng tôi cho thấy băng thông tăng thêm khoảng 5,8 GiB/s.
Một điều kỳ lạ là chúng tôi không thấy bất kỳ sự gia tăng đáng kể nào trong các bài kiểm tra băng thông ghi ngẫu nhiên hoặc tuần tự, với khác biệt đáng chú ý duy nhất là mức tăng khoảng 5,4 GiB/s trong tác vụ ghi tuần tự 64K. Hầu hết các kết quả của chúng tôi đều nằm trong khoảng chênh lệch 100 MiB/s so với nhau, điều này cho thấy hiệu năng của ngăn xếp lưu trữ mới ít nhất là đồng nhất với ngăn xếp cũ trong các trường hợp mà nó không có sự cải thiện.
Vì thông lượng thường có mối tương quan với độ trễ, chúng tôi cũng đã quan sát thấy mức giảm lớn trong độ trễ đọc ngẫu nhiên trung bình cho cả hai bài thử nghiệm 4K và 64K. Chúng tôi đã thấy mức giảm 38,46% trong tác vụ đọc ngẫu nhiên 4K không phải gốc, từ 0,169 mili giây xuống còn 0,104. Các bài thử nghiệm đọc 64K ngẫu nhiên có mức giảm nhỏ hơn, ở khoảng 13,39%. Độ trễ không thay đổi quá lớn đối với các hoạt động đọc tuần tự, nhưng các hoạt động ghi ngẫu nhiên và ghi tuần tự lại cho thấy mức tăng trên toàn bộ các bài kiểm tra, bất chấp thông lượng tương đương hoặc cao hơn.
Bên cạnh việc tăng tốc độ đọc ngẫu nhiên, một xu hướng thú vị khác được tiết lộ bởi các bài thử nghiệm FIO của chúng tôi là sự sụt giảm đáng kể trong tổng lượng sử dụng CPU đối với các hoạt động đọc và ghi tuần tự 64K và 128K. Các bài kiểm tra ghi tuần tự cho thấy những khác biệt rõ rệt nhất, với mức giảm sử dụng CPU trung bình là 12,66% đối với khối 64K, và mức giảm gần như tương đương là 11,11% đối với khối 128K. Bài kiểm tra đọc tuần tự 128K mà chúng tôi thực hiện cũng ghi nhận mức giảm sử dụng phù hợp là 12%, nhưng chỉ giảm 7,78% đối với tác vụ đọc tuần tự 64K. Một yếu tố cần xem xét là với một CPU đủ nhanh, có thể có những trường hợp cả hai ngăn xếp lưu trữ đều đạt đến tiềm năng tối đa của thiết bị lưu trữ; do đó, thông lượng có thể không tăng lên, nhưng lượng sử dụng tài nguyên CPU sẽ giảm xuống.
Các điểm chính
Mặc dù nhiều kết quả của chúng tôi nằm trong khoảng sai số giữa các lần chạy sau khi kích hoạt ngăn xếp lưu trữ mới, chúng tôi đã có thể chứng thực nhiều tuyên bố của Microsoft, bao gồm băng thông đọc cao hơn với độ trễ thấp hơn, và giảm mức sử dụng CPU trên toàn bộ các bài kiểm tra. Vì đây là một sự thay đổi khá triệt để đối với ngăn xếp lưu trữ Windows Server đã tồn tại hàng thập kỷ của họ, Microsoft trước tiên sẽ kích hoạt mặc định NVMe gốc trong phiên bản Windows Server vNext. May mắn thay, tính năng này có thể được kích hoạt trên Windows Server 2025 bằng một chỉnh sửa registry nhanh chóng hoặc một chính sách nhóm (group policy), cho phép các quản trị viên máy chủ dũng cảm tận dụng ngăn xếp mới ngay từ hôm nay (sau khi đã chấp nhận các rủi ro khi triển khai nó).
Chúng tôi mong muốn được nhìn thấy NVMe gốc được kích hoạt mặc định trên nền tảng Windows Server, và hy vọng nhận được sự đồng thuận từ các nhà sản xuất ổ cứng SSD NVMe, card RAID và HBA, những bên sẽ có thể đưa các cải tiến của Microsoft lên một tầm cao mới!
__________________________________________________
📞 Liên hệ Megacore để được tư vấn cấu hình phù hợp và giải pháp hạ tầng cho doanh nghiệp – hoàn toàn miễn phí
🌐 Website: megacore.net
📧 Email: [email protected]
📲 Hotline: 0345 888 868
Cảm ơn bạn đã tin tưởng và lựa chọn sản phẩm của Megacore. Chúng tôi cam kết mang đến cho bạn những sản phẩm chất lượng và dịch vụ tốt nhất!
