Scenario 2 demonstrates a particularly powerful feature of vSAN: providing a simple mechanism that allows the modification and reconfiguration of differentiated storage service classes over time. For instance, modifying the storage's performance or availability configuration, in order to tune for different application workloads. For vSAN, this is as simple as modifying the storage policy associated with the virtual machine or individual virtual disk, as compared with the traditional Fibre Channel SAN approach.

vSAN provides a way for service providers to easily and rigorously define and automate service-class based provisioning. Policies for service classes can be assigned based on business SLAs or required application service levels. vSAN policies are easy to dynamically change for any given workload, without migration or reconfiguration overhead. This approach through SPBM produces significant efficiencies, and enables service providers to benefit from establishing multi-tiered service levels.

SPBM is an intrinsic part of vSAN, which can help to manage, maintain, and automate provisioning to the point that the manual processes are significantly decreased. In addition, SPBM with vSAN lets service providers identify and immediately modify any initial configuration that fails to meet SLA requirements. This is a process that traditionally involved operational effort from multiple IT silos or administrative teams.

This simplified reconfiguration capability means storage resources can now be dynamically realigned and optimized to serve specific application requirements, across the entire application’s lifecycle. For instance, any changes to the application requirements requires significantly less time and effort to accommodate. Additionally, when tenants wish to differentiate their storage or move applications between test/dev and production, or when an application no longer needs the highest levels of availability, traditionally this could be quite challenging, requiring the movement or migration of physically stored data from one volume to another. In contrast, vSAN allows tenants or service providers to immediately, non-disruptively, and almost effortlessly perform such reconfigurations. 

As a result, the findings are likely to be significant when examining the process of reconfiguring a single application on vSAN, when compared to a traditional Fibre Channel SAN,. The reason for this is that with traditional array-based storage, the process of actually adjusting workload storage tiers or configurations can be a time consuming task. In the vSphere virtual infrastructure, such changes typically occur with VMware vSphere Storage vMotion®, which is far superior to the capabilities of the physical infrastructure, but still requires the movement of data from one volume to another. This process can be slow, have a significant overhead on the array, and can also be slowed down by mismatches in datastore block size. vSphere Storage vMotion is required because it is not typically the case that a storage array can change the service level of a volume without serious reconfiguration.

To provide a comparison for this scenario, we have created an estimate based on the vSphere Storage vMotion time for 4x 25 GB virtual machines across two different datastores, using different block sizes. In this scenario on traditional storage, while the storage stays online during this activity due to the significant data movement required, it is far more disruptive than the transparent nature of a similar event through the modification of a VM-level storage policy performed on a vSAN datastore through the SPBM mechanism.

The vSphere Storage vMotion activities, outlined above, have been estimated at 120 minutes, which varies significantly depending on the array hardware, SAN design and configuration, VAAI support, and disk types, among other things. It might also be possible that during these operations the administrator could perform other tasks and duties. However, in order to provide a simple comparison, in this sample scenario it is assumed that the administrator is monitoring the operations throughout, and is therefore unable to perform secondary tasks.