Contributed blog post by David Klee, Microsoft Data Platform MVP, VMware vExpert, and Founder, Heraflux Technologies
In version 6.0, VMware introduced a standard called VVols for improved integration and management with storage arrays to improve the efficiency of storage presentation to virtualized environments. Essentially, instead of placing virtual disks on a SAN LUN, where we have to manage the quantity and consumption rates of these disks and what the LUN could support, we can now bridge the gap and remove the LUN out of the equation. The virtual disks are now the base management platform by the array and not the LUN.
Think about this for a minute. All of those fancy bells and whistles that come with the storage array – those things that were really tough to leverage as SQL Server DBAs – are now available for you to leverage.
Many of the tasks that the hypervisor completed in the past, such as virtual disk migrations, disk snapshots, and linked clones, can now be harnessed by the array itself. This means that the overhead – and time to execute – are dramatically reduced, all of which make your SQL Servers more highly available and perform better.
Many of the management tasks for VM admins disappear too. There’s no more choices around which LUN to place the SQL Server objects on, how many to spread apart and balance on different LUNs, or choices around thin or thick provisioning. You just create as needed and it takes care of the rest.
Your average SQL Server VM architecture, in terms of storage configuration, normally looks like this.
Now it is greatly simplified to look like this!
One of the best improvements here is that we’re able to see performance stats per virtual machine disk at the storage layer. We no longer have a LUN to get in the way of seeing what is going on at the server’s volume level. This removal of abstraction is incredible from a performance benchmarking and baselining perspective, as we can now get a much clearer sense all the way through the system stack of the performance characteristics.
The only caveat to all of this is for shared disks for Windows Server Failover Clusters. RDMs are still needed for the time being for SQL Server Failover Cluster Instances because of the way Microsoft requires the disks to be presented. However, once the next version of VMware vSphere is released, it appears that VMware supports SCSI-3 disk reservations. The combination of SCSI-3 disks reservations plus VVols means that this solution will allow for straightforward creation of SQL Server FCI shared disks, which will completely eliminate RDMs. That means your SQL Server failover cluster disk presentation just got much easier, and I just got my weekends back (just kidding).
* Note – this is unconfirmed but referenced in a VMworld 2017 presentation. Please reference here for more details.
Pure Storage
Our friends at Pure Storage have recently released their implementation of VVols with their latest Purity 5.0 release, and I’m especially fond of it.
Pure creates volume groups to encompass the objects that make up the VM.
The individual virtual disks are presented as unique volumes.
Nothing really changes from the front end in vCenter.
Now, from a SQL Server administration perspective, what changes? What goodies can I use to make my life easier?
Snapshots
SQL Server DBAs should almost always be taking VM snapshots prior to major upgrade or patching scenarios to provide a very quick failback strategy if anything goes awry. The impact of snapshots on the performance of the virtual disk is quite high, and the mere presence of a snapshot contributes to elevated VMware CPU Co-Stop times. The impact of committing the deltas back into the virtual disks is incredibly high, high enough to even cause SQL Server outages or failures of availability solutions.
Since a VVol is an array volume, the snapshot is performed at the SAN level and on the backplane of the array. Unlike a VMware snapshot, the VM still runs against the original virtual disks and the array keeps track of the delta blocks. These can be retained much longer than I feel comfortable with VMDK-based snapshots.
See how long that took to create?
The same goes for removing it when your upgrade is complete.
Cloning
This topic is fun. Don’t think about it so much as cloning a server, as cloning a drive. How many times do you back up a production database and restore into a pre-production environment to refresh that environment for development and testing? How long does it take? Hours and hours, right? How much temporary space do you need in the process?
Not anymore.
Imagine doing a 10TB database refresh from prod to dev in just a few seconds! Take the dev database offline, clone a production VVol volume containing a database, re-present it (or refresh it) to the dev server, and bring the dev database back online. It’s just metadata at that point, and the array completes the task almost immediately, so your refreshes happen before you can finish a sip of your favorite caffeinated drink.
Pure even provides sample PowerShell to help you do this operation on their GitHub page.
Check out this video of Argenis Fernandez and Cody Hosterman discussing SQL Server with Pure and VVols.
It gets even easier now with VVols!
Platform Agnostic Portability
One truly unique feature of Pure’s implementation is the fact that these disks are just plain volumes on the array. As such, you can now move from virtual to physical and back with no issues. For those of you with large SQL Servers and don’t trust virtualization, this feature means you can leverage VVols on your physical servers as well! You can also do a virtual to physical migration as well. You’re not locked in to one compute vendor or virtualization platform. It’s just amazing. Cody Hosterman has a great post on all the fun details on this new functionality here.
I’m extremely happy that VVols are getting adopted by the storage hardware vendors, like Pure, and am already implementing them on production systems. All of these features help you, the administrator, get back to being proactive and stop worrying about the little things!
