Announcing support for SATADOM boot drives in Windows Server 2016

This blog post was authored by Scott M. Johnson, Senior Program Manager, Windows Server.

As you are probably aware, Hyper-V was launched way back in Windows Server 2008. It’s been almost a decade of evolution based on customer feedback and most recently our learnings in running Azure. The entire operating system changed because of the hypervisor and many other features were added to support the new norm – applications run on virtual machines today. However, there’s one bit of feedback that we haven’t delivered on… yet.

In a clustered virtual environment, the storage is shared between the multiple nodes, usually in a SAN device, which makes the local drives for the virtualization host almost unnecessary. You still need a local drive for the host operating system itself. For some customers, not having a local drive would be ideal, but they still need a drive to boot and the feedback was that SD cards could be used for that purpose. However, Windows Server has some requirements that SD cards are not able to meet around endurance, performance, and capacity.

Today we are excited to announce the support for SATA-connected Disk-on-Modules (SATADOM) devices as primary boot drives for Windows Server 2016 and future Long-Term Servicing Branch (LTSC) or Semi-Annual Channel releases.

“SATADOM modules show that they can operate in a high I/O environment like Windows Server and they can offer significant savings in the cost of the boot drives, density and power,” says Erin Chapple, General Manager, Windows Server. “Each server node that uses a SATADOM for the boot drive uses less power and enables higher storage density, which lowers the cost of the solution.”

Flash devices that are connected over a high-speed interface, such as SATA or PCI-e, have been supported by Windows Server for many years. In our testing, we have found that not all flash storage devices are created equal. There are three main factors needed to insure proper boot support:

• Endurance: Based on data we collected running VM Fleet workloads, we require a minimum endurance of 0.14 drive writes per day for Server boot devices. This is one order of magnitude above what our endurance data is showing.
• Performance: To ensure that a boot device can handle the necessary IO load, we are requiring that the system run the Private Cloud Simulator (PCS) test for a minimum of five days without the boot drive causing failures. Flash devices not adhering to these designs can cause large latency spikes that can take down a cluster node or cause Windows processes to slow considerably.
• Capacity: To ensure enough room for the OS, its updates, the cluster database, and logging over the five-year lifetime of the server we are recommending a minimum capacity of 128GB. As flash storage degrades, it will rewrite memory pages and mark bad cells as unusable. This causes the drive capacity to steadily trend lower over the life of the device. Overprovisioning is required to withstand the workload over time.

Approved SATADOM devices will be identified by the OEM that sells and supports the solution. Many flash storage devices that have been certified can be found on the Windows Server Catalog, however, they will need to go through additional testing and validation by the server manufacturer. OEMs should validate the quality of their SATADOM modules by running the HLK device.storage tests and must perform a full run of the Private Cloud Simulator (PCS) test in a clustered configuration for a minimum of 5 days without the boot drive causing failures.

While a SATADOM device which meets the requirements outlined in this article has sufficient endurance and over-provisoning capacity to handle typical page file and cluster database usage, if a customer has workloads which are anticipated to result in heavy swapping, or has not configured the server with sufficient system DRAM, it is recommended that the system page file is re-routed to an alternative location. Alternatively, if the system is configured with ample system DRAM, the customer can choose to completely disable the system page file. Further, the DOM module must be connected to an internal SATA port and be tagged as “non-removable”. At some point, we will likely adopt additional specifications, including support for high-write endurance devices such as 3D XPoint.

It’s also important to note that SATADOM devices should be used for the OS Boot. In that case, data drives are either Storage Spaces Direct or traditional SAN or NAS. We continue to evaluate Secure Digital (SD) cards and USB-connected flash drives and hope to include support for these types of drives in the future.

If you haven’t already, join our Windows Insiders program so you can access the new preview build for Windows Server Semi-Annual Channel releases and join the conversation in the Tech Community.