For this deployment, VSAN will be used to host a VMware Horizon View environment. The View deployment will have non-persistent VMs that rely on App Volumes, UEM, and folder redirection for a layered user persistence.
After reading several books on VSAN, including the brand-new Essential Virtual SAN (VSAN): Administrator’s Guide to VMware Virtual SAN, Second Edition that covers the latest 6.2 release, I’ve decided on this hardware for VSAN:
- Dell PowerEdge R630
- 2 x Intel Xeon E5-2680 v3 (12 core)
- 256 GB RAM
- Chassis with 8 SATA/SAS drives
- 3 PCI-e half-length, half-height slots
- QLogic 57800 (2 x 10GBaseT, 2 x 1GBaseT)
So what’s on the HCL? The 13th gen server itself is on the HCL, so that’s a good start for processor, memory and chipset. The Intel P3700 is also fully supported, a good thing since most of the I/O will hit this drive.
What’s not on the HCL? The PERC card and then Samsung SSDs. I spent a lot of time on forums, Google, and VMware expert blogs on both components. The tl;dr – slight risk but worth it….well I’ll find out soon enough!
PERC H330…why? Honestly, I would have gone with the H730 that’s on the HCL if I hadn’t spec’d these before VSAN came into the discussion. The main reason why it’s not on the HCL is due to its queue depth. VMware recommends a minimum queue depth of 256. The H330 falls at or just slightly below that in tests. Each 850 EVO drive has a queue depth of 16, so the SATA protocol itself is the limitation when it comes to queue depth rather than the PERC. Also, a recent firmware update for the H330 includes VSAN compatibility on the Dell side.
Now for the controversial component on the list: the Samsung 850 EVO. VSAN discussion threads overall disapprove of “consumer” SATA SSDs due to small queue depth, lack of power protection, and reduced durability. Let’s break each one down:
- Small queue depth: important, but it’s not everything. I setup an existing VDI environment running on several 850 EVOs in a RAID 10 and it flies with very low latency. There’s this post featuring a user who had a nightmare scenario with EVO 850s in a hybrid VSAN deployment where the EVOs were used as cache. I had a similar issue with crazy high latency until running into this thread suggesting replacement of the ESXi storage driver that literally saved my VDI deployment. That being said, that post was enough to convince me that the SATA SSDs alone probably wouldn’t be able to handle the caching tier.
- Drive reliability: I’ve deployed production VDI environments on Samsung 830, 840, and 850 SSDs. Not a single drive failed, even with constant recomposition of linked clones. The durability of the 830s and 840s may be questionable, but the 850 EVO is at a whole new level when it comes to durability according to this very in-depth study specifically on the drive.
- Power Protection: okay it’s a risk for sure, especially when silent VMFS corruption can happen. See here and here. Again, SSDs will fail, it’s just a matter of when. Power loss is always a consideration. However, all servers have redundancy power supplies on different sources. Risk is low but not zero for sure. This is why we backup!
Keep in mind, this is all theoretical right now. Actual deployment and testing is the only way to verify that my assumptions are true. Per so many different posts, it’s always recommended to follow the HCL for every component. There’s also a huge benefit to SSDs on the HCL. The Intel one that will be used in this buildout absolutely crushes the 850 EVO in every test and removes bottlenecks caused by SATA and AHCI. Keep in mind, it’s also nearly three times the price and half the capacity of the 850 EVO. In this setup, it’s about being fast, but reasonably fast.