In this blog, I would like to provide some guidance for M.2 form factor SSD as a boot device in the vSAN environment.
I mentioned in my earlier post on vSAN ReadyNode that we do not need any certification for a boot device in vSAN. We have a nicely written KB article which talks about boot device selection criteria based on performance, endurance, capacity and workload characterization for a vSAN environment. You can read the KB here.
Why M.2 SSD
We already discussed vSAN considerations when booting from a flash device here. This blog is an extension of that covering M.2 requirement. If you look into the boot device selection KB article, you will see that there are three different things to be considered in addition to ESXi booting:
- Tracing
- Logging
- Coredump
For a very small deployment with smaller memory footprint, USB/SD card could be a choice. Even though a fewer server hardware has dual SD cards configuration, the biggest challenge with these devices is they are not self-contained meaning you need remote servers to redirect logs, traces and core dumps (using syslog server and net dump collector).
From an SSD perspective, they are self-contained but you lose drive slots (typically two considering mirroring) which is certainly not a good solution for hyper-converged infrastructure (HCI) like vSAN where each server attached local storage slot is precious. They are the primary source of storage for HCI. Moreover, you need to put the boot devices behind a separate controller. It takes away one of your PCIe slots just for a boot device. For HDD, the same story exists.
Lastly, SATADOM is a better choice considering HCI deployment but they generally come in single mode (very few dual mode) and if the device fails, you need to replace it immediately. There is no redundancy built around it. Additionally, the popular SATADOM devices are based on SLC NAND technology driving up the cost for a boot device ( very few MLC based).
With M.2, you can see in the above table that it is no different than other types of SSD devices and are self-contained. It can be used as a boot device as long as the server hardware listed in vSphere HCL has M.2 slots available.
M.2 could be a single or dual device. The advantage of the dual device is that it is mirrored (hardware RAID) which provide additional redundancy to the boot device which we lack in SATADOM devices. They are typically connected to the on-board AHCI controller. It means no additional controller required to provide separation between vSAN datastore and boot device.
Out of all the choices, M.2 SSD fits the need for boot device very well for the vSAN environment.
To conclude, you have many choices (M.2 is one of them) and based on your requirement appropriate device can be chosen. As long as the boot device meets the criteria discussed in the KB, you can use it for vSAN.
For any questions on vSAN hardware, please reach out to vSAN Hardware PM [email protected].
To learn more about vSAN, visit VMware vSAN
