We've had a number of queries recently about how Storage DRS works with certain array based features. The purpose of this post is to try to clarify how Storage DRS will behave when some of these features are enable on the array.
The first thing to keep in mind is that Storage DRS is not going to recommend a Storage vMotion unless something is wrong on the datastore; either it is running out of space, or its performance is degrading.
Let's now look at the interoperability:
1. Thin Provisioned LUNs
If the array presents a Thin Provisioned LUN of 2TB which is backed by only 300GB physical, is Storage DRS aware of this when we make migration decisions? In other words, could we fill up a Thin Provisioned datastore if we choose it as a destination for a Storage vMotion operation, and it is already quite full?
Although Storage DRS is not aware that the LUN is Thin Provisioned, it still should not fill it up. The reason why is that in vSphere 5.0, a new set of VAAI features for Thin Provisioning were introduced. One of these features was to surface an alarm in vCenter when a Thin Provisioned datastore became 75% full on the back-end. If a datastore has this alarm surfaced, then Storage DRS will no longer consider it as a destination for Storage vMotion operations. This should prevent a Storage vMotion operation from ever filling up a Thin Provisioned datastore. In this case, if the 2TB Thin Provisioned datastore has 225GB of its 300GB already used, the alarm would be surfaced and Storage DRS would not consider placing any additional VMs on it.
2. Deduplication & Compression
Many storage arrays use deduplication & compression as a space efficiency mechanism. Storage DRS is not dedupe aware, but this shouldn't be a cause for concern. For instance, if a VM is heavily deduped, and Storage DRS recommends it for migration, Storage DRS does not know that the VM is deduped. Therfore the amount of space reclaimed from the source datastore will not be the full size of the VM. Also, when the VM is moved to the destination datastore, the VM will have to be inflated to full size. Later on, when the dedupe process runs (in many cases, this doesn’t run in real-time), the array might be able to reclaim some space from dedupe, but it will be temporarily inflated to full size first.
But is this really a concern? Let's take the example of a VM that is 40GB in size, but thanks to dedupe is only consuming 15GB of data on disk. Now when SDRS makes a decision to move this VM, it will find a datastore that can take 40GB (the inflated size of the VM). So that's not too much of an issue. What about the fact that SDRS is only going to gain 15GB of free space on the source datastore as opposed to the 40GB that it thought it was going to get? Well, that's not a concern either because if this datastore is still exceeding the space usage threshold after the VM is migrated, SDRS will migrate another VM from the datastore on the next run, and so on until the datastore space usage is below the threshold. so yes, it may take a few more iterations to handle dedupe datastores, but it will still work just fine.
And yes, it would be nice if Storage DRS understood that datastores were deduped/compressed, and this is something we are looking at going forward.
3. Tiered Storage
The issue here is that the Storage I/O Control (SIOC) injector (the utility which profiles the capabilities of the datastores for Storage DRS) might not understand the capabilities of tiered storage, i.e. if the injector hits the SSD tier, it might conclude that this is a very high performance datastore, but if it hits the SATA tier, it might conclude that this is a lower performance datastore. At this point in time, we are recommending that SDRS be used for initial placement of VMs and load balancing of VMs based on space usage only, and that the I/O metrics feature is disabled. We are looking into ways of determining the profile of a LUN built on tiered storage going forward, and allowing I/O metrics to be enabled.
I hope this gives you some appreciation of how Storage DRS can happily co-exist with various storage array features, and how in many ways the technologies are complimentary. While we would agree that some of the behaviour is sub-optimal, and it would be better if Storage DRS was aware of these array based features in its decision process, there is nothing that prevents Storage DRS working with these features. Going forward, we do hope to add even more intelligence to Storage DRS so that it can understand these features, and include them in its decision making algorithms.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage
