Storage resources are crucial for storing an application’s data. You should encompass both capacity and performance requirements while designing, implementing, and operating the infrastructure. We will review the most common misconfigurations and/or suboptimal design choices:

• Sizing

Storage resources define two different dimensions of resources – storage capacity and storage performance. While sizing an environment, very often only one of these dimensions, in most cases capacity, will be considered. This approach is a direct path to failure. Even if your SDDC will have enough storage to host your workload, the resulting performance in many cases is inadequate and will lead to lengthy and costly escalations.

When sizing storage, make sure to follow the recommendation of VMware Cloud Sizer (https://vmc.vmware.com/sizer) both in terms of capacity and performance. Double-check your sizing assumptions and tweak them using the advanced sizer if needed.

Figure 11.5 – VMware Cloud Sizer – Sizing Assumptions

• Storage policies

vSAN is very easy and intuitive to manage with storage policies directly in vCenter. There’s no need to work with the storage team, and it’s easy to make changes. However, it could work against you. You could be tempted to use RAID5 for all your workloads and free up more space than you’d get with RAID1. RAID5 has a known performance implication, especially for workloads with predominantly small writes, causing a lot of overhead with RAID5. If the initial sizing has been done with RAID5 configuration, you may not have enough hosts to switch to RAID1 if needed. If you find yourself in this situation, decide whether you can split some of the VMDKs and dedicate small VMDKs to some particular data type – the database transaction log and tempdb are good candidates for such optimizations.